【ソフトウェア】

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

シンクライアントを最新 Raspbian の最小構成で

このエピソードの続き。

Raspberry pi をシンクライアント端末に
Raspberry pi の OS を pidora に変更

シンクライアント用の Raspberry pi は、OS を pidora にしていたのだけれど、いつの間にか pidora は標準のラインナップから外れてしまい、ダウンロードできなくなってしまっている。
pidora を選択したのは、単に ずんべ が Debian系より Fedora系の方が慣れているというだけの理由だったのだけれど、ラインナップから外れているとなると、後々のメンテナンスがしんどくなるので、OS を raspbian に戻すことにした。

Raspberry pi Type B + Raspbian Jessie 4.1

これまでは、Raspberry pi 自身でも X-Window 環境上でブラウザを起動して使用できるように構成していたのだけれど、今回は、シンクライアントのみの機能を実装すると割り切って、裏の Windiws に RDP で接続するためだけの機能に絞る事にする。

また、最新の raspbian はサイズが大きくなっていて、SDカードは 4GB 以上を求められるのだけれど、2GB のSDカードに押し込んでシンクライアントを構築してみる事にする。
ぶっちゃけ、最近のSDカードは、4GB でも 8GB でも、安い信頼性の劣るものなら300円、信頼性のあるものでも800円くらいで購入できる。チャイナなサイトであれば、200円台のものもある。そんなケチケチせずに 4GB とか 8GB のSDカードを使ったらどうだ、とは思うのだけれど、そこはビンボー人ずんべ、手元に 2GB のSDカードが何枚も余ってしまっているので、これらの廃物(!)を利用してシンクライアント端末に仕立てたいと思う。

さて、このブログを書いているタイミングでは、Raspbian は3種類がダウンロードできる。

Raspbian Jessie 4.1
Raspbian Jessie Lite 4.1
Raspbian Wheezy 3.18

このうち、2GB のSDカードへの焼き込みができるのは、Jessie Lite だけなので、これを使う事にする。
このイメージは、最小構成で raspbian が書き込まれるが、これに必要なプログラムを追加でインストールして、シンクライアント端末にする事にする。

SDカードに Jessie Lite を書き込み、Raspberry pi を起動。

まず、raspi-config を起動して、「Expand Filesystem」を実行する。

# raspi-config

Expand Filesystem

実行前と実行後。容量が 1.3GB から 1.8GB まで拡張された。

$ df -h | grep /dev/root
/dev/root 1.3G 931M 262M 79% /
$ df -h | grep /dev/root
/dev/root 1.8G 931M 795M 54% /

続いて、必要なソフトウェアをインストールする。
今回は、シンクライアント端末に特化する事にして、以下のソフトウェアをインストールする事にし…

X-Window
RDPクライアント

以下のソフトウェアはインストールしない事にする。
今回は、RDPクライアントを全画面モードで起動し、キオスク・モードの様に動かすので、X-Window上でアプリを切り替える事は想定しない。すなわち、ウィンドウ・マネージャは必要ないので、少々乱暴かもしれないけど、これはインストールしない。

日本語環境
ウィンドウ・マネージャ

まず、X-Windowをインストールする。

# apt-get install x-window-system

続いて、RDPクライアントをインストールする。

# apt-get install rdesktop

.xinitrc を作成する。

$ vi ~/.xinitrc
#!/bin/sh
rdesktop -f -z -k ja 192.168.XXX.XXX -u ***** -p *****

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

-f:フルスクリーン(全画面)で起動。
-z:通信を圧縮して行う。
-k:キーボード・レイアウトを日本語とする。
-u:アカウント
-p:パスワード

アカウントにログインしたら、X を起動してしまうようにする。
.bashrc の末尾に、以下の1行を追加。

$ vi ~/.bashrc
startx

前述の通り、Raspberry pi に日本語環境は入れないけれど、接続するキーボードは106キーボードなので、キーボード・レイアウトを設定する。
raspi-config で設定を変更できないのかと思うけれど、なぜか raspi-config では106キーボードを選択できないので、設定ファイルを直接編集する。

# vi /etc/default/keybord
XKBMODEL=”jp106″
XKBLAYOUT=”jp”

Raspbery pi を再起動し、ログインする。
自動的に X が起動、RDPで裏の Windiws に接続。
成功!

リモート・デスクトップ画面

最終的に、使用容量は 1.1GB に収まり、空き容量は約660MB。シンクライアントとして使用するには十分でしょう。

$ df -h | grep /dev/root
/dev/root 1.8G 1.1G 661M 62% /

よしよし。
これでしばらく運用してみよう。

楽天SocialNewsに投稿!
0 0 0

ActiveXで大ハマリ

ActiveXのインストールでハマったのでメモ。

