More from: linux

特定の相手先からのメールが届かない?

職場の人からタイトルのような問い合わせがあった。
なんでもこちらからメールは届くのだが、それに対する返信がこちらへ届かないとのこと。
他の人からのメールは届くとの事なので、メーラーの設定誤りでは無い。
先方からエラーメールをFAXで送って貰ったのでそれを見ると、
”No delivery mechanism available”
となっている。
これは大抵は送信元のメールサーバが送信先のメールサーバのIPアドレスを引けない場合に発生し、DNSのMXレコードの設定が正しくない場合に発生する。
試しに適当なサーバで「host -a hogehoge.com」としてDNSの設定情報を見ると、案の定MXレコードが設定されていなかった(爆)。
ドメイン名のみでアドレス参照をするとIPアドレスを引くことは出来るので、大抵のメールサーバはそれを利用しているらしいが、件のメールサーバはRFCの既定通りの動作をしているようだ(だからIPアドレスを引け無い)。

問題はDNSの設定をしたのが私では無いので、設定を直すことが出来ないということだ。
設定した人間は上に書いたようなことを理解してくれるのだろうか???

←クリックしてくれると嬉しいです。

LANカードがやられるとは”想定外”だった

今日の朝早くにビルの電気工事(点検?)が入るとかで、昨日の内に連絡が入った。
そのビルにはPCをベースにしたサーバを2台置いてあり、停電に備えてUPSを設置してあるが悪いことにバッテリーが寿命で交換用バッテリーを注文したばかり。
しかも停電予想時間が30分ほどなのでUPSに頼るわけにはいかない。
なので、昨夜の営業終了後にサーバー2台の電源を切りに行き、翌朝出勤してきた人に電源を入れるように頼んできた。
さらに2台の内1台は以前電源を再投入したときに素直に起動しなかったことがあるので、念のため電源を入れたら連絡して貰う様に頼んできた。
今朝になって電源を入れたとの連絡があったので、そのサーバに向かってpingを打ち始めたが20分以上経過してもpingが返ってこないので、これは起動途中でハマっているなと思い現地に行った。
現地に付いてコンソールを見ると恐れていたHDDのエラーは出ていなかったが、その代わりLANインターフェースが応答してこないとのエラーが出ていた。
つまりpingに対する応答が無かったのはLANカードが正しく動作していなかったためだったのだが、何故正しく動作していないのかは不明。
とにかくネットワークに繋がらないとサーバの存在する意味が無いので、代わりに同じ型番のLANカードを複数用意して再度現地に行き交換してみた。
用意したのが手持ちの中古品だったせいか最初に交換した1枚はドライバすらロードされず使えない状態。
少々焦ったが用意した別のカードに再度交換したところ無事にドライバがロードされネットワークにも接続できた。
今回トラブったサーバは全体的に古いもので、今でも動作していること自体が不思議なくらい。
#CPUがPentiumIIIの550MHzというくらい古いが、電源ユニット以外は無交換。
それでも稼働中は特に問題を起こさないのでそのまま使っていたが、まさか電源の再投入でLANカードが死ぬとは思っていなかった。
幸い同じLANカードが何枚か手元にあったので復旧させることが出来たが、今後はなんらかの対策を講じないとならないなぁ。

←クリックしてくれると嬉しいです。

未だに4800bpsなのか・・・・・・

