【ハードウェア】

このエピソードの続き。

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上で取得した監視情報をメール以外の方法で、監視サーバに転送する仕組みを考えてみたい。

一連記事：

車のタイヤがパンクした。(涙)

ちくしょう。

とりあえず、スペアに交換。

パンクの原因はすぐにわかった。クギが刺さったとかではなく、原因は、これ。
水槽にしずめてブクブクさせるまでもなく判明。
空気バルブが裂けてしまっている。

なぜパンクの原因がすぐわかったかというと、実は9ヶ月ほど前にも同じ原因でパンクしたから。

空気バルブそのものはゴムの製品であり、元来、劣化する消耗部品であるのはわかるのだが、車に乗るようになって30年、空気バルブが裂けるという状況は9ヶ月前と今回のみであり、しかも、1年以内に2本が裂けるというのは普通じゃない。

いつだったか忘れたが、前回、タイヤ4本を交換した時に、空気バルブも4本とも交換した。
仮に空気バルブ4本が同じロットの製品であったとすると、残り2本も近い将来、裂けてしまう可能性が考えられる。
空気バルブだけ交換するというのは、ちょっともったいない気もするが、走っている時にバルブが裂けるという事態は避けたいので、予防措置的に交換する事にする。

空気バルブの交換は、部品代込み1本1,500円。3本で4,500円。
安全の値段としては安いのだろうけど、痛いと言えば痛い出費だ。(T_T)
しかし、まぁ、仕方がない。

さっそくタイヤ屋さんに車を持ち込んで交換を依頼する。
交換している途中で、店員さんが私を呼ぶ。
言いにくそうに、こう言う。

空気バルブの交換しているタイヤのところに案内される。
取り付けられている空気バルブを呼び指しながら、こう言う。

自分で触れてみると、確かにきちんとはまっていない。

走行中に空気バルブが裂けたり、空気バルブが抜けたり、といったダブルの危険があったようだ。
ガクガクブルブル。

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

価格は $2.61。現在のレートだと 280円くらいだろうか。安い。

しかし、中国製といえば、気になるのは品質だ。

さっそく撮影してみる。
キーボード（距離 約15cm、約30cm）。

本棚（距離 約2m）。

がっくり…。
完全にピンボケだ。
WEBカメラと言うと、その用途から考えて、普通は50cm～1mくらいの距離で、そこそこピントが合った状態で出荷されていそうなものなのだが、大幅にピントがズレているように見える。

しかし、このWEBカメラはオート・フォーカスではなく、マニュアル・フォーカス。
レンズ部分を回すとピント合わせができるので、回してみる。

が…まったく変化しない。
ピントのズレ具合が変わらないのではない。まったく変化しない。
なんだこれは？
中国製の製品の品質に期待しているわけではないけれど、こうもハズレが多いとイヤになる。

さて、どうするか。

ここはやはり、ビンボー人ずんべ、直せるかどうか自信はないが、おそらく中はワンパッケージの基板が入っている簡単な構造で、ピンボケの原因はごく単純なことだろうと考え、選択肢3で行く事にする。もしダメでも選択肢2になるだけだ。

とりあえず、分解してカメラ本体を取り出してみる。思った通りワンパッケージになっている。

先端の8角の部分を手で回してみると、普通に回る。
ピント調整はできるように見える。

先端の8角の部分と、カバーが噛みあっていなくて、滑っているのだろうか。

この大きな8角で、滑るなんて考えられないのだが…。
組み付けて回してみるが、きちんと回るように見える。
どういうことだ？

組み付けた状態に戻して回してみる。
回しながらよく見ると、8角の部分は回っているが、基板と繋がっているネジ部分が回っていない様に見える。

う～ん、空回りしているぞ。
どういうことだ？

再びカメラ本体を取り外して、先端部分をマジマジと見てみる。
あれ？ この8角の部分、別パーツじゃないか？
つまんで引っ張ってみると…　あ！ 外れた！

先端部分（8角の部分）が別パーツなのだが、円形の部分には引っ掛かりも何もなく、ここが空回りしていたのだ。
これはちょっと設計がショボいでしょ。
ここが滑ったら、当然ピント合わせはできないわけで、接着するなり、溝を掘って滑らないようにするなり、組み付けの時に滑らない状態にまで押し込むなり、何らかの設計上または製造上の対処が必要でしょ。

で、どうするか。
精密部品であるので、接着剤を使ったり、溝を掘るなどの変形させるような事はしたくない。
最後の「滑らない状態にまで押し込む」で行く事にする。

強めにぐっと押し込んでみる。
回しても滑らないようになった。
これでいい事にしよう。

元通りに組み付ける。

再び撮影してみる。今度はピントの調整ができた。
キーボード（距離 約15cm、約30cm）。

