大阪で建設会社を営む社長のボヤキ

電源換装

PCがおかしくなるのは決まって月曜日である。

 

今朝も会社に着いてPCを起動しようとしたらIDEのデバイス認識途中で止まったままになり、起動しなくなった。

 

とりあえずＵＳＢのＨＤＤやら不要な周辺機器を外したりして起動しようと試みたが、今度は内蔵のＨＤＤも認識しなくなった。

 

どうやらとうとう電源ユニットが天に召されたようだ。

 

ひとまず電源ユニットを外そうと、筐体を開けてみた。

 

電源ユニットを取り外すだけで、PCの内部はこんなにもスッキリする。

 

 

取り外した電源ユニットの蓋を開けて、中を覗いてみた。

 

電源ユニットの故障の原因のほとんどは電解コンデンサーの破裂で、破裂したコンデンサーはてっぺんに亀裂が入って中の液体が滲み出している。

 

それを確認するのに蓋を開けて、中の基盤に取り付けられた大小のコンデンサーを確認してみたところ、ポッコリ膨らんではいるが破裂までには至っていないようだった。

 

どこの国で作られているかわからない粗悪なコンデンサーはすぐに破裂してしまうので、こうした電子部品を購入するときはメーカーもさることながら、良質なコンデンサーを使っているかどうかも大きなポイントとなる。

 

この電源ユニットはＡＯｐｅｎ製なのでさほど粗悪な部品は使われていないと思われる。

 

いずれにしても故障の症状から、電源ユニットにほぼ間違いないと思い、新しい電源ユニットに換装することにした。

 

今日は午前中に梅田まで出向く用事があったので、帰りに日本橋にあるPCパーツ専門店に寄って電源ユニットを買って帰ってきた。

 

ＣＰＵがＰｅｎ４　ＨＤＤが４台　光学ドライブが２台　ビデオカードはｎＶＩＤＩＡのＧｅＦｏｒｃｅ６２００なので４００ｗあれば十分であったが、今回はさらに余裕を持たせて５００ｗとした。

 

早速取り付けにかかり、ＨＤＤなどのコネクターに次々に繋いでいった。

 

そして最後にマザーボードにメインのコネクターを挿そうとしたとき、コネクターの形状が違うことに気付いた。

 

 

 

