商業ビルなど600V以上の電源契約の事業者は電気事業法により電源設備の検査が義務付けられており、オフィスビルでは年に1度は計画停電があります。もちろん、先日の胆振東部地震による、大規模ブランクアウトというような致命的な停電も実際あるのです。

UPSも付いているし、UPSが正しく機能すれば、通常は正しくシャットダウンします。そして商用電源が復活すれば、正常に起動することを期待したいものです。

期待すべき事は、設計通りにシステムの自動遮断、復電、サービスの再開が行われることです。

期待通りであればです。

しかしUPS の不具合や、電源投入のタイミングによっては自動起動できないシステムがあったり、思わぬトラブルがサーバーシステム以外にも存在します(実際、復電後、UPS が付いていない HUB が飛んで1フロア全滅というケースがありました)。計画停電の際、都合が良ければシステム管理者は現場に休日出勤でアテンドして経験を積み、不慮の停電の際の運用マニュアルを作っておきたいものです。

また、計画停電の現場にアテンドして UPS に任せて、実際の遮断/復電の際に、どの様な動きや不具合があるかを確認するチャンスです。そこで現実に問題となった場合のインシデントをまとめて、現実に起こりえるアン・アテンド状態でのサーバールームやITシステム全体の弱点を確認、対策を立てる良い機会になります。

ここでは、SUSE Linux 11,12,15 の XEN/KVM 環境での計画停電前の安全な手動でのシステム遮断、システム復帰のケースを考え、オペレーション手段をマニュアル化して、考えられる復電/復電後のトラブルやチェックポイントを確認します。


- X サーバーソフトウェア -

ベアメタルシステムのコンソールを使わないで、Windows 端末から movaXterm もしくは xlaunch X サーバーを使って、各ハイパーバイザーごとに仮想マシンマネージャを起動します。ベアメタルサーバーのコンソールは、ハイパーバイザーの遮断、起動の状態を確認するだけで、できるだけ使わない様にします。



ここでは mobaxterm Home Edition を使って説明しています。

-仮想マシンの安全な遮断-

全て CPU 装置と UPS の停電遮断機能が動作するかチェックして、「放っておいて動作をチェックする」のも一手段ですが、アテンドして停電前に、各システムを安全に遮断します。

Windows からの場合、上のMovaXterm の Session ボタンから、各ホストの IP アドレスを指定して root で接続します。

仮想マネージャ GUI を起動します。

# virt-manager &

もしくは

# yast2 &
 > Virtilization > Virtitual Machine Manager

local host Not Connected の行を右ボタンで "Connect"

a0056607_09335997.jpg


Connect できたら、稼働中のVMを選んで、右ボタンから "Shut Down" > Shut Down" を選び、確認のダイアログに対して OK ボタンを押します。

a0056607_09351673.jpg

この処理を各 VM 毎に行い、ハイパーバイザー上の仮想システムを遮断します。

それ以外の VM は、上で動作しているサービスにもよりますが、およそ数十秒~数分(2~3分)以内に遮断します。遮断中の状態は "Open" メニューを開いて仮想コンソールで確認してください。

各VMが正常に停止状態になる事を virt-manager か xm list, virsh list コマンドで確認します。

- 停止しない場合 -

※ Windows7系、Windows2008 系システムは仮想環境で正常に停止(電源OFF状態)にならない場合があります。その際は virt-manager > アクティブなVMを選び右ボタンから > "Open" で仮想VMのコンソールを開きます。 Windows が "シャットダウン中"の最後の状態で 30 秒以上経っても、電源 OFF 状態にならない場合は、仮想 OS が物理的な電源オフを待っている状態なので "Force Off" (destroy) を実行しても構いません。「これ幸い」とばかりに、 Windows Update が走っている場合があるので、要注意です。

Unix/Linux 系システムはサービスの内容によりますが数十秒から数分以内に正常に遮断します。何か異常があって、あるいはサービスによっては10分以上かかる場合もあります。やりたくないのですが Pause するか Force Off するしかありません(復電後が怖いですけど...)。焦らない事です。