本棚（距離 約2m）。

ちゃんとピントを合わせる事ができた。
とりあえず、これでヨシ。
しかし、中国製の製品は、いろいろメンドクサイのう。

中国のショッピングサイト Aliexpress で商品を購入して大ハマリしたのでメモ。

手元にある Raspberry pi や、Android スティックに使用するマイクロSDカードが必要になったので、Amazonや楽天などで適当な商品を探していた。
Aliexpressと言うと、以前に「512GB SDカード」を購入して小ハマリした事があるが、正直言って、中国サイト＋中国ショップ＋中国製品というのは信用できない。
そもそも、8GBのSDカードは、Amazonで購入しても数百円で購入できるので、中国製品との差額は数百円程度、無理をして中国製品を買う必要があるのか、という話はあるのだけれど、社会勉強(！)も兼ねて購入してみた。

これだ。

価格は $2.46、日本円で300円くらいだ。送料込み。

カートに入れて購入し、商品の到着を待つ。
一週間ほどで商品が届いた。さっそく、PCに接続してみる。

容量0バイト...。
期待を裏切らない中国製品。

気を取り直して、フォーマットをトライしてみる。

フォーマットできない。ダメだ。
念のため、Windows標準ではなく、他のフォーマッターも試してみたが、同様にフォーマットできない。
明らかに不良品だ。
期待を裏切らない中国製品。

ショップに連絡すると、以下の連絡が来た。

まぁ、もっともだ。
動画を作成する。

YouTubeにアップして、ショップにURLを連絡する。
ショップの回答は…。

仕方がないので、このブログのサーバに動画ファイルをアップロードして、ショップにそのURLを連絡する。
ショップの回答は…。

なるほど、そうか、相手は中国か。アクセスできるURLがかなり制限されるのだな。
しかし、「テストを行った動画が欲しい」と言ったのはお前だろ。動画を受け取る方法くらい用意してから言ってこい！
「can"t  open」ではなくて、どうやったら動画を見られるのかを連絡してこい！

どうやったら動画を見る事ができるのだ、と強く言うと、この回答が返ってきた。

サイズ110MBのファイルをメールで送れってか。正気とは思えない。
一応試してみるが、当然、110MBの添付ファイルを付けたメールなど、送信エラーで落ちる。
なんとかならないかと調べてみると、Yahooメールが25MBまで添付できるらしい。
仕方がないのでファイルを分割し、結合するスクリプトも付けてYahooメールから送信。
やっとショップが動画確認する事ができた。

これで代替商品を送ってくると思ったら、今度は、ショップはこんな事を言ってきた。

ふざけんな！ さっさと代替商品を送ってこい。
どうして代替商品を発送するのに交換条件を付けられなきゃいかんのだ！
無条件で送ってこんかい！
しかし、ショップの回答はこうだ。

ふざけんな！ お前が必要としているか否かが★の数であるわけがないだろう！

こんなやりとりを何度も何度もしたのだが、ショップは一向に代替商品を発送しようとしない。

埒が明かない。
あまりにも腹が立ったので、ずんべは伝家の宝刀を抜いた。
ショップ対して以下の通告をする。

ショップはこんな事を言ってくる。

ふざけんな！ずんべはこう返した。

「Open Dispute（オープン紛争モード）」を突き付けて、やっと送ると言ってきた。

めんどくせー。
どうして不良品の代替商品を受けるのに、こんなに手間がかかるんだ。
グダグダ言わずに、さっさと送ってこい。

これによって、中国サイトの商品やショップについている評価である★の数はまったく意味がないものである事が、今回はっきりわかった。

ところで、ショップは、発送に際して、以下の確認を求めてきた。

まずは出荷した事が確認できればよいので、これは了承した。
しかし...
待てど暮せど、ショップはトラッキングナンバーを送ってこない。
しびれを切らして、トラッキングナンバーを要求すると、以下のように言ってきた。

ふざけんな！このトラッキングナンバーは不良品が送られてきた時のトラッキングナンバーだろ！
代替商品のトラッキングナンバーを出さんかい！
何度も強く要求したが、トラッキングナンバーは出てこない。
どう考えても、ショップは日本国内でも中国国内でもトラッキングできない方法で発送したとしか考えられない。
トラッキングできない方法で発送している以上、トラッキングナンバーは出てこないので、諦めて待つことにした。

ところが数日後、こんな事を言ってきた。

どう見ても、トラッキングナンバーとは思えない。
いくつかのサイトで追跡をしてみるが、案の定、このトラッキングコードではヒットしない。

http://global.cainiao.com/

http://www.ems.com.cn/

http://cx.11185.cn/

これはどこで追跡するのかとURLを要求すると、以下の回答が返ってきた。

