CentOS

【 httpd再起動に失敗 】

   Posted on 2012年9月9日

* じつはこれ、Fedora時代のトラブルですが
  CentOSがVer7となり、SystemV形式からsystemdに
  変更されたりもしたので、参考になるかと思い
  こちらに残しました。

珍しく昼寝をしてしまったため、眠気が来ずに
パソに向かってます。

SSLの更新のドメインが一つあったため、
更新手続きをして、証明書を頂いたのですが、
CERTに貼り付けてhttpdを再起動させるとエラーが。^^;;
どんなエラーや!?ってログを覗くと、なにやら
パスフレーズがどぉたらこぉたら・・・
そう言えば、再起動時にパスフレーズを尋ねられないまま
エラーになってしまうんですねぇ。
通常は尋ねられないようにするには、それなりの
細工しなければならないんですけど。
ちょいと閃いて、逆にパスフレーズ尋ねられなければ
行けるかと思い、その細工をしてみました。

#cd /etc/pki/tls/private/ユーザーディレクトリ/
 (プライベートキーを作成したディレクトリに行く)
#/usr/bin/openssl rsa -in ***.key -out ***.key
 (***.key は作成時のプライベートキー名)

今度はエラーもなくhttpdは見事無事再起動!

以前の再起動は

# /etc/init.d/httpd restart

で、細工前ではパスフレーズを尋ねられましたが、
現在の

# systemctl restart httpd.service

で再起動させるとエラーになっちゃうってことですね。
つまり、再パスフレーズを尋ねられないよう細工することが
必須になったってことです。

しかし、ググったところ、同様の再起動でパスフレーズを
尋ねられたという事例もあり、何が違うのかはまだ
判明しておりませぬ。。。
格安のサーバー証明で、実在証明(運用者情報)証明の
ついてないやつだからかなぁ?

SystemV形式からsystemdに変更になってから、こんなん
ばっかりで、いや~な感じ!
htttpの再起動が失敗に終われば、すべてのサイト閲覧や
webアプリケーションが死んでしまうんだから、勘弁して
欲しいよなぁ。

【 サーバーダウン顛末記@あれもこれもぶっ飛んだ・・ 】

    Posted on 2013年3月19日

今年は電源関係が鬼門のようです。

今度はサーバーの電源で使用していたUPSがぶっ飛びました。
バッテリが一瞬ショートしたような大きな音がして、
AC100Vが出力されていません。
いきなり電源が落ちたのですから、ぶら下がっていた2台の
サーバーがおかしくなっていないことを祈って、UPS交換後
スイッチオン・・・

1台は起動しましたがもう1台はブートできるディバイスが
ないと怒られ、全く起動しません。
レスキューモードからや、他のマシンにHDDをぶら下げて
ファイル救済を試みましたが、全く中身が見えません。
ファイルシステムが完全にブッ飛んだのでしょう。

幸運にも拙宅サーバーは、30分おきにユーザー領域を
バックアップしてあるので、新しいマシンにFedoraを入れて
再構築することにしました。

ここで大きな問題が。
ブッ飛んだマシンはFedora17でしたが、すでにFedora18が
リリースされていたので18をインストール。
Webやメールサーバーを設定したあと、あとはユーザー
領域をバリバリコピーするだけで良いはずなのですが、
18のユーザーインターフェイスや設定ファイルのパスが
ガラリと様変わりして、いつものように簡単に、というわけには
いかなくなってしまいました。
設定ファイルの場所を検索しながら、なんとかインストール
・設定をしてみましたが完璧とは程遠く、何かやるたびに
エラーを吐くし、こんな調子でやっていたら復旧に10日も
かかりそうなので、思い切ってFedoraへのこだわりを捨てて
CentOSに鞍替えしました。

CentOSの最新バージョン6.4は、Fedoraの古めのバージョンと
ほぼ一緒なので、問題なく設定できましたが、ブッ飛んだ方の
サーバーにはユーザーが100人近くいて、SSLの認証ドメインも
複数抱えていたので、復旧動作確認だけでもかなりの時間を
要し、すごく焦った作業になったのでイージーミスの連発。
緊急事態ほど落ち着かなきゃダメってことですよね。

大丈夫だと思っていたもう1台ですが、実はまったく
大丈夫ではありませんでした。
メールやWebサーバーなどは活きていたので気づかなかった
のですが、久しぶりに自分のサイトを覗くと、データベース
接続エラーが出ていて、サイトが表示されてません。
mysql再起動・・・何をやっても起動しません。。。
プロセスを調べてもmysqlは立ち上がっていません。

mysqlのデータもバックアップしてあるので、思い切って
アンインストールしてしまい、新たにインストールを
しなおしましたが、起動するものの機能しません。
しかも一度起動すると、リロードができなくなり
プロセスがずっと残ってしまいます。
kill -9 プロセスナンバー で殺すと再度起動しますが
状況は変わりません。

