So-net無料ブログ作成

LSIのRAIDカード、CLIからホットスペアディスクを追加する [備忘録]

 ものすごくニッチなメモだと思うが、ハマったのでメモ残しておく。(笑)

 LSIのRAIDカード9650SEでRAID5のアレイを作成してあるストレージサーバで、ディスクが1本故障。ホットスペアを使用したリビルドが走って事なきを得たが、ディスクを交換後、それをホットスペアディスクとして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の中に書くことといえば
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のテストではちゃんと通るのに。。。。。
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に対してアクセスしようとすると、クラスタの稼動系が切り替わったタイミングで…
[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…もうちょっと詳しい情報が欲しいなあ。でも、別にアセンブラを使うわけでもないサーバ屋さんにはそれほど必要ないか。。。。。(笑)

ディスクデバイス名 [備忘録]

 LinuxでHDDを接続すると、
 /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まできてる!!
 というわけで、コイツに急遽USBなディスクを複数接続してみた!!!
 そしたらあーた!!
[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命令」に対応している。
  ※この2命令は、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拡張命令2
sse3  ストリーミングSIMD拡張命令3
  →プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令(1、2、あるいは3)をサポートしている

ss  自己スヌープ
  →プロセッサは、バスに発行されるトランザクションについてプロセッサのキャッシュ構造のスヌープを実行することで、競合するメモリタイプを管理する機能をサポートしている
  ※なんかの呪文?^-^

ht  ハイパースレッディング・テクノロジ
  →このプロセッサのマイクロアーキテクチャは、同一の物理パッケージ内で複数の論理プロセッサを動作させる機能を持っている。
  ※このフィールドは、このプロセッサのハイパースレッディング・テクノロジがイネーブルになっていることを示すわけではない。

tm  温度モニター
tm2  温度モニター2
  →温度モニターの自動温度制御回路を実装している

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拡張命令4.1
sse4_2 ストリーミングSIMD拡張命令4.2
  →プロセッサはインテル・アーキテクチャ・ストリーミングSIMD拡張命令(Supplemental 3または4.1あるいは4.2)をサポートしている

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ブロックの記述を修正(というか追加)してですね…
        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」レコードを追加するべくゾーンファイルを修正していた。
 どうもコレがジャーナルファイルの不整合の原因になったようだ…ということらしい。(かなり不確定w)

 というわけで、namedを一旦停止した上で、/var/namedディレクトリにある、拡張子が「.jnl」のファイルを全部削除してからnamedを再度起動。

 messagesファイルにもnslookupの実行にもエラーが出なくなったことを確認して復旧ということに。

WindowsのActive DirectoryとbindによるDNSの連携 やりなおし編 [備忘録]

 自慢じゃないが以下略。
 とにかくWindows Serverがいかにアレで困ったちゃんなのか、世界の端っこで悪口雑言を叫びたいのだが以下略。

 さて。前アーティクルで、「ゾーンデータの動的更新を許可すれば~」みたいなことを書いた。
 が、コレが実に問題のある対応方法であるということが判った(いや…冷静に考えれば最初からわかっていたはずだ!>をれ)ので、別のやり方を探してみた。

 なにが問題だったか。それは…

問題点その1:とにかくWindows Serverがゾーンデータをみるみる書き換えてグチャグチャにしてくれるということ。
 →ゾーンデータにクライアントやサーバを書き足したくなって、ゾーンファイルを開こうものならそこには…orz

問題点その2:動的更新を全て許可してしまっているので、セキュリティもへったくれもない。
 →そうだよね…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 といった4つのゾーンへの動的更新のみ許可

 すれば、もともとのゾーンデータへの汚染は回避されるのではないか!?



 …とか妄想してみた。

 では、やってみよう!

① まずはゾーンデータの修復から…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.

 を書き足しておく。

②サブゾーンのゾーンファイルを作成する。

 上記の4サブゾーンについてゾーンファイルを作成する。
 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への動的更新を不許可とし、
 4つのサブゾーンを作成、そちらへの動的更新を許可してやることとする。

 まず、mysection.mycompany.co.jpの部分は…
        zone    "mysection.mycompany.co.jp"    in      {
                type    master;
                file    "db.mysection.mycompany.co.jp.zone";
        };

 とかこんな感じに。
 そして、4つのサブゾーンについては…
        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を強制的に動的更新するよう指示する。(または再起動でも…)
⑤最大で15分待つ

①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 というコマンドを入力する。

⑤最大で15分待つ

 DNSゾーンデータの動的更新が開始されると、(おそらく)/var/log/messages等にWindows Serverから更新があったので追加しましたよ~|削除しましたよ~  みたいなログが出るので、それを確認する。rejectとかされているようなら、aclの設定とかiptablesの設定とか関係しそうなところをチェック。
メッセージを送る