さて、sendmailでメールがうまく届かない問題について再度検証を試みてみた。とりあえず、外部ホストからsmtpポート宛にtelnetとかしてみる。
[fujirushi@somewhere fujirushi]$ telnet fujirushi.hoge.domain 25 Trying 2xx.1xx.xx.xx... Connected to fujirushi.hoge.domain. Escape character is '^]'. 220 fjserv.fujirushi.hoge.domain ESMTP Sendmail 8.11.6/8.11.6; Tue, 4 Mar 2003 23:14:40 +0900 HELO somewhere.else 250 fjserv.fujirushi.hoge.domain Hello somewhere.else [133.53.202.204], pleased to meet you MAIL From:fujirushi@somewhere.else 250 2.1.0 fujirushi@somewhere.else... Sender ok RCPT To:fujirushi@fujirushi.hoge.domain 550 5.7.1 fujirushi@fujirushi.hoge.domain... Relaying denied RCPT To:fujirushi@mail.fujirushi.hoge.domain 250 2.1.5 fujirushi@mail.fujirushi.hoge.domain... Recipient ok DATA 354 Enter mail, end with "." on a line by itself testmail . 250 2.0.0 h24EFVw28640 Message accepted for delivery QUIT 221 2.0.0 fjserv.fujirushi.hoge.domain closing connection Connection closed by foreign host. [fujirushi@somewhere fujirushi]$ |
マニュアルでコマンド発行してみると、どうやらサーバのFQDNを入れれば送信できるらしい。というわけで、症状が確認できたのでGoogle検索をする。結構な数のはずれをつかんだ後に、ここを発見。
どうやら、/etc/mail/local-host-namesにドメイン名を記載しておけば良いようだ。というわけで、さっそくlocal-host-namesを修正してfujirushi.hoge.domainと追加してみる。sendmail再起動後、もう一度テスト。
[fujirushi@somewhere fujirushi]$ telnet fujirushi.hoge.domain 25 Trying 2xx.1xx.xx.xx... Connected to fujirushi.hoge.domain. Escape character is '^]'. 220 fjserv.fujirushi.hoge.domain ESMTP Sendmail 8.11.6/8.11.6; Tue, 4 Mar 2003 23:25:19 +0900 HELO somewhere.else 250 fjserv.fujirushi.hoge.domain Hello somewhere.else [133.53.202.204], pleased to meet you MAIL From:fujirushi@somewhere.else 250 2.1.0 fujirushi@somewhere.else... Sender ok RCPT To:fujirushi@fujirushi.hoge.domain 250 2.1.5 fujirushi@fujirushi.hoge.domain... Recipient ok DATA 354 Enter mail, end with "." on a line by itself testmail . 250 2.0.0 h24EPbW28712 Message accepted for delivery QUIT 221 2.0.0 fjserv.fujirushi.hoge.domain closing connection Connection closed by foreign host. [fujirushi@somewhere fujirushi]$ |
どうやらうまくいきそうである。というわけで、プロバイダのアカウントからfujirushi@hoge.domain宛にメール送信。mailコマンドで確認をしてみるとうまく届いていた。
さて、次はこの状態でのメール不正中継の有無の確認。せっかくメールが届くようになっても不正中継が可能な状態になっていてはしょうがない。確認するのは前回のsendmail設定時にもお世話になったここ。
第三者中継調査(Third Party Relay) - 結果表示????@fujirushi.hoge.domain を担当するメールサーバーの検査結果は以下の通りです。※この検査では実際にはメール本体を送信せず、MAIL FROM, RCPT TOの応答から、第三者中継の可否を判定しております。
「受け取ったことにして、管理者には報告する」等特殊な設定がなされたサーバの場合、
実際には中継を行わないにも関わらず、「不正な中継を受け付ける」旨表示される場合がありますが、
ご了承ください。 相手方の設定によっては、メールを受け取れない場合があります。この問題はSPAMと直接には関係ありませんが、設定を見直すことをおすすめします。 直接配送による試験を続行します。 fujirushi.hoge.domain<<< 220 fjserv.fujirushi.hoge.domain ESMTP Sendmail 8.11.6/8.11.6; Tue, 4 Mar 2003 23:32:40 +0900正常：中継は拒否されました。
合格：
あなたがお使いのMXサーバーは、不正な中継を行わないように設定されています。 |
なぜかMXレコードがまたなくなっている。とりあえずMXレコードなしでもメールはたいがい届くはずだからこのあたりは適当に修正しておこう。
仕事に追われているうちに3月も半ばを過ぎてしまった。というわけで、Yahoo!BBはとりあえず快調に飛ばしている。
っていうか、接続面ではBBフォンがたまに通話中に切れてみたりするぐらいで、特に目立ったトピックはない。
加えて、家庭内サーバのほうだが、とりあえず、
の二つをやってみた。
sambaサーバの方は、publicスペースとhomeディレクトリのエクスポートとかやっておいて、家庭内の共有ファイル(っていうかデジカメのデータ)をこれまでCD-ROMで保管してあったものから移行している。これでいつでもデジカメのデータにアクセスできるようになった。
httpdの方は、とりあえず、
http://fujirushi.hoge.domain/
宛の外部アクセスは拒否するように設定し、
http://www.fujirushi.hoge.domain/
宛のものだけに応答するように設定をしてみた。で、外部アクセスを拒否している
http://fujirushi.hoge.domain/
は、家庭内ネットワークからのみ閲覧できるコンテンツを置いてみていたりしている(っていうか、これまでに作ってあったデジタルアルバムへのリンクがおいてあるだけなんだけど)。
というわけで、ここんとこコンテンツになるような内容はあまりなかったりするのであります(っていうか実際の運用にはいってしまったらサーバってのは大した変化はないんだよね)。
「悲惨な戦争」。
アメリカがイラクに対して空爆を開始した。いろいろと考えさせられることもあるけど、まあ、政治的な話題や私個人の主義主張はここで書く内容ではないような気がするのでとりあえずおいておく。
さて、日本時間の午前中にバグダットに対して始まった空爆に呼応するように米英のサーバに対してサイバーテロが頻発しているというニュースがYahoo!トピックスに出ていた。今は米英だけだが、いずれ同盟国の日本にも波及してくるかもしれないとか書いてある。
というわけで、このところ停滞気味だったサーバのセキュリティパッチの適用状況の確認をしてみると、kernelも含めていくつかのアップデート項目が出てきた。
とりあえずup2date --updateしてみる。サーバが一所懸命に頑張って落としてくるファイルを選別、その後ダウンロードを開始。と、しばし放置しておいたら、なんだかサーバの負荷がでかくなってきたのでdemoユーザーへのサービスは停止したとかなんとかいってダウンロードが打ち切られてしまった(涙)。皆、考えることは同じか…。
しょうがないので落ちてきたものだけでもというわけで、/var/spool/up2dateにあるrpm群をインストールしておくことにする。
glibcとkernelは必要なrpm群が揃っていたので、rpm -Uvhとかいう感じでインストール。kernelのアップデートがあるので一度シャットダウンして再起動。
起動してきたので、確認のためsshでログインを試みる。しかし繋がらない…。
コンソールでログインして様子見をしてみるものの、必要そうなデーモンは起動しているようだ。
と、ふと無線カードに目をやるとpowerランプが点灯していない。ということはpcmciaが死んでいる？
まずは、/etc/init.d/pcmcia startとかして起動を試みるとmoduleがないと怒られる。/proc/versionを確認すると、kernelが一つ古いバージョンになっているようだ。ということはインストール失敗？と不安大増殖。しかし、/bootをみると最新のカーネルしか存在していない。
ちょっと待て、では、この/proc/versionの表示はなんだ？それに、起動はしているのだから、どこかから古いカーネルを読み込んでいるに違いない。ならば、それが起動しないようにliloを再インストールすればいいだろう。というわけで、lilo.confの確認。
あれ？liloの設定はよさそうだぞ。では、mbrへの書き込みに失敗している？ならば、/sbin/liloでどうだ。失敗。書き込めないっていうか、古いバージョンのvmlinuzがないと怒られる。そりゃそうだ、実際/bootには新しいkernelしかないんだもの…ってもしかして、kernelってrpm -Uvhでアップデートしてはいけなかったのではないだろうか…。
もはや後悔先に立たず状態。とりあえずは、lilo.confの再確認。おや？新しいkernelに対するエントリがないぞ。というわけで、lilo.confを新しいkernelで起動するように書き直してmbrに再インストール。これはうまくいった。
さてさて、というわけで再起動。どきどきしながら起動画面を見守る。しばしののちpcmciaが起動。無線LANカードのpowerランプも点灯した。ほっと一息。
そんなわけで、家庭内サーバはとりあえずサイバーテロに対して少しは強固になったのではないかと思っている。
ところで、今日の表題の「悲惨な戦争」って、PPMだったっけ。ちょっとGoogleで調べておこう(笑)。
メモリの増設。
このところ、慌ただしい日が続いていた。前回の更新から仕事の関係で海外にいってみたり、いった先で世話になった知人のうちでサーバにつないで自宅から各種ファイルを回収してみたりなどしていたものの、サーバ自体はこれといって特に変化なく静かにかすかに埃が積もるくらい安定して動いていた。
しかし、そんな日々も年度が変わるに伴いようやく収束してきたので、これまでずっと懸案だったサーバのメモリの増設に踏み切ることにした。
サーバ用にもちいているAL-N2は、EDOのDIMMを要求するのだが、これがきょうびほとんど売っていない。もちろん、Yahoo!オークションでは中古品が売っているだろうが、出品される中古品はもっぱら16MBや32MBで私が希望する64MBのものはほとんどない。とはいえ、抜け道がないわけではない。いくつかの小規模メモリショップがYahoo!オークションで旧型機種に対応した新品メモリを手ごろな値段で販売してくれている。というわけで、そんな中の一つ、VERTEX MEMORYが出品していたEDO-DIMM 64MBの2枚セットを購入。お値段8,680円也。これが本日届いた。
メモリの増設は、特に難しいこともなく、淡々と終了。起動後、BIOSがメモリサイズの変化を検出して警告。保存して再起動すれば完了である。RedHatも無難に起動。とりあえずgnomeを起動してみるが、以前はスワップ多発で使用には耐えなかったものがとりあえず使えるようになっていた。
というわけで、サーバにも少し余裕が出てきたようなので、ぼちぼちまたなにか試してみようかなと思っている。とりあえずはデータベースでも動かしてみようかな。
ntpdの再設定。
最近、ふと気がついたのだが、サーバの時計がテレビの時報とずれている。サーバの内蔵時計はntpdで常時校正してあるはずなので、時刻がずれているということはntpdがきちんと機能していないということを意味している。というわけで、ntpdの設定を見直すことにする。
とりあえず、設定した公開ntpサーバが機能していない可能性を考えて、いくつかの公開サーバを/etc/ntp.confに追加してみた。で、ntpdを再起動するが、なぜか
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) LOCAL(0) 10 l 22 64 177 0.000 0.000 0.015
ntp.hoge.jp 0.0.0.0 16 - - 64 0 0.000 0.000 4000.00
ntp.hanya.edu 0.0.0.0 16 - - 64 0 0.000 0.000 4000.00
|
ってな感じでreachが0のままである。っていうか、たしかにlocalは生きているが外部のサーバとは通信ができていない。とりあえず、ntptimeで該当するサーバが機能しているかを確認してみるが、きちんと反応が帰ってきてどうやら生きているらしい。ということは設定ミスか？
というわけで、もう一度ntp.confを再確認。すると、
# Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. |
とあるところになにも記載されていない。ちなみに、この部分、以前ntpdを設定したときに設定した記憶もない。ってことはこれまで全然ntpdは機能していなかったということか？
というわけで、外部との通信を許可するために、それぞれの公開ntpサーバのIPをnslookupで調べて
# Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 13x.xx.xx.xx #ntp.hoge.jp restrict 21x.xxx.x.xx #ntp.hanya.edu |
というふうに通信可能にする。で、ntpdを再起動。しばし放置しておいたら、
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 21 64 377 0.000 0.000 0.015
-ntp.hoge.jp .GPS. 1 - 14 64 125 28.861 118.149 1.253
*ntp.hanya.edu .GPS. 1 - 18 64 357 31.896 117.531 1.006
|
というふうに無事に正確な時刻を取得してくれるようになった。