※ Reset, Force Reset の二つの操作は行わないでください。再起動してしまいます。万が一、再起動を選んでしまった場合、正常に起動するまで待って、シャットダウンの操作をもう一度行ってください。

- コマンドラインでの操作 -

アテンドして、手動で操作する場合、覚えておくべきテキストコマンドラインです。リモートのテキストコンソールしか使えないケースや GUI が使えない環境ではこれらのコマンドラインツールを使います。

SUSE Linux (SLES) 11 の XEN 環境の場合

xm shutdown myvm .... myvm を正常シャットダウンします。
xm destroy myvm .... myvm を強制シャットダウン(電源OFFと同じ)します。
xm reboot myvm .... myvm を正常シャットダウンしてリブート(再起動)します。
xm create -f /etc/xen/vm/myvm .... myvm を指定された VM ファイルから起動します。
xm list .... リストされている vm の状態(動作中か、稼働中か)を表示します。
xm console myvm_or_vmID .... myvmmyvm(もしくは ID No.) のテキストコンソールに切り替えます。Windows では使えません。"Ctrl+]" キーでエスケープします。

SUSE Linux (SLES12, SLES15) の XEN/KVM 環境の場合

virsh shutdown myvm .... myvm を正常シャットダウンします。
virsh destroy myvm .... myvm を強制シャットダウン(電源OFFと同じ)します。
virsh reboot myvm .... myvm を正常シャットダウンしてリブート(再起動)します。
virsh create -f /etc/libvirt/qemmu/myvm.xml .... myvm を指定された VM.xml ファイルから起動します。
virsh list .... リストされている vm の状態(動作中か、稼働中か)を表示します。
virsh console myvm_or_vmID .... myvm(もしくは ID No.) のテキストコンソールに切り替えます。Windows では使えません。"Ctrl+]" キーでエスケープします。

virsh cosole コマンドが使えない場合は次の対策が必要です(VM の再起動が必要です)

KVM on SUSE Linux(SLES12) virsh console が起動/接続できない

Accessing the VM Guest via Console


- 自動起動の設定(共通) -

VM の自動起動は virt-manager の "Details" > "Boot options" にある "Autostart" をチェックしておきます(KVM/XEN共通)。

a0056607_09424510.jpg

SLES11 の XEN 環境では /etc/xen/auto に /etc/xen/vm/MyVm のシンボリックリンクが作成されます。

SLES12,15 KVM 環境では /etc/libvirt/qemu/autostart に MyVm.xmlのシンボリックリンクが作られます。

- ハイパーバイザーの停止 -

ベアメタルハイパーバイザー SLES OS を停止( halt )します。

- 共通事項 -

- バックアップソフトウェア -

もちろん計画停電前には、重要なデータのバックアップを取ります。

バックアップが終わったらバックアップソフトウェアを停止させます。バックアップジョブが完了しているかを確認してください。バックアップジョブが走っている状態で、停電になると、どのような結果となるか想像がつきません。特に壊れやすいオートローダーには要注意です。計画停電がある場合、その時間帯に想定されるジョブは、サスペンド状態にしておくべきです。

Dell Software の NetVault の場合

# /etc/init.d/netvault stop

を実行します。

- ベアメタルハイパーバイザーの停止 -

# shutdown -h 0

でシャットダウンを開始します。正常に遮断しているかどうかの状態の確認は、リモートコンソールではなく、実コンソールで確認します。

正常に halt を実行した場合は、system halted ... の後、主電源が切れます。system halted .... の後、電源が切れない場合はメインスイッチで電源を落としてください。
また、

誤って halt ではなく Reboot を行った場合、 再起動してすぐの BIOS チェックのステージで電源を切ります。放置してしまい OS の起動ステージまで行った場合は、システムが完全に起動してから、再びVMの遮断から halt までの手続きを行ってください。時間がかかりますので要注意です。


- 考慮すべき事 -

- 一度に電源を入れない -

