現場からサーバの電源に関係する質問が来た。
といっても相手側にはサーバという意識は全く無く、サーバを設置してある場所のものを移動したいけどケーブルを抜いても大丈夫かと言う質問。
「をいをい、なんで移動する必要があるんだよ？」
というツッコミはしなかったけど、訊くと室内の模様替えをしているので、動かして良いかどうかを確認したいとのことだった。
24時間休み無く稼動させているサーバでUPSは付けているけど動作中に移動させると最悪の場合壊れるので、こちらの人間が行って対応するということにしてそれまでは待ってもらうことに。
その現場には先週も行ってきたのだが、その時にはそんな話は全く無かったので、恐らくこの連休中に持ち上がった話だと思われる。
ったく、この忙しい時に勝手な話を進めないで欲しいものだ。
More from: サーバ
←クリックしてくれると嬉しいです。
終わってなかった・・・・・・・・
昨日不調になりHDDをチェック中のサーバで走らせていたfsckは朝になっても完了していなかったorz
I/Oエラーも出ているので最低でもHDDの交換は必要になりそうだ。
つーか今時CPUクロックがMHzで表せるマシンがサーバというのもなんだかなぁ？と。
なので本体ごと交換することになると思われる。
見積りを頼もうと思ったら、販社さんが軒並み休みだという事実に愕然としてしまった。
正月休みは3日までじゃ無いのかよー！（笑）
←クリックしてくれると嬉しいです。
fsckが終わらない・・・・・・・・
不調になったサーバのファイルシステムをチェックしているけど、しばらく経ってもfsckが終わらない・・・・・・
この分だといつまでかかるか判らないから、サーバはそのままfsckを走らせたままにしてそろそろ引き上げるかなぁ？
いくらなんでも明日の朝には終わっているだろう（と思う）。
←クリックしてくれると嬉しいです。
サーバが壊れた（涙）
今日行った現場で搬入したサーバの1台が起動しなくなっていた。
通電すらしない状況なので現場ではどうすることも出来ずお持ち帰りと言うことに・・・・・・・
職場に持って帰ってきて電源ユニットを取り替えてみると電源が入ったので、電源ユニットの故障だった。
ひとまず安心したので本格的に電源ユニットを取り付け、念のためにOS（Linux）を含めてチェックをすることにした。
電源を入れBIOSの設定画面を出すと案の定バックアップ電池が切れていたようで日付等が初期状態になっていた。
日付を初めとして設定を変えている項目の設定をし直して再起動。
無事にOSが起動してくる・・・・・と思いきや自動で走ったfsckがエラーを報告してきて、自動では復旧できないからメンテナンスモードに入って自分でfsckをかけろと言って来た。
仕方が無いのでrootパスワードを入力して手動でfsckをかけたらエラーがたっぷり・・・・・・・・
電源を切る際にどうやって切ったんだ？と思うほど。
仕方が無いのでファイルシステムを復旧しているが結構な量のエラーがあるなぁこりゃ。
しかもI/O errorまで出してくるので、HDDが本格的に駄目になる寸前かも？
数日間寒いところに置いてあったからかもしれないので、しばらくは電源を切らずに放置してみようかな？
←クリックしてくれると嬉しいです。
clockコマンド
linuxでシステム時刻とCPU時刻（BIOSの時刻）は別物であり、起動時はCPU時刻を基準としてシステム時刻がセットされる。
＃linuxに限らずWindowsOSでも同様。
CPU時刻はPCの内蔵時計の時刻だが、この時計が思いのほか精度が悪い（笑）。
なので一度起動するとしばらく止めることの無いサーバの場合、気付くとかなり狂っていることがある。
linuxには時刻を自動で合わせてくれるntpという仕組みが用意されていて、ディストリビューションによってはデフォルトでインストールされる。
これはタイムサーバと呼ばれる時刻の基準となるサーバとシステム時刻を同期してくれる仕組み。
ただ、ntpで修正されるのはシステム時刻だけで、CPU時刻は修正されない。
そのままではシステム時刻とCPU時刻が大きく乖離してしまい、再起動になかなか時刻の同期がされないことにもなりかねない。
多くのシステムではシャットダウン時にCPU時刻をシステム時刻に合わせるように動作するが、これはシャットダウン時に呼び出されるスクリプト内で実行されている。
それでも不意の電源断等でシャットダウン処理がされない場合はCPU時刻とシステム時刻は同期しない。
任意のタイミングでCPU時刻をシステム時刻に合わせるためには”clock”コマンドを使うことになる。
このコマンドはオプションを何も付けないで実行すると現在のCPU時刻を表示してくれる。
システム時刻をCPU時刻に設定するにはスーパーユーザーで
#clock -w
と”-w”オプションを付けてclockコマンドを実行するだけ。
これでCPU時刻とシステム時刻が”ほぼ”一致する（コマンド実行のオーバヘッドがあるので完全に一致はしない）。
長期間動作させるサーバでは一日に一度程度このコマンドを実行するのが良いと思う（crontabに登録すれば簡単）。
←クリックしてくれると嬉しいです。
またまたntpでタイムサーバと同期できないサーバがあった
以前にもntpでタイムサーバと同期できないサーバが有り、なんとか同期を取れるように出来た。
今回久しぶりに触ることになったサーバも時刻同期が取られておらず、1時間近くも時計が狂っていた。
見るとntpデーモンは動作しているが、/usr/sbin/ntpdcで見るとタイムサーバ（ローカル）と同期が取れていない。
設定ファイル（/etc/ntp.conf）を見てもサーバの指定に特に間違いは無かったが、そのサーバ名が/etc/hostsに書かれておらず名前解決が出来ない状態だった（爆）。
「なーんだ、これが原因かぁ」
と思ってサーバ名とIPアドレスを書き加えてntpdを再起動したが相変わらず同期が取れない。
/usr/sbin/ntpdcで確認するとタイムサーバからの応答が来ないようで、”receive timestamp:”の部分がいつまで経ってもオール”０”のまま。
他のサーバからは問題無く指定したタイムサーバと同期が取れているので、タイムサーバ側の問題とも思えない。
不思議なことにntpdateコマンドでは同期できるので、123番ポートが塞がっているとか、パケットがフィルタリングされているとかでも無い。
/usr/sbin/ntpq -p タイムサーバ名
でもタイムサーバ側が親サーバと同期している状態が見える。
なので、プロトコルやネットワークの問題では無く、件のサーバのntpdの問題のように思われる。
ntp.confで指定するセキュリティがきついのかとも思ったが、/etc/ntp.conf内にはそもそも”restrict”で始まる行が無い（全ての接続を許可している状態）。
駄目元でntpのセキュリティ設定を他のサーバと同様に設定してみたがやはり同期できないorz
うーん、一体どうなっているんだろう？
とりあえず大きな狂いはntpdateで直したからもうしばらく悩んでみるかぁ（爆）
←クリックしてくれると嬉しいです。
またまた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を再起動したところ無事に届くようになった。
←クリックしてくれると嬉しいです。
メールが届かない？
仕事で使っているメールサーバから送信したメールが相手に届かない”ことがある”と言われた。
クライアントとして動作しているサーバのログを見ると問題無く送信されたことになっている。
送信用のメールサーバのログを確認しても正しく送信されたことになっている。
気になったのはクライアントからの送信要求から実際に送信がされるまでに20分以上のタイムラグがあったこと。
いろいろ検証してみると、メールサーバの送信キュー（sendmailの場合は/var/spool/mqueue）に大量に未送信メール（ほとんどがSPAMに対するエラーメール）が溜っており、これらが送信プロセスが空くのを待っているために、タイミングによっては送信リクエストが来てもすぐには送信されないことがあるらしいことが判明。
溜っているキューを無条件に削除するわけにもいかないし、対処に苦慮しているところ。
送信用サーバと受信用サーバを分離すればこの問題は解決できると思うが、現状のサーバ構成ではそうもできないところが痛い。
うーん、どうしたものかなぁ？
←クリックしてくれると嬉しいです。
今回は２千通弱だった
時々頼まれてサーバ上に残してあるメールを削除しているが、今日は約２ヶ月振りにやることになった。
いつもは先方から依頼されて実行するのだが、今回はこちらから削除が必要かどうかを尋ねたところ、
「是非やって欲しい！」
と言われた。
それだけならいつものように
fetchmail -Fv
で取得済みのメールを削除するのだけれど、今回は
「古いのだけを消して貰えないか？」
と言われてしまった。
ところが-Fvオプションを付けてfetchmailを実行すると、サーバ上にあるメールのほぼ全てを削除してしまうので、それは出来ないと答えた。
まぁそれでも良いとのことだったので早速実行して２千通弱のメールをサーバ上から削除した。
ヘッダー形式がRFCに則っていない数通が取得されずにサーバ上に残ってしまったが、全てSPAMだったのでnPopを使って削除した（先に「ほぼ全て」と書いたのはこのようなメールが残るため）。
後から考えたら.fetchidsファイルを加工してから実行すればサーバ上にメールを残すことが出来るかな？と思ったが、.fetchidsに書かれていないメールは再取得されるだけなので、やはり選択的にメールを削除するのは困難だということに気付いた。
うーん、なんか良い方法は無いかなぁ？
←クリックしてくれると嬉しいです。
サーバを移設したら（汗）
今日はサーバの内の一台を移設する予定をたてていた。
昨日から関係各所には連絡をしておき、さらに作業1時間前にも再度連絡を入れておいた。
と言っても本運用開始前の試験運用中のサーバだったので、連絡する相手もほんの僅か。
設置場所には事前に必要な配線を済ませておき、後は件のサーバーを一旦停止して運び込むだけとなっていた。
予定時刻になったのでサーバを止め、仮の設置場所から本来の設置場所に持ち込み（重かった・・・）、先に配線を済ませておいた電源ケーブルやLANケーブルを接続して電源を投入。
本来はこれだけで作業は終わりの筈だったが、サーバが起動したは良いがネットワークに接続出来ないorz
さんざん調べて判ったことはLANケーブルの挿し間違いで、それに気付くまで30分程度も悩んでしまった（汗）
＃オンボードのLANポートと増設分のLANポートの設定を勘違いしていたのが原因だったといふ・・・・
これでほぼ予定通りにサービスを再開できることになったので、関係各所に連絡を入れて利用を再開して貰った（中には連絡する前に再開したユーザーもいたけど）。
←クリックしてくれると嬉しいです。