UEFIブートのサーバでWindows Server 2016のインストール用USBメモリが起動しない


hpeのProLiantサーバにWindows Server 2016をインストールする場合、通常はIntelligent Provisioning を使う。
しかし、Administratorパスワードが不明な場合、Windows Server 2016の標準ISOイメージのレスキューモードで起動することになるのだが、Smart Array B140i用のドライバが含まれていないため、内蔵ディスクが見えない。

対処するためにはISOイメージ内のsources\boot.wim にDSIMコマンドを使ってAdd-driverすることになる。

手順は「Windows インストールメディアにドライバーを追加する」にあるものをほぼそのまま使った
1. 作業用Windows10を用意
2. Windows ADK 1709の「Deployment Tools」と「Windows Preinstallation Environment (Windows PE)」をインストール
3. メニューの登録されている「展開およびイメージング ツール環境」を選択してコマンドプロンプトを起動
4. 「copype amd64 c:\work\pe_x64」(今回、C:\work を作業用ディレクトリとした)でWindows PE環境を展開
5. C:\work\iso にWindows Server 2016 ISOの中身をコピー
6. マウント用ディレクトリ c:\work\offline を作成
7. 「dism /get-imageInfo /imagefile:”C:\work\iso\sources\boot.wim」でインデックス番号を確認
 インデックス1とインデックス2があることを確認
 レスキューの際にどちらを使うかわからないので、とりあえず両方使う

8. まずインデックス1をc:\work\offlineにマウント
「dism /mount-image /imagefile:”C:\work\iso\sources\boot.wim” /index:1 /mountdir:”C:\work\offline”」

9. smart array b140i用のドライバをc:\work\hpedriver に展開

10. ドライバを追加。複数ある場合も考慮して、/recurseオプション付きで実行
「dism /add-driver /image:”c:\work\offline” /driver:”c:\work\hpedriver” /recurse」

11. ドライバが追加されたことを確認
「dism /get-driver /image:”c:\work\offline”」

12. アンマウントする
「dism /unmount-image /mountdir:”c:\work\offline”」

13. 今度はインデックス2に対して実行
「dism /mount-image /imagefile:”C:\work\iso\sources\boot.wim” /index:2 /mountdir:”C:\work\offline”」

14. ドライバを追加。複数ある場合も考慮して、/recurseオプション付きで実行
「dism /add-driver /image:”c:\work\offline” /driver:”c:\work\hpedriver” /recurse」

15. ドライバが追加されたことを確認
「dism /get-driver /image:”c:\work\offline”」

16. アンマウントする
「dism /unmount-image /mountdir:”c:\work\offline”」

17. oscdimgコマンドを実行してISOイメージの作成
「oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\work\PE_x64\fwfiles\etfsboot.com#pEF,e,bc:\work\PE_x64\fwfiles\efisys.bin c:\work\iso c:\work\win2016-new.iso」

これで、作成したISOイメージをFAT32でフォーマットしたUSBメモリにコピーしようとしたところ、install.wimのコピーで失敗。
原因はinstall.wimのサイズがFAT32制限である4GB以上の約6GBであるため。

NTFSもしくはexFATでフォーマットしなおしたところ、コピーはできたものの、サーバ側で起動ディスクとして認識せず。
UEFIの場合、ファイルシステムがFAT32であること、という前提がある模様。
この制限については、マイクロソフトの「起動可能な USB フラッシュ ドライブを作成します。」に記載があった。

サーバー プラットフォームが Unified Extensible Firmware Interface (UEFI) をサポートする場合は、NTFS ではなく FAT32 として、USB フラッシュ ドライブをフォーマットする必要があります。 フォーマットするパーティションを FAT32 として、次のように入力します。 format fs=fat32 quick、し、[入力] をクリックします。

今回の場合は、iLO Advancedライセンスがあったので、isoイメージをiLOからマウントすることで、DVDを作成する必要はなく対応することができた。

しかし、USBメモリを使ってWindows Server 2016のインストールを行う手法があるかどうか
つまりは4GBを超えてしまったinstall.wimをダイエットすることができるのか、分割することはできるのか、という点は不明なままであった・・・


2018/03/13追記