アンアテンドで復電してしまった場合、電源が一斉に入るため、UPS やフロアの電源ラインに一斉に負荷がかかります。できるだけ、コピーや複合機、エアコンと言った、電源容量の大きな装置は、アテンドできるなら事前に主電源を切っておくかコンセントを抜いておくべきでしょう。

ちょうど自宅でブレーカーが落ちた時、エアコンや電子レンジといった機器のコンセントを抜いてから、ブレーカーを上げるようなものです。

また、各ベアメタルサーバーのBIOSメニューの中に、復電後の電源 ON のディレイ(遅延)パラメータを設定できるものがあります。「松竹梅」の「竹クラス」以上のサーバーハードウェアにはこのディレィを設定できたり、復電後に自動的にランダムに遅延起動する機能があります。また、周辺機器(例えばテープのオートローダーやiSCSI SAN ストレージなど)にも起動に時間がかかるものがあるため、電源 ON のディレイタイマーが利用できるなら設定しておくべきです。ラック内のシステムにランダムに起動がかかるようにすれば、UPS や電源ラインに余計な負荷をかけずに復電作業ができます。

- 復電後の自動起動は正しく動作するか -

BIOS の設定状態によっては、停電後、電源ボタンを操作しないと復電できない設定のものがあります。アンアテンドで、停電してしまうと、これらの装置は実際に出向いてスイッチを押さなければなりません。「松竹梅」の「梅クラス」のハードウェアには良くある話です。インフラ経験の少ないソフトウェア専門の SIベンダーのサポートを受けているお客様で、その問題に悩んでいる方がいらっしゃいました。

また、私がテストで使っているような「梅以下」の安物ハードウェアでは、モニタの電源が入っいない、マウス、キーボードが付いていない、などで BIOSチェックで停止してしまうものがあります。

また SUSE の様に手堅いシステムでは、長時間安定運用しているため、fsck が行われていません。大抵の場合、fsck してデータのチェックのシーケンスに入ります。ここも焦らずじっくり付き合う必要があります。

- プリンタ、複合機 -

復電後、プリンタ、複合機と言った電力を食う周辺機器の主電源を投入します。この作業は分担として、利用者部門に任せても構わないかも知れません。計画停電と言っても、実際電源工事やビル点検の際に、作業が完全に終わらなくても復電してしまい、また急遽、主電源が切られる場合もあります。こうした起動後のチェックに時間がかかり物理的な動作をする機器は、物理動作をする部品が急に電源が切られて故障する場合もあります。

プリンタや複合機、Wifi のアクセスポイントなどで snmp 監視ができる機能が搭載されていれば、有効にすべきです。zabbix などの監視ツールのコンソールから snmpwalk を実行して、返事が返ってくればシステム管理者の側では問題なしと判断できます。物理的に故障していない事を祈ります。

snmpwalk でデバイスの snmp 状態を確認する


--
他にも、エレベータが使えないとか、電源が切られて、セキュリティ装置が動かず、サーバールームにカードで入れない。内線もつかえなければトイレすら使えない(!)と言った、システム以外に想定、憂慮すべきモンダイと言うものが、全館計画停電というイベントには含まれます。

停電、復電というプロセスは意外と想定外の現象が出てくるものです。実際にビル全館停電がある場合は、実際にアテンドして、停電を体験してみることも重要なのです。BCPプランの策定に役立つでしょう。

また、ビルメンテナンスの業者の担当者や関係者の間で携帯電話の番号を交換しあうことも重要です。トイレに閉じ込められて出られない、なんて笑って済む問題から、行きたいのにトイレに入れないと言ったもっと生理的にもっと深刻な問題まで、店子と業者との間で十分コミュニケーションをとる事も大事なのです。





--
SUSE, SLES, KVM, XEN, 仮想化, ハイパーバイザー, 計画停電, BCP, マニュアル






[PR]
by islandcenter | 2018-10-17 09:47 | SUSE | Trackback | Comments(0)

私はほとんど無意識にですが、

「ユーザIDは8文字以内の英数字にすべし」

というのが暗黙の考え方としてありました。

