【2016年6月】

「ビジネス実務与信管理検定試験3級」を取得してみた。

リスク管理情報研究所

先の 日本化粧品検定3級、姿勢診断士5級、色彩士検定4級 に引き続き、無料で取得できる資格。

ビジネス実務与信管理検定試験

ユーザ登録をしてログインすると、利用可能なコンテンツの一覧が表示され、練習問題を解いたり、試験の申し込みができる。

とりあえず、無料でできる練習問題を全部やってみる。
むむ、意外に手強い。
でも、なんとかイケそうだ。

3級の申し込みをして、テスト開始。
問題は40問で、制限時間は30分。結構時間が足りない。
なんとか時間内に解答し、1回目のトライで、無事、合格。

ギリギリの70%だけど。
いいのいいの、資格試験なんだから、合格すれば勝ちだ。

合格証書はPDFでのダウンロードのみ。

資格は資格だけど…まぁ、暇潰しだなー。

まとめページ：

このエピソードの続き。

中国製WEBカメラで小ハマリ

再び中国製のWEBカメラを購入した。

価格は $3.07。先に購入した中国製WEBカメラよりは少し高いが、それでも 314円くらいだ。安い。

しかし、やはり、中国製品といえば、品質だ。きちんとした製品である事を願うのだが…。

まずは撮影してみる。

うん、撮影は問題なさそうだ。
しかし、ピント合わせをするために、レンズ部分を回している時に、少し違和感が。何の違和感だろう。
むむ、よく見ると、レンズが歪んでいる。

あきらかに歪んでいる。
このパーツは、単にレンズ部分を回すだけのもので、おそらく、実際にレンズが付いているわけではないだろうから、撮影そのものに大きな問題はないとは思うが、ちょっと気になる。

さて、どうするか。

前回と同じ選択肢だ。
ここはやはり、選択肢3で行く事にする。

とりあえず、分解してみる。

やはり、回す部品は、やはり単に回すだけのものだった。
つまり、工場で組み立てをする時に組み付けがいい加減と言う事だろう。

ところで、カメラの先端部分にテープが見える。

これは、先のカメラの問題と同様、滑ってピント合わせができない問題が発生したのだろうな。
やはり本来は、溝を切るなりして滑らない様にする必要があるのだろうけれど、既に生産してしまった部品に手で溝を切るわけにもいかないだろうから、応急処置的に両面テープで対処したのだろう。
元々のテープは乾燥してしまっていて粘着力がなくなっているので、貼り直す。

レンズ部分をまっすぐにして組み付け直す。

修理完了。

中国製品はいろいろメンドイのう…。

「アウトクラッシュ　組織犯罪対策課 八神瑛子Ⅱ」を読んだ。

ぶっ飛んだ女刑事が犯罪者を追う。
今回は超人的な殺人鬼と戦う物語。

実際にこんな刑事がいたら怖いけどな。
紙一重を越えて、確実に一線を踏み越してる。
一方で、こんな刑事がいて、悪い奴らをガンガン牢屋にぶち込んでほしいとも思う。

さて、 殺人鬼との戦いは…ちょっとあっけないなぁ。
いくら殺人鬼が手負いの状態と言ったって、戦闘のプロ集団をいとも簡単に屠った殺人鬼が、手負いの状態の八神瑛子にいとも簡単に倒されてしまった。
この時点では、物語の本筋である覚醒剤の密売ルートの壊滅ができる状態なので、消化試合になってしまったかな。

「X-ファイル 2016」を試写会で観た。

X-ファイル 2016

試写会に当選した。(^^)

実は ずんべ は、これまでに、X-ファイルをきちんと観たことが無い。
しかし、ちょこちょこ見てはいるので、主人公がモルダー捜査官、相棒がスカリー捜査官、超常現象やUFOなどを題材にしたドラマという事は知っている程度。
ちなみに ずんべ は、超常現象は信じないが、宇宙人は信じる。宇宙人は信じるが、UFOが来ているという事は信じない。

「きちんと観たことが無い」という事に深い意味は無く、以前は仕事バカだった事もあって、「ドラマを見る」という習慣がそもそもなかった。
日本のドラマでも、「男女7人夏物語」「ロングバケーション」「101回目のプロポーズ」「HERO（第1期）」「古畑任三郎」「王様のレストラン」などの有名どころのドラマでも、リアルタイムでは見たことがなかった。
最近になって、テレビドラマを観るようになって（多くは録画だけど）、過去の作品も観るようになり、今頃になって「なかなかおもしろいじゃん」と思うようになった次第。

