OpenGroove

Scientific Linux 6.1をいじる機会があったので、ハマったことのメモなんぞを。ミニマムインストールだと普通入っているはずのツールが入ってなくていちいちつまづく。まずscpが使えなかったので、以下実行。

/var/log/messagesにこんなエラーが吐かれたら。 May 10 13:10:11 kernel: crond[3880]: segfault at 00000000000000b0 rip 00002b8b07ed4e47 rsp 00007fff99a52fc0 error 4

sshd_configの設定は問題ない。なのに、リスタートをかけたら落ちたまま上がってこなくなった、、、という、信じ難いことも、世の中起こる時は起こる。

ファイルのシンボリックリンク作成でハマった記憶はあまりないが、ディレクトリでつまづいた。ディレクトリのシンボリックリンクは「/（スラッシュ）」のありなしで挙動が全然違うので、要注意。

sshでのアクセス制限は、sshd_configに直接記述する他、PAMの設定でも可能。sshd_configに記述する方法は、変更の都度sshdを再起動しなくてはいけない。

sshd_configの設定チェックはLinuxサーバ構築に欠かせない。何のことかわかっていない項目も実はあったりするので、おさらいしてみた。PAMについてもひと言。

sshでリモートホストにアクセスしてsudoする処理があるスクリプトをcronにしかけると、sudo: sorry,you must have a tty to run sudo.とエラーになってしまう。

Linuxカーネル2.6は、デフォルトでIPv6が有効となっている。無効にするための設定は多くネットで公開されているが、ディストリやそのバージョンにより異なってくるようだ。

/etc/ssh/sshd_configを編集したら、sshdを再起動する。この時に注意しないと、万が一の場合ログアウト後にsshログインが出来なくなってしまう。

showmount -e nfshostnameコマンドで、NFSサーバがエクスポートしているディレクトリ一覧を取得できる。もしこの時に”RPC:Program not registered.”エラーになったら。

例えばMySQLのスロークエリログなど各種ログに記録される、UNIX timestamp。そのままではいつのことか分からないが、通常日時へ変換してくれるコマンドがある。

ログローテートの設定において、ログファイル名の末尾を数字ではなく日付にしたい時。logrotate-3.7.3以降の場合、”dateext”を記述するだけでいいらしい。なんだ、簡単じゃないか、と思ったが。。

Linuxにおけるlogrotate（ログローテート）の機能についておさらい。しかし今回は、logrotateの設定をどこにどう書くかという話でなく、動作確認や、うまく動作しない時の対処について。

LPICのレベル1、2ともに登場する、SSHの公開鍵認証の設定。参考書を読んでもよく分からず苦手、と思っていたが、数年前に実務で利用しており確か自分で設定したこともあったような、、、と思い出した。

多くのソフトウェア関連の参考書ではインストールの方法は書かれているが、アンインストールの方法は書かれていないものだ。大事なことなのに。なので、例によってここに書いておく。（もちろん自分が知りたいのはWindowsやMacでどうするかではなく、UNIX/Linux上での話）

Linuxでソースインストール時に実行するconfigure。オプションを沢山指定する場合など、コマンドをテキストファイルからコピーしてターミナル画面に貼付けたりすると思うが、そこでミスがあっておかしな状態で実行されてしまうこともあるだろう。

壊れたディスクを他のサーバにつないで中身を確認したり復旧させたい時には、デバイスファイルを普通にマウントすればよいだろう。それがLVM構成の場合、どうすればいいだろうか。ググリまくった結果、概ね基本手順は以下でよいと思われる。、、、が、やったことがないので確証はない。 1.壊れたディスクを他のサーバに接続する 2.pvscanで接続先サーバ内のPV（物理ボリューム）を認識させる 3.vgscanで接続先サーバ内のVG（ボリュームグループ）を認識させる 4.vgchange -a y [VG名] で対象VGをアクティベイトする 5.対象LVをマウントする # mount /dev/VG名/LV名 /マウントポイント これで中身を確認したり、データを吸い出したりできる、はず・・・ ディスクをつないだサーバ内でVG名が重複していると認識できないため、VG名をデフォルトのまま使用していた場合はVG名を変更しなくてはならない。サーバ構築時にVG名をユニークなものにしておくと、後々いいかもしれない。 参照URL いろんなサイト見たけど、とりあえず以下挙げておく。 http://ugawalab.miyakyo-u.ac.jp/f6/toshihiro/settei/mount.html http://blog.matsumoto-r.jp/?p=284 http://www.hdd-pro.com/drd/2009/11/linuxlvm.html 追記 前提として、ディスクが壊れていたらマウントできない可能性が高いので、上記の操作はスムーズいかないかもしれない。エラーになったらfsck、だろうか。ちなみに-fオプションをつけるとクリーンフラグが立っているファイルシステムも強制的にチェックする。しかし壊れているディスクにさらに強制的にfsckをかけると被害が広がる、という意見もある。その辺りの判断は「これが正解」というのはなさそうである。。

