【ソフトウェア】

delegate + TLS 1.2

このエピソードの続き。

CentOS 5.9 + TLS 1.2

今回は、delegate でリバース・プロキシを組んでいる環境で TLS 1.2 での接続を行う。

現在の環境では、FireFoxで警告が出てしまう。

SSL警告

リバース・プロキシの環境では、ブラウザの接続先はプロキシ・サーバとなるため、プロキシ・サーバが TLS に対応していなければ、この警告が出る。
従って、プロキシ・サーバがロードしている openssl ライブラリを更新して対処する事にする。

現在のプロキシ・サーバがロードしている openssl は 0.9.8x。古い。(^^;

Loaded: OpenSSL 0.9.8x 10 May 2012
Loaded: Zlib 1.2.3

これを、新しい openssl を読み込ませるように更新する。

それでは、トライしてみる。

(1).openssl を手動でインストールする。

$ cd openssl-1.0.2s
$ ./config shared enable-ssl2 enable-ssl3 --prefix=/*****/openssl-1.0.2s
$ make
$ su -
# make install

(2).opensslライブラリを差し替える。

この環境では、単純に delegate のディレクトリに openssl ライブラリを置く事で、そのライブラリを読むようにしている。

# cd /*****/delegate/sbin
# ls -l
合計 4084
-rwxr-xr-x. 1 root root 4180673 2月 19 23:43 2014 delegated
lrwxrwxrwx. 1 root root 51 7月 18 09:58 2019 libcrypto.so -> /*****/openssl-0.9.8x/lib/libcrypto.so.0.9.8
lrwxrwxrwx. 1 root root 48 7月 18 09:59 2019 libssl.so -> /*****/openssl-0.9.8x/lib/libssl.so.0.9.8

このシンボリックリンクを置き換える。
既存の openssl ライブラリ(0.9.8x)をバックアップする。

# mv libcrypto.so 20190718.libcrypto.so
# mv libssl.so 20190718.libssl.so

新しい openssl ライブラリ(1.0.2s)のシンボリックリンクを作成する。

# ln -s /*****/openssl-1.0.2s/lib/libcrypto.so.1.0.0 libcrypto.so
# ln -s /*****/openssl-1.0.2s/lib/libssl.so.1.0.0 libssl.so

確認する。

# ls -l
合計 4084
lrwxrwxrwx. 1 root root 51 2月 20 15:14 2014 20190718.libcrypto.so -> /*****/openssl-0.9.8x/lib/libcrypto.so.0.9.8
lrwxrwxrwx. 1 root root 48 2月 20 15:14 2014 20190718.libssl.so -> /*****/openssl-0.9.8x/lib/libssl.so.0.9.8
-rwxr-xr-x. 1 root root 4180673 2月 19 23:43 2014 delegated
lrwxrwxrwx. 1 root root 51 7月 18 09:52 2019 libcrypto.so -> /*****/openssl-1.0.2s/lib/libcrypto.so.1.0.0
lrwxrwxrwx. 1 root root 48 7月 18 09:52 2019 libssl.so -> /*****/openssl-1.0.2s/lib/libssl.so.1.0.0

delegate を再起動し、ロードされた openssl ライブラリを確認する。

Loaded: OpenSSL 1.0.2s 28 May 2019
Loaded: Zlib 1.2.3

上記(1)でインストールした openssl 1.0.2s がロードされた。

(3).正常な鍵マークが復活!

正常な鍵マークが復活!

無事、TLS 1.2 で通信された。

TLS 1.2 で接続された

これでよし!

楽天SocialNewsに投稿!
0 0 0

楽天アフィリエイト WordPressプラグイン

WordPress用の楽天アフィリエイト プラグインを作った。

これまで、Amazonのアソシエイトを中心に商品リンクを貼っていたのだが、Amazonアソシエイトは規約が変更され、ある程度の売上実績がないとAPIが利用できなくなってしまった。

[重要] Product Advertising API 利用ポリシーの変更について

そこで、楽天アフィリエイトにもAPIがあるので、主軸を楽天アフィリエイトに移そうと思う。

API一覧 - 楽天ウェブサービス

Amazonでは、商品のコードは「ASIN」と呼ばれる商品コードに統一されており、どのような種類の商品でも、同じAPIで「ASIN」を商品コードとする事で商品リンクが作成できた。
しかし楽天では、商品の種類によって、呼び出すAPIや商品コードの指定方法が異なるので、ここが少々めんどくさい。
とりあえず今回は、楽天市場用、楽天ブックス(書籍)用、楽天ブックス(DVD/Blu-ray)用の3種類のプラグインを作成する事にする。

また、以前に、Aliexpress用プラグインを作成しているが、この実装に合わせて、以下の様な書式で商品リンクの挿入ができるようにし、キャッシュ機能も実装する。

(1).楽天市場

楽天市場の商品では、商品コードを拾うのが少々めんどくさい。
ページのソースを開き、ソース中の以下の様な記述を探す。

itemid:['honest-online:10000015'],

商品コードは「:」で区切られていて、前半が店舗コード、後半が商品コードと思われるが、「:」も含めて全体が商品コードであるので、これを商品コードとして記述する。
小さいサイズの商品リンクも表示できる。

[rakuten size="large"]honest-online:10000015[/rakuten]
[rakuten size="small"]honest-online:10000015[/rakuten]

実際の表示は以下のようになる。

【日本正規代理店】ORICO 4ポート USBハブ usb3.0 ハブ usb3 ハブ usbハブ 3.0 高速 5Gbps USB3.0 HUB バスパワー VL812チップ搭載 30CM …
【日本正規代理店】ORICO 4ポート USBハブ usb3.0 ハブ usb3 ハブ usbハブ 3.0 高速 5Gbps USB3.0 HUB バスパワー VL812チップ搭載 30CM …
【日本正規代理店】ORICO 4ポート USBハブ usb3.0 ハブ usb3 ハブ usbハブ 3.0 高速 5Gbps USB3.0 HUB バスパワー VL812チップ搭載 30CM …
【日本正規代理店】ORICO 4ポート USBハブ usb3.0 ハブ usb3 ハブ usbハブ 3.0 高速 5Gbps USB3.0 HUB バスパワー VL812チップ搭載 30CM …

 

(2).楽天ブックス(書籍)

楽天ブックス(書籍)の商品では、ページ中に表示されている「ISBNコード」を商品コードとして記述する。

[rbooks size="large"]9784062764131[/rbooks]
[rbooks size="small"]9784062764131[/rbooks]

実際の表示は以下のようになる。

永遠の0
永遠の0
【講談社文庫】百田 尚樹
永遠の0
永遠の0
【講談社文庫】百田 尚樹

 

(3).楽天ブックス(DVD/Blu-ray)

楽天ブックス(DVD/Blu-ray)では、ページ中に表示されている「JANコード」を商品コードとして記述する。

[rdvd size="large"]4988135805799[/rdvd]
[rdvd size="small"]4988135805799[/rdvd]

実際の表示は以下のようになる。

ショーシャンクの空に
ショーシャンクの空に
ティム・ロビンス/モーガン・フリーマン/ウィリアム・サドラー/フランク・ダラボン
ショーシャンクの空に
ショーシャンクの空に
ティム・ロビンス/モーガン・フリーマン/ウィリアム・サドラー/フランク・ダラボン

 

Aliexpress用プラグインとフォーマットを合わせてあるので、これらを混在させて並べてもOK。

エイリアン 【Blu-ray】
エイリアン 【Blu-ray】
トム・スケリット/ヴェロニカ・カートライト/ハリー・ディーン・スタントン/リドリー・スコット
5Pcs/card JNKXIXI Bateria CR2032 3V Lithium Button Battery BR2032 DL2032 ECR2032 CR 2032 Lithium Batteries
5Pcs/card JNKXIXI Bateria CR2032 3V Lithium Button Battery BR2032 DL2032 ECR2032 CR 2032 Lithium Batteries
人魚の眠る家
人魚の眠る家
【幻冬舎文庫】東野圭吾
ガタカ
ガタカ
イーサン・ホーク/ユマ・サーマン/ジュード・ロウ/アンドリュー・ニコル
2PCS H7 H3 LED H1 H9 H4 H13 Bulb 60W Headlights Auto Lamp With H11 LED car Light 6000K White 12V Automobile LED lamp BH
2PCS H7 H3 LED H1 H9 H4 H13 Bulb 60W Headlights Auto Lamp With H11 LED car Light 6000K White 12V Automobile LED lamp BH

 

これでヨシ。
とりあえず、バージョン1.0。

楽天SocialNewsに投稿!
0 0 0

CentOS 5.9 + TLS 1.2

あるWEBサイトで、最新の FireFox でSSLの警告が出るようになった。

SSL警告

SSLは Let's Encryptで、何か更新処理を誤ったのだろうかと思ったのだけれど、他のブラウザ(Internet Explorer 11、Edge、Google Crome)では警告は出ておらず、FireFoxのみで警告が出ている。スマホでも同様にFireFoxでは警告が表示される。
この警告が出るのは、企業のサイトでは、ちょっとマズい感じ。

この警告がどうして出るのかいろいろ調べてみると、証明書そのものも問題ではなく、プロトコルの問題のようだ。
どうやら、各ブラウザが2020年に TLS 1.0、TLS 1.1 での接続ができなくなるように動作が変更されるようなので、FireFoxは、その事前警告を出しているようだ。

TLS 1.0 で接続されている

このWEBサイトはレンタルサーバで、OSは CentOS 5.9。
root権限が貰えているサーバであるけれど、テスト環境があるわけではないので、様々アップデートをかけるのは少々リスクが大きい。なんとかWEBサーバのみに影響範囲を抑える形で対処したい。

いろいろ悩んで、以下の方法で対処する事にした。

① 最新のopensslをユーザ領域に手動でインストールする。
② Apacheの起動スクリプトを修正し、上記(1)でインストールしたopensslをロードさせるようにする。

それでは、トライしてみる。

(1).opensslを手動でインストールする。

$ cd openssl-1.0.2s
$ ./config shared enable-ssl2 enable-ssl3 --prefix=/*****/local
$ make
$ make install

稼働しているApacheは、古いバージョンのライブラリをロードする様になっている。
Apacheを再コンパイルするなどすると影響が大きいので、インストールしたライブラリのバージョンを偽装する事にする。

# cd /*****/local/lib
# ln -s libssl.so.1.0.0 libssl.so.6
# ln -s libcrypto.so.1.0.0 libcrypto.so.6

(2).Apacheが上記(1)でインストールしたライブラリを正しくロードするか、依存関係を確認してみる。

まず、通常の起動。
/usr/lib 配下のライブラリがロードされる。

# ldd /usr/sbin/httpd | grep libssl
libssl.so.6 => /lib/libssl.so.6 (0xb7b04000)

次に、上記(1)でインストールしたライブラリをロードさせての起動。
上記(1)でインストールしたライブラリがロードされた。

# LD_LIBRARY_PATH=/*****/local/lib ldd /usr/sbin/httpd | grep libssl
libssl.so.6 => /*****/local/lib/libssl.so.6 (0xb7a8d000)

よし、いけそうだ。

(3).Apacheの起動スクリプトを修正する。

# cd /etc/init.d
# vi httpd

Apacheの起動部分に、LD_LIBRARY_PATHでopensslのパスを挿入する。
これにより、上記(1)でインストールしたライブラリは、Apacheに限定して使用される。

LANG=$HTTPD_LANG LD_LIBRARY_PATH=/*****/local/lib daemon --pidfile=${pidfile} $httpd $OPTIONS

(4).Apacheを再起動する。

# /etc/init.d/httpd restart

が、残念ながら、phpのモジュールのロードでエラーが発生してしまった。

# /etc/init.d/httpd restart
httpd を停止中: [ OK ]
httpd を停止中: [失敗]
httpd を起動中: httpd: Syntax error on line 210 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/php.conf: Cannot load /etc/httpd/modules/libphp5.so into server: /etc/httpd/modules/libphp5.so: undefined symbol: EVP_md2
[失敗]
#

がんばってphpの再インストールもトライしようかと思ったけれど、このWEBサイトではphpは使用していないので、phpのサービスを停止する事で対処する事にした。

(5).サーバのコントロール・パネルでphpのサービスを停止する。

phpを停止

(6).再びApacheを再起動する。

# /etc/init.d/httpd restart
httpd を停止中: [ OK ]
httpd を起動中: [ OK ]
#

成功した!

(7).正常な鍵マークが復活!

正常な鍵マークが復活!

無事、TLS 1.2 で通信された。

TLS 1.2 で接続された

これでよし!

楽天SocialNewsに投稿!
0 0 0

Apache 仮想ドメイン設定の読み込み

会社の開発サーバにおいて、Apache に設定する仮想ドメイン <VirtualHost></VirtualHost> は頻繁に設定を追加/削除する。
新しいプロジェクトが立ち上がれば仮想ドメインを追加、プロジェクトが終了すれば削除、プロジェクトが再開すれば設定を復元。

これまでは、以下の様に設定して運用していた。

Apache の「httpd.conf」では、以下の様に仮想ドメインのまとめ設定ファイル「vhosts.conf」をインクルードしておく。

Include ~/conf/vhosts.conf

読み込む「vhosts.conf」では、以下のように必要な仮想ドメインの設定ファイルをインクルードする。
不要な仮想ドメインは「#」でコメントアウトされている。

Include ~/conf/blog.zunbe.com.conf
Include ~/conf/blog2.zunbe.com.conf
Include ~/conf/www.patentic.co.jp.conf
#Include ~/conf/www.archive.com.conf
#Include ~/conf/www.archive.net.conf

その上で、ディレクトリ内に置かれている仮想ドメインの設定ファイルを置いておくのだが、ただ置いただけでは、どの仮想ドメインが現状で有効であるのかわかりにくいため、archives ディレクトリを作成して、無効なドメインは移動して隔離していた。

~/conf/blog.zunbe.com.conf
~/conf/blog2.zunbe.com.conf
~/conf/www.patentic.co.jp.conf
~/conf/archives/www.archive.com.conf
~/conf/archives/www.archive.net.conf

仮想ドメインを追加/削除/復元するには、vhosts.conf の記述を変更した上で、仮想ドメインの設定ファイルを archives ディレクトリから移動し、Apacheを再起動していた。

十分簡単だとは思うのだけれど、もう少し簡単にならないだろう。
ん~と考えて、はっと気が付いた。
Include ディレクティブって、ワイルドカード(*)が使えるじゃないか。

と、言う事で、以下の様な設定での運用に変更。

Apache の「httpd.conf」では、以下の様に仮想ドメインのまとめ設定ファイルをインクルードしておく。
「+」が付いているのがミソ。

Include ~/conf/+*.conf

その上で、以下の様に仮想ドメインの設定ファイルを配置する。
先頭が「+」である設定ファイルのみが読み込まれる。

~/conf/+blog.zunbe.com.conf
~/conf/+blog2.zunbe.com.conf
~/conf/+www.patentic.co.jp.conf
~/conf/-www.archive.com.conf
~/conf/-www.archive.net.conf

仮想ドメインを追加する場合は、先頭が「+」の設定ファイルを作成して置く。
仮想ドメインを削除する場合は、先頭の「+」を「-」にリネームする。
仮想ドメインを復元する場合は、先頭の「-」を「+」にリネームする。
その上で、Apache を再起動する。

仮想ドメインが有効か無効かは、ファイル名を見るだけでわかる。

なんてことない技だけど、これでずいぶん運用が楽になった。(^^)

楽天SocialNewsに投稿!
0 0 0

SELinuxで小ハマリ

SELinux で小ハマリしたのでメモ。

CentOS 上で稼働している Apache にSSL証明書を取り込もうとしている。

オレオレSSL証明書を作る。
コマンド的には、ざっと、こんな感じ。

# openssl req -new -key server.key -sha256 -out server.csr
# openssl x509 -req -days 365 -sha256 -in server.csr -signkey server.key -out server.crt
# openssl rsa -in server.key -out server-nopw.key

とりあえず、/root/ssl に置いて試してみる。

# mkdir /root/ssl
# cp server.csr server-nopw.key /root/ssl

Apache の設定ファイル(/etc/httpd/conf.d/ssl.conf)に作成したSSL証明書を設定する。

SSLCertificateFile /root/ssl/server.crt
SSLCertificateKeyFile /root/ssl/server-nopw.key

Apache を再起動すると…あれ? 起動しない!

# service httpd restart
Redirecting to /bin/systemctl restart  httpd.service
Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.

メッセージの通り、コマンドを打ち直してステータスを確認してみる。

# systemctl status httpd.service -l
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since 火 2017-08-01 20:26:01 JST; 1min 34s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 24056 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 22160 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Process: 24055 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 24055 (code=exited, status=1/FAILURE)8月 01 20:26:01 laravel systemd[1]: Starting The Apache HTTP Server...
8月 01 20:26:01 laravel httpd[24055]: AH00526: Syntax error on line 105 of /etc/httpd/conf.d/ssl.conf:
8月 01 20:26:01 laravel httpd[24055]: SSLCertificateFile: file '/root/ssl/server.crt' does not exist or is empty
8月 01 20:26:01 laravel systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
8月 01 20:26:01 laravel kill[24056]: kill: cannot find process ""
8月 01 20:26:01 laravel systemd[1]: httpd.service: control process exited, code=exited status=1
8月 01 20:26:01 laravel systemd[1]: Failed to start The Apache HTTP Server.
8月 01 20:26:01 laravel systemd[1]: Unit httpd.service entered failed state.
8月 01 20:26:01 laravel systemd[1]: httpd.service failed.

「SSLCertificateFile: file '/root/ssl/server.crt' does not exist or is empty」と表示されている。
「ファイルが存在しない、または、空」って、どういう事?

ファイルを確認する。
存在するる。

# ls -l /root/ssl/server.crt
-r--------. 1 root root 1277  8月  1 20:25 /root/ssl/server.crt

ファイルの内容を確認する。
内容は問題ないように見える。

# cat /root/ssl/server.crt
-----BEGIN CERTIFICATE-----
MIIDgjCCAmoCCQD6g88R6RKqXjANBgkqhkiG9w0BAQsFADCBgjELMAkGA1UEBhMC
SlAxDjAMBgNVBAgMBUFpY2hpMQ8wDQYDVQQHDAZOYWdveWExCzAJBgNVBAoMAlBz

(略)

S6+Q5EMXtIyCSUHFEOp525JFVAEJ/hTYv6ivBu8Cv7hi4057Cfg=
-----END CERTIFICATE-----

SSL証明書を作成する時に何か間違えたか?
SSL証明書を作り直してみる。
同じエラーが発生する。

ファイルのパーミッションか?
rootのみが見えるように変更してみる。
同じエラーが発生する。

# chmod 700 /root/ssl
# chmod 600 /root/ssl/*

ん~? なんだこれ?

あれやこれやと悩んで、はっと気が付いた。もしかして、SELinux か!
SELinux の状態を確認してみる。オンだ。

# getenforce
Enforcing

SELinux を無効化し、Apacheを起動してみる。
起動した!

# setenforce 0
# getenforce
Permissive
# service httpd start
Redirecting to /bin/systemctl start httpd.service

原因はSELinuxだ!
Apache は、SELinux に阻まれて、SSL証明書が読めないのだ。

Apache の設定ファイルのディレクトリを確認してみる。
なるほど、「httpd_config_t」が必要なのか。

# ls -dZ /etc/httpd/conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 /etc/httpd/conf

SSL証明書が置かれているディレクトリの設定を確認する。

# ls -dZ /root/ssl
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 /root/ssl

SELinux の設定を変更する。

# chcon -R -t httpd_config_t .
# ls -dZ /root/ssl
drwxr-xr-x. root root unconfined_u:object_r:httpd_config_t:s0 /root/ssl

SELinux を有効化し、Apacheを起動してみる。
起動した!

# setenforce 1
# getenforce
Enforcing
# service httpd start
Redirecting to /bin/systemctl start  httpd.service

わかってしまえば何てことないのだが、4時間も悩んでしまった。(^^;

楽天SocialNewsに投稿!
0 0 0

ESXi上のゲストOSのパーティション操作

ESXi上で稼働させている仮想マシンのディスクが足りなくなってしまった。

ディスクが足りなくなってしまった

最初に仮想マシンを作成した時に、ディスク容量をケチったら、Cドライブがいっぱいになってしまい、残り389MB。Windows Updateにも失敗するようになってしまった。
昔なら、ディスクのパーティション分割をやり直して、OSを再インストールという状況なのだけれど、最近はパーティションの構成を編集できる便利なツールがあるので、これを利用してなんとかしてみる。

「コンピュータの管理」で見ると、現在のパーティションの構成は、こんな感じ。

パーティションの構成

仮想マシンのディスク容量は、ESXiの管理パネルである VMWare vSphere Client を操作して増やすことができる。
40GB→60GBと、20GBを追加した。

20GBを追加 20GBを追加

再び「コンピュータの管理」で見ると、現在のパーティションは、こんな感じになる。

パーティションの構成

追加した20GBは末尾にある。
増やしたいドライブはCドライブなのだが、パーティションが連続していないと結合(拡張)できないので、この状態では、追加20GBをCドライブに追加する事ができない。
Dドライブを末尾に移動して、すなわち、以下の様な状態にする必要がある。

パーティションを移動する

このパーティションの移動は、以下のツールで行う事にする。

EASEUS Partition Master

しかし、ひとつ問題がある。
このツールはインストールが必要なのだけれど、現在稼働中のこの仮想マシンにインストールしたくない(余計なソフトウェアをインストールしたくない)。
かといって、ディスクは仮想なので、物理ディスクのように、他のハードにディスクを接続するというわけにはいかない。
どうするか。

考える。
考える。
考える。
ちーん。

物理ディスクと同じ様に、仮想ディスクを他の仮想ハードに接続すればいんじゃないのか。
そして、他の仮想ハードにツールをインストールして、接続した仮想ディスクのパーティションを操作すればいいのではないか。
やってみよう。
問題の仮想マシンをパワーオフした上で、VMWare vSphere Client で、問題の仮想マシンに接続されている仮想ディスクを、他の仮想ハードに接続する。

仮想ディスクを他の仮想ハードに接続する

仮想ディスクを他の仮想ハードに接続する 仮想ディスクを他の仮想ハードに接続する 仮想ディスクを他の仮想ハードに接続する 仮想ディスクを他の仮想ハードに接続する 仮想ディスクを他の仮想ハードに接続する

仮想ディスクを他の仮想ハードに接続する

他の仮想ハードを起動し、「コンピュータの管理」で見ると、こんな感じになる。

パーティションを移動する

Partition Master Free を起動し、Gドライブを末尾に移動する。

Gドライブを末尾に移動する Gドライブを末尾に移動する

続いて、Fドライブと未割り当て領域をを結合(Fドライブを拡張)する。

Fドライブを拡張する Fドライブを拡張する

変更を反映する。

変更を反映する

「コンピュータの管理」で確認する。
バッチリだ。

パーティションの構成

他の仮想マシンから、仮想ディスクを切り離す。

仮想ディスクを切り離す 仮想ディスクを切り離す

問題の仮想マシンを起動し、エクスプローラで確認する。

エクスプローラで確認する

無事、Cドライブが拡張され、Cドライブのディスク領域に余裕ができた。
Windows Update も成功。
よしよし。

楽天SocialNewsに投稿!
0 0 0

ESXi監視で大ハマリ (12) – コマンドで監視(F)

このエピソードの続き。

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)/

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

ESXi WELCOMEページ

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

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

ESXi 情報ページ

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

/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)」が表示されている。
クリックすると、内容も表示される。

