[linux]マルチパスSANブート+ボリュームコピー環境でのリストア方法

Linux(RHEL)+マルチパスSANブート+ディスク装置のボリュームコピー環境でのシステムリストア方法。
最近では、ディスク装置の機能として持っている、論理ボリュームを丸ごとコピーする機能を利用して、システムバックアップを取得するのが、お手軽バックアップとして流行っている模様。
これを利用すると、コピー元のディスクがつぶれた場合、コピー先のディスクをホストに見せるようにするだけで(プレゼントやらマッピングやらマスキングやら・・・)リストアできるように見えるが、LInux+マルチパスSANブート環境だと簡単にはいかない。
その解決方法を以下に示す。
※ディスク装置はHP MSAを想定
※このバックアップ方法は、業務を停止することなくバックアップを取得できるメリットがある、とメーカーは言うが、OSが何しようとが関係なしに、ディスク装置側で勝手にバックアップをとってしまうため、不整合なファイルシステムの状態をとってしまうかもしれないリスクがある。(例えば、ファイル書き込み中とか・・・)


1.コピー先のディスクを、ホストに見せる(MSAの場合はマッピング)。これは当然
2.ホストをブートしてみる・・・・
3.するとinitrd処理中にエラーになり、やがてVGの重複が発生し、レスキューのためのパスワード入力プロンプトが表示されて停止する
(エラーになる原因は、ボリュームコピーによりマルチパスを構成するためのwwidが実際の物と異なっているので、マルチパスが構成できず全パスが個別の重複したディスクとして見えてしまう。マルチパスはwwidをヒントに同一ディスクの複数パスを探し出す。)
# ここで、あきらめる人が多いはず・・・
4.rootのパスワードを入力する
5./bootであるデバイスをマウントする(但し/bootのファイルシステムがパーティションの上に直接乗っているときのみ。LVM不可!)
普段/bootが/dev/mapper/mpath0p1なら、/dev/sda1。(sdb1でもsdc1でもsdd1でも可。実体は同じ)

# mount /dev/sda1 /boot

6.initrdを展開する
 initrdの中のファイルをいくつか編集するので、イメージを展開する。

# cd /boot
# cp -p initrd-xxxxx.img initrd-xxxxx.img.bk
# mkdir tmp
# cd tmp
# zcat initrd-xxxxx.img | cpio -i -o

7.論理ボリュームのSCSIシリアル番号(wwid)を調べる
/dev/disk/by-id/ディレクトリにあるシンボリックリンク名の頭「scsi-」を削ったものが論理ボリュームのSCSIシリアル番号。

# ls /dev/disk/by-id/
scsi-1111222233334444aaaabbbbccccdddd
scsi-1111222233334444aaaabbbbccccdddd-part1
scsi-1111222233334444aaaabbbbccccdddd-part2

上の赤太字がSCSIシリアル番号。
8. initスクリプト中のmultipathコマンドで指定してある論理ボリュームのSCSIシリアル番号(wwid)をコピー先ディスクの番号に書き換える(下、赤斜体文字箇所)。

# vi init
:(省略)
/bin/multipath -v 0 1111222233334444aaaabbbbccccdddd
:(省略)

9.etc/multipath.conf中の信頼する論理ボリュームのSCSIシリアル番号(wwid)を新しい番号に書き換える(下、赤斜体文字箇所)。

vi etc/multipath.conf
blacklist_exceptions {
wwid “1111222233334444aaaabbbbccccdddd
}

10.var/lib/multipath/bindingsファイル中のデバイス名エイリアスに紐づける論理ボリュームのSCSIシリアル番号(wwid)をコピー先の番号に書き換える(下、赤斜体文字箇所)。

# vi var/lib/multipath/bindings
mpath0 1111222233334444aaaabbbbccccdddd

 (このファイルで、wwid:1111222233334444aaaabbbbccccddddのディスクはmpath0を使用すると定義している)
11.initrd再作成
 次回以降の起動で使用できるように、編集したinitrdを再作成(イメージ化)する。

# find . | cpio –quiet -o -c | gzip -c > ../initrd-xxxxx.img

12.再起動

# exit

以上で、めでたく起動できる。

viエディタの現在のモードをわかりやすくする

viエディタの現在のモードをわかりやすくする