お客様に納品しているソフトウェアは、開発言語が Microsoft Visual Basic 6.0(以下、VB6)で、AxtiveXで提供されているものがある。
ActiveXでソフトウェアを提供する事によって、Microsoft Internet Explorer(以下、IE)上で Windows ネイティブなプログラムを実行する事ができるため、WEB経由で動作するシステム上で、IE 上でシームレスにプログラムを動かせるので、便利に使用してソフトウェアを開発していた。
また、ActiveXが持つ機能を使用して VB6 のランタイムライブラリも自動的に必要なDLLのみがインストールされるのも便利なところだ。

しかしながら、昨今はセキュリティがひじょうに厳しくなった事もあって、ブラウザ上でネイティブなコードを実行できる ActiveX は避けられる方向にある。
代表例は Flash で、過去は、サイトのトップページで多用されていたが、現在は、スマートフォン端末やタブレット端末で使用できない事もあり、昨今では、ほとんど使われなくなった。

また、VB6 は、開発環境としては古いものであり、現行でマイクロソフトのサポートサイクル内にあるOSでは、Windows Vista までしか開発環境のインストールはサポートされていないものである。

開発ツール対応 OS 一覧

とは言え、お客様に納品しているソフトウェアは、そう簡単に新しいものには変えられないので、使える限りは、使い続ける事が原則だ。マイクロソフトの都合や、開発サイドの都合で、問題なく動いているものを、わざわざお金をかけて作り直しなどさせてはくれない。

そういうわけで、過去に VB6 + ActiveX で納品したソフトウェアの改修を行う事になったのだが、問題が発生した。

まず、ユーザ様の環境に合わせたテスト環境し、過去に納品した ActiveX のインストールを試してみる。
最新の IE である IE11 に合わせて若干の調整が必要であったが、インストールは問題なくでき、ActiveX は問題なく動作した。
ここまでは順調だ。

後日、プログラムを改修した ActiveX のパッケージで、インストールを試したところ、今度は問題が発生した。
ActiveX をインストールする旨のダイアログは表示されるが、インストールに失敗してしまう。エラーも何も出ない。

インストールはスタートする

インストールはスタートするのに、何も言わずに終了し、インストールに失敗してしまう。
なぜだ?
新しく作成した ActiveX のパッケージがおかしいのか?

試しに、先にインストールが成功した、過去に納品した ActiveX を一旦削除して、もう一度インストールをしてみると、こちらもインストールできなかった。
いったい何が起こっているのだ?

IE の「インターネット オプション」の設定を変更し、セキュリティを緩々にしてみる。
インストールできない。

テスト環境は ESXi 上に作成しているので、インストール操作を行う前にバックアップした環境を書き戻してみる(インストールに成功した環境に戻してみる)。
インストールできない。

んんんん??

ActiveX のインストールが行われる際に、IE は Temporary Internet Files にログを残すので、これを参照してみる。

IEのログ

すると…