どう見ても違う。絶対に違う。
このページにも、トラッキングナンバーの形式がこのように書かれている。ショップが提示してきたトラッキングナンバーと明らかに形式が違う。検索できるわけがない。

念のため検索はしてみたが、もちろんヒットしない。
それに、何だこのドメイン名は。まともに運用されているドメインとは思えない。

あー、もー、くそー、めんどくせー。
以前のトラッキングコードを言って騙そうとするな！
意味のないトラッキングコードなんか出すな！
検索できないURLなんか出して騙そうとするな！
「約束通りではなく、中国でも追跡できない方法で発送しました」って最初から正直言え！
小学生じゃあるまいし、バレバレな嘘ばっかりつきやがって。
くそ、腹が立つ！

要するに、このショップの管理者は、「トラッキングナンバーを提示する」事の意味がわかっていないのだ。
トラッキングナンバーを提示する事によって、ショップは発送した事を証明できる。
できるだけ安い発送方法で送ろうという考えは分らないでもないが、評価に★5を付けない購入者に対して、トラッキングできない発送方法を使い、その問い合わせに対して嘘を言って逃げようなどという行動では、購入者の信頼を落とすだけだ。★の数、すなわち評価はどんどん下がっていく。

辛抱強く15日待って、やっと代替商品が到着した。PCに接続すると、無事、8GBと認識。
書き込みもOK、書き込み後のコンペアもOK。
と、いう事で、300円の商品を手に入れるのに1ヶ月かかった。
素直にAmazonで信頼ある商品を買えばいいのではないか、とは思うのだけどね。

ちなみに、付けた評価は、もちろん★1だ。

商品の初期不良というのは、よくある事。特に中国製品の歩留まりは悪いのだろう。致し方ない。
しかし、発送した商品が不良品であると判明した場合、すみやかに代替商品を発送してこれば、評価は★5になる。きちんとした対応がなされれば問題はない。
今回のようなショップの対応の場合は、評価に★1だって付けたくない。マイナス評価だ。

また、購入者側にも問題がある。
「評価に★5を付ければ代替商品を発送する」という要求を受けた購入者は、言われるがまま評価に★5を付けてはならない。
そもそも「★」すなわち「評価」が何を意味するものであるかを考えるべきだ。
「★」すなわち「評価」とは、その商品を購入した人の、ショップや商品に対する評価である。「強制された評価である★5」が並んでいるという事は、すなわち「評価されていない」のであるから、その★の数は何の意味も持たない。
Amazonなどでも、信頼性の低い商品に対して、業者自身が高評価のコメントを書き込んで、あたかも信頼性のある商品であるかの如く偽装するという事が話題になっているが、それと同じである。偽装された評価には意味がない。
そして、評価の偽装に購入者自身が加担する事は、回り回って購入者自身の不利益を招く。評価は正しく行うべきだ。

あと、信頼性の低いパーツはマークをしておく。

これで、しばらく使ってみよう。

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

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

30年くらい前、ずんべ は NEC PC-6001MKⅡ を持っていたのだが、同時期に販売されていた PC-8001 シリーズや、PC-8901 シリーズと比べると、とても非力なPCだった。
ずんべ は、この 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」で運用してみようと思う。

このエピソードの続き。

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

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

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

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

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

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

.xinitrcを変更。

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

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

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

if [ $TERM = 'linux' ]; then
  startx
fi

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

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

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

このエピソードの続き。

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

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

これまでは、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」を実行する。

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

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

X-Window
RDPクライアント

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

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

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

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

.xinitrc を作成する。

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

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

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

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

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

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

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

サブPCから異音がする。

ハードディスクの異音っぽくない。冷却ファンの異音っぽい。
筐体を開けてみると、やはり、冷却ファンから異音が出ている。

仕方ない、交換するか。

ジャンク・ボックスをひっくり返してみる。
規格がほぼ同じである冷却ファンはあったのだが…やはりというか、すべてコネクタの形状が違う。(T_T)

同一サイズ、同一コネクタの冷却ファンはあったのだが、消費電力が少し大きい。

元々の冷却ファンは0.68A、交換する冷却ファンは0.85A。
まぁ、よいか。

と、いう事で、取り付け。

電源オン。

無事、起動した。
異音もしない。
めでたし、めでたし。

数年前からお風呂で読書をするようになって、お風呂の中の電灯を交換して、明るくするようにしている。

最初に引っ越してきた時には、普通の白熱電球が付いていた。
100円ショップなんかでは、2個セット100円で購入できる。

[amazon isize="large"]B00AYP4CWS[/amazon]

お風呂で読書をするようになると、これでは暗いので、明るい電球型蛍光灯に交換した。
左の写真は、以前に100円ショップで100円で購入したもの。
そういえば、最近は、この商品は100円ショップで見かけなくなった気がする。