コマンドモードにして(現在何モードかがわからなければ、とりあえず[Escキー]を連打)

:set showmode

すると、右下(または左下)に現在のモードが表示される。

                   
                   
— 挿入 —

コマンドモードの場合は、何も表示されない。

KSH のコマンド履歴 およびにファイル名補完を有効にする

KSH のコマンド履歴およびにファイル名補完を有効にする方法

シェルのviモードを有効にする。

$ set -o vi

viモードを有効にしたら・・・
Escキーを押して(viでいうところのコマンドモードにする)

[Escキー]

コマンド履歴は

Ctrl+K(一つ前(過去)のコマンド)
Ctrl+J(1つ後(直近)のコマンド)
/<検索ワード>[Enterキー] (コマンド履歴から検索)

ファイル名補完(bashでいうところのタブ補完)は

*(アスタリスクShift+:)
※補完できる状態まで入力している必要あり。候補が複数ある場合は全部rリストされるので注意。

シェルスクリプトでtelnet接続→コマンド実行

シェルスクリプトでtelnet接続→コマンド実行

シェルスクリプトで、他ホストにtelnetログインしてコマンドを実行し情報を取得する方法。
たとえば、L2/L3スイッチの統計情報やarpテーブルの情報を自動的に取得する処理をシェルスクリプトで作成したいとき
telnetの場合、FTP転送をヒアドキュメントを使用して自動的に実行するのと同じ方法では実装できない。理由は、ヒアドキュメントの場合、標準入力に間髪入れずに入力内容を送りこんでしまうので、ログインプロンプトを待つことができないから。
ユーザ名を標準入力に送り込む前に少し待機すると、ログインすることができる。
ポイントは、
・ヒアドキュメントを使用せずに、コマンドのグループ化とパイプを使用してtelnetコマンドの標準入力にコマンドを送り込む
・sleepコマンドで待機
実際のやり方は以下を参照。(Ciscoのスイッチからarpテーブル情報を取得する場合。)

$ (sleep 5; #パスワードプロンプトが表示されるまでsleepコマンドで待つ
echo username;sleep 5; #ユーザ名入力 標準入力に送り込むのでechoで出力(Ciscoスイッチは実際にはユーザ名入力はありません)
echo password;sleep 10; # パスワード入力
enable;sleep 5; #特権モードへ切り替え
echo enablepassword;sleep 1; # 特権モードのパスワード入力
show arp;sleep 1; # arpテーブル取得
exit; ) | telnet 192.168.1.250 >> arp.log # コマンドをグループ化し、その標準出力をパイプでtelnetコマンドの標準入力に送り込む

追記:
 この方法はスクリプトで、passwdコマンドを使ってパスワードを自動設定するときにも使えます!

clamdが起動しない・・・

clamdが起動しない

# service clamd start
clamd を起動中: /bin/bash: line 1: 14616 File size limit exceeded/usr/local/sbin/clamd [失敗]

でも

# /usr/local/sbin/clamd
# echo $?
0

では起動する。
この差はいったい・・・
このような場合の基本、ログを見てみる。
起動失敗パターン

# less /var/log/clamd.log
Sat Apr 11 01:07:07 2009 -> +++ Started at Sat Apr 11 01:07:07 2009
Sat Apr 11 01:07:07 2009 -> clamd daemon 0.95.1 (OS: linux-gnu, ARCH: i386, CPU: i686)
Sat Apr 11 01:07:07 2009 -> Log file size limited to 2097152 bytes.
Sat Apr 11 01:07:07 2009 -> Reading databases from /var/lib/clamav
Sat Apr 11 01:07:07 2009 -> Not loading PUA signatures.

こちらは成功パターン