ESXi 情報ページ

これにより、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経由でプッシュする事も可能かもしれない。
機会があったら試してみようと思う。

一連記事:

楽天SocialNewsに投稿!
0 0 0

ESXi監視で大ハマリ (11) – コマンドで監視(E)

このエピソードの続き。

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 上でのファイル生成と、ファイル取得の際のアクセスがコンフリクトする事もない。
いい感じだ。
これで行こう。

一連記事:

楽天SocialNewsに投稿!
0 0 0

ESXi監視で大ハマリ (10) – コマンドで監視(D)

このエピソードの続き。

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 の再インストールが必要になった場合などにインストール以外の作業が生じてしまうので、できるだけ避けたい。

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

一連記事:

楽天SocialNewsに投稿!
0 0 0

ESXi監視で大ハマリ (9) – コマンドで監視(C)

このエピソードの続き。

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 から飛んでくるアラート・メールは、以下の様な文面である。

発生日時  :2016/05/10 05:38:04
サーバ   :********.**.**.**
IPアドレス :192.168.***.***
サービスタグ:*******
重大度   :Warning
内容    :Warning Status Alert. Device: ********.**.**.**

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

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

一連記事:

楽天SocialNewsに投稿!
0 0 0

広告

まとめページ

取得した資格
登った山

広告

サイト内検索

WordPress

広告

RSS

RSS 記事
RSS コメント
Server offered by
有限会社パテンティックソフトウェア
Profile for zunbe
zunbeの読書メーター
読んだ本
-
ページ数
-
書評投稿数
-