--
実際、海外の数万人規模の巨大企業でも、単一のディレクトリサービスでその様な ユーザアカウントの Naming Standard (命名規則) で運用している所をよく見ました。近年は、ユーザIDもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでID管理に複雑な機能が要求されます。

- UNIX系 OS の場合 -

UNIX 系 OS のネーミングスタンダードでは、POSIX 準拠した場合、ユーザ ID は 9 バイトで、お尻の1バイトは NULL 文字で、実質8バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。

limits.h

{_POSIX_LOGIN_NAME_MAX}
The size of the storage required for a login name, in bytes (including the terminating null).
Value: 9

一応の決まりですが実際には、今のディストリビューションやメーカー独自の UNIX 系システムは、独自拡張されており、現在、販売もしくは配布されている多くの Linux ディストリビューションや Unix 系 OS では多くの場合 32 バイトです。ただし、 UID とユーザ名を関連付けるライブラリにバグがあったりすると、表示上 8文字以上のユーザ名が UID に化けてしまうと言った問題もでてきます。

アカウントと連動するアプリケーション側が、古い標準に従って8文字に制限している場合もあるので

「システム的には管理運用上ユーザアカウント名は8文字以内」が無難

であると考えます。

ps doesn't display usernames > 8 characters

ちなみに MySQL は 16 バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。

6.3.1 ユーザー名とパスワード


- Windows の場合 -

Windows (2000/XP) のユーザアカウント文字数の最大長は20文字でした。

ユーザーアカウントとログオンパスワードの最大文字数について(Windows(R)2000/XP)

Windows10 に関しては情報がみつかりませんでしたが、Windows7 も20文字なので、恐らく最大20文字の制限は引きずっているでしょう。AD の場合も20バイトの様です。

Windows 10でユーザーアカウント名に使用できる文字の制限について


それにしても CON とか LPT とかの文字列が使えないってのもなんだか笑わせられます。こんな制限は、DOS 時代を知らない、若い方々には訳が分からないでしょう。俗にいう「CONCONバグ」 の残骸です。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。

特殊文字はハイフンやアンダースコアは OK の様です。文字間にドットが入っても問題ない様です。カンマは不可。

ちなみに、マイクロソフトアカウントでユーザ作成した際の文字数が5文字を超えると、\Users\xxxxx のユーザフォルダ名は5文字にトランケート(丸めて短くされる)されます。そのため、5文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが5文字を超えると「色々と楽しくて痛ましい事故?」が起こるようです。例えば

robocopy c:\users\%login_name\*.* \\nas\backup

などとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。困ったものです。

User folder name truncated

[Windows 10] ユーザー フォルダーの名前が Microsoft アカウントのアドレスの最初の 5 文字になっているのですが、なぜなのか分かりません。



- メールアドレス -

メールアドレスは、ドメイン名も含めた最大長 256 文字、@以前の、いわゆるローカルアカウント部分は最大64文字です。これに@以下のドメインを含めて最大 256 文字という事です。
ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー(クライアント側)の制限により、その限りではありません。もっと制限がかかっている場合があります。

https://ja.wikipedia.org/wiki/メールアドレス

一般的なマルチユーザのシステム単体(Unix だの VAX だの)では、ローカルホスト内でメールが使えればよかったので「ログイン名=メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。

- NetIQ eDirectory/LDAP の場合 -

ちなみに NetIQ eDirectory の CN (Common Name : UserID) は64 バイトまで許容しています。と言うより AD や Notes の認証のために LDAP 自体が x.500 の標準として 64 バイトに制限されているようで、eDirectory そのもの自体に制限は無いようです。


しかし、NetIQ のドキュメントではスタンダードな命名規則の事例として、8バイトの英数小文字と ”-” ( ハイフン ) を推奨しています。万物共用の命名規則として通用するわけです。