Microsoftの公式記述を発見
手法1「WinPE: Store or split images to deploy Windows using a single USB drive
 USBメモリにパーテーションを2つ作り、FAT32のメイン領域と、NTFSのinstall.wimのみをおく領域を作る、というもの

手法2「Split a Windows image file (.wim) to span across multiple DVDs
Dism /Split-Imageコマンドを使ってinstall.wimをinstall.swmに分割するというもの

Dism /Split-Image /ImageFile:C:\work\iso\sources\install.wim /SWMFile:C:\work\iso\sources\install.swm /FileSize:4000

(上記ページだと4700となっているけど、4GB超えてて大丈夫なの?と心配なので余裕をもって)

postfix/dovecotメールサーバでWindows Live Mail 2012がエラーになる


qmail+vpopmailという古代の環境から、postfix/dovecotのメールサーバに移行した。
移行の詳細については別途記事にしますが、移行後、Windows Live Mail 2012ユーザからクレームが・・・

POP3で受信ができないという
原因は、Windows Live Mail 2012のPOP3アクセス機能が古い、という点に尽きる。
対処するにはサーバ側でセキュリティを弱める設定を入れる必要があった。

その1:POP3受信時にエラー

/var/log/dovecot/pop3.log

Feb 19 10:35:59 oflex-1096-1 dovecot: pop3-login: Disconnected (tried to use disallowed plaintext auth): user=<osakana@example.net>, rip=xxx.xxx.xxx.xxx, lip=xxx.xx.x.xxx, session=<brxUt4ZlTfPbavEx>

→ dovecotの「ssl = required」と「disable_plaintext_auth = yes」の設定により発生
これを「ssl = yes」と「disable_plaintext_auth = no」に変更することで対処できる

設定箇所は下記の3ファイル
/etc/dovecot/dovecot.conf ではsslとdisable_plaintext_authの双方が設定されている可能性がある
/etc/dovecot/conf.d/10-auth.conf ではdisable_plaintext_authが設定されている可能性がある
/etc/dovecot/conf.d/10-ssl.conf ではsslが設定されている可能性がある
3ファイルをそれぞれ確認して修正すること

うちの環境ではssl=requriedがdovecot.confと10-ssl.confの双方で設定されていたが、
10-ssl.confしか認識しておらずいくら設定しても反映されないと悩んだ。

その2:SMTP送信時にエラー1

/var/log/maillog

Feb 19 10:41:49 mailserver.osakana.net postfix/smtpd[8343]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 504 5.5.2 <clienthostname>: Helo command rejected: need fully-qualified hostname; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<clienthostname>

→postfixの「smtpd_helo_restrictions」で「reject_non_fqdn_helo_hostname」が設定されているため発生

現在値確認

# postconf smtpd_helo_restrictions
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access pcre:/etc/postfix/helo_access.pcre reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
#

変更前の /etc/postfix/main.cf の該当部分

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
    reject_non_fqdn_helo_hostname
    reject_unknown_helo_hostname

変更後の /etc/postfix/main.cf の該当部分

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
    reject_unknown_helo_hostname
#    reject_non_fqdn_helo_hostname
# postconf smtpd_helo_restrictions
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access pcre:/etc/postfix/helo_access.pcre reject_unknown_helo_hostname
#

その3:SMTP送信時にエラー2

Feb 19 11:04:48 mailserver.osakana.net postfix/smtpd[11966]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 450 4.7.1 <clienthostname>: Helo command rejected: Host not found; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<clienthostname>

→postfixの「smtpd_helo_restrictions」で「reject_unknown_helo_hostname」が設定されているため発生

変更前はエラー1と同じなので省略

変更後の /etc/postfix/main.cf の該当部分

# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
#    reject_non_fqdn_helo_hostname
#    reject_unknown_helo_hostname

その4:SMTP送信時にエラー3
/var/log/maillog

Feb 19 11:07:08 mailserver.osakana.net postfix/smtpd[12710]: NOQUEUE: reject: RCPT from clienthostname.osakana.net[xxx.xxx.xxx.xxx]: 454 4.7.1 <osakana@example.com>: Relay access denied; from=<osakana@osakana.net> to=<osakana@example.com> proto=ESMTP helo=<DTCF801>