このサーバーもFedora17なので、直にサポートが切れるため、
こちらもCentOSに変更し、全てを構築しなおすことに。
( CentOSもいずれFedora18と同様なものになるでしょうけど、
 バージョンは完全更新期限が2015年で、最終サポートは
 2020年まであるので、その間ゆっくりお勉強できそうです。)

別マシンにCentOS6.4をインストール、Web・Mail・FTP・DNS
MYSQL・など最小限の設定し、ユーザー領域やSSLのキー・
mysqlのデータなどをrsyncで移動させます。
バックアップからの復旧ではないので、かなり楽チンですが、
FTPサーバーなどはバージョンが異なることで、設定ファイルが
大幅に変更があったものもあり、手打ち設定作業も発生しましたが、
Fedoraの古いバージョンで経験しているので作業は順調でした。

バックアップしてあったデータを所定の位置に戻すと、
ブログのひとつは復旧しました。
ところが拙生のブログが復旧せず、相変わらずエラーを
履き続けます。
あんなことやこんなこと、思いつくこと全てを
やったのですがダメです。

あんなことやこんなことってのは具体的には

mysqlcheck -c データベース名 -u ユーザー名 -p
mysqlcheck –auto-repair -c -o データベース名 -u ユーザー名 -p
mysqlcheck -r データベース名 -u ユーザー名 -p
等々。

phpMyAdminからも修復や最適化をやってみましたがこれもNG。
エクスポートしてみると特にちゃんとSQL文が構成されているように
見えるので、それを新しい方にインポート・・・NGです。

そこでついに諦めました。
テキストでエキスポートしておいて、新たに構築したWordpressに
手作業でコピペしようと決心しました。
何年分もの投稿は一気には無理なので、とりあえず今年の分だけ
復旧させ、あとは少しずつやることにしますが、固定ページも
半端でないボリュームです。
固定ページのサーバー関係は自身の備忘録であり、拙宅以外の
サーバーをいじる時に役立つため、このあたりから復旧ですね。

無線やサーバーのカテゴリは、サーチエンジンから飛んでくる方が
多かったので、リンク切れになっちゃいますね。
パーマネントリンクを書き換える?(却下です。)
Facebookなんかに貼ったページリンクもかぁ。@ため息

今回のトラブルは、いくらログを眺めても決定的な原因が
探し当てられなかったのですが、以前のマシンでmysqlが
全く稼働しなくなったことと、新たに構築したマシンに
データ移動しても一部のデータベース(拙性のブログ)が
NGであったことから、mysqlが拙生のデータベースへアクセス
している最中に電源が切れて、mysqlがぶっ飛び、データベースは
異常終了したため、InnoDBとの整合性が取れなくなったのでは
ないかと睨んでいます。

疲れたぁ~~~

【 片割れがDOWN@RAIDアレイ 】

          Posted on 2014年4月8日

本人も5年ぶりくらいにひいた風邪でグジュグジュで
ありましたが、サーバーからのラブレターで、RAID1で
ミラーリングしているHDDの片割れもDOWNしたらしい
ことを知りました。

# cat /proc/mdstat の結果

Personalities : [raid1]
md6 : active raid1 sdb8[1] sda8[0]
3144696 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk

md4 : active raid1 sdb6[1] sda6[0]
1048568 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk

md0 : active raid1 sdb1[2] sda1[0]
524276 blocks super 1.0 [2/2] [UU]

md2 : active raid1 sda3[0]
31456188 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk

md5 : active raid1 sda7[0]
2096120 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk

md3 : active raid1 sda5[0]
5241848 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk

md7 : active raid1 sdb9[1] sda9[0]
911358844 blocks super 1.1 [2/2] [UU]
bitmap: 2/7 pages [8KB], 65536KB chunk

md8 : active raid1 sdb10[1] sda10[0]
6142968 blocks super 1.1 [2/2] [UU]

md1 : active raid1 sdb2[1] sda2[0]
5241848 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk

md2・md3・md5のRAIDアレイ構成からsdbが仲間はずれ・・
一応

# mdadm -D /dev/md2

などとやってみましたが、結果はTotal DevicesやActive
Devicesが1個しか検出されません。
なにかの拍子でこうなるけど、自然復帰や再度RAIDアレイに
追加してやると直ることもあるので、まずは悪あがきを。
sdaは全て活きていて、sdb3(md2)・sdb5(md3)・sdb7(md5)が
死んでるので以下を実行してみる。。。

# mdadm –manage /dev/md2 -add /dev/sdb3
# mdadm –manage /dev/md3 -add /dev/sdb5
# mdadm –manage /dev/md5 -add /dev/sdb7

で、活き返ったのはmd5に参加するsdb7だけでした。
1回やってダメなら絶対深追いしてはなりませぬ。
かえって事態を悪化させてしまうことになりかねません。
1台交換決定ということで。