Linuxでバックアップに利用されるLVMの機能、スナップショット。 スナップショットは単にデータのコピーを取るのではなく、対象となる論理ボリュームにおける、その瞬間のポインタを捉える。もっと一般的な言い方をすると、「ある瞬間のファイルシステムイメージを保持」したもの。 捉えられたポインタはスナップショット領域に保持されるわけだが、スナップショットを作成した瞬間のポインタがそのまま保持されるのではない。ファイルシステム上でなんらかの変更があれば、スナップショット領域内において差分が更新される。さらに、スナップショット領域内には変更前のデータ（のポインタ？）も退避され、保存される。 ….と、いうことらしい。この辺りはちょっと難しい。。 仕様については切り上げて、実践編。 スナップショットを作成するには、lvcreateに-sオプション、もしくは–snapshotをつける。-nで領域の名前を指定する。以下は、論理ボリューム”/dev/vg_name/lv_name”のスナップショットをsnap_testという名で作成している。 ※スナップショット用の領域が確保されていることが前提。ないと怒られる。 # lvcreate -s -L 200MB -n snap_test /dev/vg_name/lv_name 作成後lvdisplayしてみると、スナップショット領域が出来上がっているのが確認できるだろう。 作成したスナップショットは、dumpやrsyncなど利用してバックアップに使える。スナップショットは通常のデバイスと同じように扱えることができて、dumpでテープにバックアップを取るのであれば以下コマンドでOK。 # dump 0uf /dev/st0 /dev/vg_name/snap_test rsyncを実行する場合は、スナップショットをマウントしておく。 # mount -r /dev/vg_name/snap_test /mnt/snap_point　 snap_testを”/mnt/snap_point”にマウント ※rsyncコマンド例は今回は割愛。気が向いたら追記。 スナップショット領域は放っておくとどんどん増えていくので、バックアップが済んだら速やかに削除する。 アンマウントしてからlvremoveする。 # umount /mnt/snap_point # lvremove -f /dev/vg_name/snap_test　←-f は–forceでも。 スナップショットの説明は以下サイトが分かりやすいかも。 http://www.atmarkit.co.jp/flinux/rensai/root06/root06b.html

Linuxマシンが予期せぬタイミングで再起動したとしたら、どんな原因が想定されるだろうか。あまり多くの有力事例は見当たらないが、切り分け参考のために集めた情報の備忘録。 切り分けの確認として、基本は/var/log/messagesをみる、他にはcron、last、secureログも、かな。/var/log/messagesを確認しても異常を示す表示はなかった、という事例もあるようだが。 http://mlog.euqset.org/archives/vine-users/072858.html ちなみに、マシンの電源が突然切れたかどうかを確認したかったら。正常な電源断時のメッセージは/var/log/messagesにキレイに吐かれてるので、そこを手がかりに判定可能。 http://q.hatena.ne.jp/1193893387 「エラーの瞬間のプロセスが不運だとログ書かない」らしい。 特にハードが原因の場合。ドライバなどソフトウェアが問題の場合はログやCoreなど手がかりになるものが残ることが多い、とか。以下、ちょっと参考になる元ネタ。 http://mlog.euqset.org/archives/linux-users/103782.html カーネルパニックについて カーネルパニックはOS内部の問題と思っていたが、メモリ不良やCPU高負荷時に頻発、ソフトウェアよりハード原因で発生することが多い気がする、といった意見もある。カーネルパニックが発生した場合、デフォルトではそのまま操作待ちの状態で待機するようになっている。カーネルパニックが起きた際に自動的に再起動させるには、以下のようにしておく。 カーネルパニックが起きたら5秒後に自動的に再起動をさせる例 # echo 5 > /proc/sys/kernel/panic が、これだと再起動後にデフォルトに戻ってしまうので、恒久的に設定するには/etc/sysctl.confに記述しておく。 # vi etc/sysctl.conf 以下のように記述 kernel.panic = 5 設定の反映 # sysctl -p 設定の確認 # sysctl kernel.panic kernel.panic = 5 自動再起動時のメール通知、なんか設定しておくとスマートかもしれない。以下cronにて、再起動されたタイミングで「dmesg」コマンドの出力結果と直近の/var/log/messages100行分のログをadmin@example.co.jp宛に通知する指定。 # crontab -e @reboot (dmesg ; tail -100 /var/log/messages)| Mail -s “`hostname` rebooted” admin@example.co.jp ※実際は1行 参考URL http://www.itmedia.co.jp/help/tips/linux/l0140.html http://www.itmedia.co.jp/help/tips/linux/l0486.html http://aozorlinux.exblog.jp/9365765/ [...]

ユーザごとのリソースを制限できるファイ、/etc/security/limits.confについてちょっとしたまとめ。