これはテスト用にセットアップしたアカウントがSMTPポート25を使っていたせいで失敗していた。
ポート587に変更したら成功

fail2banで全部JAILのステータスを確認したい


Linuxサーバでfail2banを使ってアクセス拒否設定を行っている。

JAILを複数している場合に、全部を一括で確認する手段が標準ではない模様。
調べたところ「kamermans/fail2ban-allstatus.sh」の下記コメントを発見

joergludwig commented on 20 Dec 2017
Shorter version:
fail2ban-client status | sed -n ‘s/,//g;s/.*Jail list://p’ | xargs -n1 fail2ban-client status

これを ~/.bashrc に下記にように追加し、「fail2ban-check」で確認出来るように設定した。

alias fail2ban-check="fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p' | xargs -n1 fail2ban-client status"

CephのOSD毎のPlacement Groupの数を確認する


Cephのテスト環境を構築してみた。

シナリオ通りに構築を進めていき、とりあえずは問題なくは終わった。
終わったんだけど、最後にステータスでも確認してみるかとceph healthを実行してみたところHEALTH_WARNが・・・

[root@ceph01 ~]# ceph health
HEALTH_WARN too many PGs per OSD (480 > max 300)
[root@ceph01 ~]#

OSDにたくさんのPGが割り当てられてる、といってるけど、具体的にはどれくらいあるんだろう?

と調べていくと、stackoverflowにある、下記のPGとOSDの関係性に関する質問を発見
Ceph too many pgs per osd: all you need to know

そこで紹介されている「Get the Number of Placement Groups Per Osd」に、OSD毎のPG数をコマンドで確認する手法が掲載されていた。

「ceph pg dump」の出力結果を整形して見やすいようにしている、というものだった。

ceph pg dump | awk '
BEGIN { IGNORECASE = 1 }
 /^PG_STAT/ { col=1; while($col!="UP") {col++}; col++ }
 /^[0-9a-f]+\.[0-9a-f]+/ { match($0,/^[0-9a-f]+/); pool=substr($0, RSTART, RLENGTH); poollist[pool]=0;
 up=$col; i=0; RSTART=0; RLENGTH=0; delete osds; while(match(up,/[0-9]+/)>0) { osds[++i]=substr(up,RSTART,RLENGTH); up = substr(up, RSTART+RLENGTH) }
 for(i in osds) {array[osds[i],pool]++; osdlist[osds[i]];}
}
END {
 printf("\n");
 printf("pool :\t"); for (i in poollist) printf("%s\t",i); printf("| SUM \n");
 for (i in poollist) printf("--------"); printf("----------------\n");
 for (i in osdlist) { printf("osd.%i\t", i); sum=0;
   for (j in poollist) { printf("%i\t", array[i,j]); sum+=array[i,j]; sumpool[j]+=array[i,j] }; printf("| %i\n",sum) }
 for (i in poollist) printf("--------"); printf("----------------\n");
 printf("SUM :\t"); for (i in poollist) printf("%s\t",sumpool[i]); printf("|\n");
}'

これをテスト環境で実行してみると下記の様な出力を得られた

[root@ceph01 ~]# ceph pg dump | awk '
BEGIN { IGNORECASE = 1 }
 /^PG_STAT/ { col=1; while($col!="UP") {col++}; col++ }
 /^[0-9a-f]+\.[0-9a-f]+/ { match($0,/^[0-9a-f]+/); pool=substr($0, RSTART, RLENGTH); poollist[pool]=0;
 up=$col; i=0; RSTART=0; RLENGTH=0; delete osds; while(match(up,/[0-9]+/)>0) { osds[++i]=substr(up,RSTART,RLENGTH); up = substr(up, RSTART+RLENGTH) }
 for(i in osds) {array[osds[i],pool]++; osdlist[osds[i]];}
}
END {
 printf("\n");
 printf("pool :\t"); for (i in poollist) printf("%s\t",i); printf("| SUM \n");
 for (i in poollist) printf("--------"); printf("----------------\n");
 for (i in osdlist) { printf("osd.%i\t", i); sum=0;
   for (j in poollist) { printf("%i\t", array[i,j]); sum+=array[i,j]; sumpool[j]+=array[i,j] }; printf("| %i\n",sum) }
 for (i in poollist) printf("--------"); printf("----------------\n");
 printf("SUM :\t"); for (i in poollist) printf("%s\t",sumpool[i]); printf("|\n");
}'
dumped all in format plain