*** Code Download Log entry (20 Nov 2015 @ 23:35:09) ***
Code Download Error: (hr = 800c0007) 要求されたリソースのデータは使用できません。Operation failed. Detailed Information:
CodeBase: http://***********************
CLSID: {********-****-****-****-************}
Extension:
Type:LOG: Item **********.ocx being processed.
--- Detailed Error Log Follows ---
LOG: Download OnStopBinding called (hrStatus = 0 / hrResponseHdr = 0).
LOG: Item **********.ocx being processed.
LOG: Item MSVCRT.DLL being processed.
LOG: Item MSINET.OCX being processed.
LOG: Item INETJP.DLL being processed.
LOG: Item COMDLG32.OCX being processed.
LOG: Item CMDLGJP.DLL being processed.
LOG: Item MSCOMCTL.OCX being processed.
LOG: Item MSCMCJP.DLL being processed.
LOG: Item msvbvm60.dll being processed.
LOG: Item OLEAUT32.DLL being processed.
LOG: Item OLEPRO32.DLL being processed.
LOG: Item ASYCFILT.DLL being processed.
LOG: Item STDOLE2.TLB being processed.
LOG: Item COMCAT.DLL being processed.
LOG: Item VB6JP.DLL being processed.
LOG: URL Download Complete: hrStatus:0, hrOSB:0, hrResponseHdr:0, URL:(http://***********************.CAB)
LOG: Download OnStopBinding called (hrStatus = 800c0007 / hrResponseHdr = 8007007e).
LOG: Redundant download attempted, but no more codebases available.
LOG: URL Download Complete: hrStatus:800c0007, hrOSB:0, hrResponseHdr:8007007e, URL:(http://activex.microsoft.com/controls/vb6/VB6JP.cab)
LOG: Reporting Code Download Completion: (hr:800c0007 (FAILED), CLASSID: d80b51ca..., szCODE:(http://***********************.CAB), MainType:(null), MainExt:(null))

2行目でエラー「800c0007」が記録されている。
その原因は、下から2行目の、リターンコード「8007007e」のようだ。
エラーとして記録されているURLは、これだ。

http://activex.microsoft.com/controls/vb6/VB6JP.cab

えぇ~?
activex.microsoft.com 上のパッケージにアクセスできない?

wget コマンドでダウンロードを試みてみる。

$ wget http://activex.microsoft.com/controls/vb6/VB6JP.cab
--2015-11-20 23:49:35--  http://activex.microsoft.com/controls/vb6/VB6JP.cab
activex.microsoft.com をDNSに問いあわせています... 61.213.151.18, 61.213.151.10
activex.microsoft.com|61.213.151.18|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 404 Not Found
2015-11-20 23:49:36 エラー 404: Not Found。
$

404 Not Found…。orz

nslookup で activex.microsoft.com を引いてみる。

$ nslookup activex.microsoft.com
Server:         XXX.XXX.XXX.XXX
Address:        XXX.XXX.XXX.XXX#53Non-authoritative answer:
activex.microsoft.com   canonical name = activex.microsoft.com.edgesuite.net.
activex.microsoft.com.edgesuite.net     canonical name = a1670.g2.akamai.net.
Name:   a1670.g2.akamai.net
Address: 61.213.151.10
Name:   a1670.g2.akamai.net
Address: 61.213.151.18
$

DNSは引けるが、何だよ、この akamai.net って。

2日待ってみたが、一向に復旧しない。
サーバ activex.microsoft.com の障害って、どこに連絡をすればよいのだ?
マイクロソフトのMSDNのサポートに電話をしてみる。
が…まったく要領を得ない。
サポート窓口の人は、技術的な事はまったくわからないようで、「ActiveX」も、「activex.microsoft.com」も、拡張子「.CAB」も、「DNS」も、「nslookup」も通じない。
文字通り、話にならない。まったく埒があかない。
結局、最後はこうだ。

このサーバは、時々アクセスできなくなる事があるようです。
しばらくお待ちいただければ復旧すると思います。
このサーバに関する連絡窓口はございません。

いやいや、「時々、アクセスできなくなる事がある」って、おかしいやろ。
「このサーバに関する連絡窓口はございません」って、おかしいやろ。
activex.microsoft.com が動いていないという事は、世界中で ActiveX のインストールができない状態になってるって事だぞ。そんな重要なサーバが、何日も落ちっぱなしっておかしいやろ。

ちなみに、実は7年前にも似たような事があった。

【プログラミング】ActiveXで大ハマリ

この時は、完全にアクセスできないのではなく、不安定な状態で、ダウンロードできたり、できなかったり、という状況で、パッケージをローカル・サーバに置くことで回避できた。
しかし今回は、まったくアクセスできないので、パッケージを手元に置こうにも、そのパッケージのダウンロードもできない。

どうにもならない。
マイクロソフト君、しっかりしてくれ。

■2015/11/26 追記

再度マイクロソフトに問い合わせてみたけれど、やっぱり「わからない」という回答。
なんだかなぁ。

仕方がないので、activex.microsoft.com からのダウンロードは諦め、開発PC上の DLL や OCX が正であると考えて、パッケージを作成するときに、DLL や OCX をすべてパッケージに含めるように設定を変更してパッケージを作成。
当然の如く、パッケージは肥大化し、約200KBだったCABが、10倍の2MBに。

$ ls -l
-rw-r--r--. 1 zunbe zunbe  206058  3月 13 21:56 2013 OLD-ActiveX.CAB
-rw-r--r--. 1 zunbe zunbe 2007507 11月 26 05:20 2015 NEW-ActiveX.CAB

これで一応、新しい ActiveX をインストールする事はできるようになった。
ファイルのサイズは大きくなってしまったが、これはヨシとする。
とりあえずは、これでいい。

しかし、まだ問題が。
プログラムの検証をするために、旧版の ActiveX をインストールしなければならない。
ずんべ 自身がインストールするだけなら、ランタイム・ライブラリをインストールした上で、旧版の ActiveX を regsvr32 で登録すれば何とかなるが、お客様もでも同様に新旧両方の ActiveX をインストールして検証をする必要があるので、お客様には「regsvr32で」というわけにはいかない。

仕方がないので、作成した新版のパッケージを元に、旧版のパッケージを手動で作成する事にする。
まず、作成した新版の CAB を一旦解凍する。
新版の ActiveX を、旧版の ActiveX に差し替える。
INF ファイルも手動で修正する。
再び CAB に固める。
作成した旧版のパッケージで、インストールをトライしてみると、無事成功。

やれやれだぜ。(空条承太郎風)

楽天SocialNewsに投稿!
0 0 0

広告

まとめページ

取得した資格
登った山

広告

サイト内検索

WordPress

広告

RSS

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