OpenGroove

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/
カーネルパニック発生時にCoreを吐かせるかどうかも、設定してやらないといけないみたいだ。これについては別途。
結論
大雑把な切り分けとして、/var/log/messagesその他ログやコアダンプ出力があるかの確認、cronが変なことになってないか、侵入形跡の確認、そこに手がかりがなかったらハード起因（まれにネットワーク周り）を疑ってみる、ってところだろうか???

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

カーネルパニックとダンプ採取ツールkdumpの話。以下、ほとんどIBMの公開資料からの抜粋なのだが、PDFが重いし、書き出さないと脳に落とし込めないので。。
Linuxカーネルは想定外の状況（カーネルがどのように処理を継続するべきか判断できない状況）が発生すると、panic()と呼ばれる特別な関数を実行する。これをカーネルパニックと呼ぶ。しかし、これはカーネルが自発的にpanic()関数を実行した場合に発生する現象なので、全てのカーネル障害でカーネルパニックが発生するわけではない。カーネルがpanic()関数の実行すら出来ずにフリーズする場合もある。
カーネルパニック発生時のサーバのメモリの内容をカーネルダンプに出力することが可能。RHEL5ではkdumpというツールを利用できるが、所定のrpmや設定が必要。なお詳細は割愛するが、diskdump、netdumpなど他のメモリダンプ機能もある。
kdumpではサーバのメモリ上にあらかじめカーネルダンプを出力するための特別なカーネル（クラッシュカーネル）を常駐させておく。カーネルパニックが発生すると、通常のカーネルからクラッシュカーネルに処理を委譲する。つまり、通常のカーネルには問題が発生しているため、安全のために新たなカーネルでカーネルダンプの出力処理を実施する、というわけだ。
ちなみに「クラッシュカーネルが使用するメモリ領域はサーバ起動時に確保され、通常のカーネルは使用しないように設計されている」そうだ。えーと、でもここには「事象発生時にセカンドカーネルを動作させるため、物理メモリをあらかじめセカンドカーネル用に割り当てておかねばならない」とも。。うーむ、この辺、ちょっと理解できてません。
以下の手順のことかな、、、
kdumpに関する設定ファイル
/boot/grub/grub.conf
クラッシュカーネル用のメモリ領域を指定。通常はcrashkernel=128M@16Mとする。この場合物理メモリの16MB〜(16+128)MBを使用する。
/etc/sysconfig/kdump
通常は変更必要なし
/etc/kdump.conf
カーネルダンプの出力方法の指定
大体、ダンプ出力先は/var/crash。これも設定しておく。詳しくはIBMの資料参照。それと、kdumpを利用するにはkdumpサービスを起動しておく必要があるので# chkconfig kdump on としておく。
他にもいろいろあるんだろうけど、今回はこの辺で。
また何か出て来たら追記。
参照URL
http://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-003FFEF9
http://aozorlinux.exblog.jp/9365765/
関連記事
Linuxマシン突然再起動に関する備忘録
※カーネルパニック発生時に自動再起動させる設定など

Linuxアーキテクチャの確認方法について。
カーネル(OS)が32bitか64bitかの確認方法はいろんなところで書かれているが、いくつか方法があるのでまとめてみた。
細かい説明は省いて、とりあえず羅列。
$ uname -m
$ arch
$ gcc -v

上記実行の結果がi686（やそれに準ずる値）だったら32bit。
x86_64だったら64bit。
が、こんなのあったのか！と目から鱗だったのが、以下のコマンド。
$ getconf LONG_BIT

これは、「32」とそのものズバリを回答してくれる。
カーネルが32bitでもCPUが64bit、ということもあり得るようだ。
/proc/cpuinfoのflagsにlm(long mode)フラグがあったら64bitCPUってことらしい。
以下元ネタ。英語の勉強も兼ねて。
http://www.cyberciti.biz/faq/linux-how-to-find-if-processor-is-64-bit-or-not/

Linuxで、gz拡張子がついた圧縮ファイルの中身を、解凍せずに見たいとき。

ファイルの中身が軽いことが分かっていれば、gzcatで。
中身が膨大であることが分かっていたら、gzip -dcでlessかtailにパイプする。
# gzip -dc access_log.1.gz | less
# gzip -dc access_log.1.gz | tail -30

Linux記事一覧はこちらをどうぞ
↓ ↓ ↓
Linux-index

Linuxにおいてファイルシステムの詳細情報を出力するtune2fs -lとdumpe2fs。dumpe2fsには、Journal sizeとブロックグループの情報も表示される、という違いがあるようだ。

Linux新規ファイルシステム作成時のコマンドは、ファイルシステムの種類によりいろいろ。混乱しがちなので、ちょっとまとめてみた。例えばext3ファイルシステムを新規に作成するには、以下3通りのコマンドがある。

ユーザへのsudo権限を定義するファイル、/etc/sudoersの記述に関するメモ。NOPASSWDを記述しておくと、sudo実行時にパスワード入力を求められない。コマンドが長い場合や沢山ある場合には見やすくするために改行すればよいが、カンマ区切りを入れるのを忘れないようにw