該当サーバーはこのBLOGも発信しているもので、つまり拙生の
個人的使用なものであるため、ホットスワップでやる必要はなく、
ちょうどやる予定だった清掃も含め、作業はシャットダウンして
行いました。

まずは以下の要領でsdbの関わるパーティションをRAIDアレイから
切り放してしまいます。

# mdadm /dev/md0 –manage –fail /dev/sdb1
故障と認識させSYNCを禁じます。

# mdadm /dev/md0 –manage –remove /dev/sdb1
 RAIDアレイの構成から取り除きます。 

拙生の場合はsdb10(md8)まであるので、この作業を延々と続けます。
これが終了したらシャットダウンさせます。

交換したHDDをsdbとして、再度sdaとRAID1を構築するには、
sdaと全く同じパーティションを切らなくてはいけません。
fdiskのPで表示されるsdaのパーティションのシリンダ数で
sdbを切ってやり、フォーマットするのは結構手間のいる作業です。
しかもCentOSが属するRedHat系は、インストール時にGUIで
RAID構築をすると、シリンダ数が1-50・50-100のように
切れ目が同じ50となるため、これをfdiskで切ろうとすると
1-50の次は51から始めないとダメ!って怒られてしまいます。

そんな時拙生は以下のお気に入りsfdiskコマンドで、sdaの
パーティションをsdbに一気に丸ごとコピーしてしまいます。

# sfdisk -d /dev/sda | sfdisk /dev/sdb –force

ものぐさにはこの世に勝るコマンドなし!って感じですね。w

後は

# mdadm /dev/md0 –manage –add /dev/sdb1
# mdadm /dev/md1 –manage –add /dev/sdb2
# mdadm /dev/md2 –manage –add /dev/sdb3

のごとく、sdbのすべてのパーティションをRAIDアレーへの
組み込みを全部終わるまで繰り返します。

注意としては、HDDのプライマリパーティションは4つまでで、
それ以上はプライマリの一つを拡張パーティションとして
切ることになります。
拙生の場合はsdb1~sdb3までがプライマリ、sdb4は拡張
パーティションの全体であり、さらにそれを細かく切ったものが
sdb5・sdb6・・・・のように続きます。
つまりsdb4はRAIDアレーに参加するわけではないので、
md3以降に参加するのはsdb5以降になるので間違ってはいけません。

めでたく復旧して【!万歳!】かと思いきや、syncの状況確認で

# cat /proc/mdstat

を何度か実行していると、一度UUに戻ったアレイが_Uに・・・^^;;
なんと今度はsdaのパーティションの1つがコケました。

そうなんです。
同時期に購入した同ロッドのHDDは、同じような時期にコケて
おかしくはないのです。
拙生は1台取り替えたら、数日中にもう1台も交換するのですが、
おかしくなって慌てて取り替えたのは今回が初めてですね。
ま、ギリギリセーフということで事なきを得ました。
両方一緒だったらと思うとぞっとしますね。
ラッキーだったのは風邪のために仕事で外に出ていなかったことです。

昔はRAID1の構成にCentOSなどをインストールしても、GRUBだけは
指定した片方にしかインストールされず、もう一方をgrubコマンドで
hd0に指定してインストールしておかなければ、GRUBがインストール
されている方が逝かれたら起動しなくなってしまいましたが、
grub2だと勝手にインストールしてくれますねぇ。
プラットホームやRAID・LVMのサポート、パーティション・テーブルや
ファイルシステムのサポートが格段に充実して、もうGRUB2以外は
使う気になれません。
慣れ親しんだGRUB (Grand Unified Bootloader) Legacy の時代に
幕が下りたということなのでしょう。

もう一つだけ
パーティションの話の際に必ず(しつこく)付け加えるのですが、
交換するHDDは必ず容量が同じか大きくなくては駄目です。
少しでも容量足りないと、同じパーティションは切れないので
構成することは不可能です。
1TBや2TBと表示があっても、メーカーやロッドにより若干容量が
違うので要注意です。
ノウハウとして、2TBなら1.8とか1.9しか使わないことで、微妙な
容量の違いを吸収できます。
必要なら大きい分は後から

# mdadm –grow /dev/md7 –size=max

のごとく拡大できますので、あまりケチらないように。w
ただし2TB以上のHDDを使いこなすには、MBRなどをよく
勉強してからでないと痛い目にあいます。
Logical Block Addressingでアクセスできるセクタ数40億に
論理セクターの512Bを掛けると2TBという限界が見えてくる・・・
などというお話は次回にということで。。。
ま、32bitの壁ってやつですな。

* 以前にも書きましたがaddやgrowなど複数文字の前は【-】になっていますが
  実際のコマンドは【-】が2つ並んでいます。
  WordPressのエディタが勝手に変換しちゃいます。
  例外もありますが、オプションでdなど単数文字の場合は【-】は1個、
  複数文字の場合は【-】が2つであることがほとんどです。
 

HOME