# less /var/log/clamd.log
Sat Apr 11 01:08:17 2009 -> +++ Started at Sat Apr 11 01:08:17 2009
Sat Apr 11 01:08:17 2009 -> clamd daemon 0.95.1 (OS: linux-gnu, ARCH: i386, CPU: i686)
Sat Apr 11 01:08:17 2009 -> Log file size limited to 2097152 bytes.
Sat Apr 11 01:08:17 2009 -> Reading databases from /var/lib/clamav
Sat Apr 11 01:08:17 2009 -> Not loading PUA signatures.
Sat Apr 11 01:08:17 2009 -> Not loading PUA signatures.
Sat Apr 11 01:08:20 2009 -> Loaded 538775 signatures.
Sat Apr 11 01:08:20 2009 -> LOCAL: Unix socket file /tmp/clamd.socket
Sat Apr 11 01:08:20 2009 -> LOCAL: Setting connection queue length to 15
Sat Apr 11 01:08:20 2009 -> Limits: Global size limit set to 104857600 bytes.
Sat Apr 11 01:08:20 2009 -> Limits: File size limit set to 26214400 bytes.
Sat Apr 11 01:08:20 2009 -> Limits: Recursion level limit set to 16.
Sat Apr 11 01:08:20 2009 -> Limits: Files limit set to 10000.
Sat Apr 11 01:08:20 2009 -> Archive support enabled.
Sat Apr 11 01:08:20 2009 -> Algorithmic detection enabled.
:(以下省略)

失敗パターンはシグネチャを読み込めていない??
どこでこけてるのかわからないので、起動スクリプトをデバッグモードで実行してみる

# bash -vx /etc/init.d/clamd
:(省略)
clamd を起動中: + ulimit -f 20000
+ LANG=
+ daemon /usr/local/sbin/clamd
:(省略)
+ /bin/bash -c ‘ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/clamd’
/bin/bash: line 1: 14503 File size limit exceeded/usr/local/sbin/clamd
+ ‘[‘ 153 -eq 0 ‘]’
+ failure ‘clamd 起動’
:(省略)

このところどころで出てくるulimitって何ですか??
さっきの/usr/local/sbin/clamdを直接実行したときは起動できたのでulimitが非常にくさい!
で、さっきのログを見た結果、シグネチャが読み込めていない。
シグネチャのサイズがでかすぎる??

# ls -l /var/tmp/clamav-0cae8acb8c9855ce5c67f55328bfce6e:
合計 25380
-rw-rw-rw- 1 root root 17992 4月 11 01:26 COPYING
-rw-rw-rw- 1 root root 4725917 4月 11 01:26 main.db
-rw-rw-rw- 1 root root 716040 4月 11 01:26 main.hdb
-rw-rw-rw- 1 root root 318 4月 11 01:26 main.info
-rw-rw-rw- 1 root root 20480000 4月 11 01:26 main.mdb

20MB??この数字、起動スクリプトをデバッグしたときにどこかにあったよな・・・

