qmailの受信が遅い 原因:djbdnsのdnscacheの逆引き?
この数年まったく問題なく、動き続けていたメールサーバが、この数日で受信(pop3)での接続が、極端に遅くなってしました。
通常メールが無ければ瞬時に終わるが、1分程度かかってします。
何とか受信ができるが、このままほっとくわけにはいかず、復旧作業を行った。
環境は、qmailのtcpserverからの、qmail-popup。
/var/qmail/bin/qmail-popup XXXX.XX.XX /home/vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d Maildir
ステップ1
同じサーバ上で動作している、DNSのキャッシュサーバ(dnscache)の再起動
※dnscacheは、djbdns を利用
結果:変わらず(遅い)
ステップ2
vchkpw は、MySQL上のアカウントチェックを行っているため、MySQLを再起動
結果:変わらず(遅い)
ステップ3
supervise でチェックをしている、/usr/bin/tcpserver -v -R -c 200 0 110 /var/qmail/bin/qmail-popup XXXX.XX.XX /home/vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d Maildir
を再起動
結果:変わらず(遅い)
?? 一体どこが悪いのか ??
確認1
/var/log/maillogのvchkpw-pop3のlogin情報を確認
クライアントからメールを読みにいっても、ログ出力がされない。と思いきや、1分後に”login success”!!
予測:アカウントチェック以前が遅い!!
確認2
※nslookup コマンドで、IPの逆引きを行う
結果:遅い!!
わかった!! pop3にアクセスされたIPの逆引きが遅い!!
でも、djbdnsのdnscacheは正常に動作して、正引きは問題なく高速である。
なぜ???? もう、数年使っているのに。その間何もしていないが。
調べようにも、情報がない!
で、本当にそうなのか確認のために、djbdnsのdnscacheは使わずに、GoogleのパブリックDNS(8.8.8.8/8.8.4.4)を使って見ることに。
/etc/resolv.conf
search YY.YY.YY
nameserver 8.8.8.8 ※追加
nameserver 8.8.4.4 ※追加
nameserver 127.0.0.1
その瞬間、瞬間にPOP3の接続ができる。正常な状態に戻る!!
結論:djbdnsのdnscacheの逆引きが正常に動作しない!!
なぜ??
いったん、このままGoogleのパブリックDNSを使って運用を開始する。
qmailで構築している環境で急にメールが送信できない(再発!!)
またしても、qmailで構築しているサーバで急にメールが送信できない状態に陥りました。7月13日今朝の8:00頃から。前回発生した状況とまったく同じ。
早速、一時的にClamdでスキャンさせない設定で、無事できる状態にする。
また、Clamdのバージョンアップをしなければ....
DELL RAID SAS5iRのリビルド
5年以上障害も無く動作していただDELLサーバーのミラーリングの片側のハードディスクが故障し、その交換を実施しました。
RAIDカードは、SAS5/iR
早速その手順を。
前準備
同じディスクを準備、ディスクを全”0"クリアする。
※シーゲートのツール(Seagate DiscWizard)で行う。
故障状態を把握
# mpt-status -i 1 ioc0 vol_id 1 type IM, 2 phy, 298 GB, state DEGRADED, flags ENABLED ioc0 phy 0 scsi_id 32 ATA ST3320620NS G , 298 GB, state ONLINE, flags NONE ioc0 phy 1 scsi_id 255 , 298 GB, state MISSING, flags OUT_OF_SYNC
※物理ディスクそのものが、認識していないことが判明
※注意※ この時の”phy X”の数字は、RAIDカード SAS5/iRの”SlotNum”とは違います!!間違えて正常なディスクを交換すると、全てデータがお釈迦になります。
故障したディスクを交換
・サーバーの電源をOFFし、電源ケーブルを抜き、SAS 5/iRから出ている2本の青いSATAケーブルを確認し、”ID 0”側のディスクを交換する。
※注意※ 間違っても正常なディスクを交換しないこと!!
・サーバーの電源をONし、再度SAS5/iRのBIOSを起動する。
※ここで、自動でリビルド(RESYNC)になると思ったが、ならなかった。
手動でリビルドを実行
上記画面上の”Manage Virtual Disk”を実行する。
※この画面の”Synchronize Mirror”を実行すればよいと思っていたが、選択できず。どうやら、交換したディスクが”Secandary Disk”として認識していないよう。
※”Manage Secandary Disk”を実行し、交換した側のディスクをSecandary DiskとしてYESで選択する。決して、正常側を選択しないこと。画面撮影忘れました。
※選択した瞬間、リビルドが自動でスタート
※しばらく様子をみて、5%ぐらいのところで、BIOSから抜ける。この時REBOOTがかかるがそのまま起動させる。起動画面で一瞬、SYNCしていることがわかる。
リビルド中を確認
# mpt-status -i1 ioc0 vol_id 1 type IM, 2 phy, 298 GB, state DEGRADED, flags ENABLED RESYNC_IN_PROGRESS ioc0 phy 1 scsi_id 32 ATA ST3320620NS G , 298 GB, state ONLINE, flags NONE ioc0 phy 0 scsi_id 0 ATA ST3320620NS G , 298 GB, state ONLINE, flags OUT_OF_SYNC
※リビルドしていることを確認する。
※リビルド中も通常のサービスを提供しています。
迷惑メールになる
このところ、迷惑メールで問合せが多くなった。
その中でも、Hotmail(Liveメール)に送っても迷惑メールにされてしまうとの問合せがあった。
対策として、SPFレコードの見直しと、その後の解除願いをする。
https://support.msn.com/eform.aspx?productKey=edfsmsbl2&ct=eformts
Gmailの添付ファイル容量
Gmailの添付ファイルの容量は、25MBのようです。
LinkStationの復旧方法
バッファローのLinkStationが故障し、ファイルが取り出せなくなった場合、HDDを丸裸にしIDE ATAとUSBを変換する装置(大判振舞 使用)とLinux KNOPPIXを利用してファイルを取り出す方法です。
尚、KNOPPIXは、ファイルシステムにXFSを利用しているため、LinkStationのHDDをマウントすることができる。
ただし、日本語ファイル名が化ける。そのため、単なるファイルコピーだとファイル名が化けた状態のため、FTP経由もしくはSSH(SFTP)経由でコピーすることになる。
【FTP クラインとして】
WindowsにFTPサーバを構築して、knoppix側のncftpからコピー(put)する
−−ディレクトリーを含んだputのパラメータは、”put -R *”となる−−
【FTP サーバとして】
knoppix側でFTPサーバを起動し、WindowsからFTPでコピー(get)する
−−knoppix(LCAT)では、FTPサーバ設定が難しく、断念−−
【SSH】
knoppix側でSSHを起動して、WindowsのWinSCP経由でコピーする
−−knoppix(LCAT)でのSSHの設定方法−−
メニュー −[KNOPPIX]−[Services]−[Start SSH Server]
一番楽なのが、SSH経由でのコピー。ただし、時間がかかる。
追伸:LinkStationでMacで共有していた場合、.AppeDoubleがコピーできない。その場合、スキップする。
またまた1週間で2さいと
デザイナー2人のおかげで、また1週間で2つのサイトのCMSを設定(テンプレート化)を行なった。CMSは得意とすつMovbaleTypeです。
今回、サイトの仕様で、画像ファイルが存在しない場合、指定の画像を出す仕様があり、MovableTypeのプラグインで実装した。使用したプラグインは、IfFIleExistです。
【IfFIleExistのインストール方法】
指定のファイル1つを、pluginsにコピー
【使い方】
・実ファイルの場合
<mt:IfFileExist path="PATH+ファイル名"> <p>ファイル有り<p/> <mt:Else> <p>ファイル無し<p/> </mt:IfFileExist>
・URLで指定の場合
<mt:IfFileExist url="URL+ファイル名"> <p>ファイル有り<p/> <mt:Else> <p>ファイル無し<p/> </mt:IfFileExist>
これでOK。
追伸:2月22日に全MovableTypeがバージョンアップされ、管理しているサイトのバージョンアップで丸一日以上かかった。