[amazon isize="large"]B002QEHM5E[/amazon]

その後、更に、もっと明るいLED電球に交換した。
明るさは590lm。

[amazon isize="large"]B0049RNTKI[/amazon]

今回、これを更に、もうひと回り明るいLED電球に交換した。
明るさは810lm。

[amazon isize="large"]B00OIRULY6[/amazon]

白熱電球 → 電球型蛍光灯 → LED電球(590lm)→ LED電球(810lm) と交換し、当然の事ながら、交換する度に明るくなっていく事が体感してわかる。
一度、読書用に明るい電球にすると、白熱電球には戻れない（戻りたくない）。

LED電球(590lm)→ LED電球(810lm) の交換は、明るくするためだけの交換なので、逆に消費電力はアップしているが、白熱電球→電球型蛍光灯→LED電球 の交換は、消費電力の節約も兼ねている。

ところで、LED電球は消費電力が少なく、寿命が長い事から、LED電球に交換すると家計にも優しくエコだと言われるが、本当なのだろうか。

ちょっと検証してみよう。
以下を仮定する。

・ずんべ がお風呂で読書するとして、1日の点灯時間は2時間を仮定する。

・電気代は22円/1KWを仮定する。

・各電球の価格、消費電力、交換頻度は、それぞれ以下を仮定する。

1年～5年で、必要な金額は以下のようになる。

水色の部分が各年で必要な金額であるが、これをグラフにすると以下の様になる。

白熱電球からの交換では、電球型蛍光灯でも、LED電球でも、1年ちょっとで元が取れるので、すぐにでも交換した方がいいようだ。
電球型蛍光灯とLED電球では、消費電力に大きな差がないので金額の推移に大差はないが、電球型蛍光灯は電球の交換が必要である分だけ、じわじわと逆転する。長い目で見れば、LED電球に交換した方がいいと言えるが、消費電力には大差がないので、使用中の電球型蛍光灯が切れるまで使ってから、交換の機会にLED電球にするという形がいいようだ。

-----

上の例は、毎日2時間点灯する場合であるが、点灯時間が短い、たとえば、トイレの電球などの場合はどうだろうか。

こちらも、ちょっと検証してみよう。
以下を仮定する。

・1日の点灯時間は10分強（0.2時間）を仮定する。

・その他の条件は同じ。

表にすると、以下の様になる。

グラフにすると、以下の様になる。

点灯時間が短い場合は、5年使っても元が取れない。
また、白熱電球は1年に1回、電球型蛍光灯は2年に1回交換する事を前提としているけれど、点灯時間が短い分、実際の交換時期はもっと長くなり、1.5倍～2倍程度は持つと仮定すると、LED電球に交換しても電気代の節約効果はほとんどない。
もちろん、10年、20年といった、長いスパンで考えれば意味があると言えるけれど、「10年、20年かけて数百円がトントンになる」程度では、正直言って、高価なLED電球を買おうと思うほどの魅力は感じない。

結局のところ、電気代を抑えられるかどうかは電灯の点灯時間にかかっているので、点灯時間が短い用途では、電球そのものの価格も考慮すると、LED電球にしたからといって、必ずしも経済的に有利になるとは限らない。
要するに、使用目的を考えて、その用途に適した電球を選ばなければならないという事だ。

検証した結果、かような当たり前の事がわかった。(^^;

-----

ちなみに、ずんべ の自宅には、電球を取り付けるソケットが4個ある。
そのうち2個にLED電球、2個に電球型蛍光灯が取り付けてある。
で、いろいろ電球を交換した結果、使える状態で取り外されている白熱電球が3個残っている。

蛍光灯型電球は2～3年で切れるだろうし、LED電球も故障しないという保証があるわけではないので、一応スペアとして保存はしておくけれど、果たして出番があるだろうか。
ぶっちゃけた話、これらは全部、資源の無駄遣いなのだが。

--

■2016/02/25 追記

最近ネットで、LED電球の寿命について話題になっている事がある。
LED寿命は4万時間など、長寿命なのだが、実際には、半年で切れてしまったり、1年で切れてしまうという事がけっこう発生しているらしい。10年使う前提で、価格の高いLED電球を購入しても、白熱電球と変わらない寿命で切れてしまうのである。
これは、LEDそのものが切れるのではなく、多くはLED電球で使われている他の部品が故障するために発生するとの事だ。
当然に、LED電球内のどの部品が故障しても、LED電球もろとも交換になるわけなので、速く故障する部品がある以上、「LED電球は寿命が長い」とは言えない事になる。
それでも、白熱電球や電球型蛍光灯よりは平均的には遥かに寿命が長いと言えるとは思うが、カタログ値通りではない事は確かなようだ。