# less /etc/init.d/clamd
:(省略)
start() {
echo -n $”Starting $prog: ”
# Don’t allow files larger than 20M to be created, to limit DoS
# Needs to be large enough to extract the signature files
ulimit -f 20000
LANG= daemon $progdir/$prog
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
:(省略)

20480000byte ギリギリアウト??
なので/etc/init.d/clamd 中の ulimit -f の値を24000にしてみる。

# vi /etc/init.d/clamd
:(省略)
start() {
echo -n $”Starting $prog: ”
# Don’t allow files larger than 20M to be created, to limit DoS
# Needs to be large enough to extract the signature files
ulimit -f 24000
LANG= daemon $progdir/$prog
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
:(省略)

起動

# service clamd start
clamd を起動中: [ OK ]

起動できた!
原因はシグネチャファイルのサイズが起動スクリプトで定義されているファイルサイズ制限より大きかったから。
以上

[linux]OS再インストールなしにマザーボードを交換してみる

OS再インストールなしに、マザーボードを交換してみる

C7プロセッサを載せた自宅サーバのマザーボードが不安定になったので、マザーボードを交換してみた。面倒なOS再インストールおよびミドルウェア再設定なしで。何も考えずにするとディスク(VG)が見えなくなるので厄介。
▼環境

 OS:CentOS 5.3
 マザーボード:EPIA-LN10000EG(C7) → D945GCLF2(Atom330)

マザーボードのSATAコントローラが交換前後で異なるので、マザーボード交換後は当然ディスク(というよりLVM VG)が見えなくなる。
▼ 以下やったこと。
マザーボード交換後、何も手当てをせずに起動してみる。
initrdを読み込んで、VGを探し始めたところで「No volume groups found」といわれてしまう。
予想通りの結果。initrdの中にICH7用のSATAドライバがないから(現時点で読み込んでいるのはVIAのSATAドライバ)。
念のためディスク自身が使用できることを確認するために、CentOSのインストールDVDのレスキューモードで起動。VGも認識したので、ディスク自身も使用できること(問題ないこと)は確定。
さて、ここでinitrdをICH7用ドライバを読み込むように作り変えることになるのだが、どれがICH7用ドライバかわからない。レスキューモードで起動しているがlsmodをみても判断できない。
ということで・・・
外付けHDDにCentOSをインストールしてみる(再インストールなしと書いているが、データを破壊しないという意味なので・・・)。
※このときGRUBの2段階目は外付けHDDに向くので、後ほど注意!
インストール後、/etc/modprobe.confの内容を確認。
こんな感じ。

alias scsi_hostadapter ata_piix
alias scsi_hostadapter1 usb-storage
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r –ignore-remove snd-hda-intel
alias eth0 r8169

これをどこかにメモしておいて、こちらのOSはシャットダウン。外付けHDDは外す。
次に、もう一度CentOSのインストールDVDのレスキューモードで起動。
内蔵HDDの(/mnt/sysimage)/etc/modprobe.confの中身を上記メモの内容に置き換えて、initrdを再作成する。

# vi /mnt/sysimage/etc/modprobe.conf
(上記メモ内容に置き換え)
# chroot /mnt/sysimage
# cp -p /boot/initrd-2.6.18-92.1.22.el5.img? /boot/initrd-2.6.18-92.1.22.el5.img.c7
# mkinitrd -f? /boot/initrd-2.6.18-92.1.22.el5.img 2.6.18-92.1.22.el5

作成したinitrdを解凍してみて、ちゃんとICH7用のドライバが組み込まれていることを確認する

# gzip -dc? /boot/initrd-2.6.18-92.1.22.el5.img > /tmp/initrd.cpio
# mkdir /tmp/initrddir
# cd /tmp/initrddir
# cpio -i –file ../initrd.cpio
# less init
(ここで、insmod /lib/ata_piix.koがあることを確認)

確認できたら、GRUB(ブートローダ)の2段目の向き先を内蔵ディスクに戻す

(先ほどのchrootの環境のまま)
# /sbin/grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
# sync

これにて完了!
あとはexitして、再起動すれば元通りに起動できる。

[linux]コンパイル時に「ld: cannot find -l」となるときの解決方法

linux(Redhat系)にて、ソフトウェアインストールのコンパイル時に

/usr/bin/ld: cannot find -lXext

というエラーメッセージが表示され、コンパイルが失敗してしまうときの 解決方法。
-lに続くパッケージ?のライブラリがないから上記のようなエラーが発生する。(configureのチェックをすり抜けちゃってるんですね・・・)
つまり、-l<パッケージ名> なら「lib<パッケージ名>-devel」というパッケージを用意すればよいことになる。
具体的には 「ld: cannot find -lXext」なら「libXext-devel」
どのパッケージかわからなければ

yum search lib<パッケージ名>

で表示されたパッケージを全てインストールしてしまえばよい。

[Linux]ネットワークインターフェースの通信モード(全二重/半二重/オートネゴシエーション)確認方法

Linuxでの、ネットワークインターフェース(NIC)の通信モード(全二重/半二重/オートネゴシエーション)確認方法
以下のコマンドを実行

# ethtool? <インターフェース名(eth0など)>
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:?? 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:? 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s????????????? ←リンク速度
Duplex: Full ←通信モード(全二重/半二重)
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on ←オートネゴシエーションの有効
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000001 (1)
Link detected: yes

オートネゴシエーションを有効にしたいなら

# vi /etc/sysconfig/network-scripts/ifcfg-<インターフェース名>
ETHTOOL_OPTS=”autoneg on”??? ←変更または追加
# service network restart

とある事情で、オートネゴシエーションを無効にして、100Mbps半二重固定で通信させたいなら

# vi /etc/sysconfig/network-scripts/ifcfg-<インターフェース名>
ETHTOOL_OPTS=”speed 100 duplex half autoneg off”??? ←変更または追加
# service network restart

上記(100Mbps半二重固定)を一時的に反映させたいだけなら

# ethtool -s <インターフェース名> speed 100 duplex half autoneg off