2010年12月2日木曜日

ntpqのreachのステータス

時間同期の確認にntpqを使ったときに、peers の reachについてよくわかんなかったけど、調べたら出てきた。
http://www.cisco.com/JP/support/public/ht/tac/100/1007845/ntpassoc-j.shtml

要するに、過去8回のポーリングの結果、同期した->1、同期しなかった->0を書いてるだけなので。
いい状態が全て1=377。8進数ということに気をつけるべき。

そうすると、今どんな状態なのか?ということだが、カンタンに考えるとこんなことになりそうだ。

(1)NTPの同期ができなくなった時の遷移
376 -> 374 -> 370 -> 360 -> 340 -> 300 -> 200 -> 0(同期ロス)

(2)NTPが同期し始めたときの遷移
1 -> 3 -> 7 -> 17 -> 37 -> 77 -> 177 -> 377(全部同期している)

検証はまた後ほど。

2010年8月4日水曜日

時間を少しずつずらす。

たまに、ntpdをかけ忘れたりとかで時間がかなり狂うことがありますが、それを「チョコっとずつ修正」する方法です。
adjtimexというパッケージを使います。

※CentOS (5.4)では adjtimex.(arch)というパッケージがありました。
 # yum install adjtimex
 でインストールできそうです。

使い方ですが、せっかちは人は以下のとおり。タブンrootユーザじゃないとダメです。
# adjtimex --tick (値)
現在の値を確認するときは次のとおり。
# adjtimex --print
値はデフォルト値が10000ですが、この値から大きくすると早く進んで、小さくすると遅れます。
早くしたい場合 : 10001以上
通常        : 10000
遅くしたい場合 : 9999以下
考え方は前の記事のURLを参照となりますが、Linuxの場合0.1μ秒毎に1回割り込みが発生し、この割り込みが10000回で1秒とカウントします。
ですので、上の値を+10とすれば、1ms/1secすすみ、+100とすれば10ms/1sec進ませることができます。
ただしこの割り込みの精度はあまりよくなさそうで、ロードアベレージが高かったりすると途端に狂いだします。
なので、調整するコマンドがあるんですかねぇ。

ハードウェアクロックはJST?UTC?

日本語のBlogなのでローカルタイムの基準はJSTでもいいでしょう(笑)
ハードウェアクロックについてLocalTimeがいいのかUTCがいいのかわからなかったのですが、LinuxのDocumentに書いてありました。

#電化製品のマニュアルは後で読む派なので。

http://www.linux.or.jp/JF/JFdocs/Clock/time-tracking.html

大まかにまとめると
・RTCにローカルタイムを求めるOSとデュアルブートしていればローカルタイム
・Linuxは基本はUTCにしたほうがいい。
・RTCにローカルタイム(上記URLだとDST:サマータイム)を設定すると1時間ずれる。

ふむふむ、OSがローカルタイムのRTCを見る必要があれば、RTCにする、Linuxしか乗っからない場合は、UTCにする。。。というようにとれますね。

上のURLのドキュメントを見ると、UTCが推奨だそうですが、実際のところハードウェアログを見るときに簡略化するために、ローカルタイムを設定していたりしていますかねぇ。。。

どちらにあわせる・・・というのはいろいろポリシーが分かれますが、やはり基本はUTCにあわせたほうがいい気がします。

2010年7月30日金曜日

OCN IPv6にCisco1812Jでつなぐ

手軽なIPv6サービスで固定v6ネットワークがもらえるサービス(&様々な理由で笑)なので、使って見た。
OCN IPv6 : http://www.ocn.ne.jp/ipv6/
300円/月でできるし手軽・・・と思いながらすでに3年くらい放置。
1万円くらいを無駄にしながらも、ようやく今年のGWにCiscoの設定完了~

てか、情報少なすぎ。

苦労して設定したので、そのConfigの一部を公開で。
少しでもv6推進に役に立てばと。

OCN IPv6はすごく面倒。
インターフェース仕様はこちら : http://www.ocn.v6.ntt.net/ocnipv6/pdf/ocnipv6uni_ver1.0.pdf
コレを見ると、要するに

IPv6(DHCPv6) over PPP(LCP+IPv6CP) over L2TP over IPv4 (over ppp over ether)

・・・長いわ。

設定はpseudowireでカプセルプロトコルをL2TPv2で設定、その中にVirtual-PPP1インターフェイスでPPPの認証を通す。
自分で言っててわかってないので、わかる方いれば教えてほしいです。正直、はい。
Wiresharkで解析しながら、DebugLogをとりながらいろいろ試した結果、このConfigでようやく落ち着いた。

ルータモードでOCN IPv6に接続するConfig(抜粋):
l2tp-class ocnv6l2tp
hello 30
hostname (OCNv6のユーザID)
!
ipv6 unicast-routing
pseudowire-class ocnv6
encapsulation l2tpv2
protocol l2tpv2 ocnv6l2tp
!
interface FastEthernet0
no ip address
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet1
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
ipv6 address 2001:380:xxxx:xxxx::1/64
!
interface Virtual-PPP1
no ip address
ipv6 enable
ipv6 dhcp client pd ocnv6
keepalive 60
no cdp enable
ppp pfc local request
ppp acfc local request
ppp authentication chap callin
ppp chap hostname (OCNv6のユーザID)
ppp chap password 7 (OCNv6のパスワード)
ppp direction callout
pseudowire (OCNv6トンネルGW) 1 pw-class ocnv6
!
interface Vlan100
ip address xxx.xxx.xxx.xxx 255.255.255.248
ip tcp adjust-mss 1414
!
interface Dialer1
ip unnumbered Vlan100
ip mtu 1454
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname (フレッツID)
ppp chap password 7 (フレッツPassword)
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
!
dialer-list 1 protocol ip permit
no cdp run
ipv6 route ::/0 Virtual-PPP1
もうCiscoをしばらく触ってなかったから、あってるかどうかもワカラン。
まぁ、つながったから良いんだけど。

間違い箇所があったらコソット教えてください。

2010年7月27日火曜日

zabbixbar for firefox!

NagiosCheckerのようなものでZabbixBarというものがあるらしい。

Zabbix Bar : https://forxa.mancomun.org/frs/?group_id=205
最新版は1.2.2 (2010/07/27現在)だが、FireFox3.6.xとかではそのままでは動かない。

対策は、.zipのもの(ex. zabbixbar_1.2.2.zip)を一度展開してから、

install.rdf : (1.2.2では23行目)
em:maxVersion="3.0.*" />

em:maxVersion="3.6.*" />
に変更して、再度zip圧縮。

拡張子を.zipから.xpiに変更してFirefoxに読み込ませると解決。
いまのところ、なんとなく問題は無い様子。

設定方法は、
 Firefox右下の赤い「Z」を右クリック->preferences
で、URLとID,Passを入力。
URLは最後の「/(スラッシュ)」は要らないらしい。

何かあったら怖いので、現在現用機ではguestアカウントで利用中。

このBlogは・・・

ちょっとにっちな裏技的なところを攻めてきます。