さて、試写会は、既に発売されている「X-ファイル 2016」の中から、第1話と第4話の試写。
モルダーもスカリーも老けたなぁ。
劇中でも、モルダーが「階段を駆け上がって追いかけるような年じゃない」といったセリフもあり、一瞬「ターミネーター:新起動/ジェニシス」のシュアちゃんが頭の隅をよぎった。(^^;

1本目、第1話は、モルダーとスカリーがX-ファイルに戻る物語。
2本目、第4話は、画家が創造した守り神が実体化して殺人を続ける物語。

あれ～、ずんべ の記憶にあるX-ファイルのイメージとずいぶん違うな。
ずんべ の記憶にあるX-ファイルは、超常現象やUFOを題材にしてはいるけれど、現実からかけ離れる事はなく、あくまでもFBIの捜査官として謎を追っていくような感じだった気がするのだが…。
特に第4話は、現実からかけ離れすぎていて、正直、「なんだこれ？」だった。
ぶっちゃけ、「ほんとにあった! 呪いのビデオ」くらいのデキの気がする。
全話を観れば、最後は一点に集約するのだろうとは思うけど、買ってまで観たいとは、ちょっと思えなかった。
CSで放送されるのを待つか。

ところで、今回の試写会は ZIP-FM が主催という事もあって、ZIP-FM のミュージックナビゲーター（名前忘れた(^^;）が司会に来ていた。
そのミュージックナビゲータもX-ファイルは好きで、観ていたという。
しかし、紹介の途中で「ナタリー」という名前を連発していた。もちろん正解は「スカリー」だ。
ぶっちゃけ、観ていない事がバレバレだ。
商売で司会をやっている以上、必ずしも自分が見た事があるものだけが担当になるとは限らないという事はわかってはいるけども、メインのキャストの名前を間違えるとなると、やっぱり興醒めする。
もうちょっと勉強してから司会やってよね。

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)
ESXi監視で大ハマリ (7) - あとがき(A)
ESXi監視で大ハマリ (8) - あとがき(B)
ESXi監視で大ハマリ (9) - コマンドで監視(C)
ESXi監視で大ハマリ (10) - コマンドで監視(D)
ESXi監視で大ハマリ (11) - コマンドで監視(E)

もうひとつアイデアを出しておこうと思う。
ESXi へは、https でもアクセスできる。
以下のページにアクセスして、IDとパスワードを入力すると…

https://(ESXi)/

以下のようなページが表示される。

WELCOMEページが表示がされるという事は、おそらくHTMLファイルが存在しているであろうとアタリを付け、ESXiのディスクを探索してみる。

# find / -type f -name "*.html"
/usr/lib/vmware/hostd/docroot/index.html

あった。「/usr/lib/vmware/hostd/docroot/」の配下だ。
ここにファイルを置けば、https経由で情報を取れるのではないか。

# cd /usr/lib/vmware/hostd/docroot
# mkdir disk
# esxcli storage core device smart get -d ***** > disk/ata-status.txt

監視サーバからアクセスしてみる。

$ wget -q --no-check-certificate --http-user=root --http-password=***** https://(ESXi)/disk/ata-status.txt
$ cat ata-status.txt
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 OK     N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              80     44         63
Power-on Hours                63     0          63
Power Cycle Count             100    20         100
Reallocated Sector Count      100    36         100
Raw Read Error Rate           80     44         63
Drive Temperature             39     0          44
Driver Rated Max Temperature  61     45         56
Write Sectors TOT Count       200    0          200
Read Sectors TOT Count        N/A    N/A        N/A
Initial Bad Block Count       100    99         100

取れた！
WEB経由でも取得する事ができた。

ちなみに、以下のページアクセスすると…

https://(ESXi)/host

以下のようなページが表示され、ログや設定情報を参照する事ができる。

この情報ページに組み込むこともできるようだ。
このページに表示されている情報は、以下のファイルにに定義されている。

/etc/vmware/hostd/webAccessibleConfigFiles.xml

このファイルに定義を追加する。

<configFileInfo>
　　<uriReference>/host/disk-status-raid</uriReference>
　　<path>/*****/disk-status-raid.txt</path>
　　<displayName>Disk Status (RAID DISK)</displayName>
　　<mimeType>text/plain</mimeType>
　　<method>GET</method>
　　<method>HEAD</method>
　　<method>PUT</method>
</configFileInfo>

<configFileInfo>
　　<uriReference>/host/disk-status-ata</uriReference>
　　<path>/*****/disk-status-ata.txt</path>
　　<displayName>Disk Status (ATA DISK)</displayName>
　　<mimeType>text/plain</mimeType>
　　<method>GET</method>
　　<method>HEAD</method>
　　<method>PUT</method>
</configFileInfo>

サーバを再起動する。

# /etc/init.d/hostd restart

情報ページにアクセスする。

https://(ESXi)/host

定義した「Disk Status (RAID DISK)」と「Disk Status (ATA DISK)」が表示されている。
クリックすると、内容も表示される。

これにより、https経由でESXiから情報をダウンロードする事ができる。

更に、CGIも探してみる。
あった。CGIは「/usr/lib/vmware/hostd/cgi-bin/」の配下だ。

# find / -type f -name "*.cgi"
/usr/lib/vmware/hostd/cgi-bin/esxcli.cgi
/usr/lib/vmware/hostd/cgi-bin/esxcfg-info.cgi
/usr/lib/vmware/hostd/cgi-bin/vm-support.cgi

今回は試していないが、CGIでスクリプトを実行し、動的に状態を生成する事も可能だろう。
もしかしたら、ESXi側から他のサーバに情報をWEB経由でプッシュする事も可能かもしれない。
機会があったら試してみようと思う。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)
ESXi監視で大ハマリ (7) - あとがき(A)
ESXi監視で大ハマリ (8) - あとがき(B)
ESXi監視で大ハマリ (9) - コマンドで監視(C)
ESXi監視で大ハマリ (10) - コマンドで監視(D)