そこで eDirectory や LDAP でユーザアカウントを管理して、長いオブジェクト名や特殊文字を使用すると、マルチベンダーシステムで Windows や Linux のログインや動作で問題が起こります。LDAP との互換性のため、特殊文字にドットは使えません。ドットは、 eDirectory のコンテナ区切り文字です。特殊文字はハイフンだけ許可されます。LDAP サーチする場合は CN にカンマや@が入っているとURLと間違えられ問題があるからでしょう。

Sample Standards Document#

Tip: Valid Characters in eDirectory

GroupWise はデフォルトで eDirectory の CN (common name) がメールアドレスのローカル部分になります。

- という事で -

また、Unix 系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。Windows 系システムではケースセンシティブではありません。

レガシーなホストコンピュータなどのプリケーションの一部では、やっぱり8バイトが最長ユーザアカウントというケースもあり、

どうも「ユーザアカウント長、文字制限は8文字以内の英数小文字とハイフン

というのが ID 管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード(命名規則)構築方法でしょう。

セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。


- 文字数を8文字以内にする法則 -

- アカウントの長さは6~7文字の英数字 -

後に述べる「同姓同名問題」を解決させるため、8文字目は丸めて最大7文字とします。8文字使う場合は特例とします。もちろん、ユーザ名が"津・浦子"さんの場合 "tsuu" と短くなるのは構わないとは思いますが、必要に応じて文字を追加して6文字以上(tsuurrk)にする、と言った方法も良いと思います。8文字以上のIDを要求する場合、長ければトランケートして8文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。

もちろん2バイト文字や特殊記号の利用は厳禁、特別に許されても”-”ハイフン位にしておきます。ただ ”-” 文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。


- ファミリーネーム+ファーストネームイニシャル -

大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを1文字加えて「同姓異名」を区別します。

よく、イニシャル+ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。

- 同姓異名、同姓同名の区別 -

同姓同名、同姓異名で、ファーストネーム+イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。

Nakajima Kenji : nakajik
Nakajima Kensaku : nakajkn
Nakajima Kenichi : nakajkc
Nakajima Kenji(2): nakaknj

という感じです。

- 回避できない場合は8文字目を数値にする -

Nakakjik と nakajik2 ですね。これで例外があっても8文字に収まります。

- 表記はヘボン式 -

普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式(日本式)ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。

ヘボン式ローマ字

東京都生活文化局 - ヘボン式ローマ字綴方表

- 使ってはいけない文字(列)がある -

一般的にOSでファイル名として利用できない特殊記号や文字列、システム間で互換性のない文字(列)などは、or 条件の最大公倍数で禁忌とすべきです。

Unix 系OSでは "0","/" などが禁忌文字ですし、mac の場合は "/" だけ。":"や "|" とか "<>" もパイプに相当するためやめた方がいい。おそらく "Null" などの特殊なデバイスを意味するユーザIDもやめるべきでしょう。 Windows 系OSでは前述したように、特殊文字と "CON" とか "LPT1" とかのファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。モノによっては "-" も文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。

また、当たり前ですが機種依存文字(○付数字やカッコつきの「株」「〒」)とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「5C文字」を含む。

つまりはすべての漢字を含め2バイトの文字は使うべきではありません

正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。
「英数小文字6~8バイト以内」とするのが && 条件で絞り込んだ最小公約数として命名規則に加えるべきです。

- 重要なのは文書化しておく事 -

忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って8文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。

--
とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に8文字運用している現場で、たまたま9文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、8文字に短くして問題が解決しています。

NetIQ の eDirectory を使ったID管理システム自体が、&& 条件で最小公倍数の 「8 文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。

もっともこう言った問題点は社内システムでは問題になりますが、今時 google のアカウントを8バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ただウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限8文字以上が必須だったりしますし。”8文字”(以下)が無難だ、というのはどこでもあり得る話なのです。

ログインIDが短いと、セキュリティ上問題があるんじゃないかとも思われますが、IDもパスワードもブランクで不明なアカウントをブルーフォートアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。

ユーザのログインIDの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザIDは何文字が許されるか」も併せて調べるともっと面白いかも知れません。





[PR]
by islandcenter | 2018-10-08 16:42 | Identity Management | Trackback | Comments(0)