So-net無料ブログ作成

計画停電とLinux [小技(Linux)]

 まずは、遅ればせながら東北関東大震災で被災された皆様には心よりお見舞い申し上げます。

 さて、現在東京電力エリア内では「計画停電」真っ盛りですが、計画停電の時間が始まるまでにはなんとかしてサーバを自動でシャットダウンしたいものです。
 そこで、その方法を紹介します。

 atコマンドを使います。

 と、その前に、まずは「atd」が起動していることを確認しましょう。
[root@haruka ~]# ps -ef | fgrep atd
root      1157 16571  0 11:14 pts/5    00:00:00 fgrep atd
rpcuser   2667     1  0 Jan08 ?        00:00:00 rpc.statd
root      2870     1  0 Jan08 ?        00:00:00 /usr/sbin/atd


 3行目の「/usr/sbin/atd」がソレです。起動していない場合は、 service atd start なりしておきましょう。自動起動の設定なら chkconfig atd on です。

 そして、計画停電が6:20から開始される場合なら、5分前にシャットダウンしておくとすると

 at 6:15

 とか実行します。すると…
[root@haruka ~]# at 6:15
at>

 とかプロンプトが表示されますので、ここにシャットダウンコマンドを記述します。
[root@haruka ~]# at 6:15
at> shutdown -h now

 ↑まずはこんな感じ。そして、Enterキーを忘れずに押しておきましょう。2行目のプロンプトが表示されます。
[root@haruka ~]# at 6:15
at> shutdown -h now
at>

 ↑こうなる。そしたら、「Ctrl + D」でプロンプトを抜けます。
[root@haruka ~]# at 6:15
at> shutdown -h now
at>
job 1 at 2011-03-24 06:15


 というように、「ジョブID」とそのジョブが実行される正確な日時が表示されます。

 ちなみに、atコマンドに指定した時刻が…
① まだ到来していない場合
 (例)atコマンドを入力した時間が12:00で、atコマンドの引数に指定した時間が18:00だった場合
 →その日の18:00に実行されます

② もう過ぎちゃった場合
 (例) (例)atコマンドを入力した時間が12:00で、atコマンドの引数に指定した時間が06:00だった場合
 →次の日の06:00に実行されます

 ちゃんとatコマンドによるジョブが登録されたかどうか確認したい場合は、「atq」コマンドで確認できます。
[root@haruka ~]# atq
3       2011-03-24 06:15 a root
[root@haruka ~]# date
2011年  3月 23日 水曜日 11:25:23 JST

 atqコマンドで表示されているのは、ジョブIDが「3」で、そのジョブは2011-03-24の06:20に実行されることがわかります。

 ジョブの詳細が知りたい場合は、「at -c」で見ることが出来ます。-cオプションに続けてジョブIDを指定します。
[root@haruka ~]# at -c 3
#!/bin/sh
# atrun uid=0 gid=0
# mail     root 0
umask 22
HOSTNAME=haruka.mycompany.com; export HOSTNAME
SHELL=/bin/bash; export SHELL

(途中省略)

shutdown -h now

[root@haruka ~]#

 環境変数の設定が自動的に行われるので、最初びっくりするかもしれませんが、最後のほうに「shutdown -h now」がちゃんと追加されていることがわかります。

 「間違えて登録しちゃった!」という場合、ジョブを削除するのは「atrm」コマンド。ジョブIDを続けて指定するとそのジョブが削除されます。
[root@haruka ~]# atrm 3
[root@haruka ~]# atq

 ↑こんな具合。

 あとは時間が来ればサーバがシャットダウンされます。

 ところで、東京電力が公表している計画停電の予定に併せて、今日・明日の分だけでなくもっと先の予定まで登録しておきたい!という場合にも対応できます。

 いちいちatコマンドでshutodownと書くのは面倒くさいので、まず最初に実行したいコマンドを記述したファイルを作成しておきます。例えばこんな具合。

 echo "shutdown -h now" > /tmp/command.txt

 atコマンドに「-f」オプションを追加ます。
 先ほど紹介したときに時刻だけを記述した項目には日付も同時に指定することができます。
 例えば、2011年3月31日の6:15にサーバをシャットダウンしたいなら、

 at -f /tmp/command.txt 06:15 03/31/2011

 と、時間と日付を指定すればOK。
 なお、日付のところに「tomorrow」と書けば、「明日の」6:15に実行されるし、「今から1時間後」という指定も可能で、

 at -f /tmp/command.txt now + 1 hour

 と指定すればよい。他にも便利で楽しい日時の指定方法があるが、紹介してると終わらなくなるので(笑)基本的なものだけ紹介した。

