ntpd で時刻同期されない
前から、nptd で「Invalid argument」のエラーがでて、ntpq で調べると同期していないことがよくあった。
sendto(210.173.160.87) (fd=23): Invalid argument: 84 time(s)
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp-b2.nict.go. .NICT. 1 u 4d 1024 0 28.833 -0.974 0.000
ntp-b3.nict.go. .NICT. 1 u 4d 1024 0 28.564 -0.524 0.000
ntp3.jst.mfeed. 133.243.236.20 2 u 4d 1024 0 24.476 -0.475 0.000
*LOCAL(0) .LOCL. 13 l 22 64 377 0.000 0.000 0.001再起動すると正常に同期するが、また何日かすると同じエラーがでて同期していないということが続いたのでちょっと調べた。すると以下のメーリングリストに全く同じ現象の質問があり、回答もあった。
今のNTPDは自ホストのIPアドレスがDHCP等によって変化した場合、再起動が必要なようです。
(http://lists.ntp.isc.org/pipermail/questions/2005-August/006340.html あたりにありました)sendto(x.y.z.w): Invalid argumentというメッセージがログに多発しているようならこの問題かも知れません。対策はインターフェースがアップし直す度にインターフェースの起動スクリプトからNTPDも再起動せよということのようです。
なるほど、こちらのIPが変わるとダメなようだ。
pppoeの再起動シェルにntpを再起動する処理を追加した。これで少し様子を見てみる。
NICの追加
今回いかれたNICはオンボードのNICだったので、新しくNICを追加した。
これまで、外向きは eth0、内向きは eth1 だったが、今回追加して新しく eth2 が出来た。
しかし、iptables などの設定は全て eth1 にしている。これををすべて eth2 にするのはしんどいので、udev の設定ファイルを書き換え、追加したNIC を eth1 に、オンボードのNICを eth1 → eth2 にした。
まず、新しいNICを指す前に eth0、eth1 の MAC アドレスをメモっておく。その後、PCを止めNICを追加する。
再起動すると、新しいNICを認識してくれるので、その MAC アドレスもメモる。
そして起動したら、下記のファイルを開いて、eth1 ←→ eth2 を書き換える。
- /etc/udev/rules.d/z25_persistent-net.rules
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:ab:cd:ef", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:12:34:56", NAME="eth2" ← eth1 を eth2 に書き換える
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:99:99:99", NAME="eth1" ← eth2 を eth1 に書き換える。
また、今回 eth2 は壊れてるので、起動時に up しないようにしておく。
- /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.255.0
broadcast 192.168.0.255
# auto eth2 <b>← コメントアウト</b>この後、再起動して新しく追加した NIC が eth1 で起動していることを MAC アドレスから確認する。
また、通信ができるか確認する。
LANが遅い
１年位前から遅いような気がすると思っていたが、ちょっと前から家のLANがとても遅くなった。ADSL なのに、速度を計測すると600kbps くらいしか出てない。
ちなみに家のLANは以下のような構成。
+----------+ +------+ +-----+
- (internet) --+ PCルータ +------+ ハブ +-------+ PC1 |
| (Debian) | +-+----+ +-----+
+----------+ |
| +-----+
+------------+ PC2 |
| +-----+
:これはおかしいと思い原因を探ってみた。
まず考えられるのが、ケーブルにノイズが乗り、元の回線から遅くなっているケース。しかしPCルータから計測すると6〜7Mbps くらい出ている。
となると、おかしいのはPCルータから各PCのどこかで遅くなっていることになる。
PC1-PCルータ、PC2-internet、PC1-PC2 など色々な組み合わせで測定してみたが、いまいちどこで遅くなっているかつかめない。
PCルータや、LAN 内のPCのTCPウィンドウサイズや、MTU など色々調整してみるが、変化はない。
仕方がないので、tcpdump でパケットをキャプチャしてみた。すると、何か LAN 内のPCからの ack がおかしい。
09:24:02.639406 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: . 518:1542(1024) ack 143 win 5840
09:24:02.639738 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:02.785027 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: . 1542:2566(1024) ack 143 win 5840
09:24:02.785702 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: P 2566:3590(1024) ack 143 win 5840
09:24:02.786033 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:02.821451 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: P 3590:4614(1024) ack 143 win 5840
09:24:02.821772 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:02.822187 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: . 4614:5638(1024) ack 143 win 5840
09:24:02.822466 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:02.967361 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: . 5638:6662(1024) ack 143 win 5840
09:24:02.967691 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:03.003777 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: P 6662:7686(1024) ack 143 win 5840
09:24:03.004105 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 1542 win 9216
09:24:03.004503 IP storage1.flickr.vip.mud.yahoo.com.www > 192.168.0.38.38347: . 1542:2566(1024) ack 143 win 5840
09:24:03.004784 IP 192.168.0.38.38347 > storage1.flickr.vip.mud.yahoo.com.www: . ack 7686 win 12288
1行目で、internet 側から1542 バイト目までのパケットを受けている。2行目でその ack を返している。ここまでは問題ない。
問題は次の行から。internet 側から2566バイト目までを受取ったはずだが、ack は 1542 で返しており、それがその後も続いている。
これは、どこかで 1452:2566 のパケットが落ちてることを示している。
試しにPC1 - PCルータ間である程度大きなパケットを ping で送ってみた。するとやはりパケットロスしていた。
$ ping 192.168.0.1 2000 5 2008 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0 ms 2008 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0 ms ----192.168.0.1 PING Statistics---- 5 packets transmitted, 2 packets received, 60.0% packet loss
他のPCから試しても同じ結果だった。また念のためPCルータ上でパケットをキャプチャしてみると、送受信は5パケットとも処理しているが、PC1上でキャプチャすると、2パケットしか返答がない。
これらの結果から、どうやらPCルータの LAN 向けの NIC の送信バッファがいかれているのが原因のようだ。
NIC を差換えて再度速度を計測するとLAN 内のPCからも6〜7Mbps 出るようになった。
昔、先輩から「ネットワークの障害は、物理層から調べろ」と言われたが、今回のケースは正にそれだったなぁ。
ssh で "Permission denied (publickey)."
ひさしぶりに Debian etch のクライアントを触って、サーバ(こちらも etch)にsshで繋ごうとすると、エラーになった。
$ ssh 192.168.0.1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is c3:9f:be:5a:ff:b1:e0:89:19:2a:15:f3:ae:b3:9c:e4. Please contact your system administrator. Add correct host key in /home/maluboh/.ssh/known_hosts to get rid of this message. Offending key in /home/maluboh/.ssh/known_hosts:1 RSA host key for 192.168.0.1 has changed and you have requested strict checking. Host key verification failed.
これは、今年の5月に発覚したDebianのOpenSSLパッケージの脆弱性にたいする対応をサーバ側のマシンへ行ったために出ている。
Debian JP Project - OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）
上記のページの手順で、パッケージを更新した後、クライアント側のknown_hostsの値を一旦削除してやり、再度接続すればOK。
$ ssh 192.168.0.1 Permission denied (publickey).
と思いきや、エラーになった。ググってみると、ssh のプロトコルがよくないとかいろいろ情報が出てくるが、今回エラーになったのもOpenSSLパッケージの更新によるもの。
クライアント側の公開鍵をssh-keygenで再生成し、サーバ側に登録すれば無事に繋ぐことができた。
読売ジャイアンツ セ・リーグ優勝
最近、金融不安や、円高、株価の記録的下落、生保の破綻など暗いニュースが続くが、昨日もまた一つ暗いニュースが……
て言うか、巨人に7連敗もしていちゃ、そりゃ追いつかれるよ。
阪神が優勝した2003年、2005年といい、最後大失速した去年といい、なんかシーズン後半はダメ虎っぷりが出て困る。クライマックスシリーズは頑張れといいたいが、何となく雰囲気が重いので、中日にもやられるんじゃないかとビクビクしてしまうな。