(￣□||||!!　マジ！？

 

 

 

ここ数年の間ＰＣを作っていなかったので、規格が変わっているなんて思いもしなかった。

 

どうしよう・・・

 

途方に暮れながらコネクターを眺めていると、どうやら形状は同じでピンの数が異なっていることに気付いた。

 

もしかしたら互換性ある？　と思い、ネットで調べてみたら、旧規格２０ピンで新規格２４ピンになっていて、互換性があるとのことであった。

 

で、コネクターをよくよく見ると端部の４ピンは外れるようになっていた。

 

 

ということで、いらない４ピンを外し（というかちぎって）旧規格にも使える２０ピンにしてみた。

 

事なきを経て電源ユニットの換装は完了した。

 

 

一度この状態でモニターとキーボードを繋いで起動し、Windowsが正常に作動することを確認した。

 

 

そして今回、買い物ついでにメモリとＳＳＤを購入した。

 

 

ノーブランドのＤＤＲ４００（ＰＣ−３２００）の１ＧＢを二枚挿して、合計３ＧＢに。

 

 

ＳＳＤは近いうちにWindowsをインストールして、起動ドライブにする予定。

 

ちなみに半年前に自宅のＰＣをＳＳＤ化したのだが、ＰＣの起動時間やアプリケーションソフトの起動が劇的に短縮されて驚いた。

 

とりあえずこれでしばらくの間はＰＣのトラブルからは開放されそうである。

 

恐怖のマンデーモーニング

このところＰＣの調子が立て続けにおかしくなってきている。

 

昨夜も自宅のＰＣがフリーズしたり勝手に再起動したりとご機嫌ナナメ。

ブログを書いていたのに消えてしまった

 

 

そして今朝、会社のＰＣを起動しようとスイッチを入れるも無反応・・・

 

何度押してもウンともスンとも言わない

 

をいをい、お前もかよ(;｀O´)o!

 

 

とにかく月曜日の朝はＰＣがおかしくなっている確率が高く、恐怖のマンデーモーニングなのである。

 

 

仕方なく筐体を開けてマザーボードに繋がっているスイッチからのコネクターを抜いて短絡させてみた。

が、やっぱり無反応。

 

多分これは電源だろうとあたりを付けて、電源を外してみることにした。

 

 

ごちゃごちゃに絡まった電源ケーブルのコネクターをハードディスクやＤＶＤドライブから抜くのは至難の業で、余計なコード類に引っ掛けないように慎重かつ大胆に抜いていく。

 

ちなみにこのＰＣにはハードディスク４台とＤＶＤドライブ１台、フロッピーディスク１台が搭載されている。

 

というのも会社のＬｉｎｕｘサーバのバックアップも兼ねているため、どうしても大容量のディスクが必要となるのである。

その分消費電力も大きいため、電源は多少の余裕をもったものを搭載している。

 

 

やっとこさケーブルを外して電源を分解してみたら、案の定ホコリだらけ。

 

まず、掃除機でキレイにして内部を覗いてみたら、コンデンサーが妊娠していた。

 

あ〜　やっぱりかぁ

 

けど、人間で言えば妊娠５ヶ月程度で、破裂もなく中の液も滲み出ていないので、コンデンサーの機能としては損なわれていないはず。

 

騙し騙しであれば何とか使えるはずなので、再度電源を組み立てて起動するか試してみた。

 

とりあえずディスク類にはコネクターを挿さず、マザーボードのみ繋いでスイッチを入れてみた。

 

すると、ウィ〜ンというファンの回転とともにマザーボードからピッという起動音が鳴ったので、どうやら復活したようだ。

 

早速電源を本体に取り付けて、コネクターを元の場所へ挿して、元通りにする。

 

ところが、その作業をしている時に、ねじの存在に気づいた。

ねじが４つ余っている

 

電源のねじだと瞬時に気づいたが、作業の大半は終わっている。

 

別にこのねじがなくても特に問題はないが、精神衛生上よろしくないので付けておく事にした。

 

そして頑張って繋いだコネクターを一旦外し、ねじを取り付けた。

 

コネクターを差込むのは造作のないことだが、写真を見てわかるとおり、ケーブルの取り回しに苦労するのである。

 

適当に取り回してしまうと、ごちゃごちゃがさらにごちゃごちゃになり、最悪の場合コネクターまで届かないことにもなりかねないので、距離の遠いところから出来るだけ絡まないように最短距離で差し込まなければならない。

 

やっとの思いで繋ぎ終わり、後は蓋を閉めて完了である。

 

とりあえず起動はしたものの、またいつ再発するかわからない。

 

そろそろ新しいＰＣが欲しいなぁ〜

 

 

 

またもや発病 NICの入れ替わり

真夏の月曜日は恐ろしい。

 

ウチのサーバは土曜日の深夜から日曜日の朝方にかけてバックアップやらサーバメンテの自動スクリプトが起動するので、非常に負荷が掛かっている。

 

特に夏場は締め切った事務所の中はおそらく４０℃以上にはなっているはず。

 

もし熱暴走でもしようものなら・・・　　あぁ、恐ろしい〜

かと言ってサーバのために一晩中エアコンをかけておくのもためらってしまうこのご時世。

 

心の中で「耐えろ〜！」と祈ることが関の山である。

 

と、前置きはこの辺にして、今日の午前中にサーバが不調を訴えた。

クライアントのWindowsマシンからsambaで構築されたファイルサーバへのアクセスが非常に重く、Excelの小さなファイルでも普段なら瞬時に開くのが今日は1分以上かかっている。

 

とりあえずSWATからsanbaの状態を確認したが、正常であった。

正常であったがとりあえずsambaを再起動して様子を見る事にした。

 

そうこうしているうちに症状はどんどん悪化して、とうとうマウントしているネットワークボリュームが切断されてしまった。

 

ちょっと冷や汗が出てきた。

 

自分のPCからサーバにSSHでログインしようとするが、いつもより反応が遅い。

 

サーバの負荷を確認したところ、ロードアベレージはわずかMAX0.2だった。

 

カーネルの吐き出すログを確認すると、クライアントからのセッション開始要求がきても応答でタイムアウトになっている。

 

なぜタイムアウトになるのか？　　ん〜　ますますわからん。

 

その内インターネットにも繋がらなくなったのでコンソールからログインし、あちこちにpingを叩いてみたところ、ローカルは全部通じているようであったが、外側のルータからはunreachableになっていた。

 

疑わしきは外側のNIC　もしくはルータのI/Fか。

 

とそのときふと２年前の出来事（DNSが遅い！）を思い出した。

 

まさか？　と思いながらも２枚のNICに刺さっているケーブルを入れ替えてみた。

しかし結果は同じ。

もしかしてNICが暑さでイカれたか？

 

ひとまず再起動してdmesgで各NICに割り当てられたMACアドレスを確認して、modprobe.confで設定している値と見比べてみたらきっちり入れ替わっていた。

 

一体何が原因でどのタイミングでこんなことになるのかは全くわからないが、ネットで調べると勝手に入れ替わってしまう現象はよくあるそうだ。

 

それと、今回の不調で再起動したが、uptimeを見たら今日まで465日間稼動していた。

いくら安定稼動しているからと言ってもやはり1年に1度ぐらいは再起動してやるほうがよさそうだ。

 

話を元に戻すと、勝手に入れ替わってしまうことはこの先も発生する可能性は十分あるので、その対処法とやらをここに記す。

 

前回は modprobe.conf に alias を指定するのみだったが、コレは起動時における入れ替わりを防止するための策に過ぎず、恒久的に固定する方法ではない。

 

恒久的に固定するためには、/etc/sysconfig/network-scripts/以下の、

ifg-eth* にMACアドレスを書き加えておけばデバイスマッピングが固定されることになる。

 

一連の手順をおさらいも含めて書いておく。

 

まずターゲットとするNICがどの位置に刺さっているのかを

lspci -v で確認する。

 

/etc/modprobe.confでNICとデバイスをマッピングする。

 

ifconfig eth*　でNICのMACアドレスを確認し、ifcfg-eth* の設定ファイルで

HWADDR=00:11:22:33:44:55

の行を追加してNICにMACアドレスを固定する。

 

ちなみに商用のUNIXではこれが当たり前の設定だそうな。

 

設定ファイルを書き換えたらリブートして疎通を確認する。

 

 

ふぅ〜　結局今日は午後からこれに掛かりっきりになってしまった。

 

 

 

qmail/あて先不明の受信処理

存在しない宛先へのメールが届いた場合の処理方法。

 

設定方法は、各バーチャルドメインのトップディレクトリにある

.qmail-defaultを編集する。

 

①あて先不明でっせ〜　と送信元へエラーを返す。

/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox

 

ごく一般的な設定内容であるが、あて先不明メールのほとんどがスパムでしかもスパムの送信元のほとんどは偽装されているのでいちいちエラーメールを返していると無駄なトラフィックを増大させるだけなので、

 

②知らんぷりして、ゴミ箱に(￣ ￣ )ノ”　⌒＊　ポイッ!イラン と捨ててしまう。

/home/vpopmail/bin/vdelivermail '' delete

 

この方法が無難であるが、サーバ管理者として確認しておきたい！という場合、

 

③あて先不明メールを指定のアドレスへ転送する。

/home/vpopmail/bin/vdelivermail '' [e-mail]

 

④とにかく届いたメールをすべて転送したい場合。

&[e-mail]

 

以上。

 

rsyncのログが文字化け

cronで走らせているrsyncのログが文字化けしていた。

 

kccやnkf --guessオプション　あるいはiconvで調べるとどうやら

ASCIIコードとなっているようだ。

 

ところが、ロケールとして設定しているEUCはASCIIのサブセットに

なるので、nkfやiconv lvを使ってもきちんと変換してくれない。

 

そもそも設定してるロケールの文字コードでログが吐き出されていない

ことがおかしいので、正しい文字コードで出力するようにスクリプトを

変更した。

 

元々はcrontabにてコマンドをフルパスでダラダラと書いていたのを

別スクリプトとして書き直した。

さらにそのスクリプトの１行目に

 

#!/bin/bash

 

２行目に

 

export LANG=ja_JP.eucjp

 

を付け加え、実行コマンドを書いた。

 

いくつかテストしてみると今度はうまく行ってるようで、２バイト文字の

ファイル名でも文字化けせずにログに吐いていた。

 

 

原因はまだはっきりと調べていないが、cronが実行されるときの

実行環境とログインしているときのロケールが異なっているから

だと推測する。

 

なので、cronが実行されるときにもロケールを明示的にしてやる

ことで文字化けを回避できるのではないか、と思う。