PC用のGPSレシーバ(I-O DATA 高感度USB接続GPSレシーバー「NAVI CLIP」 UMGPS/MF
)の仕様を見ていると、PCへのデータ転送速度が4800bpsとなっている。
この製品はUSB接続の製品なのだが、昔のRS-232C接続の製品もこの速度だったので、未だに変わっていないようだ。
10年ほど前にDebian GNU LinuxをベースにGPSレシーバとFOMA端末を接続した小型システムを開発したことがあるが、その際GPSレシーバとの通信速度が4800bpsというのがネックになった。
というのは当時でもLinuxのシリアルドライバで設定できるRS-232Cの通信速度は9600bpsが最低で、それ以下の速度に設定することが出来なかったため。
ハードウェアとしては16550A互換のUARTなので、150bpsといった低速の通信速度にも対応しているが、Linuxのシリアルドライバがそれに対応していないために、そのままでは4800bpsでの通信が出来ない。
16550Aの通信速度は2バイトのレジスタの内容で決定されるが、Linuxのドライバはその内の1バイトしか書き換えないらしい(9600bps以上ならそれでも設定可能)ので、プログラムで該当のレジスタ(分周レジスタ)を直接書き換えるようにして4800bpsでの通信を可能にしてGPSレシーバから座標データを読み込めるようにした。
この時はC言語でプログラムを書いていたが、レジスタを直接書き換えるのには「outb」関数を使った覚えがある。
#outb(0x80,レジスタのアドレス)ってな感じで。
つか、こんなプログラムを書かないと使えないデバイスってどうよ?と思ったのは内緒(笑)。

似たようなことを一昨年にも書いていた(汗)
「Windows用ddコマンド」

←クリックしてくれると嬉しいです。

ネットワークの分離

職場のネットワークを分離するのに安いブロードバンドルーターを買ってきて試したが、あっさりと分離できてしまった。
単にルーターの設定で「アドレス変換をしない」「WAN接続はIPアドレスを手動で設定」の2点を設定しただけ。
あとは元のネットワーク上に存在するサーバ類にstatic routeを設定すれば今までどおりにサーバーへのアクセスも可能だし、プリンタへの印刷も問題なく行えた。
サーバーへのstatic route設定は最初に手動で行い、再起動後も設定がされるように設定ファイルにも書いておいた。
linuxでのroute設定は、
/sbin/route add -net 192.168.xxx.0/24(追加したネットワークアドレス) gw 192.168.yyy.zzz(ルーターのIPアドレス)
設定ファイルは
/etc/sysconfig/static-routes
なので、そのファイルに
any net 192.168.xxx.0 netmask 255.255.255.0 gw 192.168.yyy.zzz
の記述を追加すると、起動時に自動でルーティング情報が設定される。
もしもこのファイルが無ければ新しく作ればOK!

ちなみに今回使ったルーターはこれ。
BUFFALO BBR-4MG 有線BroadBandルータ BroadStation エントリーモデル
B0000DJLOE
2千円ちょっとで買えるけど、複雑なルーティングとかをせずに、単にネットワークを分離するくらいならばそこそこ使えると思う。

←クリックしてくれると嬉しいです。

printcapの書き順で変わるのかな?

職場のプリンタを一台ネットワークプリンタに替えた。
今までLinuxサーバのパラレルポートに直結していたプリンタが不調になり、買い換えたプリンタがUSBとLANのポートしか持っていないので、仕方なくネットワークで接続することになった。
で、Linuxサーバ側のprintcapをリモートプリンタ対応に修正(問題なく印刷されているもう一台のプリンタ用の設定をコピーしてきて、リモートホスト名とスプールディレクトリ名を書き換えた)してlpdサービスを再起動したが、印刷がされない(あれ?)。

今まで他所ではこれで良かった筈なんだけど、今回は何故か素直に印刷されない。
lpc status lp
を実行してみるとスプールには溜まっていて、リモートホスト(この場合はプリンタのネットワークインターフェース)にデータを送信しているとなっているが、プリンタ側のjobランプは消灯したままなので、データは送られていない。
lpd restart lp
を実行すると印刷されたので、どうやらプリンタには異常は無さそうだ。
ここで再度印刷をしてみたが、やはりサーバのスプールに溜まるだけで一向にプリンタにデータが送られない。
しかも今回は
lpd restart lp
としても印刷されず、
/etc/rc.d/init.d/lpd restart
を実行してlpdサービスを再起動し、その後に
lpd restart lp
を実行してようやく印刷された。
うーん、何故?