ESXi側で能動的に監視をしようとすると、どうしてもESXi上で cron などを用いて定期実行をかける必要がある。
少し発想を変えて、ESXiを「監視情報を提供する」サーバとし、監視サーバを「監視情報を取得する」クライアントとして構成したらどうだろうか。

sshコマンドには、接続先のコンピュータ上のプログラムを実行する機能がある。
sshのヘルプを参照してみる。

$ ssh --help
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
　　　　　[-D [bind_address:]port] [-e escape_char] [-F configfile]
　　　　　[-I pkcs11] [-i identity_file]
　　　　　[-L [bind_address:]port:host:hostport]
　　　　　[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
　　　　　[-R [bind_address:]port:host:hostport] [-S ctl_path]
　　　　　[-W host:port] [-w local_tun[:remote_tun]]
　　　　　[user@]hostname [command]

最後に [command] とある。 実験してみよう。

$ ssh zunbe@(server) /bin/date
zunbe@(server)'s password:
2016年  6月 21日 火曜日 20:07:38 JST

サーバ側のプログラムが実行され、その実行結果を取得する事ができた。

esxcliコマンドとMegaCliコマンドを実行するスクリプトを準備し、ESXi側に置く。

#!/bin/sh
echo "===== " `hostname' " ====="
echo "----- RAID -----"
MegaCli -PDList -aALL
echo "----- ATA -----"
esxcli storage core device smart get -d *****

監視サーバ側からESXiに接続し、先のスクリプトを実行する。

$ ssh zunbe@(server) disk.sh
Password:

取れた！

=====  (server)  =====
----- RAID -----
Adapter #0Enclosure Device ID: N/A
Slot Number: 0
Drive's postion: DiskGroup: 0, Span: 0, Arm: 0
Enclosure position: N/A
Device Id: 0
WWN:
Sequence Number: 2
Media Error Count: 0
Other Error Count: 36
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA：

　　：
----- ATA -----
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 OK     N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              80     44         63
Power-on Hours                63     0          63
Power Cycle Count             100    20         100
Reallocated Sector Count      100    36         100
Raw Read Error Rate           80     44         63
Drive Temperature             40     0          44
Driver Rated Max Temperature  60     45         56
Write Sectors TOT Count       200    0          200
Read Sectors TOT Count        N/A    N/A        N/A
Initial Bad Block Count       100    99         100

自動実行させる場合は、ESXi側から監視サーバに転送した時と同様、ssh-keygen で鍵セットを作り、ESXi（サーバ）、監視サーバ（クライアント）にセットして実行するようにすればよい。

取得したファイルを解析して、改めてアラート・メールを発信するプログラムを準備する必要がある事は、ESXi 側から転送する場合と同じであるが、この方法なら、ESXi上での設定は最小限で、ESXi 上でのファイル生成と、ファイル取得の際のアクセスがコンフリクトする事もない。
いい感じだ。
これで行こう。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)
ESXi監視で大ハマリ (7) - あとがき(A)
ESXi監視で大ハマリ (8) - あとがき(B)
ESXi監視で大ハマリ (9) - コマンドで監視(C)

esxcliコマンド、MegaCliコマンドで取得した監視情報を scp で監視サーバに転送する事を考えてみる。

まず、ESXi上にscpコマンドが存在しているか確認する。

# which scp
/bin/scp

あった。

ssh-keygen で鍵セットを作り、ESXi、監視サーバにセットする。
その上で、コマンドを実行。

# MegaCli -PDList -aALL > disk/raid-status.txt
# esxcli storage core device smart get -d ***** > disk/ata-status.txt
# scp -q -r disk zunbe@*****.**.**.**:.
zunbe@*****.**.**.**'s password:

監視サーバ側では、転送されたファイルを解析してエラーなどを出力すればよい。
監視サーバ側で、転送されたファイルを解析して、改めてアラート・メールを発信するプログラムを準備する必要はあるが、取得した監視情報を ESXi から外に出すことができた。

ただし、この方法にはもうひとつひとつ難題がある。
cron を設定しなければならない事である。
ESXi上でも cron は設定できるようであるが、crontab が使えない、再起動時に cron の設定がクリアされる、などの問題があるらしく、これらを解消する必要があるらしい。
今回は cron の設定は試していないのだが、これを設定するのは少々メンドクサイし、ESXi の設定をいろいろ弄るのは、後々、たとえば、ESXi の再インストールが必要になった場合などにインストール以外の作業が生じてしまうので、できるだけ避けたい。

もう少し簡単な方法で実現できないだろうか。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)
ESXi監視で大ハマリ (7) - あとがき(A)
ESXi監視で大ハマリ (8) - あとがき(B)

ずいぶん間が空いてしまったけれど（以前に記事を書いたのは2014年6月）、いろいろ試行錯誤して構築した監視機構は、あまろ使い勝手がよくないし、仰々しい構成にしている割に得られる情報が少ないので、根本的に考え直してみる事にした。

もともと、やりたかった事は「ESXiに接続されているディスクのエラー監視」である。
RAIDのディスクも、通常のディスクも、ESXi上で監視する事そのものは「ESXi監視で大ハマリ (4) – コマンドで監視(B)」でできている。
何が問題かと言うと、ESXi上で得た監視データを管理者に通知する事、すなわち、ESXi上からメールを発信する事が簡単ではないという点である。
結局、メールで発信する事が困難であったため、DELLツールを導入し、結果、仰々しい監視システムになってしまった。

そして、仰々しい監視システムの割に、得られる情報はひじょうに乏しい。
たとえば、OpenManage Essentials から飛んでくるアラート・メールは、以下の様な文面である。

ちなみに、このアラート・メールは、筐体の蓋を開けた時に飛んできたものであるが、この内容だけでは、どんなエラーが起こっているのか、まったくわからない。
もちろん、「何らかの障害が発生した事がわかる」事が重要で、詳細状況は、改めて OpenManage Server Administrator にアクセスして調べればよいとは言える。
しかし、やはり、仰々しい監視システムの割に得られる情報が少ないのは否めないので、もう少しシンプルにしたい。

今回は、ESXi上で取得した監視情報をメール以外の方法で、監視サーバに転送する仕組みを考えてみたい。

一連記事：

「捜査一課―警部補児島要」を読んだ。

けっこう期待して読んだのだが…あまり入り込めなかった。
ラストに入るまではダラダラと話が続く。
正直、ラストに入るまで、半分読み飛ばし状態だった。

しかし、ラストは…ほう、なるほど。
更にラストのラスト（エピローグ）は…ほう、なるほど。最後の最後で楽しめました。

ただ、警察側の紅一点、立山加奈子をもう少し活躍させてほしかったかな。

「HK/変態仮面」をCSで視聴した。

HK/変態仮面

く…く…くだらん。
超くだらん。
しかし、無意味に完成度は高い気がするな…。