【ソフトウェア】

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

ssmtpで小ハマリ

Raspberry pi 上で稼働するシステムを開発していて、メールの送信で小ハマリしたのでメモ。

Raspberry pi/左:3 Type B、右:2 Type B

Raspberry piからメールを発信したいのだが、通常のポート25ではなく、サブミッション・ポート 758 を使用して発信したい。
そこで、ssmtpをインストールして送信する事にした。

ssmtpをインストールし、設定を行う。

# apt-get install ssmtp

設定はこんな感じか。

# cd /etc/ssmtp
# vi ssmtp.conf
----------
mailhub=*****.co.jp:587
AuthUser=*****
AuthPass=*****
AuthMethod=LOGIN
UseTLS=Yes
UseSTARTTLS=Yes
----------

送信してみる。

$ sendmail -t
From:*****.co.jp
To:*****.co.jp
Subject:TEST
TEST
sendmail: Authorization failed (535 5.7.8 Error: authentication failed: authentication failure)
$

へ? Authorization failed だと?

同じサーバ上の別のメール・アカウントで試してみる。

$ sendmail -t
From:*****@*****.co.jp
To:*****@*****.co.jp
Subject:TEST
TEST
$

送信できた。
最初に試したメール・アカウントだけがうまくない。
どゆこと?

パスワードを簡単なものに変えてみる。
送信できた。

パスワードで使用できない文字があるのか。
パスワードを1文字づつ変えながらリトライしてみる。
むむむ、パスワードに「#」が含まれていると送信エラーになるようだ。

「#」がダメって…まさか、設定ファイル(/etc/ssmtp/ssmtp.cof)の読み込みで、「#」以降を無条件にコメントとして削除してしまうようなショボい話じゃないだろうなー。

ssmtpのソースコードを確認してみる。

