先週末の土曜日にサービスが止まっていたDNSサーバに駄目元でリクエストを出したらきちんと名前解決が出来た。
ということは、12/11はなんらかの理由で一時的にサービスが止まっていたということか？
ま、なんにせよ復活してくれて良かった良かった。
だけど、また止まったら困るので、参照順位は最後にしてあるけどね。
More from: server
←クリックしてくれると嬉しいです。
いきなりネットに繋がらなくなった（汗）
OUTLOOK2003について少々調べ物をしていたところに
「ネットに繋がらないんですけどー」
という問い合わせが入ってきた。
大半のPCはネットへの接続にプロキシサーバを経由しているので、（ここのところ調子が悪いこともあって）早速プロキシサーバの生存を確認したが、問題なく動作している（ように見えた）。
ところがプロキシの動作ログを見ると、要求されたアクセスは全てエラーとなっている。
つまりクライアント側からは全く接続できていない状態ということだ。
エラーの内容を見ると、なんと名前解決が出来ないというもの。
ここでプロキシのプロセスだけが名前解決が出来ないのか、それとも全てのプロセスで名前解決が出来ないのか（つまりnamedで名前解決が出来ないのか）を調べるためにhostコマンドを使ってwww.yahoo.co.jpのアドレスを取得しようとしたが、hostコマンドが終わらない（待ちに入ったままで終了しない）。
つまり、全システム的に名前解決が出来ないということが判明。
最初はネームデーモン（named）自体のトラブルかと思い、いろいろ試してみたが症状に変化が無いので、思い切ってサーバのリブートまでしてしまった（汗）。
ところが、リブートしても名前解決が出来ないままだったので、これは外部に原因があるのではないかと疑い、上位のネームサーバを疑ってみた。
そこで/etc/resolv.confに別のネームサーバのアドレスを追加してnamedを再起動したところ、（時間はかかるけれど）無事に名前解決が出来るようになった。
つまり、参照していた上位のネームサーバが何らかの理由でサービスを停止していたと言う訳だ。
試しに
host www.yahoo.co.jp ”応答が無いネームサーバのアドレス”
としてみると確かに応答してこない。
次に
host www.yahoo.co.jp ”応答のあるネームサーバのアドレス”
とすると即座に
Address: xxx.xxx.xxx.xxx（応答のあるネームサーバのアドレス）#53
Aliases:
www.yahoo.co.jp is an alias for www.ya.gl.yahoo.co.jp.
www.ya.gl.yahoo.co.jp has address 124.83.235.204
と回答が返って来る。
やはり外部のネームサーバが原因だったということだ。
時間がかかるのはファイルの上のほうに書いたサーバに問い合わせを出して、それがダメなら次のサーバに問い合わせを出すためなので、応答が無いサーバの記述をファイルの最後に回したところ、応答速度が改善された。
こんな事象は初めてだったので解決まで30分以上もかかってしまった。過去に同じ事例があればもっと早く解決できていたのになぁ、、、、、
←クリックしてくれると嬉しいです。
CENT OSのインストールCD
RED HAT系のフリーのOSであるCENT OSは現在5.5が最新らしいけど、インストール用のイメージファイルを見てびっくり。
なんとCD-ROMだと7枚にもなるのね、、、、、、
DVDのイメージだとファイル容量が約3.9GBなので、こっちだと一枚で済むけど、最近購入したサーバだとDVDからのインストールで躓くことが多いので、CD-ROMのインストールメディアを作ることにした。
それにしても7枚かぁ、、、、、、、、、、焼くのが面倒だなぁ（爆）
←クリックしてくれると嬉しいです。
トラブルじゃ無かったんだ
昨日接続できなかった札幌市のウェブサイトは、トラブルではなくサーバー室移転作業に伴う工事のための計画的なサービス停止だったとのこと。
今朝になって見てみると、トップページに
札幌市公式ホームページ一時停止のお知らせ 平成22年（2010年）11月27日（土）9時～24時の間、サーバ室の移転作業に伴い、 札幌市役所公式ホームページが停止します。 利用者の皆さまにはご迷惑をおかけいたしますが、ご了承ください。
との記述があった。
でもなぁ、予定していたんだったら、別サーバでも立ててサービス停止中でもこの一文だけは読めるようにしておいて欲しかった。
毎日のようにアクセスするわけでは無いし、必ずしもトップページから入っていくわけでも無いのだから、上記の告知文を目にしない人だって大勢いた筈。
ちょっと不親切だよなぁー、と思った次第だが、機材のトラブルとかクラッキングされたとかでは無かったようで安心した。
←クリックしてくれると嬉しいです。
sambaで繋がらなかったのは（汗）
先日ここに書いたサブネットをまたいで繋がらなかったsambaサーバーはなんとか繋がった。
いろいろと調べてマスタブラウザの設定やら、WINSサーバがどうたらとかの情報が出てきたが、結局のところそんな面倒なことでは無かった。
いろいろ調べた情報を見ながら/etc/samba/smb.confの内容を見ていたら、global sectionにある「hosts allow」で、自分が所属するサブネットと127.0.0.0（自分自身）のアドレスしか書いてなかった。
これは自分が所属するサブネットのクライアントと自分自身からのアクセスしか許可しないということなので、ここに繋げたいクライアントのサブネットを記述することで無事に接続できるようになった。
具体的には
hosts allow = 192.168.1. 127.
となっていたので、これを
hosts allow = 192.168.1. 192.168.2. 127.
のように「192.168.2.」の部分を書き加えたというわけ。
こんな単純なことで週末悩んでいたのはちと恥ずかしいかも（汗）
←クリックしてくれると嬉しいです。
delegatedが起動しなくて悩んだ
職場のサーバの一台が非常に重くてクライアントから接続できないとの連絡があり、試しに自席のPCからログインしようとしたところ、タイムアウトでログインできない。
仕方が無いので現場に行ってみるとディスプレイに一瞬だけログイン画面が表示されたが、すぐにブラックアウトしてしまい状態の確認が出来ない。
かといって放っておく訳にも行かないので、電源SWを押して自動でシャットダウンをさせたが電源が落ちない。
最後の手段で電源SWを長押しして電源を切り、すぐに電源を入れなおしたところ無事に起動したが、やはりログイン画面が一瞬で消えてしまう（ディスプレイには信号が行っている）。
とにかく起動自体は出来たので、近くのPCからログインしてみると問題なく入れた。
これでひとまずは安心と思っていたが、午後になってそのサーバ経由での印刷が出来ないとの連絡が入ってきた。
サブネット間のルーターの役目もしているサーバなので、パケットの中継がうまくいっていないのが原因と思い、試しに他のサーバから反対側のサブネットの特定のホストにpingを打ったが返事が無い。
ということで中継に使っていたdelegatedが起動しているかをチェックしたところ全く起動していなかった。
以前このサーバを扱ったのはかなり前だったので、記憶を頼りにdelegated用の起動ファイルを探し、そのファイルを使って起動してみたが、
NG, this executable is not signed
のメッセージが出て起動しない。
これは以前から良く出ていた現象で、makeし直して実行ファイルを/usr/sbinの下にコピーすればとりあえず動くことを覚えていたので、早速その通りにしたがやっぱり動かない（あれ？）。
いろいろ調べて
/usr/sbin/delegated -Fesign -w
を実行してサインをし直したところ、上記のエラーは出なくなったが、今度は
ERROR: NO ACTIVE PORT
とのエラーでやはり起動しない。
うーーーーん、、、、、、、、、困った・・・・・・・・
で、気付いたのは
「要はパケットフォワーディングが出来ればいいんじゃないか！」
ということ。
で、
/proc/sys/net/ipv4/ip_forward
の中身をチェックすると”1”となっていたので、パケットフォワーディングは有効になっていた。
さらに
/etc/sysctl.conf
の中にも
net.ipv4.ip_forward = 1
と記述されている。
だとすると反対側のサブネットまでパケットは到達しているはず。
あれぇ？おかしいなぁ？と思い、それまで試さなかったホストへpingを打つとしっかり返事が来たorz
なんと複数のIPアドレスに向けてpingを打っていたが、全て動いていないホストだったらしい、、、、、、、
不調の連絡をくれた部署に連絡すると、すでに印刷は出来るようになっているということだった（設定を多少変更したとのこと）。
存在しない問題に1時間以上も時間を費やしてしまった、、、、、、
←クリックしてくれると嬉しいです。
この大量のパケットはなんだろう？
先日からトラブル続きのサーバで、ループバックインターフェース（lo）に異常な量のパケットが流れている。
同様の機能を持たせている他のサーバに比べても非常に多い（100倍近い流量）ので、なにか異常なことが発生しているのかもしれない。
このあたりになにかトラブルの元があるような気がするが、まだ解明できていない。
←クリックしてくれると嬉しいです。
sambaでの接続が回復した・・・・・・・
しばらく前からsambaでアクセス出来ないと言われて預かっていたサーバで、ようやくアクセスが可能になった（と思う）。
正確には起動直後はアクセス可能なのだが、時間が経過するとアクセスが遮断されるようになっていた。
いろいろ調べていてlog.nmbdを見るとマスターブラウザになろうとしてなれないというエラーが出ていた。
同じセグメントにはWindowsサーバもあり、そちらがマスターになっているようでリクエストを遮断しているように思えた。
まぁマスターブラウザにする必要も無いので、smb.confを修正してマスターブラウザにならないようにしたが、それでもエラーは出ていたが、とりあえずこの件は無視。
http://www.samba.gr.jp/ にあった文書を参考に、
smbclient -L サーバ名
でlinuxサーバ自身から接続しようとすると
Receiving SMB: Server stopped responding
session request to “サーバ名” failed (Call timed out: server did not respond after 20000 milliseconds)
とタイムアウトを起こしてしまいアクセス出来無い。
さらにsambaのログにも残らないので、これはリクエストがsmbdに渡っていないということだ。
そこで
netstat -a
コマンドでnetbios-ssn ポートが「LISTEN」状態になっているかを確認すると、それさえ表示されない（あれ？）。
ps -ax
でプロセスを確認すると
smbd -D
は動いているから、その前になにか障害があるようだ。
気になったのは
/var/log/samba/log.nmbd
に停止時のログとして
Packet send failed to 192.168.122.255(138) ERRNO=無効な引数です
というエラーが記録されているが、こんなIPアドレスを設定した覚えは無い。
nmbdが正しく動作しているかを確認するために、
nmblookup -B “サーバ名” __SAMBA__
を実行すると、正しいIPアドレスが帰ってくるから少なくともnmbdは動作していて、リクエストも受け取ってくれている。
次にクライアントのアドレスも返してくれるか、
nmblookup -B 192.168.xxx.255 “クライアントPC名”
を実行すると、こちらもIPアドレスが帰ってくる。
さらにブロードキャストへの応答を確認しようと
nmblookup -d 2 ‘*’
を実行したところ、
added interface virbr0 ip=192.168.122.1 bcast=192.168.122.255 netmask=255.255.255.0
added interface eth0 ip=ｘｘｘ.ｘｘｘ.ｘｘｘ.ｘｘｘ bcast=ｘｘｘ.ｘｘｘ.ｘｘｘ.255 netmask=255.255.255.0
querying * on 192.168.122.255
Got a positive name query response from 192.168.122.1 ( 192.168.122.1 )
192.168.122.1 *<00>
と出力された。
interfaceのeth0は設定してあるが、もう一つの”virbr0″というのは設定した覚えは無い。
ところがこのIPアドレスには見覚えがある。
そう！log.nmbdにあった謎のブロードキャストアドレスと同じネットワークのアドレスだ。
そもそも”virbr0″というinterfaceは設定していないのだが、何故に出て来ているのだろうと思って、”virbr0″でググって見ると、どうも（XENとかで使う）ヴァーチャルマシン用のブリッジデバイスのことらしい。
この”virbr0″というinterfaceはlibvirtをインストールすると勝手に作られるらしく、どうもこれが本来のeth0の邪魔をしている感じだ。
/sbin/ifconfig
でネットワークの設定を見ても立派にネットワークインターフェースとして設定されている。
なので、このインターフェースを
/etc/sysconfig/network-scripts/ifdown virbr0
として止めようとしたが、
使い方: ifdown <デバイス名>
と出てしまい止められない（そりゃそうだ、実在のデバイスでは無いのだから）。
XENをインストールした覚えは無いが念のため
ps -ax | grep xen
としてみたが、当然ながら何も出てこない。
やけっぱちで
ps -ax | grep vir
としてみたら、
2189 ? S 0:00 libvirtd –daemon
というのが出てきたでは無いか。
仮想マシンを使うつもりは毛頭無いので、これを動かす必要も無く、早速止めることにした。
止めるには
/etc/rc.d/init.d/
の下にある”libvirtd”スクリプトを使えば良く、
/etc/rc.d/init.d/libvirtd stop
で簡単に止まった。
そうしたところ、virbr0というインターフェースは消滅し、smbclientでの接続も可能になり、クライアントPCからの接続も可能になった（はぁー、長かった・・・）。
ただ、このままではサーバの起動時に自動でlibvirtdが起動してしまうので、
/sbin/chkconfig –level 345 libvirtd off
として、自動起動を止めた。
しっかし、なんでlibvirtなんて入っていたのかなぁ？
←クリックしてくれると嬉しいです。
無限ループは解決したけど
昨日書いた「Ridoc Document Routerの無限ループ」はなんとか解決した。
今日の朝Ricohに問い合わせたところ、複数の原因が考えられるがとりあえず出来ることを教えてもらえたので、現場に行ってやってみた。
ループに陥る原因としては、受信したデータを処理中にサーバがダウンしたために、処理が中途半端になったデータがあることや、処理するデータが大量にあるために処理に時間がかかり一見無限ループに陥ってしまったように見える場合もあるとのこと（いや、それは判りますがね）。
他には実行ファイルそのもの（Dds.exe）の破損も考えられるということだったが、今回は敢えて考えないことにした。
今回のはIO機器から送ったデータがA4一枚分しか無いことや、サーバを何度再起動しても変化が無いことからデータ量が多過ぎるということが原因とは思えず、やはり処理途中の中途半端な状態のデータがある為に配信サービスのプロセスが処理を終了できないでいると考えた。
そこで処理途中の中途半端な状態のデータを捨てることで正常な状態に復帰するのではないか（いや、「復帰して欲しい」が正解か）と思い、IO機器から送られたデータがどのように処理されるかを教えて貰い、正常に処理がされていればデータが存在しないはずのフォルダにあるファイルを消すことにした。
以降のフォルダ名の先頭の「RidocCab」はインストール時に指定したデータフォルダ名を指すので、ドライブレターやフォルダ名はその指定したものになる(例えばデータフォルダを「C:\Ricoh-data」とした場合は「C:\Ricoh-data\FtpRoot\”機器NO”」のようになる）。
IO機器から送られたデータは、最初に「RidocCab\FtpRoot\”機器NO”」に入り、処理に伴い「RidocCab\DR\Spool\Compose」→「RidocCab\cabinet\WG_Root\”各フォルダ”」の順に移動して行くので、最初の2つのフォルダにはファイルは残らない（筈）。
＃ここで言う”機器NO”とは、各IO機器が持っている固有のNoで、配信管理ツールでFAX配信ログやスキャナー配信ログの”配信元機器”に表示されるNOのこと。
なので、「RidocCab\FtpRoot\”機器NO”」及び「RidocCab\DR\Spool\Compose」内のファイルをフォルダごと消すことにした。
まず最初に作業中にIO機器からのデータを受信しないように、タスクマネージャを使ってDds.exeの動作を止めて配信サービスを終了させた（配信管理ツールからでは停止できなかったため）。
次に念のため「RidocCab\DR\Spool」以下のフォルダとファイルを全て他の場所にバックアップとしてコピーした（幸い「RidocCab\FtpRoot\”機器NO”」以下にはファイルは無かったので「RidocCab\DR\Spool」以下だけで済んだ）。
その後「RidocCab\DR\Spool」以下のフォルダ（「Compose」「Entries」「Error」「JobList」）内のファイルとフォルダを全て削除した。
削除が完了したところでサーバを再起動し、起動後にタスクマネージャで負荷を見たところ、それまでは100%だったのがDds.exeが動作している状態でも数%まで下がっていたので、試しにFAX機からデータを送ったところ無事に指定したフォルダにデータが格納された。
これでなんとかIO機器からのデータを正常に処理することが可能になったが、サーバ自体はHDDにエラーがあって動作が不安定のままなので、早急にHDDを交換して再構築しなくてはならない。
HDDを交換して「EASEUS Drive Copy」を使ってディスク全体をコピーするつもりだけど、エラーのあるHDDを正しくコピーすること出来るのかな？
←クリックしてくれると嬉しいです。
Ridoc Document Routerの無限ループ
先日から調子の悪いRidoc Document Routerサーバをだましだまし使っていたが、昨夜からまた止まっていたようでＦＡＸが受信したデータをサーバに送れずにいた。
ところがサーバ自体のＯＳは起動していたようでpingにきちんと応答を返してくる。
現場のユーザーからもＦＡＸが使えないという問い合わせも無いので、現場に行って確認してみると確かにＯＳは起動している。
クライアントＰＣからRidoc Deskで接続することも出来、配信されたデータを見ることも出来るが、ＦＡＸ機からの接続がうまく行かない様でネットワークエラーの状態が続いていて、受信したFAXデータをサーバに送れないためメモリ残量が20%を下回ってしまった。
受信したFAXを紙に印刷してしまえばメモリを開放することが出来るのだが、悪いことに紙詰まりを起こしていて印刷が出来ない状態。
とりあえず受信したFAXを印刷するために詰まった用紙を取り除き、用紙を補給してなんとか全てを印刷してメモリは開放できたが、相変わらずサーバにはデータを送ることが出来ない。
配信管理ツールでIO機器設定を見てみると何故か同じFAXが2つ登録されていたので、片方を削除して念のためFAX機の設定で配信サーバのアドレスを確認すると案の定クリアされていた。
クリアされていた配信サーバのアドレスを正しく設定しなおすとネットワークエラーは解消されたので、試しに一枚スキャンしてサーバに送ってみると、FAX機からは正常に送られたように見えた。
ところが、サーバの配信ログを見ると全く配信された記録が見当たらず、クライアントからも見えない。
RicohのRidoc Document Routerが受信したドキュメントを処理できずに無限ループに陥ってしまったようだ。
どうも強制的にサーバが停止した時にデータやファイルの整合性が狂ってしまったらしい。
またループに陥ったせいで配信管理ツールからサービスの停止を試みてもサービスが停止しないので、タスクマネージャからDds.exeのプロセスを停止することでようやくサービス停止の状態になった。
かなり以前にも似たようなことがあり、その時はRicohの担当者の方のアドバイスを受けながら復旧させたような記憶があるが、どのようにして復旧させたかが今現在判らない（汗）。
明日にでも再度Ricohに問い合わせてみるかぁ、、、、、、なんかファイルを削除したような気がするんだよなぁ、、、、、
←クリックしてくれると嬉しいです。