クラスタシステムとssh [備忘録]

 ちょっと番外編。
 heartbeat等でクラスタシステムを構築した場合に、1点問題になることがある。それは「ssh」。

 クラスタを構成する各ノードを指定してsshやslogin等を実行する場合は通常のサーバに対するものとなんら変わることが無いが、クラスタのVIPに対してアクセスしようとすると、クラスタの稼動系が切り替わったタイミングで…
[root@chiaki .ssh]# ssh nfscl01 uname -a
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:5
RSA host key for nfscl01 has changed and you have requested strict checking.
Host key verification failed.

 こんな感じの(もっと違うメッセージになることもある)エラーになって困ってしまう。

 これは、クラスタシステムに組み込まれているsshのキーペアがノードによって異なるために生じる問題だからだ。
 上記の例(このblogでheartbeatの解説をしている環境)では、

  ・nfs001 … クラスタに参加しているノード その1
  ・nfs002 … クラスタに参加しているノード その2
  ・nfscl01 … クラスタシステムに割り当ててあるVIP(必ず稼動しているほうのサーバにアクセスできるアドレス)

 ということになっているが、
Node: nfs002.mycompany.com (6a838508-67eb-47f3-9a46-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-c47c-426f-8dc4-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs001.mycompany.com

 という状態であれば、nfscl01というアドレスでアクセスできる先のサーバは「nfs001.mycompany.com」であるが、
Node: nfs002.mycompany.com (6a838508-67eb-47f3-9a46-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-c47c-426f-8dc4-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs002.mycompany.com

 という状態であれば、nfscl01というアドレスでアクセスできる先のサーバは「nfs002.mycompany.com」になってしまうのである。

 クライアントからサーバにアクセスしたときに提示されるサーバの公開鍵が、「nfs001.mycompany.com」のものだったり、「nfs002.mycompany.com」のものだったりするから困った事態になってしまうのである。

 そこで、解決方法の一つとしてよく用いられるのが、サーバ側のキーペアファイルを「nfs001.mycompany.com」と「nfs002.mycompany.com」とで同じものを用いてしまおうというもの。セキュリティ的にどうなの?という指摘があるかもしれないが、その辺はそういうことに詳しい人にお任せするとして、ここではこの方法でエラーを回避する方法を紹介する。

 まず、手順は以下の通り。
①:片方のサーバのキーペアファイルを稼動系サーバからコピーして上書きする
②:サーバにアクセスするクライアントの「known_hosts」ファイルから、VIPに対するキーの記述されている行と、キーペアファイルをコピーして上書きしたクラスタノードの行を削除する
③:クラスタのVIPと、待機系サーバに対してsshあるいはsloginなどを実行する。

①:片方のサーバのキーペアファイルを稼動系サーバからコピーして上書きする
 まず、サーバ側のキーペアファイルを統一する作業を行う。

 サーバのsshキーペアファイルは、通常は/etc/ssh配下に保存されている。
[root@nfs001 ~]# cd /etc/ssh
[root@nfs001 ssh]# ls -la
合計 184
drwxr-xr-x  2 root root   4096  2月  9 12:36 .
drwxr-xr-x 81 root root   4096  3月 18 04:02 ..
-rw-------  1 root root 132839  9月 13  2010 moduli
-rw-r--r--  1 root root   1827  9月 13  2010 ssh_config
-rw-------  1 root root    672  2月 28 14:22 ssh_host_dsa_key
-rw-r--r--  1 root root    590  2月 28 14:22 ssh_host_dsa_key.pub
-rw-------  1 root root    963  2月 28 14:22 ssh_host_key
-rw-r--r--  1 root root    627  2月 28 14:22 ssh_host_key.pub
-rw-------  1 root root   1675  2月 28 14:22 ssh_host_rsa_key
-rw-r--r--  1 root root    382  2月 28 14:22 ssh_host_rsa_key.pub
-rw-------  1 root root   3323  9月 13  2010 sshd_config

 このうちの、「ssh_host_*」の6ファイル(場合によっては4ファイルだったり、8ファイルだったりすることもあるが、その場合はそれら4ファイルまたは8ファイルの全てが対象となる。以下同じ)を、もう一方のクラスタノードからコピーしてきて上書きしてしまう。
 ここでは、nfs002が稼動系でnfs001が待機系になっているので、nfs002 → nfs001とコピーすることにする。

 scp -p nfs002:'/etc/ssh/ssh_host*' /etc/ssh/

 これでキーペアファイルが上書きされる。なお、秘密鍵ファイルの(拡張子「.pub」が付いていない)ほうはパーミッションが600でなければならないので、必ずチェックするように。

 そしたらsshdを一旦再起動する。

 service sshd restart

 これでサーバ側のキーペアファイルが更新された。

②:サーバにアクセスするクライアントの「known_hosts」ファイルから、VIPに対するキーの記述されている行と、キーペアファイルをコピーして上書きしたクラスタノードの行を削除する

 さて。この状態だと、クライアントから見たらサーバの公開鍵が変更されているので、known_hostsに保存されている情報と食い違うこととなり、sshがエラーを返すようになってしまう。そこで、known_hostsから該当するサーバの情報を削除しなければならない。

 known_hostsは、ログインディレクトリの下に「.ssh」というディレクトリが作成され、その中に保存されている。rootユーザーなら /root/.ssh/known_hosts だし、piro791というユーザーなら、おそらく /home/piro791/.ssh/known_hosts であるはずだ。

 known_hostsがデカすぎて探すのが面倒なときは、わざとエラーを発生させて、そのメッセージの中から行数を取得するのがいい。(笑)例えば、このアーティクルの冒頭で紹介したsshのエラーだったら、
Offending key in /root/.ssh/known_hosts:5

 というように出ているので、「/root/.ssh/known_hosts」の5行目にその削除すべき行があることがわかる。これを削除すればよい。なお、サーバが複数のNICを持っていたり、Aliasアドレスを持っている場合は複数の行が記録されていることも考えられるので、それら全てを削除するように。

③:クラスタのVIPと、待機系サーバに対してsshあるいはsloginなどを実行する。

 で、新しい公開鍵情報をknown_hostsに書き込む必要があるが、これはsshコマンドにやらせるのが面倒無いだろう。(コピー元になったサーバの行をコピーして編集してもいいけどね…)
[root@chiaki .ssh]# ssh nfs001 uname -a
The authenticity of host 'nfs001 (172.16.40.101)' can't be established.
RSA key fingerprint is 90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Are you sure you want to continue connecting (yes/no)? 

 こんな具合に、known_hostsに公開鍵情報を書き足してもいい?と質問してくるので、「yes」と答えればOK。
[root@chiaki .ssh]# ssh nfs001 uname -a
The authenticity of host 'nfs001 (172.16.40.101)' can't be established.
RSA key fingerprint is 90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'nfs001,172.16.40.101' (RSA) to the list of known hosts.
Linux nfs001.mycompany.com 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

 こんな具合に公開鍵が保存される。鍵交換が済んでいてパスワードなしでログインできるようになっていれば、これ以降のsshアクセスなら…
[root@chiaki .ssh]# ssh nfs001 netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth1       1500   0    33452      0      0      0    33410      0      0      0 BMRU
eth2       1500   0    33540      0      0      0    33497      0      0      0 BMRU
eth4       1500   0   986955      0      0      0     2141      0      0      0 BMRU
lo        16436   0    39845      0      0      0    39845      0      0      0 LRU

 こんな風に改めて鍵交換をするまでも無くパスワードなしでアクセスすることが可能だ。

/proc/cpuinfoの「flags」調査 [備忘録]

 http://piro791.blog.so-net.ne.jp/2010-07-22
 ↑このページの/proc/cpuinfo の「flags」についての調査結果を追記しました。
 AMD…もうちょっと詳しい情報が欲しいなあ。でも、別にアセンブラを使うわけでもないサーバ屋さんにはそれほど必要ないか。。。。。(笑)
メッセージを送る