新規にPCを設定していて出て来たトラブル。
ファイルサーバーに接続させるために”net use”コマンドを使っても”ネットワークパスが見つかりません”と出て接続できない。
ところがサーバー名をIPアドレスにすると問題無く接続できるので、ファイルサーバー側での問題ではない。。
これはDNSサーバーにファイルサーバーのエントリーが無いためだろうということで担当者に追加して貰った。
ところがそれでも同じ現象が発生し全く改善されないので、仕方なくIPアドレスでの接続にしている。
DNSサーバーへの登録ミスだろうと思っていたが、問題のPCからサーバー名でpingを打つとちゃんと名前解決が出来ている。
調べてみると”net”コマンドとpingでは名前解決の方法が異なっていて、Windowsに古くからある”net”系のコマンドはNetBIOS（over TCP/IP）での名前解決、UNIX系OSから来たpingはDNSサーバー（hosts含む）での名前解決だそうな。
道理でDNSサーバーにエントリーを追加してもダメなわけだorz。
これを解決するにはWINSサーバーを立てれば良さそうなんだけど、その際にDNSサーバーとの整合性をどうやってとるかがまだ不明（調べが付いていない）。
うーん、名前解決を複数の手段で行わなければならないのは面倒だから、DNSサーバーに統一してくれなかねぇ・・・
More from: DNS
←クリックしてくれると嬉しいです。
ネットが繋がらない？
今日になって元顧客のところから「ネットが見れなくなった」とSOSが来た。
最初はルーターのせいかと思い再起動をして貰ったとのことだが、それでも解決しなかったらしく再度SOSが来た。
そこのルーターはちょっと高価なルーターで、メーカー保守が切れているので別の製品に買い換えて貰っていた筈だったが、現在その顧客をサポートしている会社の人と話をすると、実は新しいルーターには替えていないとのこと。
なので丁度良い機会なのでルーターを交換して貰うことで話は終った（後はあちらの会社の仕事になる）。
ところが夕方になってから同じルーターを使っている別の元顧客からも同じSOSが入ってきた。
同様にルーターのせいかとも思ったが、業務用のルーターが1日で2台も壊れるとは思えない。
こちらもサポートをしている会社の人と話をするとDNSサーバーの情報がプロバイダ指定のものと異なっていることが判明した。
試しに設定をプロバイダ指定のアドレスに変更したところあっさりと解決。
元々設定してあったアドレスは別プロバイダ（KDDI）のもので、DNSサーバーとして返答を返してくれなかったらしい。
試しに私もそのサーバーに問い合わせを出してみると問題無く名前解決が出来るので、サーバーとして正しく動作しているのはたしか。
では何故元顧客のところでは駄目だったのかな？と思ったら、私の環境ではプロバイダがKDDIだった（汗）。
ということは今までは他のプロバイダを利用しているクライアントからの問い合わせにも応えていたが、今日になって自社の契約者のクライアントからの問い合わせにのみ応えるようになったのかな？
だとすると一軒目も同じ原因だったのかも・・・
後で他のプロバイダを利用しているところから試してみよう。
←クリックしてくれると嬉しいです。
またまたsendmailの設定を見直した
2008年11月18日の記事「sendmail」ではsendmailにDNSサーバを参照させない方法を書いた。
たまたま別のサーバのメンテをしていて、root宛のメールが大量に滞留していたので見てみると宛先のサーバ名が引けないで送信できずに残っているものだった。
しかもこのサーバではsendmailを始めとするMTAが動作しておらず、メールを出そうとしても送信queueに溜るだけだったorz
そこで送信先のサーバ名を/etc/hostsファイルに追加して（ローカル環境なのでhostsファイルに書けば十分）、MTAとなるsendmailにDNSサーバを参照させないように
hosts files
の一行だけを書いた
/etc/service.switch
ファイルを準備し、sendmail.cf内の
#O ServiceSwitchFile=/etc/service.switch
の行頭の”#”を削除（コメントアウトを外）して有効化し、sendmailを再起動した。
これで件のサーバが出力するメールは無事に目的のサーバに届くようになった筈だったが、最初は正しく設定したはずが何故かきちんと配送されずに「？？？」だった。
そこでsendmail.cfを見直すとservice.switchファイルの場所を間違って記述していた。
再度sendmail.cfを修正してsendmailを再起動したところ無事に届くようになった。
←クリックしてくれると嬉しいです。
MXレコードの設定が終わったようだ
昨日書いたMXレコードを設定していないDNSサーバは昨日の内に設定が完了したようで、nslookup -type=mx hogehoge.comで見ても、host -t mx hogehoge.comで見てもMXレコードが見えるようになった。
これでメールの送信元に昨日のようなエラーが返ることもなくなるだろう。
それにしてもDNSサーバの設定をしたのは経験1年のほぼ新人なんだけど、私の「MXレコードが設定されていない」の一言で理解したようなのには少々驚いた。
けっこう出来の良い新人らしい・・・・・・・
←クリックしてくれると嬉しいです。
特定の相手先からのメールが届かない？
職場の人からタイトルのような問い合わせがあった。
なんでもこちらからメールは届くのだが、それに対する返信がこちらへ届かないとのこと。
他の人からのメールは届くとの事なので、メーラーの設定誤りでは無い。
先方からエラーメールをFAXで送って貰ったのでそれを見ると、
”No delivery mechanism available”
となっている。
これは大抵は送信元のメールサーバが送信先のメールサーバのIPアドレスを引けない場合に発生し、DNSのMXレコードの設定が正しくない場合に発生する。
試しに適当なサーバで「host -a hogehoge.com」としてDNSの設定情報を見ると、案の定MXレコードが設定されていなかった（爆）。
ドメイン名のみでアドレス参照をするとIPアドレスを引くことは出来るので、大抵のメールサーバはそれを利用しているらしいが、件のメールサーバはRFCの既定通りの動作をしているようだ（だからIPアドレスを引け無い）。
問題はDNSの設定をしたのが私では無いので、設定を直すことが出来ないということだ。
設定した人間は上に書いたようなことを理解してくれるのだろうか？？？
←クリックしてくれると嬉しいです。
先日止まっていたDNSサーバ
先週末の土曜日にサービスが止まっていたDNSサーバに駄目元でリクエストを出したらきちんと名前解決が出来た。
ということは、12/11はなんらかの理由で一時的にサービスが止まっていたということか？
ま、なんにせよ復活してくれて良かった良かった。
だけど、また止まったら困るので、参照順位は最後にしてあるけどね。
←クリックしてくれると嬉しいです。
いきなりネットに繋がらなくなった（汗）
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分以上もかかってしまった。過去に同じ事例があればもっと早く解決できていたのになぁ、、、、、
←クリックしてくれると嬉しいです。
sendmail
久しぶりにメールサーバの設定の見直しをした。というのも詳細は書けないが、元々ローカルのみで配送していたサーバを外部と接続したせいで、見直しが必要となったからだ。
配送自体はローカルネットワークのみで行いたいので、外部への転送は必要無い（というか配送されると困る）。
最初は送信先のホストを限定しようとしたが、上手い方法が見つからない。
sendmail.cfの記述で可能だとは思うが、どのサイトを見ても直接sendmail.cfを編集するのではなく、ＣＦもしくはm4を使っている。
私も最初だけはm4を使った覚えがあるが、その後は直接sendmail.cfを編集している。おかげでCFやm4の設定ファイルの書き方を忘れてしまった。
さらに直接編集しているので元となった設定ファイルは古すぎて今となっては使えない。
まぁいろいろ調べているうちにsendmailにDNSを使わせない手段を発見した。これを最初から知っていれば苦労してネームサーバなんぞを立てる必要無かったのに。
他のサーバからの名前解決要求が来るのでnamed自体を止めることは出来ないが、sendmailがDNSを使わなくなれば、配送先のMXレコードを引くことも出来なくなって、結果的に外部への配送が失敗することになりそうだ。
実際に/etc/service.switchを作成して試してみると、ローカルの配送は今までどおりに行き、外部への配送は失敗した。
これでこのサーバを使っての外部へのメール送信は出来なくなった。今日はこれに半日かけてしまった、、、、
BGM:最強○×計画、切情！佰火繚乱、妄想ブレイク って、いったい・・・・・・
←クリックしてくれると嬉しいです。