結局のところ他所のサーバのprintcapの中身を参考にして行の順番を一部入れ替え、
/etc/rc.d/init.d/lpd restart
を実行したところ無事に印刷が出た。
数度印刷を繰り返しても素直に印刷されるので、原因はprintcapの記述にあったようだ。
必要な事項は全て記述しておいたのだが、行の並びも大事だったようだ。
でも、もう一台のプリンタは問題なく印刷されるんだよなぁ、、、、、、何故?

←クリックしてくれると嬉しいです。

Linuxでタイムゾーンの変更を行うには

職場のサーバの時刻が狂っていたので、タイムサーバーに同期させたところ、分と秒は合ったが時がおかしくなってしまった。
あれぇ?と思ってよく見ると、時刻表示の最後の部分が”JST”ではなく”CST”になっている。
このサーバを構築したのは自分では無いのでインストール時にどのような設定を行ったかは知らないが、タイムゾーンが日本では無く、合衆国中部標準時になっている。
これを日本標準時にするのに下記の手順を実行した(全てスーパーユーザーにて実行)。
#cd /usr/share/zoneinfo/Asia
#cp Tokyo /etc/.
#cd /etc
#mv localtime localtime.org(念のためバックアップを取った)
#cp(or mv) Tokyo localtime
要はタイムゾーン情報を合衆国中部標準時用のファイルから日本標準時用のファイルに入れ替えたということ。
なにも実体のファイルを入れ替えなくても、次のようにしてシンボリックリンクを張っても良いと思う。
#ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
というか、こっちのほうがスマートかも。

←クリックしてくれると嬉しいです。

「時計が進まなくなるサーバ」のその後

昨年12/13に書いた記事「時計が進まなくなるサーバ」で取り上げたThinkCentreを転用したサーバーだが、起動オプションに”noapic acpi=off”を付けて再起動してから三週間が経過しても問題無く動作を続けている。
やはりカーネル内部でのハードウェアタイマ割り込みの処理がうまく行っていなかったようだ。
実は年末前にチェックした時も問題無かったので、そのまま年末年始の休みに入ったというわけ。
年が明けても問題が無いようなので、これでこの問題で手を煩わされることも無いかな?

←クリックしてくれると嬉しいです。

先日止まっていたDNSサーバ

先週末の土曜日にサービスが止まっていたDNSサーバに駄目元でリクエストを出したらきちんと名前解決が出来た。
ということは、12/11はなんらかの理由で一時的にサービスが止まっていたということか?
ま、なんにせよ復活してくれて良かった良かった。
だけど、また止まったら困るので、参照順位は最後にしてあるけどね。

←クリックしてくれると嬉しいです。

時計が進まなくなるサーバ

以前から時々時計が止まってしまい、それにともなっていろんなサービスが止まってしまうサーバがあるが、ここ三日間で三度のリブートをする羽目になった。
流石にこのままでは年末年始の休み期間中が不安なので、再度調べてみた。
稼動させているハードウェアがIBMのThinkCentreだということを思い出し、それでググってみた。
というのも過去にThinkPadにLinuxを入れたところ多少のトラブルがあったことを思い出したから。
そうしたところ、数は少ないながらも似たような事象が報告されているのを発見。
複数のサイトで見つけた対処法はapicの無効化というもの。
なので、/boot/grub/grub.conf内の
kernel /vmlinuz/xxxxxxxxxxxxxxxxxxxx の行の最後に”noapic acpi=off”の記述を追加してみた。
リブートしないと結果は判らないが、流石にサービスに支障がない状態で停めるわけにもいかず、明日の早朝に再起動し、その後経過を見ることにした。
これで解決してくれると助かるけどなぁ・・・・・・・・・・

←クリックしてくれると嬉しいです。

いきなりネットに繋がらなくなった(汗)

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分以上もかかってしまった。過去に同じ事例があればもっと早く解決できていたのになぁ、、、、、

←クリックしてくれると嬉しいです。