LSIのRAIDカード、CLIからホットスペアディスクを追加する [備忘録]
ものすごくニッチなメモだと思うが、ハマったのでメモ残しておく。（笑）
LSIのRAIDカード9650SEでRAID5のアレイを作成してあるストレージサーバで、ディスクが１本故障。ホットスペアを使用したリビルドが走って事なきを得たが、ディスクを交換後、それをホットスペアディスクとしてCLIから組み込む方法がよく判らなかった。リビルド完了後・ディスク交換作業直後の状態
p7のスロットにあるディスクが、交換作業を終えて、ホットスペアに組み込みたいディスク。
（苦手な）英語のマニュアルを読んでいくと、/cx add type=spare disk=p:-pとかいう書式でいけそうだと判った。
…が、コレがうまくいかなかった。
うーむ…。そのディスクは使えませんお（＾ω＾） ということ。新品ではないが問題ないはずのディスクなんだけどもなあ…。
うーむむむ。よくわからん。
そこで、ディスクを一旦抜き差ししてみた。
すると…
なんということでしょう～！ p7のディスクの「Unit」の項目が「u?」から「-」に変化している。
案の定…
ホットスペアとして組み込みに成功。
「u?」という状態になってたらダメなんだねー。知りませんでした。
LSIのRAIDカード9650SEでRAID5のアレイを作成してあるストレージサーバで、ディスクが１本故障。ホットスペアを使用したリビルドが走って事なきを得たが、ディスクを交換後、それをホットスペアディスクとしてCLIから組み込む方法がよく判らなかった。リビルド完了後・ディスク交換作業直後の状態
//sunflower> /c6 show all /c6 Driver Version = 2.26.08.007-2.6.18RH /c6 Model = 9650SE-16ML /c6 Available Memory = 224MB /c6 Firmware Version = FE9X 4.08.00.006 /c6 Bios Version = BE9X 4.08.00.001 /c6 Boot Loader Version = BL9X 3.08.00.001 （略） Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK u? 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
p7のスロットにあるディスクが、交換作業を終えて、ホットスペアに組み込みたいディスク。
（苦手な）英語のマニュアルを読んでいくと、/cx add type=spare disk=p:-pとかいう書式でいけそうだと判った。
…が、コレがうまくいかなかった。
//sunflower> /c6 add type=spare disk=7 The following drive(s) cannot be used [7]. Error: (CLI:144) Invalid drive(s) specified.
うーむ…。そのディスクは使えませんお（＾ω＾） ということ。新品ではないが問題ないはずのディスクなんだけどもなあ…。
//sunflower> /c6/p7 show all /c6/p7 Status = OK /c6/p7 Model = WDC WD20EARS-00S8B1 /c6/p7 Firmware Version = 80.00A80 /c6/p7 Serial = WD-WCAVY3331147 /c6/p7 Capacity = 1.82 TB (3907029168 Blocks) /c6/p7 Reallocated Sectors = 0 /c6/p7 Power On Hours = 7284 /c6/p7 Temperature = 37 deg C /c6/p7 Spindle Speed = 5400 RPM /c6/p7 Link Speed Supported = 1.5 Gbps and 3.0 Gbps /c6/p7 Link Speed = 3.0 Gbps /c6/p7 NCQ Supported = Yes /c6/p7 NCQ Enabled = Yes /c6/p7 Identify Status = N/A /c6/p7 Belongs to Unit = N/A /c6/p7 Drive SMART Data: 10 00 01 2F 00 C8 C8 00 00 00 00 00 00 00 03 27 00 97 94 D1 24 00 00 00 00 00 04 32 00 64 64 2A 00 00 00 00 00 00 05 33 00 C8 C8 00 00 00 00 00 00 00 07 2E 00 C8 C8 00 00 00 00 00 00 00 09 32 （以下略）
うーむむむ。よくわからん。
そこで、ディスクを一旦抜き差ししてみた。
すると…
//sunflower> /c6 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK - 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
なんということでしょう～！ p7のディスクの「Unit」の項目が「u?」から「-」に変化している。
案の定…
//sunflower> /c6 add type=spare disk=7 Creating new unit on controller /c6 ... Done. The new unit is /c6/u1. WARNING: This Spare unit may replace failed drive of same interface type only. //sunflower> /c6 show all /c6 Driver Version = 2.26.08.007-2.6.18RH /c6 Model = 9650SE-16ML /c6 Available Memory = 224MB /c6 Firmware Version = FE9X 4.08.00.006 /c6 Bios Version = BE9X 4.08.00.001 /c6 Boot Loader Version = BL9X 3.08.00.001 （略） Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON u1 SPARE OK - - - 1863.01 - OFF VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK u1 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
ホットスペアとして組み込みに成功。
「u?」という状態になってたらダメなんだねー。知りませんでした。
Gmailさんでdkimが通らない！？（続報） [備忘録]
rsa-sha256でGmailさんにdkim=passするよ！というつぶやきをもらったので、追加で調査してみたところ、どうもdkim-genkeyする段階で、/etc/mail/dkim-filter.confを記述してるかしてないかで変わってくる模様。
というのも、わたしが試したときには、
① dkim-genkey を実行する
↓
② /etc/mail/dkim-filter.conf を書く
↓
③ /etc/rc.d/init.d/dkim-filter を書く
という流れで実行し、dkim-filterの起動スクリプト内に必要な情報は書き並べたので、confの中に書くことといえば
これくらいしか書いてなかった。（笑）この状態では、dkim-filterはrsa-sha256だと思って振舞うっぽい？
実際、Gmailで確認できたメールのヘッダには「a=rsa-sha256」と記載があった。
で、dkim-genkeyする前に、dkim-filter.confに
と記述してから、dkim-genkeyをしてみると、「a=rsa-sha256」でも「dkim=pass」と、なったことが確認できた。
まとめると、「SignatureAlgorithm」を明示的に書かなかった場合、
・dkim-filter はデフォルトのアルゴリズムを rsa-sha256だと解釈する
・dkim-genkey はデフォルトのアルゴリズムをrsa-sha1だと解釈する
ということに？？？？？？？？？
これならこのあたりの挙動に説明は付くけども・・・・・
と、すると、sendmail.netに投げて返ってきたテストメールの
↑コレはなにをもって「GOOD」と言っているのでしょうかねえ？？？？？
謎です。。。。。
というのも、わたしが試したときには、
① dkim-genkey を実行する
↓
② /etc/mail/dkim-filter.conf を書く
↓
③ /etc/rc.d/init.d/dkim-filter を書く
という流れで実行し、dkim-filterの起動スクリプト内に必要な情報は書き並べたので、confの中に書くことといえば
On-Badsignature accept On-NoSignature accept
これくらいしか書いてなかった。（笑）この状態では、dkim-filterはrsa-sha256だと思って振舞うっぽい？
実際、Gmailで確認できたメールのヘッダには「a=rsa-sha256」と記載があった。
で、dkim-genkeyする前に、dkim-filter.confに
SignatureAlgorithm rsa-sha256
と記述してから、dkim-genkeyをしてみると、「a=rsa-sha256」でも「dkim=pass」と、なったことが確認できた。
まとめると、「SignatureAlgorithm」を明示的に書かなかった場合、
・dkim-filter はデフォルトのアルゴリズムを rsa-sha256だと解釈する
・dkim-genkey はデフォルトのアルゴリズムをrsa-sha1だと解釈する
ということに？？？？？？？？？
これならこのあたりの挙動に説明は付くけども・・・・・
と、すると、sendmail.netに投げて返ってきたテストメールの
Authentication System: DomainKeys Identified Mail Result: DKIM signature confirmed GOOD Description: Signature verified, message arrived intact Reporting host: sendmail.net More information: http://mipassoc.org/dkim/ Sendmail milter: https://sourceforge.net/projects/dkim-milter/
↑コレはなにをもって「GOOD」と言っているのでしょうかねえ？？？？？
謎です。。。。。
Gmailさんでdkimが通らない！？ [備忘録]
これはメモ。
postfix+dkim_milterでメールにDKIMの署名を付けてみて、Gmailさんにテストメールを送信してみると・・・
Authentication-Results: mx.google.com; spf=pass (google.com: domain of p791@mycompany.com designates 125.***.***.149 as permitted sender) smtp.mail=p791@mycompany.com; dkim=neutral (bad format) header.i=@mycompany.com
と、なってしまう場合。
sendmail.netのテストではちゃんと通るのに。。。。。
さんざん悩んだ結果、dkim-milterの新しい目のバージョンではDKIMの署名に「rsa-sha256」を使う模様。実際、メールのヘッダをよーく見てみると、
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mycompany.com; s=sarah;
と、なってる。
confや起動オプションの指定は何も明示していないので、デフォルトがコレになっているようです。
が、Gmailさんはコレが理解できないらしいです。
dkim-filterの起動オプションに、「-S rsa-sha1」を付けて起動すると、アラ不思議！！
Authentication-Results: mx.google.com; spf=pass (google.com: domain of p791@mycompany.com designates 125.***.***.149 as permitted sender) smtp.mail=p791@mycompany.com; dkim=pass header.i=@mycompany.com
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mycompany.com; s=sarah;
と、DKIMの判定がpassになりました。
おそらく、dkim-filter.confに記述する方法でも良いと思うんですけどもね。
延々と苦しんだぜ・・・
postfix+dkim_milterでメールにDKIMの署名を付けてみて、Gmailさんにテストメールを送信してみると・・・
Authentication-Results: mx.google.com; spf=pass (google.com: domain of p791@mycompany.com designates 125.***.***.149 as permitted sender) smtp.mail=p791@mycompany.com; dkim=neutral (bad format) header.i=@mycompany.com
と、なってしまう場合。
sendmail.netのテストではちゃんと通るのに。。。。。
Authentication System: DomainKeys Identified Mail Result: DKIM signature confirmed GOOD Description: Signature verified, message arrived intact Reporting host: sendmail.net More information: http://mipassoc.org/dkim/ Sendmail milter: https://sourceforge.net/projects/dkim-milter/ Authentication System: Domain Keys Result: (no result present) Reporting host: More information: http://antispam.yahoo.com/domainkeys Sendmail milter: https://sourceforge.net/projects/domainkeys-milter/ Authentication System: Sender ID Result: SID data confirmed GOOD Description: Sending host is authorized for sending domain Reporting host: sendmail.net More information: http://www.microsoft.com/senderid Sendmail milter: https://sourceforge.net/projects/sid-milter/ Authentication System: Sender Permitted From (SPF) Result: SPF data confirmed GOOD Description: Sending host is authorized for sending domain Reporting host: sendmail.net More information: http://spf.pobox.com/
さんざん悩んだ結果、dkim-milterの新しい目のバージョンではDKIMの署名に「rsa-sha256」を使う模様。実際、メールのヘッダをよーく見てみると、
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mycompany.com; s=sarah;
と、なってる。
confや起動オプションの指定は何も明示していないので、デフォルトがコレになっているようです。
が、Gmailさんはコレが理解できないらしいです。
dkim-filterの起動オプションに、「-S rsa-sha1」を付けて起動すると、アラ不思議！！
Authentication-Results: mx.google.com; spf=pass (google.com: domain of p791@mycompany.com designates 125.***.***.149 as permitted sender) smtp.mail=p791@mycompany.com; dkim=pass header.i=@mycompany.com
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mycompany.com; s=sarah;
と、DKIMの判定がpassになりました。
おそらく、dkim-filter.confに記述する方法でも良いと思うんですけどもね。
延々と苦しんだぜ・・・
クラスタシステムとssh [備忘録]
ちょっと番外編。
heartbeat等でクラスタシステムを構築した場合に、1点問題になることがある。それは「ssh」。
クラスタを構成する各ノードを指定してsshやslogin等を実行する場合は通常のサーバに対するものとなんら変わることが無いが、クラスタのVIPに対してアクセスしようとすると、クラスタの稼動系が切り替わったタイミングで…
こんな感じの（もっと違うメッセージになることもある）エラーになって困ってしまう。
これは、クラスタシステムに組み込まれているsshのキーペアがノードによって異なるために生じる問題だからだ。
上記の例（このblogでheartbeatの解説をしている環境）では、
・nfs001 … クラスタに参加しているノード その１
・nfs002 … クラスタに参加しているノード その２
・nfscl01 … クラスタシステムに割り当ててあるVIP（必ず稼動しているほうのサーバにアクセスできるアドレス）
ということになっているが、
という状態であれば、nfscl01というアドレスでアクセスできる先のサーバは「nfs001.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配下に保存されている。
このうちの、「ssh_host_*」の６ファイル（場合によっては４ファイルだったり、８ファイルだったりすることもあるが、その場合はそれら４ファイルまたは８ファイルの全てが対象となる。以下同じ）を、もう一方のクラスタノードからコピーしてきて上書きしてしまう。
ここでは、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のエラーだったら、
というように出ているので、「/root/.ssh/known_hosts」の5行目にその削除すべき行があることがわかる。これを削除すればよい。なお、サーバが複数のNICを持っていたり、Aliasアドレスを持っている場合は複数の行が記録されていることも考えられるので、それら全てを削除するように。
③：クラスタのVIPと、待機系サーバに対してsshあるいはsloginなどを実行する。
で、新しい公開鍵情報をknown_hostsに書き込む必要があるが、これはsshコマンドにやらせるのが面倒無いだろう。（コピー元になったサーバの行をコピーして編集してもいいけどね…）
こんな具合に、known_hostsに公開鍵情報を書き足してもいい？と質問してくるので、「yes」と答えればOK。
こんな具合に公開鍵が保存される。鍵交換が済んでいてパスワードなしでログインできるようになっていれば、これ以降の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 … クラスタに参加しているノード その１
・nfs002 … クラスタに参加しているノード その２
・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_*」の６ファイル（場合によっては４ファイルだったり、８ファイルだったりすることもあるが、その場合はそれら４ファイルまたは８ファイルの全てが対象となる。以下同じ）を、もう一方のクラスタノードからコピーしてきて上書きしてしまう。
ここでは、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…もうちょっと詳しい情報が欲しいなあ。でも、別にアセンブラを使うわけでもないサーバ屋さんにはそれほど必要ないか。。。。。（笑）
↑このページの/proc/cpuinfo の「flags」についての調査結果を追記しました。
AMD…もうちょっと詳しい情報が欲しいなあ。でも、別にアセンブラを使うわけでもないサーバ屋さんにはそれほど必要ないか。。。。。（笑）
ディスクデバイス名 [備忘録]
LinuxでHDDを接続すると、
/dev/sda
とか、
/dev/hdb
とかいう具合に、aから順にデバイス名が割り当てられるわけです。
で、zまで行ったら、その次はどうなるの？という疑問があったわけです。（笑）
そんな中、会社にこのよーなマシンが登場しました。。。
sdyまできてる！！
というわけで、コイツに急遽ＵＳＢなディスクを複数接続してみた！！！
そしたらあーた！！
sdaa
そうきましたか。（笑）
で、sdaa、sdab、sdac…となっているのですが、ということは、sdazまで行ったら次はsdbaなのかな？？
じゃあ、sdzzの次はsdaaaかすら・・・？
検証不能につき識者の方のツッコミ求む！！！！（笑）
/dev/sda
とか、
/dev/hdb
とかいう具合に、aから順にデバイス名が割り当てられるわけです。
で、zまで行ったら、その次はどうなるの？という疑問があったわけです。（笑）
そんな中、会社にこのよーなマシンが登場しました。。。
[root@chunli ~]# cat /proc/partitions major minor #blocks name 8 0 976762584 sda 8 16 976762584 sdb 8 32 976762584 sdc 8 48 976762584 sdd 8 64 976762584 sde 8 80 976762584 sdf 8 96 976762584 sdg 8 112 976762584 sdh 8 128 976762584 sdi 8 144 976762584 sdj 8 160 976762584 sdk 8 176 976762584 sdl 8 192 976762584 sdm 8 208 976762584 sdn 8 224 976762584 sdo 8 240 976762584 sdp 65 0 976762584 sdq 65 16 976762584 sdr 65 32 976762584 sds 65 48 976762584 sdt 65 64 976762584 sdu 65 80 976762584 sdv 65 96 976762584 sdw 65 112 976762584 sdx 104 0 573366680 cciss/c0d0 104 1 104391 cciss/c0d0p1 104 2 573255427 cciss/c0d0p2 65 128 1957888 sdy 65 129 1 sdy1 65 132 4080 sdy4 65 133 255984 sdy5 65 134 255984 sdy6 65 135 112624 sdy7 65 136 292848 sdy8 253 0 534151168 dm-0 253 1 39092224 dm-1 9 0 10744387456 md0
sdyまできてる！！
というわけで、コイツに急遽ＵＳＢなディスクを複数接続してみた！！！
そしたらあーた！！
[root@chunli ~]# cat /proc/partitions major minor #blocks name 8 0 976762584 sda 8 16 976762584 sdb （途中省略） 65 144 1953514584 sdz 65 145 1953512001 sdz1 65 160 1953514584 sdaa 65 161 1953512001 sdaa1 65 176 1953514584 sdab 65 177 1953512001 sdab1 65 192 1953514584 sdac 65 193 1953512001 sdac1 253 2 7813988352 dm-2
sdaa
そうきましたか。（笑）
で、sdaa、sdab、sdac…となっているのですが、ということは、sdazまで行ったら次はsdbaなのかな？？
じゃあ、sdzzの次はsdaaaかすら・・・？
検証不能につき識者の方のツッコミ求む！！！！（笑）
/proc/cpuinfo 再調査編 [備忘録]
2011.03.04追記：
さらにFlagsの項目について調査結果を追記した。
/proc/cpuinfoの中身の再調査編です。
/proc/cpuinfoの「flags」について追加調査してみた。
fpu 浮動小数点演算ユニットに対応
→浮動小数点演算プロセッサ「Intel387」に相当するFPUを搭載している。
vme 仮想モード拡張機能
→プロセッサは仮想8086モードをサポートしている
de デバッグ拡張機能
→プロセッサはI/Oブレークポイントをサポートしている
pse ページサイズ拡張機能
→プロセッサは4Mバイトのサイズのページをサポートしている
tsc タイムスタンプカウンタ
→「RDTSC命令」に対応している
※CPUクロックごとに加算されるカウンタを読み出す命令らしい。
msr モデル固有レジスタ
→「RDMSR命令」「WRMSR命令」および、モデル固有レジスタ(MSR)をサポートしている
pae 物理アドレス拡張機能
→32ビットを超える物理アドレスをサポートしている
※要するに、4GB以上の物理アドレスに対応…ということかな？
mce マシンチェック例外
→マシンチェック例外（例外18番）に対応している
※回復不能なハードウェア障害を検出する機能？よくわかりません。Microsoft的には、コレを検出すると「対処不能です。壊れてます。」という主張になるらしい。
cx8 8バイト比較交換命令
→「CMPXCHG8命令」に対応している
apic オンチップAPICハードウェア
→プロセッサはソフトウェアによるアクセスが可能なローカルAPICを搭載している
※「ローカルAPIC」は、CPU内部にある「割り込み」を制御するためのコントローラ。マルチCPU（マルチコアCPU）のプロセッサ間通信などにも使われたりする仕組み
sep 高速システムコール
→プロセッサは高速システムコール命令「SYSENTER命令」「SYSEXIT命令」に対応している。
※この２命令は、CPUの動作を「カーネルモード」に切り替えるために利用される。（特権モードとどう違うのかな？）従来の切り替え方法よりも高速に切り替えることができるため、オーバーヘッドが少なくなる…というシロモノだそうで。
mtrr メモリタイプ範囲レジスタ
→プロセッサは「MTRR_CAPレジスタ」なるものをサポートしている
pge ページ・グローバル・イネーブル
→ページ・ディレクトリ・エントリ（pde）とページ・テーブル・エントリ（pte）内とでグローバルビットをサポートしている
※なんのこっちゃ？
mca マシン・チェック・アーキテクチャ
→MCG_CAPレジスタをサポートしている
※そういうものが存在するらしい。（笑）
cmov 条件付移動命令
→「CMOVcc命令」をサポートしている。fpuフラグと同時に有効になっている場合は、「FCMOVCC命令」と「FCOMI命令」もサポートしている
pat ページ属性テーブル
→ページ属性テーブルをサポートしている。メモリタイプ範囲レジスタ(MTRR)を補強するもの。
※詳細は何かの魔法の呪文みたいで理解不能でした…
pse36 36ビット・ページサイズ拡張機能
→プロセッサが4GBを超える物理メモリに対して4MBサイズのページ機能に対応していることを示す
※「pse」フラグは、「4MBサイズのページ機能に対応してますよ」というだけみたい。このフラグはその機能が4GB以上のメモリ領域でも対応してますよということっぽい
psn プロセッサシリアルナンバーが有効
→96ビット長のプロセッサシリアルナンバーをサポートしていて、かつその機能が有効になっている
※「存在」かつ「有効」というのは、BIOSでOFFにできちゃうからかな。
clflush CLFLUSH命令のサポート
→プロセッサは「CLFLUSH命令」をサポートしている
※CPUのキャッシュをクリアする命令？ …のように読めた。（私のつたない英語力では）
dts デバッグストア
→プロセッサはアドレスへの分岐とアドレスからの分岐の履歴をメモリに書き込む機能を持っている
acpi 温度モニタとソフトウェア制御クロック機能
→プロセッサの温度を監視し、ソフトウェアの制御下であらかじめ定義されたプロセッサのパフォーマンスを調整するための機能に対応している
mmx MMXテクノロジ
→インテル・アキテクチャMMXテクノロジ拡張命令セットに対応している
fxsr 高速浮動小数点セーブ／リストア
→浮動小数点コンテキストの高速セーブ／リストア用の命令「FXSAVE命令」と「FXRSTOR命令」に対応している
sse ストリーミングSIMD拡張命令
sse2 ストリーミングSIMD拡張命令２
sse3 ストリーミングSIMD拡張命令３
→プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令（１、２、あるいは３）をサポートしている
ss 自己スヌープ
→プロセッサは、バスに発行されるトランザクションについてプロセッサのキャッシュ構造のスヌープを実行することで、競合するメモリタイプを管理する機能をサポートしている
※なんかの呪文？＾－＾
ht ハイパースレッディング・テクノロジ
→このプロセッサのマイクロアーキテクチャは、同一の物理パッケージ内で複数の論理プロセッサを動作させる機能を持っている。
※このフィールドは、このプロセッサのハイパースレッディング・テクノロジがイネーブルになっていることを示すわけではない。
tm 温度モニター
tm2 温度モニター２
→温度モニターの自動温度制御回路を実装している
pbe ペンディング・ブレーク・イネーブル
→プロセッサがストップクロック・ステートになっているとき、割り込みが未処理であり、通常の動作に戻って割り込みを処理する必要があることをプロセッサに報告する機能をサポートしている
monitor MONITOR命令/MWAIT命令のサポート
→プロセッサは「MONITOR命令」と「MWAIT命令」をサポートしている
est 拡張版Intel SpeedStepテクノロジ
→プロセッサは第2世代のIntel SpeedStepテクノロジに対応している
cx16 CMPXCHG18B命令のサポート
→「CMPXCHG16B」命令をサポートしている
xtpr タスク・プライオリティ・メッセージの送信機能
→「タスク・プライオリティ・メッセージ」の送信を無効にする機能をサポートしている
nx エグゼキュート・ディスエーブル・ビット
→PAEモード・ページングが有効の場合に、エグゼキュート・ディスエーブル・ビットに対応する
lm ロングモード
→IA-32アーキテクチャの64ビット拡張技術をサポートする
lahf LAHF命令／SAHF命令
→64ビット拡張技術が有効時に「LAHF命令」「SAHF命令」をサポートする
以下は2011.03.04追記分
3dnow 3DNow!命令セット
→AMD 3DNow!命令セットをサポートしている
3dnowext 3DNow!拡張命令セット
→AMD 3DNow!拡張命令セットをサポートしている
popcnt POPCNT命令
→ビット数を数える命令「POPCNT」命令をサポートしている
ssse3 Supplemental Streaming SIMD Extensions 3
sse4_1 ストリーミングSIMD拡張命令４．１
sse4_2 ストリーミングSIMD拡張命令４．２
→プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令（Supplemental ３または４．１あるいは４．２）をサポートしている
mmxext AMD拡張MMX命令セット
→AMDが拡張したMMX命令セットに対応している
cmp_legacy マルチコアプロセッサに関する情報の取得方法
→マルチコアプロセッサに関する情報について、Legacy Methodに対応している。（推奨はされていないらしい）
extapic x2APIC
→プロセッサはx2APIC（Extend x2APICモード）に対応している。
※マルチプロセッサ環境において、高速動作を可能にするためのギミック…らしい？
syscall syscall/sysret命令
→高速にカーネルモードに切り替える／復帰するためのsyscall命令とsysret命令に対応している
rdtscp rdtscp命令
→TSCに加えてTSC_AUX領域も同時に読み込むようにrdtsc命令を拡張した「rdtscp」命令に対応している。
※rdtsc命令への対応は「tsc」フラグで確認できる
svm 「Secure Virtual Machine」
→AMDの仮想化支援技術「Secure Virtual Machine」に対応している
※Intelでいうところの「vt」フラグに対応するものかすら？
misalignsse Misaligned SSE モード
→Misaligned Access Support Added for SSE Instructions
※詳しいことは不明。AMDの拡張機能？？
さらにFlagsの項目について調査結果を追記した。
/proc/cpuinfoの中身の再調査編です。
/proc/cpuinfoの「flags」について追加調査してみた。
fpu 浮動小数点演算ユニットに対応
→浮動小数点演算プロセッサ「Intel387」に相当するFPUを搭載している。
vme 仮想モード拡張機能
→プロセッサは仮想8086モードをサポートしている
de デバッグ拡張機能
→プロセッサはI/Oブレークポイントをサポートしている
pse ページサイズ拡張機能
→プロセッサは4Mバイトのサイズのページをサポートしている
tsc タイムスタンプカウンタ
→「RDTSC命令」に対応している
※CPUクロックごとに加算されるカウンタを読み出す命令らしい。
msr モデル固有レジスタ
→「RDMSR命令」「WRMSR命令」および、モデル固有レジスタ(MSR)をサポートしている
pae 物理アドレス拡張機能
→32ビットを超える物理アドレスをサポートしている
※要するに、4GB以上の物理アドレスに対応…ということかな？
mce マシンチェック例外
→マシンチェック例外（例外18番）に対応している
※回復不能なハードウェア障害を検出する機能？よくわかりません。Microsoft的には、コレを検出すると「対処不能です。壊れてます。」という主張になるらしい。
cx8 8バイト比較交換命令
→「CMPXCHG8命令」に対応している
apic オンチップAPICハードウェア
→プロセッサはソフトウェアによるアクセスが可能なローカルAPICを搭載している
※「ローカルAPIC」は、CPU内部にある「割り込み」を制御するためのコントローラ。マルチCPU（マルチコアCPU）のプロセッサ間通信などにも使われたりする仕組み
sep 高速システムコール
→プロセッサは高速システムコール命令「SYSENTER命令」「SYSEXIT命令」に対応している。
※この２命令は、CPUの動作を「カーネルモード」に切り替えるために利用される。（特権モードとどう違うのかな？）従来の切り替え方法よりも高速に切り替えることができるため、オーバーヘッドが少なくなる…というシロモノだそうで。
mtrr メモリタイプ範囲レジスタ
→プロセッサは「MTRR_CAPレジスタ」なるものをサポートしている
pge ページ・グローバル・イネーブル
→ページ・ディレクトリ・エントリ（pde）とページ・テーブル・エントリ（pte）内とでグローバルビットをサポートしている
※なんのこっちゃ？
mca マシン・チェック・アーキテクチャ
→MCG_CAPレジスタをサポートしている
※そういうものが存在するらしい。（笑）
cmov 条件付移動命令
→「CMOVcc命令」をサポートしている。fpuフラグと同時に有効になっている場合は、「FCMOVCC命令」と「FCOMI命令」もサポートしている
pat ページ属性テーブル
→ページ属性テーブルをサポートしている。メモリタイプ範囲レジスタ(MTRR)を補強するもの。
※詳細は何かの魔法の呪文みたいで理解不能でした…
pse36 36ビット・ページサイズ拡張機能
→プロセッサが4GBを超える物理メモリに対して4MBサイズのページ機能に対応していることを示す
※「pse」フラグは、「4MBサイズのページ機能に対応してますよ」というだけみたい。このフラグはその機能が4GB以上のメモリ領域でも対応してますよということっぽい
psn プロセッサシリアルナンバーが有効
→96ビット長のプロセッサシリアルナンバーをサポートしていて、かつその機能が有効になっている
※「存在」かつ「有効」というのは、BIOSでOFFにできちゃうからかな。
clflush CLFLUSH命令のサポート
→プロセッサは「CLFLUSH命令」をサポートしている
※CPUのキャッシュをクリアする命令？ …のように読めた。（私のつたない英語力では）
dts デバッグストア
→プロセッサはアドレスへの分岐とアドレスからの分岐の履歴をメモリに書き込む機能を持っている
acpi 温度モニタとソフトウェア制御クロック機能
→プロセッサの温度を監視し、ソフトウェアの制御下であらかじめ定義されたプロセッサのパフォーマンスを調整するための機能に対応している
mmx MMXテクノロジ
→インテル・アキテクチャMMXテクノロジ拡張命令セットに対応している
fxsr 高速浮動小数点セーブ／リストア
→浮動小数点コンテキストの高速セーブ／リストア用の命令「FXSAVE命令」と「FXRSTOR命令」に対応している
sse ストリーミングSIMD拡張命令
sse2 ストリーミングSIMD拡張命令２
sse3 ストリーミングSIMD拡張命令３
→プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令（１、２、あるいは３）をサポートしている
ss 自己スヌープ
→プロセッサは、バスに発行されるトランザクションについてプロセッサのキャッシュ構造のスヌープを実行することで、競合するメモリタイプを管理する機能をサポートしている
※なんかの呪文？＾－＾
ht ハイパースレッディング・テクノロジ
→このプロセッサのマイクロアーキテクチャは、同一の物理パッケージ内で複数の論理プロセッサを動作させる機能を持っている。
※このフィールドは、このプロセッサのハイパースレッディング・テクノロジがイネーブルになっていることを示すわけではない。
tm 温度モニター
tm2 温度モニター２
→温度モニターの自動温度制御回路を実装している
pbe ペンディング・ブレーク・イネーブル
→プロセッサがストップクロック・ステートになっているとき、割り込みが未処理であり、通常の動作に戻って割り込みを処理する必要があることをプロセッサに報告する機能をサポートしている
monitor MONITOR命令/MWAIT命令のサポート
→プロセッサは「MONITOR命令」と「MWAIT命令」をサポートしている
est 拡張版Intel SpeedStepテクノロジ
→プロセッサは第2世代のIntel SpeedStepテクノロジに対応している
cx16 CMPXCHG18B命令のサポート
→「CMPXCHG16B」命令をサポートしている
xtpr タスク・プライオリティ・メッセージの送信機能
→「タスク・プライオリティ・メッセージ」の送信を無効にする機能をサポートしている
nx エグゼキュート・ディスエーブル・ビット
→PAEモード・ページングが有効の場合に、エグゼキュート・ディスエーブル・ビットに対応する
lm ロングモード
→IA-32アーキテクチャの64ビット拡張技術をサポートする
lahf LAHF命令／SAHF命令
→64ビット拡張技術が有効時に「LAHF命令」「SAHF命令」をサポートする
以下は2011.03.04追記分
3dnow 3DNow!命令セット
→AMD 3DNow!命令セットをサポートしている
3dnowext 3DNow!拡張命令セット
→AMD 3DNow!拡張命令セットをサポートしている
popcnt POPCNT命令
→ビット数を数える命令「POPCNT」命令をサポートしている
ssse3 Supplemental Streaming SIMD Extensions 3
sse4_1 ストリーミングSIMD拡張命令４．１
sse4_2 ストリーミングSIMD拡張命令４．２
→プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令（Supplemental ３または４．１あるいは４．２）をサポートしている
mmxext AMD拡張MMX命令セット
→AMDが拡張したMMX命令セットに対応している
cmp_legacy マルチコアプロセッサに関する情報の取得方法
→マルチコアプロセッサに関する情報について、Legacy Methodに対応している。（推奨はされていないらしい）
extapic x2APIC
→プロセッサはx2APIC（Extend x2APICモード）に対応している。
※マルチプロセッサ環境において、高速動作を可能にするためのギミック…らしい？
syscall syscall/sysret命令
→高速にカーネルモードに切り替える／復帰するためのsyscall命令とsysret命令に対応している
rdtscp rdtscp命令
→TSCに加えてTSC_AUX領域も同時に読み込むようにrdtsc命令を拡張した「rdtscp」命令に対応している。
※rdtsc命令への対応は「tsc」フラグで確認できる
svm 「Secure Virtual Machine」
→AMDの仮想化支援技術「Secure Virtual Machine」に対応している
※Intelでいうところの「vt」フラグに対応するものかすら？
misalignsse Misaligned SSE モード
→Misaligned Access Support Added for SSE Instructions
※詳しいことは不明。AMDの拡張機能？？
WindowsのActive DirectoryとbindによるDNSの連携 やりなおし編おかわり [備忘録]
自慢じゃないが以下略
さて、少し前にLinuxでbindなDNSサーバにWindows Active Directoryで必要なDNSの機能を肩代わりさせようということでbind9に連携の設定を入れたが、どうもまだ足らないことがあるようで、時間がたったらいろいろ不都合が現れた。
まったく…Windows Serverはわからんのう…（遠い目
ということで、あれこれ調査をしていたらですね…
①名前解決ができなくなってる
②ドメインコントローラが見つからない！とか怒られる。
③nslookup してみると SRVFAILとか怒られる
という訳で原因調査と対応を検討してみた。
すると…
bind9系をADのDNSとして使おうとしたらはまった（cvyan様）という記事を発見。
yumでインストールしたbind9はまさに9.3.1以降！！
そんな訳で、zoneブロックの記述を修正（というか追加）してですね…
と、「check-names ignore;」を追加。この行の追加は、_msdcs以外にも追加する必要がある。（要するに動的更新を許可しているゾーン全部）
しかしまだnslookupではちゃんと名前解決できずWindowsXPなクライアントからも「ドメインコントローラが見つかりません」というエラーが。
調査の結果、/var/log/messagesに
Apr 8 10:32:18 dns001 named[26294]: zone _msdcs.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _sites.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _tcp.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _udp.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
とかいうエラーが出ている。
動的更新のジャーナルファイルの中で不整合が起きたらしい。
これにはちょいと心当たりがあって、Linuxでbind9なDNSマスターしか存在しなかったところにDNSスレーブを追加する設定を行っていたのだが、その際に各ゾーンファイルに「NS」レコードを追加するべくゾーンファイルを修正していた。
どうもコレがジャーナルファイルの不整合の原因になったようだ…ということらしい。（かなり不確定ｗ）
というわけで、namedを一旦停止した上で、/var/namedディレクトリにある、拡張子が「.jnl」のファイルを全部削除してからnamedを再度起動。
messagesファイルにもnslookupの実行にもエラーが出なくなったことを確認して復旧ということに。
さて、少し前にLinuxでbindなDNSサーバにWindows Active Directoryで必要なDNSの機能を肩代わりさせようということでbind9に連携の設定を入れたが、どうもまだ足らないことがあるようで、時間がたったらいろいろ不都合が現れた。
まったく…Windows Serverはわからんのう…（遠い目
ということで、あれこれ調査をしていたらですね…
①名前解決ができなくなってる
②ドメインコントローラが見つからない！とか怒られる。
③nslookup してみると SRVFAILとか怒られる
という訳で原因調査と対応を検討してみた。
すると…
bind9系をADのDNSとして使おうとしたらはまった（cvyan様）という記事を発見。
yumでインストールしたbind9はまさに9.3.1以降！！
そんな訳で、zoneブロックの記述を修正（というか追加）してですね…
zone "_msdcs.mysection.mycompany.co.jp" in {
type master;
file "db._msdcs.mysection.mycompany.co.jp.zone";
allow-update {
192.168.1.1;
192.168.1.2;
};
allow-transfer {
192.168.1.5;
};
check-names ignore;
};
と、「check-names ignore;」を追加。この行の追加は、_msdcs以外にも追加する必要がある。（要するに動的更新を許可しているゾーン全部）
しかしまだnslookupではちゃんと名前解決できずWindowsXPなクライアントからも「ドメインコントローラが見つかりません」というエラーが。
調査の結果、/var/log/messagesに
Apr 8 10:32:18 dns001 named[26294]: zone _msdcs.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _sites.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _tcp.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
Apr 8 10:32:18 dns001 named[26294]: zone _udp.mysection.mycompany.co.jp/IN/Office_Network: journal rollforward failed: journal out of sync with zone
とかいうエラーが出ている。
動的更新のジャーナルファイルの中で不整合が起きたらしい。
これにはちょいと心当たりがあって、Linuxでbind9なDNSマスターしか存在しなかったところにDNSスレーブを追加する設定を行っていたのだが、その際に各ゾーンファイルに「NS」レコードを追加するべくゾーンファイルを修正していた。
どうもコレがジャーナルファイルの不整合の原因になったようだ…ということらしい。（かなり不確定ｗ）
というわけで、namedを一旦停止した上で、/var/namedディレクトリにある、拡張子が「.jnl」のファイルを全部削除してからnamedを再度起動。
messagesファイルにもnslookupの実行にもエラーが出なくなったことを確認して復旧ということに。
WindowsのActive DirectoryとbindによるDNSの連携 やりなおし編 [備忘録]
自慢じゃないが以下略。
とにかくWindows Serverがいかにアレで困ったちゃんなのか、世界の端っこで悪口雑言を叫びたいのだが以下略。
さて。前アーティクルで、「ゾーンデータの動的更新を許可すれば～」みたいなことを書いた。
が、コレが実に問題のある対応方法であるということが判った（いや…冷静に考えれば最初からわかっていたはずだ！＞をれ）ので、別のやり方を探してみた。
なにが問題だったか。それは…
問題点その１：とにかくWindows Serverがゾーンデータをみるみる書き換えてグチャグチャにしてくれるということ。
→ゾーンデータにクライアントやサーバを書き足したくなって、ゾーンファイルを開こうものならそこには…orz
問題点その２：動的更新を全て許可してしまっているので、セキュリティもへったくれもない。
→そうだよね…Windows Serverからはゾーンデータいじりたい放題だものね…orz
ということで、これらに対する問題を解決すべく立ち上がったのであった！！！！！！！
前提：
Windows Server でActive Directoryを運用している。
Linuxなサーバでbind9を運用していて、なおかつこのbind9をプライマリーでマスターなDNSにして使いたい
少なくともWindows ServerのIPアドレスは固定されている。（DHCPは使ってない。クライアントは別としても…）
※セカンダリーでスレーブなDNSについては後で考えることにする。
ここで例示するゾーン、あるいはドメイン名は「mysection.mycompany.co.jp」と仮定する。
アプローチ：
Windows Serverからの動的更新を拒否してしまう方法もある。が、しかし、いろいろと問題が多い様子であることから、やはりWindows Serverからの動的更新は許可せざるを得ない様子だ。
ではどうするか？
ゾーンデータの全体を動的許可の対象としてしまうから悪いのであったため、Windows Serverにゾーンデータを汚させてやってもよいサブゾーンを作成することでこの問題を回避することにする。
/var/log/messagesを見たり、ゾーンデータを眺めていると、
_msdcs
_sites
_tcp
_udp
というサブゾーン（サブドメイン）を使っているようであった。Windows Serverから動的更新にくるドメイン名・サーバ名等々はには必ずこれらのどれかの名前が入っている。
つまり…
mysection.mycompany.co.jp への動的更新は不許可
にしつつ、
_msdcs.mysection.mycompany.co.jp
_sites.mysection.mycompany.co.jp
_tcp.mysection.mycompany.co.jp
_udp.mysection.mycompany.co.jp といった４つのゾーンへの動的更新のみ許可
すれば、もともとのゾーンデータへの汚染は回避されるのではないか！？
…とか妄想してみた。
では、やってみよう！
① まずはゾーンデータの修復から…orz
もともとのゾーンデータ「mysection.mycompany.co.jp」をちゃんと作成しなおす。
前アーティクルを信じちゃったみなさん…ｺﾞﾒﾝﾅｻｲ…
謝罪と賠償は私じゃなくてマイクロﾅﾝﾄｶに求めてください…orz
で、修復ついでに、ゾーンファイルの中にサブゾーンへの委任情報を記入する。つまり…
を書き足しておく。
②サブゾーンのゾーンファイルを作成する。
上記の４サブゾーンについてゾーンファイルを作成する。
TTLと、SOAレコード、そしてNSレコードだけあればよいはず。テンプレートとしてはこんな感じか？
とかかな？SOAレコードのパラメータは適宜変更してちょうだい。
③ /etc/named.confを修正し、サブゾーンの設定を追加する。ついでに動的更新まわりの修正
/etc/named.confを修正する。
mysection.mycompany.co.jpへの動的更新を不許可とし、
４つのサブゾーンを作成、そちらへの動的更新を許可してやることとする。
まず、mysection.mycompany.co.jpの部分は…
とかこんな感じに。
そして、４つのサブゾーンについては…
「192.168.1.1」はActive Directoryサーバのアドレスを書き入れる。aclセクションで列挙してもいいね。
上記の例示では「_msdcs」について記述しているが、同様に_sitesや_tcpや_ucpについても記述してやる。
④ そしてnamedを起動する！
service named start
とかこんな感じで！！
⑤ Windows Server側のネットワークの設定を変更する。
Windows Server側の、ネットワーク接続のプロパティを変更し、DNSの参照先をLinuxでbind9なサーバに変更しよう。
変更が終わったら、コマンドプロンプトを起動して、ipconfig /registerdnsを実行して15分くらい待つ。
⑥ /var/log/messagesとかを監視して設定が変更され、オリジナルのゾーンファイルが汚染されないことを確認する
ちなみに、/var/log/messagesを見ていると、mysection.mycompany.co.jpゾーンへの更新に拒否されている形跡のログが出てくる。これはどうやら
Windows Serverが、自分自身のAレコードを動的に追加・更新しにくることが原因らしい。
とめる方法は現在模索中でよく判っていない。
が、これはエラーになっていてももともとのゾーンファイルの中にWindows Serverのアドレスをきちんと書いておけば問題なく参照できるので、今は目を瞑ることとする…
識者の方、とめ方を知っていたら是非教えてくだしあ。
とにかくWindows Serverがいかにアレで困ったちゃんなのか、世界の端っこで悪口雑言を叫びたいのだが以下略。
さて。前アーティクルで、「ゾーンデータの動的更新を許可すれば～」みたいなことを書いた。
が、コレが実に問題のある対応方法であるということが判った（いや…冷静に考えれば最初からわかっていたはずだ！＞をれ）ので、別のやり方を探してみた。
なにが問題だったか。それは…
問題点その１：とにかくWindows Serverがゾーンデータをみるみる書き換えてグチャグチャにしてくれるということ。
→ゾーンデータにクライアントやサーバを書き足したくなって、ゾーンファイルを開こうものならそこには…orz
問題点その２：動的更新を全て許可してしまっているので、セキュリティもへったくれもない。
→そうだよね…Windows Serverからはゾーンデータいじりたい放題だものね…orz
ということで、これらに対する問題を解決すべく立ち上がったのであった！！！！！！！
前提：
Windows Server でActive Directoryを運用している。
Linuxなサーバでbind9を運用していて、なおかつこのbind9をプライマリーでマスターなDNSにして使いたい
少なくともWindows ServerのIPアドレスは固定されている。（DHCPは使ってない。クライアントは別としても…）
※セカンダリーでスレーブなDNSについては後で考えることにする。
ここで例示するゾーン、あるいはドメイン名は「mysection.mycompany.co.jp」と仮定する。
アプローチ：
Windows Serverからの動的更新を拒否してしまう方法もある。が、しかし、いろいろと問題が多い様子であることから、やはりWindows Serverからの動的更新は許可せざるを得ない様子だ。
ではどうするか？
ゾーンデータの全体を動的許可の対象としてしまうから悪いのであったため、Windows Serverにゾーンデータを汚させてやってもよいサブゾーンを作成することでこの問題を回避することにする。
/var/log/messagesを見たり、ゾーンデータを眺めていると、
_msdcs
_sites
_tcp
_udp
というサブゾーン（サブドメイン）を使っているようであった。Windows Serverから動的更新にくるドメイン名・サーバ名等々はには必ずこれらのどれかの名前が入っている。
つまり…
mysection.mycompany.co.jp への動的更新は不許可
にしつつ、
_msdcs.mysection.mycompany.co.jp
_sites.mysection.mycompany.co.jp
_tcp.mysection.mycompany.co.jp
_udp.mysection.mycompany.co.jp といった４つのゾーンへの動的更新のみ許可
すれば、もともとのゾーンデータへの汚染は回避されるのではないか！？
…とか妄想してみた。
では、やってみよう！
① まずはゾーンデータの修復から…orz
もともとのゾーンデータ「mysection.mycompany.co.jp」をちゃんと作成しなおす。
前アーティクルを信じちゃったみなさん…ｺﾞﾒﾝﾅｻｲ…
謝罪と賠償は私じゃなくてマイクロﾅﾝﾄｶに求めてください…orz
で、修復ついでに、ゾーンファイルの中にサブゾーンへの委任情報を記入する。つまり…
_msdcs IN NS dns.mysection.mycompany.co.jp. _sites IN NS dns.mysection.mycompany.co.jp. _tcp IN NS dns.mysection.mycompany.co.jp. _udp IN NS dns.mysection.mycompany.co.jp.
を書き足しておく。
②サブゾーンのゾーンファイルを作成する。
上記の４サブゾーンについてゾーンファイルを作成する。
TTLと、SOAレコード、そしてNSレコードだけあればよいはず。テンプレートとしてはこんな感じか？
$TTL 1d
@ IN SOA dns.mysection.mycompany.co.jp admin.mycompany.co.jp (
2010032901
3h
1h
1w
1h )
IN NS dns.mysection.mycompany.co.jp.
とかかな？SOAレコードのパラメータは適宜変更してちょうだい。
③ /etc/named.confを修正し、サブゾーンの設定を追加する。ついでに動的更新まわりの修正
/etc/named.confを修正する。
mysection.mycompany.co.jpへの動的更新を不許可とし、
４つのサブゾーンを作成、そちらへの動的更新を許可してやることとする。
まず、mysection.mycompany.co.jpの部分は…
zone "mysection.mycompany.co.jp" in {
type master;
file "db.mysection.mycompany.co.jp.zone";
};
とかこんな感じに。
そして、４つのサブゾーンについては…
zone "_msdcs.mysection.mycompany.co.jp" in {
type master;
file "db._msdcs.mysection.mycompany.co.jp.zone";
allow-update {
192.168.1.1;
};
};
「192.168.1.1」はActive Directoryサーバのアドレスを書き入れる。aclセクションで列挙してもいいね。
上記の例示では「_msdcs」について記述しているが、同様に_sitesや_tcpや_ucpについても記述してやる。
④ そしてnamedを起動する！
service named start
とかこんな感じで！！
⑤ Windows Server側のネットワークの設定を変更する。
Windows Server側の、ネットワーク接続のプロパティを変更し、DNSの参照先をLinuxでbind9なサーバに変更しよう。
変更が終わったら、コマンドプロンプトを起動して、ipconfig /registerdnsを実行して15分くらい待つ。
⑥ /var/log/messagesとかを監視して設定が変更され、オリジナルのゾーンファイルが汚染されないことを確認する
ちなみに、/var/log/messagesを見ていると、mysection.mycompany.co.jpゾーンへの更新に拒否されている形跡のログが出てくる。これはどうやら
Windows Serverが、自分自身のAレコードを動的に追加・更新しにくることが原因らしい。
とめる方法は現在模索中でよく判っていない。
が、これはエラーになっていてももともとのゾーンファイルの中にWindows Serverのアドレスをきちんと書いておけば問題なく参照できるので、今は目を瞑ることとする…
識者の方、とめ方を知っていたら是非教えてくだしあ。
WindowsのActive DirectoryとbindによるDNSの連携 [備忘録]
※ MicrosoftのTECHNETやその他検索エンジンからお越しの方は、このアーティクルではなく、WindowsのActive DirectoryとbindによるDNSの連携 やりなおし編の方をご覧ください。このアーティクルのままだと酷い目に遭いますので…orz
自慢じゃないが、Windows Serverについては門外漢だったので、Windows Serverについてはなかばほったらかしししてたところ、Active DirectoryにはDNSが必須で、Windows Serverに組み込まれているDNSがいろいろとアレで困ったちゃんだったので、もともとbind9でDNSを立て、そちらにActive Directoryが必要とするDNSの機能について面倒を見させることに。
調べてみると、Windows ServerにWindows版のbindを入れて…みたいな記事はいろいろ出てきたようだったが、Linuxのbind9で…という情報がわかりづらかったので、ここで軽く整理。
前提知識として、『どうしてActive DirectoryにDNSが必須なんですか？』という疑問点について整理すると、結局のところ、そのドメイン（？）を管理しているADサーバの情報を、DNSのSRVレコードに登録・管理しているという点になるのかすらね。よって、bind9側はこの「SRVレコード」に対応していなければならないが、いまどきのbind9なら全く問題なく対応している模様だ。
そして、注意事項としては、Active DirectoryはDNSデータを動的に更新するようなので、少なくとも、Windows ServerからのDNS更新については許可すべきということらしい。Microsoftの説明によれば、「強く推奨」ということのようなので、最悪一切不許可でも良いのかもしれない。そのあたりは組織内のネットワーク管理ポリシー、あるいはDNSの管理ポリシー次第か。
では、Linuxなbind9にWindows ServerのActive Directoryで必要とするDNSの機能の面倒をみさせる方法を以下にメモメモ。
おおまかな手順としては以下の通りか。
①bind9が動作しているLinuxサーバ側で、Active Directoryで使用するドメイン（？）についてゾーンを作成する
②bind9が動作しているLinuxサーバ側で、Windows ServerからのDNSゾーンデータの動的更新について許可設定を加える
③Active Directoryを管理しているWindows Server側の「TCP/IPのプロパティ」で、DNSの参照先をbind9が動作しているLinuxサーバ」に変更する
④Active Directoryを管理しているWindows Serverに、DNSを強制的に動的更新するよう指示する。（または再起動でも…）
⑤最大で１５分待つ
①bind9が動作しているLinuxサーバ側で、Active Directoryで使用するドメイン（？）についてゾーンを作成する
/etc/named.confに、そのドメインのPCとかサーバとかを管理するゾーンを作成する。簡単に書くとこんなのを追加。
mysection.mycompany.co.jpの部分はそれぞれのドメイン名に応じて変更してもらうとして、ゾーンファイルの中には最低でもSOAレコードとNSレコード、DNSサーバ自身とWindows ServerのAレコードかCNAMEレコードあたりは書いておく。
ここまでの部分がまずは完全であることを確認する。nslookupとかdigとかお好みのコマンドでどうぞ。
②bind9が動作しているLinuxサーバ側で、Windows ServerからのDNSゾーンデータの動的更新について許可設定を加える
「①」が完璧で有ることがかくにんできたら、次は先ほどのゾーンセクションの中に、動的更新を許可する設定を追加する。
追記した部分は、
allow-update { Windows ServerのIPアドレス;
};
という部分。もし、Active Directoryサーバが複数立っている場合は、全部のサーバについて書く必要が有るらしい。
ここまで済んだら、namedをリロードなり再起動なりしておく。個人的には再起動を推奨かね？
③Active Directoryを管理しているWindows Server側の「TCP/IPのプロパティ」で、DNSの参照先をbind9が動作しているLinuxサーバ」に変更する
コントロールパネルからネットワークのプロパティを開き、TCP/IPの設定を変更する。DNSの参照先設定が記述されている部分を変更し、bind9が動作している（今設定変更を行った）Linuxサーバのアドレスを設定してOKをクリックして閉じる。
④Active Directoryを管理しているWindows Serverに、DNSを強制的に動的更新するよう指示する。（または再起動でも…）
Windows Serverのコマンドプロンプトから、IPCONFIG /REGISTERDNS というコマンドを入力する。
⑤最大で１５分待つ
DNSゾーンデータの動的更新が開始されると、（おそらく）/var/log/messages等にWindows Serverから更新があったので追加しましたよ～｜削除しましたよ～ みたいなログが出るので、それを確認する。rejectとかされているようなら、aclの設定とかiptablesの設定とか関係しそうなところをチェック。
自慢じゃないが、Windows Serverについては門外漢だったので、Windows Serverについてはなかばほったらかしししてたところ、Active DirectoryにはDNSが必須で、Windows Serverに組み込まれているDNSがいろいろとアレで困ったちゃんだったので、もともとbind9でDNSを立て、そちらにActive Directoryが必要とするDNSの機能について面倒を見させることに。
調べてみると、Windows ServerにWindows版のbindを入れて…みたいな記事はいろいろ出てきたようだったが、Linuxのbind9で…という情報がわかりづらかったので、ここで軽く整理。
前提知識として、『どうしてActive DirectoryにDNSが必須なんですか？』という疑問点について整理すると、結局のところ、そのドメイン（？）を管理しているADサーバの情報を、DNSのSRVレコードに登録・管理しているという点になるのかすらね。よって、bind9側はこの「SRVレコード」に対応していなければならないが、いまどきのbind9なら全く問題なく対応している模様だ。
そして、注意事項としては、Active DirectoryはDNSデータを動的に更新するようなので、少なくとも、Windows ServerからのDNS更新については許可すべきということらしい。Microsoftの説明によれば、「強く推奨」ということのようなので、最悪一切不許可でも良いのかもしれない。そのあたりは組織内のネットワーク管理ポリシー、あるいはDNSの管理ポリシー次第か。
では、Linuxなbind9にWindows ServerのActive Directoryで必要とするDNSの機能の面倒をみさせる方法を以下にメモメモ。
おおまかな手順としては以下の通りか。
①bind9が動作しているLinuxサーバ側で、Active Directoryで使用するドメイン（？）についてゾーンを作成する
②bind9が動作しているLinuxサーバ側で、Windows ServerからのDNSゾーンデータの動的更新について許可設定を加える
③Active Directoryを管理しているWindows Server側の「TCP/IPのプロパティ」で、DNSの参照先をbind9が動作しているLinuxサーバ」に変更する
④Active Directoryを管理しているWindows Serverに、DNSを強制的に動的更新するよう指示する。（または再起動でも…）
⑤最大で１５分待つ
①bind9が動作しているLinuxサーバ側で、Active Directoryで使用するドメイン（？）についてゾーンを作成する
/etc/named.confに、そのドメインのPCとかサーバとかを管理するゾーンを作成する。簡単に書くとこんなのを追加。
zone "mysection.mycompany.co.jp" in {
type master;
file "db.mysection.mycompany.co.jp.zone";
};
mysection.mycompany.co.jpの部分はそれぞれのドメイン名に応じて変更してもらうとして、ゾーンファイルの中には最低でもSOAレコードとNSレコード、DNSサーバ自身とWindows ServerのAレコードかCNAMEレコードあたりは書いておく。
ここまでの部分がまずは完全であることを確認する。nslookupとかdigとかお好みのコマンドでどうぞ。
②bind9が動作しているLinuxサーバ側で、Windows ServerからのDNSゾーンデータの動的更新について許可設定を加える
「①」が完璧で有ることがかくにんできたら、次は先ほどのゾーンセクションの中に、動的更新を許可する設定を追加する。
zone "mysection.mycompany.co.jp" in {
type master;
file "db.mysection.mycompany.co.jp.zone";
allow-update { 192.168.0.1;
};
};
追記した部分は、
allow-update { Windows ServerのIPアドレス;
};
という部分。もし、Active Directoryサーバが複数立っている場合は、全部のサーバについて書く必要が有るらしい。
ここまで済んだら、namedをリロードなり再起動なりしておく。個人的には再起動を推奨かね？
③Active Directoryを管理しているWindows Server側の「TCP/IPのプロパティ」で、DNSの参照先をbind9が動作しているLinuxサーバ」に変更する
コントロールパネルからネットワークのプロパティを開き、TCP/IPの設定を変更する。DNSの参照先設定が記述されている部分を変更し、bind9が動作している（今設定変更を行った）Linuxサーバのアドレスを設定してOKをクリックして閉じる。
④Active Directoryを管理しているWindows Serverに、DNSを強制的に動的更新するよう指示する。（または再起動でも…）
Windows Serverのコマンドプロンプトから、IPCONFIG /REGISTERDNS というコマンドを入力する。
⑤最大で１５分待つ
DNSゾーンデータの動的更新が開始されると、（おそらく）/var/log/messages等にWindows Serverから更新があったので追加しましたよ～｜削除しましたよ～ みたいなログが出るので、それを確認する。rejectとかされているようなら、aclの設定とかiptablesの設定とか関係しそうなところをチェック。
ぴろりん さん
-
nice! 18
記事 143
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