pool :  4       5       6       7       8       9       10      11      12      13      14      1       2       15      3       | SUM
----------------------------------------------------------------------------------------------------------------------------------------
osd.4   39      29      25      36      27      24      35      34      30      28      34      33      35      29      32      | 470
osd.5   36      35      28      31      21      29      27      37      37      30      32      36      37      27      37      | 480
osd.6   38      37      30      35      30      24      37      33      32      31      27      32      33      31      27      | 477
osd.7   33      34      30      31      25      34      35      42      32      33      21      30      31      28      33      | 472
osd.8   29      32      39      35      28      39      31      34      36      35      38      34      35      24      21      | 490
osd.9   32      34      33      33      37      38      39      27      30      31      28      29      27      26      26      | 470
osd.10  39      31      34      24      35      36      35      40      34      37      37      45      32      31      37      | 527
osd.11  25      26      30      33      36      42      27      30      42      31      28      32      28      35      31      | 476
osd.0   27      39      38      29      35      24      34      26      28      31      38      23      33      31      32      | 468
osd.1   29      30      29      28      43      24      34      30      22      34      30      37      34      44      29      | 477
osd.2   27      32      35      33      31      38      21      24      30      26      37      26      26      36      33      | 455
osd.3   30      25      33      36      36      32      29      27      31      37      34      27      33      42      46      | 498
----------------------------------------------------------------------------------------------------------------------------------------
SUM :   384     384     384     384     384     384     384     384     384     384     384     384     384     384     384     |
[root@ceph01 ~]#

また、NAKAMURA Minoru’s Home Pageにある「RADOS の概略 (RADOS と CRUSH と Placement Group の関係)」は、Cephの理解に役に立った

OpenStack上の仮想インスタンスを物理サーバ間移動(マイグレーション)させる手法について


OpenStackで仮想インスタンスを動かしている場合に、物理サーバ間を移動させる手法について、いまいちまとまっているものがなかったので、メモ。

・物理サーバを指定して仮想インスタンスを起動
 → 不可能
  アベイラビリティーゾーン(availability-zone)というサーバをまとめたグループ(雑な表現)を指定して
  起動することまでしかできない

・仮想インスタンスを稼働中に物理サーバを移動させる
 → 可能
 例えば起動ディスクを含めcinderボリュームを使っている場合、下記コマンドで実施できる

# openstack server migrate --live 移動先ComputeNote --block-migration 仮想インスタンスUUID --wait

「migrate」と「migration」の2つの単語が混じっているので、惑わされないこと。

 上記だと、移動が終わるまでコマンドが終了しない。「–wait」を抜いた場合、下記の様な形でマイグレーションの進捗状況を確認することが出来る

# openstack server migrate --live 移動先ComputeNote --block-migration 仮想インスタンスUUID
# nova server-migration-list
# nova server-mgirationshow 仮想インスタンスUUID マイグレーション番号

「openstack sevrer show 仮想インスタンスUUID」では進捗のパーセンテージのみ確認可能。
それに対して、「nova server-mgirationshow 仮想インスタンスUUID マイグレーション番号」では、全体で何バイト転送する必要があり、現在何バイト転送が終了しているか、といった詳細を確認することができる。

参考資料
 nova Migrate instances
 nova Live-migrate instances

・止まってる物理サーバ上にあった仮想インスタンスを他の物理サーバで起動させる
 → nova evacuateコマンドで可能

# nova evacuate 仮想インスタンスUUID 移動先ComputeNode

nova evacuateは、元々起動していた物理サーバ上の「nova-compute」と通信が取れない場合に実行できる。

参考資料
 nova Evacuate instances
 nova Recover from a failed compute node

・ERRORステータスになっててmigrateが出来ない
「nova reset-state 仮想インスタンスUUID」を実行することで、ステータスがリセットできる。

参考資料
 nova Troubleshoot Compute