/*
read_config() -- Open and parse config file and extract values of variables
*/
bool_t read_config()
{

 (略)

  while(fgets(buf, sizeof(buf), fp)) {
    char *begin=buf;
    char *rightside;
    /* Make comments invisible */
    if((p = strchr(buf, '#'))) {
       *p = (char)NULL;
    }

 (略)

がっくり。orz

楽天SocialNewsに投稿!
0 0 0

Raspberry pi を Overclock で動かす

Raspbian で raspi-config を起動したら「Overclock」という設定がある事に気がついた。

Overclock

なんだこれ?
このタイトルの通り、CPUをオーバークロックで動かして高速化できるのだろうか。

30年くらい前、ずんべ は NEC PC-6001MKⅡ を持っていたのだが、同時期に販売されていた PC-8001 シリーズや、PC-8901 シリーズと比べると、とても非力なPCだった。
ずんべ は、この PC-6001MKⅡ の水晶振動子を高クロックなものに換装して、むりやりマシンパワーを上げた事がある。

PC-6001MKⅡ

もちろん、オーバークロックすると、PC自体は不安定になる場合があるので、元々取り付けられていた水晶振動子にスイッチで切り替えられるようにしていた。
昔のPCは、そんな事もできたけれど、Raspberry pi の Raspbian では、動作クロックをソフトウェア的にコントロールできるらしい。
すごい、すごい。

実際、オーバークロックによって、どのくらい速度が変わるのだろう。
UnixBench を使って、動作速度を計測してみようと思う。

オーバークロックを設定しようとすると、警告が表示される。

警告

訳すと…

オーバークロックすると、寿命を縮めるかもしれない。
オーバークロックすると、動作が不安定になるかもしれない。
オーバークロックを無効にするには、シフトキーを押しながらブートしてください。

という感じだろうか。
要するに自己責任でやれって事だ。
これをやって、Raspberry pi が壊れてしまっても数千円だ。やってみよう。

オーバークロックの選択肢は6個ある。

選択肢

このうち、以下の3つの設定で動作速度を計測してみる事にする。

None(デフォルト)
Medium
Turbo

結果は…

■None

Dhrystone 2 using register variables        1677505.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      239.1 MWIPS (10.0 s, 7 samples)
Execl Throughput                                169.2 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         28763.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks            9142.5 KBps  (30.2 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks         77165.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              130202.8 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  14739.9 lps   (10.0 s, 7 samples)
Process Creation                                443.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    364.5 lpm   (60.2 s, 2 samples)
Shell Scripts (8 concurrent)                     46.5 lpm   (60.6 s, 2 samples)
System Call Overhead                         327900.7 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    1677505.4    143.7
Double-Precision Whetstone                       55.0        239.1     43.5
Execl Throughput                                 43.0        169.2     39.3
File Copy 1024 bufsize 2000 maxblocks          3960.0      28763.1     72.6
File Copy 256 bufsize 500 maxblocks            1655.0       9142.5     55.2
File Copy 4096 bufsize 8000 maxblocks          5800.0      77165.4    133.0
Pipe Throughput                               12440.0     130202.8    104.7
Pipe-based Context Switching                   4000.0      14739.9     36.8
Process Creation                                126.0        443.0     35.2
Shell Scripts (1 concurrent)                     42.4        364.5     86.0
Shell Scripts (8 concurrent)                      6.0         46.5     77.5
System Call Overhead                          15000.0     327900.7    218.6
========
System Benchmarks Index Score                                          73.8

■Medium

Dhrystone 2 using register variables        2171985.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      310.1 MWIPS (10.0 s, 7 samples)
Execl Throughput                                189.9 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         33122.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           10475.4 KBps  (30.1 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks         86263.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              159753.6 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  16159.4 lps   (10.0 s, 7 samples)
Process Creation                                472.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    406.3 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                     53.2 lpm   (60.9 s, 2 samples)
System Call Overhead                         430825.0 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2171985.2    186.1
Double-Precision Whetstone                       55.0        310.1     56.4
Execl Throughput                                 43.0        189.9     44.2
File Copy 1024 bufsize 2000 maxblocks          3960.0      33122.7     83.6
File Copy 256 bufsize 500 maxblocks            1655.0      10475.4     63.3
File Copy 4096 bufsize 8000 maxblocks          5800.0      86263.4    148.7
Pipe Throughput                               12440.0     159753.6    128.4
Pipe-based Context Switching                   4000.0      16159.4     40.4
Process Creation                                126.0        472.9     37.5
Shell Scripts (1 concurrent)                     42.4        406.3     95.8
Shell Scripts (8 concurrent)                      6.0         53.2     88.7
System Call Overhead                          15000.0     430825.0    287.2
========
System Benchmarks Index Score                                          86.4

■Turbo

Dhrystone 2 using register variables        2431707.5 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      347.7 MWIPS (9.9 s, 7 samples)
Execl Throughput                                282.6 lps   (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         48943.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           15322.5 KBps  (30.1 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        129841.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              200511.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  25045.2 lps   (10.0 s, 7 samples)
Process Creation                                725.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    590.4 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                     75.7 lpm   (60.3 s, 2 samples)
System Call Overhead                         467398.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2431707.5    208.4
Double-Precision Whetstone                       55.0        347.7     63.2
Execl Throughput                                 43.0        282.6     65.7
File Copy 1024 bufsize 2000 maxblocks          3960.0      48943.3    123.6
File Copy 256 bufsize 500 maxblocks            1655.0      15322.5     92.6
File Copy 4096 bufsize 8000 maxblocks          5800.0     129841.4    223.9
Pipe Throughput                               12440.0     200511.2    161.2
Pipe-based Context Switching                   4000.0      25045.2     62.6
Process Creation                                126.0        725.8     57.6
Shell Scripts (1 concurrent)                     42.4        590.4    139.2
Shell Scripts (8 concurrent)                      6.0         75.7    126.1
System Call Overhead                          15000.0     467398.3    311.6
========
System Benchmarks Index Score                                         117.7

おぉ、すごい。
高いクロックを選択して動かすと、確かに速くなる。
「None」に比べて、「Medium」では約1.1倍、「Turbo」では約1.5倍で動作している。

警告画面に表示されていた通り、オーバークロックで動かすとハードウェアの寿命を縮めてしまう可能性があるのだろうけど、1.5倍は捨てがたい。
壊れて元々で「Turbo」で運用してみようと思う。

楽天SocialNewsに投稿!
0 0 0

rdesktopで小ハマリ

このエピソードの続き。

Raspberry pi をシンクライアント端末に
Raspberry pi の OS を pidora に変更
シンクライアントを最新 Raspbian の最小構成で

シンクライアントから接続する裏の Windows は 7 だったのだけれど、Windows 10 に変更する事にした。

Raspberry pi Type B

裏の Windows 10 を準備し、rdesktop の接続先を変更、ログイン!
が、接続できず、X-Window が落ちてしまう。
なんだ?

.xinitrc をリネームして外し、X を起動する。
ターミナルが起動するので、コマンドラインで rdsktop を実行してみる。

$ rdesktop -f -z -k ja 192.168.XXX.XXX -u ***** -p *****
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.

何やらエラーが出ている。
調べてみると、 どうやら rdesktop は開発が止まっていて、Windows 10 には対応していないようだ。
更に調べてみると、rdesktop から派生したソフトウェアで、freeRDP というソフトウェアがあるらしい。

試してみる。
freeRDPをインストール。

# apt-get install freerdp-x11

.xinitrcを変更。

$ vi ~/.xinitrc
#!/bin/sh
xfreerdp /u:***** /p:***** /v:192.168.XXX.XXX

ちなみに、指定しているオプションは以下の通り。

/u:アカウント
/p:パスワード
/v:接続先マシン

ついでに、.bashrc の起動スクリプトも、コンソールでログインした時だけ起動するように修正。
いや、実は、X-Window を起動した時に、Xが起動 → xterm が開く → startx → Xが起動 → xterm が開く → startx → Xが起動 → … と無限ループ起動になってしまったのだ…。(超大汗)

$ vi ~/.bashrc
if [ $TERM = 'linux' ]; then
  startx
fi

ログインし直してみる。
Windows 10 に接続できた。

Windows 10

キーボード・レイアウトも漢字変換も問題なし。

キーボード・レイアウト & 漢字変換

よしよし。
これまで使っていた裏の Windows 7 は、もういらないので削除。

楽天SocialNewsに投稿!
0 0 0

広告

まとめページ

取得した資格
登った山

広告

サイト内検索

WordPress

広告

RSS

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