オタク日記

(Mac と Linux, 2014Q2)

目次

2014-06-18 (Wed): 自宅サーバがクラッシュ
2014-06-07 (Sat): Raspberry Pi カメラ再訪
2014-05-31 (Sat): Python 環境の見直し
2014-05-21 (Wed): MacPro で久々の Kernel Panic
2014-05-19 (Mon): ストリーミング動画を OpenCV で受ける
2014-05-14 (Wed): Raspberry Pi と Webcam でストリーミング
2014-05-11 (Sun): Raspberry Pi を組込み用に
2014-05-03 (Sat): Cygwin on Windows 8.1
2014-04-23 (Sat): Windows 8.1 on VMware Fusion
2014-04-19 (Sat): Ubuntu Server を 14.04 LTS に
2014-04-13 (Sun): Wireshark 復活
2014-04-12 (Sat): HeartBleed Bug?

古い日記: 2014Q1   2013Q4   2013Q3   2013Q2   2013Q1  
2012 年   2011 年   2010 年   2009 年   2008 年   2007 年  
2006 年   2005 年   2004 年   2003 年   2002 年   2001 年


2014-06-18 (Wed): 自宅サーバがクラッシュ

即日改訂 :-)

Mac Pro のメモリがおかしくなって、その時は「もうだめか」と思ったものだが、 その後一月近く無事に動いてくれて、危機感が薄れてきていた。 (というか、中古の旧型 Mac Pro が意外に高価で、現行機に頼り続けるしかなかったとも言う :-)

しかし、そんな平和な日々も長くは続かず、今度は、 自宅サーバ (Lark、 Ubuntu-14-04 on ThinkPad X200) がクラッシュ…… 昨晩、寝ているところを家人の「ネットに繋らない」とのクレームで起こされた。 なので、最初は WiFi ルータを疑ったが、どうやらそれは、 Lark の DHCPd + Dynamic DNS が止まった事による artifact だったようだ。

CPU (本体左奥)のあたりが触れないくらい熱いので、 Power button の長押しで一旦電源を切り、 5 分程放置して少し温度が下がってから起動したら、あっさり動き始めた。 家中の PC/Mac がインターネットにアクセスできるようになったようだ。 (有難い!) しかし、オーバヒートが原因だったように見えるので、ThinkPad を立てた状態でしばらく様子を見る。

その間にちょろっと原因解明を…… syslog には何も残っていない。 というか警告もなしに、ゴミ(バイナリ?)データが書き込まれてお終いになっている。 これはおかしいな、と思い、CPU 温度や電池がどうなっているか調べようとしたら、 /proc の下にそれらしいファイルが何もない。 BAT0 も同様……。 どうやら、新しい Ubuntu では各所の温度や電池の状態を調べるには、 それぞれ固有のコマンドを用いる事になっているらしい。

何はともあれ温度の測定は必須だ……

fukuda@lark:~% sudo apt-get install lm-sensors
fukuda@lark:~% sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +49.0°C  (crit = +127.0°C)
temp2:        +46.0°C  (crit = +104.0°C)

thinkpad-isa-0000
Adapter: ISA adapter
fan1:        3773 RPM
temp1:        +49.0°C  
temp2:        +47.0°C  
temp3:            N/A  
temp4:        +47.0°C  
temp5:        +35.0°C  
temp6:            N/A  
temp7:        +34.0°C  
temp8:            N/A  
temp9:        +48.0°C  
temp10:       +50.0°C  
temp11:           N/A  
    .....
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +41.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +47.0°C  (high = +105.0°C, crit = +105.0°C)
沢山有り過ぎて何の温度なのかよく分らないが、少くともファンは回っていて、 CPU の温度が 41℃ と 47℃ らしいことは分る。 ちょっと話がうますぎるが、件のホットスポットを実際に手で触ってみたら、 ほんのり暖かい程度になっていた。

さて次はバッテリの状態……

% fukuda@lark:~% sudo apt-get install upower 
% fukuda@lark:~% upower -e                                              
/org/freedesktop/UPower/devices/battery_BAT0
/org/freedesktop/UPower/devices/line_power_AC
% fukuda@lark:~% upower -i /org/freedesktop/UPower/devices/battery_BAT0
 native-path:          BAT0
 vendor:               SANYO
model:                42T4534
serial:               482
power supply:         yes
updated:              Tue 17 Jun 2014 10:58:51 PM JST (14 seconds ago)
has history:          yes
has statistics:       yes
battery
  present:             yes
  rechargeable:        yes
  state:               charging
  energy:              2.18 Wh
  energy-empty:        0 Wh
  energy-full:         20.08 Wh
  energy-full-design:  28.8 Wh
  energy-rate:         0 W
  voltage:             15.093 V
  percentage:          10%
  capacity:            69.7222%
  technology:          lithium-ion    
lm-sensor は「大昔からディフォルトでこれだったよな」という記憶が有ったが、 こっち (upower) は「何これ」状態。何より、実際には存在しない path (/org/freedesktop/...) を参照する、というのが気色悪い。

それはともかく、これを見ると「充電量が 10% のまま永久に充電中」になっていて、もはやバッテリとして働いていないのは明白。 ここで AC アダプタを外したら即パワーオフだろう—— いつぞやは好奇心に抗しきれずにやってしまったが、今回は踏み止まる事ができた :-)

それでは、と何故か残してあった、互換バッテリと入れ換えてみるが、 こちらは 3 時間経っても残量が 0 のまま。 どうやら、ダメになっていた奴を捨てきれないで引出しにしまい忘れていただけ、 のようだ。

仕方ないので、互換バッテリを発注した。送料込で 5000円也。

過熱の原因がダメなバッテリである可能性は十分あるので、 発注したバッテリが届くまで、何も挿さないでおこうかとも思ったが、 万が一の怪我の功名を期待して、元の方 (4 cell) に差し替えて、新バッテリの到着を待つ事にした。

2014-06-18 (Wed): 出かける段になってふと見たら、バッテリのインジケータが、 オレンジの点滅から、グリーンに変っている……。はて?と、また Lark にログインして upower コマンドで見てみると、
fukuda@lark:~% upower -i /org/freedesktop/UPower/devices/battery_BAT0 
    .....
  battery
    .....
    state:               fully-charged
    energy:              18.66 Wh
    energy-empty:        0 Wh
    energy-full:         20.08 Wh
    energy-full-design:  28.8 Wh
    energy-rate:         0.033 W
    voltage:             16.689 V
    percentage:          92%
    capacity:            69.7222%
    technology:          lithium-ion 
なんだとか。10% からまったく変化しなかった残量が 92% になり、"charging" 一辺倒だった status が "fully-charged" になっている。 要は、バッテリが復活した。完全復活とはいかないが、AC 電源の瞬断に対する保護くらいにはなるだろう。 とすると、さっき注文したばかりのバッテリは無駄になってしまう。 とりあえずキャンセルした。

目出たいのだが、しかし一方でこれは、ThinkPad の電源制御回路自体がおかしくなっていたかも知れないという事でもあるので、 ますます根本原因が分らなくなってしまった。正に痛し痒し。


2014-06-07 (Sat): Paspberry Pi カメラ再訪

先週までで、一応カメラからのストリームを TCP/IP 越しに転送して表示できる事は確認できたのだが、 マルチストリームでそれができるかを確認した。

新 Raspberry Pi の追加とカメラの装着

本体は既に買ってあったが、SD card は新たに買う必要が有った。 前回 class 6 のカードに Raspbian OS を書き込むのに、えらく時間がかかったので、 今回は class 10 のを奮発した。 で、前回と同様にして Mac-mini で書こうとしたのだが、 やっぱり凄く遅い。というか、前回の 1.5 MB/s よりさらに遅くなって、 300 kB/s あたりとなっている。単純外挿すれば、2時間半以上かかる事になる。 さすがにこれは中断した。

次に、 Mavericks の Disk Utilities を使って焼いてみた。 すると、あっと言う間に転送が終って 「なあんだ、最初からこうすれば良かったんだ」 と思ったが、しかし、こうして焼いたカードでは、 ブートが途中で止まってしまう。

やはり dd コマンドを使うしかないのか。しかし、bs を細かく弄るくらいしか思いつかないなぁ、なんて悩んでいると、 ふと最初に感じた疑問を思い出した。どこかで見つけたインストラクションに of=/dev/rdisk2 としろと有ったが、# diskutil list では当然 /dev/disk2 なので、rdisk2 は何かの間違いだろうと決めて、disk2 としたのだった。 まさか、とは思ったが、rdisk2 で試してみた。すなわち、

fukuda@mac-mini-3:~% diskutil unmountDisk /dev/disk2
Unmount of all volumes on disk2 was successful

fukuda@mac-mini-3:~% sudo dd bs=1M  if=2014-01-07-wheezy-raspbian.img of=/dev/rdisk2              
2825+0 records in
2825+0 records out
2962227200 bytes (3.0 GB) copied, 242.136 s, 12.2 MB/s 
てな具合に 4 分で終ってしまった。何と、8 - 40 倍のスピード改善!

焼けた SD カードと友人に買ってきてもらった USB キーボードを古い方の Raspi に挿して power-on したら無事立ち上がった。Raspi01 と同様に初期設定を行う。 違うのは、hostname を Raspi02 とした事くらい。

新しい SD カードを新しい方の Raspi に挿す (以降、Raspi02 と呼ぶ)。

新しく購入した Raspberry Pi Camera Module (ver.1.3) をそれぞれ、Raspi に装着。

Raspi 設定から camera の起動

Raspi01: Raspi01 を turn on して Quadra (Mac Pro) から ssh でログインして packages を更新。mjpg_streamer も更新 (git pull) して、再コンパイル:

pi@raspi01:~% sudo apt-get update
pi@raspi01:~% sudo apt-get upgrade
pi@raspi01:~/mjpg-streamer% git pull
pi@raspi01:~/mjpg-streamer/mjpg-streamer-experimental% make USE_LIBV4L2=true clean all    
pi@raspi01:~/mjpg-streamer/mjpg-streamer-experimental% sudo make DESTDIR=/usr install
pi@raspi01:~% mjpg_streamer \
         -i "/usr/lib/input_raspicam.so -fps 30" \
         -o "/usr/lib/output_http.so -w /usr/www" &! 

Raspi02: こちらも Raspi02 を power on した後 Quadra から ssh でログインして作業。 raspi01 でやった作業を最初から繰返す(つまり、libv4l-devel, cmake 他のインストールから始める。)

pi@raspi02:~% sudo apt-get update
pi@raspi02:~% sudo apt-get upgrade
pi@raspi02:~% sudo apt-get install libv4l-dev libjpeg8-dev subversion imagemagick uvcdynctrl 
pi@raspi02:~% sudo apt-get install cmake
pi@raspi02:~% git clone https://github.com/jacksonliam/mjpg-streamer.git
pi@raspi02:~% cd mjpg-streamer/mjpg-streamer-experimental/
pi@raspi02:~/mjpg-streamer/mjpg-streamer-experimental% make USE_LIBV4L2=true clean all    
pi@raspi02:~/mjpg-streamer/mjpg-streamer-experimental% sudo make DESTDIR=/usr install
pi@raspi02:~% mjpg_streamer \
        -i "/usr/lib/input_raspicam.so -fps 30 -br 55 -co 20" \
        -o "/usr/lib/output_http.so -w /usr/www" &! 
Snapshot of binocular camera
Multi (両眼視) カメラのプロトタイプ

マルチストリームの受信

まずウェブブラウザで試してみたが……

先々もっとストリーム数を増やすかも知れないので、 何だか前途に暗雲が漂う結果となったが、 OpenCV-Python のスクリプトではなんとかうまく行った。 但し、表示ウィンドウの名前と URL をそれぞれ raspi01 と raspi02 にして get_stream01.py と get_stream02.py を作り、別々に起動する必要が有った。

fukuda@quadra:~% python2.7 script/get_stream01.py  &!      
fukuda@quadra:~% python2.7 script/get_stream02.py  &!    

この時の CPU の占有率は、

いずれも、1 core あたりで、動きの多い画面にしても然程変化しない。

ちなみに、Raspi の方は

何故か前回の測定(71 %) より減っている。 これくらいなら余裕で対応可と言えそう。

Snapshot of dual video streaming
マルチカメラのビデオストリームを表示
(非常に大雑把ながら両眼視できている?)
両眼視カメラの取り付けがいい加減すぎるのもさる事ながら、 カメラモジュールの感度のバラツキも相当なものだった。 (これで既に、"-br 55 -co 20" (brightness 50 → 55, contrast 0 → +20%) の補正を入れている。) その結果、かなりチルトや明るさの差異が残っているが、これでもなんとか立体視はできる。 (私はできました——長く見ていると頭が痛くなりますが。) しかし、融通無碍のヒトの目(しかも私はこれが得意なヒト)だからできるので、 これをプログラムでやるのは大変かも知れない。

2014-05-31 (Sat): Python 環境の見直し

py3k だけで生きて行くのは難しい

何故か「ムキ(向き?)」になって Python 3K への移行を目指してきたが、 Django, Mezzanine がそれに対応するようになるに及んで、かなり目標に近付いたと思っている。 (よく考えてみれば、Gnuplot.py, gnuradio, git, web2py 等々 py27 でないとダメなものはまだ結構あるのだが。)

そんなところに OpenCV を使う事になったので、当然のように、 py33 で何とかならないかとジタバタしてみた。 少し前にちょこっと触ったみた時に OpenCV3 ならば py3k で動きそう、という感触を得ていたので、 またぞろ「向き」になって、3.0.0b の make を試みたのだが、 どうしてもインタプリタとして、Python-2.7.x を選んでしまう。 もうちょっと押せそうな気もしたが、 それまでに「そもそもどれが 3.0.0b のソースなのか分らなかった」事とか、 Stack Overflow で見た担当者の傲慢さ等にも嫌気が差してきていたので、 3.0.0b は諦めて、2.9.x で行く決心がついた。

つまり py33 を通す事はあきらめて、 py27 の上で、2.9.x を使う事にした。

PyPI と MacPorts の干渉

Mezzanine は MacPorts に無いので、 不本意ながら PyPI 版を使っている。 つまり、Python のパッケージコントロールは MacPorts と PyPI (pip) とが混在していた。 インストール当初は何の問題も無く両立しているように見えたが、 pip freeze で、MacPorts のパッケージが見える (list される) ので、何だか気味が悪いなとは思っていた。

で、今回 py33-matplotlib を MacPorts でインストールしようとしたら、 その悪い予感が当ってしまった。 sixpyzt が依存関係を満足しないと言って、matplotlib のインストールが途中で止まる。 では pip で再インストールを、となったが、そもそも pip が起動できない。 MacPorts で pip を再インストールしてもダメ…… 大パニック。

一層、全部強制的に消して一から、とキレかけたが……何とか気を取り直して pip の起動時のエラーメッセージを見て、ファイル

/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pip-1.5.3.dist-info
を削除すれば良いのではないかと見当をつけ、それを実行したら問題は解決した。

ここまで来て、MacPorts で入れた pip を、その後何度も pip 自身で upgrade した事を思い出した。これが悪かったに違いない。 MacPorts と pip を安定に共存させるには MacPorts で入れたパッケージは pip でアップグレードできないようにする仕組が必要のようだ。 ともあれ、これも、py33 への拘りをあきらめる遠因となった。

OpenCV-Python と matplotlib の環境構築

というような訣で、OpenCV-Python とその関連のモジュール ( numpy, scipy, matplotlib, iPython) を、py27 の上にインストールする事にした。 これで良いなら全てが MacPorts で管理できるので、それ程難しい話ではない。

しかし、些細ながら、依存性がうまく解決されないところもあるので、 インストールの手順の案を示しておく。

# baseline
fukuda@quadra:~% sudo port install python2.7 py27-readline py27-numpy    
# OpenCV-Python (takes a long time.)
fukuda@quadra:~% sudo port install opencv
# matplotlib
fukuda@quadra:~% sudo port install py27-matplotlib
fukuda@quadra:~% sudo port install py27-ipython
# py27-scientific has been installed with py27-ipython
fukuda@quadra:~% sudo port install py27-pyqt4 py27-pygments py27-zmq 
# these modules are required for ipython on qtconsole
fukuda@quadra:~% ipython qtconsole --pylab=inline 
ここまでで、qtconsole の上の iPython の shell が立ち上がり、command を受けつけるとともに、グラフ出力がシェル内に表示される。
Irregular Memory Configuration
qtconsole で Interactive Shell 内にグラフが表示される

iPython? matplotlib?

この両方とも上で事も無げにインストールしているが、 実はこれまで matplotlib を意識的に避けてきたのだった。 Gnuplot + Gnuplot.py に比べてこちらの方が、python + numpy の環境への親和性が高そうだという事は解っていて、移行してみようか、 と思い立った事も何度かあるのだが、その度に撃退されてしまった。 iPython を使うか使わないか、pylab って何やってんだろ、等の「もやもや」と相俟って、 チュートリアルをやっている内に頭の中が煮詰ってきて、「もうやってられねぇ」 となるのでありました。

今回も半ば切れかけていたのだが、こういう時はやはり「急がば回れ」のようで、 matplotlib のホームページに秀逸な解説 (FAQ) が有った。それを自分なりに纏めてみると……

  1. モジュールを実直に load して、ディフォルト無しで、グラフを作ろうとすると
    >>> import matplotlib.pyplot as plt
    >>> import numpy as np
    >>> x = np.arange(0, 10, 0.2)
    >>> y = np.sin(x)
    >>> fig = plt.figure()
    >>> ax = fig.add_subplot(111)
    >>> ax.plot(x, y)
    >>> plt.show()    
    結構面倒だし、一度 plt.show() した後は fig object がおかしくなるようで、fig = plt.figure() の行から入力しなおさないと、 plt.show() が効かない。
  2. さすがにこれでは面倒すぎるので、pyplot の state-machine を使うと
    >>> import matplotlib.pyplot as plt
    >>> import numpy as np
    >>> x = np.arange(0, 10, 0.2)
    >>> y = np.sin(x)
    >>> plt.plot(x, y)
    >>> plt.show()    
    てな具合に簡素化できる。
  3. さらに pylab を使うと、
    >>> from pylab import * 
    >>> x = arange(0, 10, 0.2)
    >>> y = sin(x)
    >>> plot(x, y)
    >>> show()    
    とできる。つまり、pylab は matplotlib.pyplot と numpy を含んでいる、という事。
  4. iPython の起動時
    fukuda@quadra:~% ipython --pylab 
    とやれば、この import 文まで省略できる上に、show() も省略できて
    In [1]: x = arange(0, 10, 0.2)
    
    In [2]: y = sin(x)
    
    In [3]: plot(x, y)
    Out[3]: [<matplotlib.lines.Line2D at 0x1066b41d0>]    
    のような感じになる。 (この場合は、inline ではなく、別の窓が開いてグラフが表示される。) こうなって何が嬉しいか、というと、どうやら MATLAB とそっくりになる事らしい。
どうにか相互関係が理解でき、「イライラの素」は取り除けたように思う。 しかし、自分は MATLAB に精通している訣でもないし、iPython の Interactive Shell をどうしても使いたい、と思う方でもない。(上の ipython qtconsole --pylab=inline にはちょっとそそられたが、しかし、全体を png でしかセーブできないのでは、 あまり嬉しくない。) 何より、例えば三次元プロットを画きたいと思った時に、 やり方の見当もつかずに、いきなり立ち往生、というのでは困る。 なので、普段は 2. で作業し、本格的な plot に際しては 1. に戻るという方針で行く事にする。 結局は Python のディフォルトの Interactive Shell に戻るという「いつものオチ」であるが、それでも Gnuplot.py を使うよりも格段にスマートになったような気がする。

2014-05-21 (Wed): MacPro で久々の Kernel Panic

今朝は Quadra (MacPro 1,1) の「轟音」で目が醒めた。 これまでも偶にあったように、 ファンが全力で回転しているだけだろうと思い、Power SW でスリープさせようとするが、ちっとも応答しない。 寝惚け眼でディスプレイを点けてみると、何と「Power SW 長押しで、Power Off/On しろ」とある。 いっぺんに目が醒めて、言われる通りに再度立ち上げてみると、 あな嬉しや、ちゃんと立ち上がった…… しかし、何と memory が 4 GB しか認識されていない。 何とかせねばと焦るが、MacPro の筐体を開けるには、Dyson が必須なので、皆が起き出すまで、しばらく MacBook Air で仕事をした。

MacPro に戻って System Information をよく観ると、 何と DIMM Riser Card B のメモリが認識されていない。 うむ Card が壊れたか、と思うが、一応お約束の手順から始める。

  1. Riser A/B を Mother Board (MB) から外し、メモリを挿し直す。 その上で、Riser Card も挿し直す ⇒ 無事ブートし、8 GB 認識される。 「なんだ、やっぱりこれか……」と安心しかけていたら、いきなり「バシッ」 という音がして reboot が始まる。無事立ち上がったが、4 GB しか認識されなくなった。もう一回、shtudown/start をやってみるが、 認識されるのはやはり 4 GB だけだった。
  2. Riser B を MB から外す ⇒ 無事ブートし 4 GB 認識される。 Apple の言い分からすると、本来これは有り得ない。Riser A/B の対応する slot にメモリが挿さってないといけないから。
  3. 上で外した Riser B を、Riser A と取り替える(つまり、 元の Riser B を ソケット A に挿す)⇒ 無事ブートし 4 GB 認識。 どうやら、問題は MB 側 (のソケット B の辺り) に有りそうだ。
  4. Riser B のメモリを両方とも Riser A に移し、 それを MB のソケット A に挿す。⇒ 無事ブートし 8 GB 認識。 良かった、App を沢山起動しっぱなしのズボラな生活を続けられる、 元い、VMware Fusion が使い続けられる!

最後のは「さらに有り得ない」構成の筈だが、何故か上手く動いている。

Irregular Memory Configuration
Riser A Card だけでちゃんと動いている様子
2014-05-23 (Fri): その後二日程様子を見たが、 特に問題なく動いているようだ。 アプリの起動が特に遅くなったという事もないし、ファンの暴走も起きてない。 一回だけ、4 GB 近いメモリが解放されない、という事があり、 ちょっと嫌な感じがしたが、VMware Fusion の上の Windows8.1 を (suspend でなく) きちんと止めてから quit する事で正常に戻った。

結局、Apple さんのメモリ構成に対する「要求」は過剰だったとも言えるが、 メモリモジュールが結構高温になる事もあり、モジュール 4 本がすべて Riser A に載っている状態というのもあまり好ましくない。 しかし本格的に修理するとなれば即 MB の交換となる訣で、 こっちも何だかアホらしい気がする。とりあえずは現状のままで様子を見よう。

この愛機 MacPro は買って 8 年で、すっかり枯れて安定していた—— 今回の Kernel Panic の診断メッセージによると、前の Panic は 410 日も前だとか。 なので、次にハードウェアの故障が出たら「天寿」だと諦めようと思っていたが、 今回の故障は結果的には何とか救えてしまった…… ともあれ、長期的にどうするかを考えないといけない。が、あの火鉢(ゴミ箱) MacPro には食指が動かないしなぁ。旧型 MacPro の中古を手に入れるか、 またぞろ Linux に戻るか……悩ましい。


2014-05-19 (Mon): ストリーミング動画を OpenCV で受ける

RaspPi 純正のカメラを繋ぐ

Raspbian/RaspPi で動く最新の mjpg-streamer は、どうやら Raspberry Pi Camera Module (? 例によって、どれが正式な型名なのかよく分らない)に特化しているようだ。 このカメラだと、Sharpness, Contrast はもとより、画像の Rotation や Flip まで制御できるらしい…… という事で、どうしても試してみたくなり、 純正カメラ (Rev 1.3) を知人からお借りして継いでみた。

しかしすぐにはうまく行かなかった。mjpg-streamer を立ち上げると

mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
error create camera 
と言われて、それから先へ一歩も進めない。 当然パラメータやオプションを弄ってみたが、どれも効き目が無かった。

大いに悩んだが、結論から言うと、 「raspi-config で、camera を enable していなかった」というお粗末。 しかし、弁解をさせて頂くなら、これを enable してなくても、 普通のウェブカメラでは前述のように問題なく動いたんだよねぇ。

ともあれ、これをイネーブルして動く事を確認したので、 motion daemon を止めてしまい、改めて mjpg_streamer を USE_LIBV4L2=true を外して再コンパイルするところから……

pi@raspi01 ~ $ sudo apt-get remove motion
pi@raspi01 ~ $ sudo update-rc.d -f motion remove
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ make clean all
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ sudo make DESTDIR=/usr install
install --mode=755 mjpg_streamer /usr/bin
install --mode=644 input_uvc.so output_file.so output_http.so input_raspicam.so /usr/lib/
install --mode=755 -d /usr/www
install --mode=644 -D www/* /usr/www
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ cd
pi@raspi01 ~ $ mjpg_streamer -i "/usr/lib/input_raspicam.so --fp 30" 
  -o "/usr/lib/output_http.so -w /usr/www"
MJPG Streamer Version: svn rev: Unversioned directory
 DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c,  input_init(), 118): argv[0]=raspicam input plugin
....
 i: fps.............: 30
 i: resolution........: 640 x 480
 i: camera parameters..............:

Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 400, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
 o: www-folder-path...: /usr/www/
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled
 i: Starting Camera
 DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c, worker_thread(), 553): Host init, starting mmal stuff
 ....
 DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c, worker_thread(), 880): Starting video output
とメッセージを一杯出しながら起動に成功し、WebCam の時と同じような方法で、 リモートの Safari から動画を観る事ができた。

pi@raspi01 ~ $ top  
  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
  ....
  3533 pi        20   0  108m 2288  956 S  71.3  0.6   5:45.70 mjpg_streamer    
  ....

OpenCV: インストールと動作確認

さて本題の OpenCV。 これを大昔の記憶を基に Quadra (MacPro 1,1) にインストールしようとしたら結構はまってしまった……大体 Python.org の PyPI で opencv で検索したら、opencv-cython 他、ずらずらと出てくるのが良くないぞ :-p。 (あと、OpenCV3 に拘ったのも時間の浪費だった。)

要は、今時の OpenCV には Python binding が「同梱」されているので、 MacPorts で opencv をインストールすれば、関連の module (cv, cv2 等) も一緒にインストールされるのだった。

fukuda@quadra:~% port installed opencv
The following ports are currently installed:
  opencv @2.4.8_2
  opencv @2.4.9_0+python27 (active)
fukuda@quadra:~% python2.7
Python 2.7.6 (default, Nov 12 2013, 13:12:10) 
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv, cv2
>>> cv2.__version__
'2.4.9'    
ちなみに、-2.4.9 は、4/25 に出たばかりの最新版(偉いぞ、MacPorts!)

お客様は OpenCV で、と仰っているので Python binding に拘るのは、半ば私の趣味であるが、しかし、実際これは霊験あらたかで

fukuda@quadra:~% python2.7
Python 2.7.6 (default, Nov 12 2013, 13:12:10) 
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2, cv
>>> cv2.namedWindow("Original")
>>> cap0 = cv2.VideoCapture(0)
>>> key = -1
>>> while (key < 0):
...   success0, img0 = cap0.read()
...   cv2.imshow("Original", img0)
...   key = cv2.waitKey(27)
...    
等と、インタラクティブに動作を確認する事ができる。 cv2.VideoCapture(0) とするだけで、ディフォルトのカメラとのリンク(?) を確立してくれる訣で(どうやっているのか分らないけど)感動物である。 (但し、インタラクティブの場合は cv2.waitKey() は動かないようだ。) その結果として
Webcam Streaming with mjpg-streamer
OpenCV-Python が WebCam の動画を表示中
のような画像が得られる。

OpenCV: ストリーム映像を受ける

さて、この cv2.VideoCapture() をうまく設定してやれば、 (つまり '0' のかわりに URL を書いて)remote のネットワーク・カメラからの動画を OpenCV のフレームとして取り込めるのではないか、というのが「お題」であったのだが、 結局今のところこれはうまく行ってない。 しかし、Motion-JPEG に話を限るなら、単に JPEG 画像を次々に送ってくるだけなので、VideoCapture の代りに、urllib を使ってダラダラとデータを取り込み、その後で frame を切り出し、decode してもうまく行く筈……という事で、 StackOverflow から拾ってきた snipet を基に、次のようなコマンドを書いてみた。

# get_frame.py
import cv2
import urllib 
import numpy as np

stream = urllib.urlopen('http://raspi01.otacky.jp:8080/?action=stream')
bytes = ''
while True:
    bytes += stream.read(1024)
    a = bytes.find('\xff\xd8')
    b = bytes.find('\xff\xd9')
    if a != -1 and b != -1:
        jpg = bytes[a:b+2]
        bytes = bytes[b+2:]
        i = cv2.imdecode(np.fromstring(jpg, dtype=np.uint8),
                         cv2.CV_LOAD_IMAGE_COLOR)
        cv2.imshow('i',i)
        if cv2.waitKey(1) > 0:
            exit(0)   
ちなみに、'\xff\xd8' と '\xff\xd9' は、JPEG frame の delimiter で、np.fromstring() は、string から 1 次元の行列を作る numpy の関数。

これを用いて streaming を試す。

# Raspi に log in して、mjpg_streamer を起動
fukuda@quadra:~% ssh pi@raspi01
pi@raspi01 ~ $ mjpg_streamer -i "/usr/lib/input_raspicam.so --fp 30" \
    -o "/usr/lib/output_http.so -w /usr/www" &!
[1] 2151
    ....
 i: fps.............: 30
 i: resolution........: 640 x 480
 i: camera parameters..............:
    ....
 o: www-folder-path...: /usr/www/
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled
 i: Starting Camera
# '&!' をつけて起動したので、prompt が帰ってくる。Exit して Quadra に戻る
pi@raspi01 ~ $ exit
logout
Connection to raspi01 closed.
# Quadra で先の streamer script を走らせる
fukuda@quadra:~% python2.7 script/get_stream.py
Corrupt JPEG data: 32764 extraneous bytes before marker 0xd9 

ここで、self-power の USB-Hub ごしに Logitech のカメラをつないであれば、 上記の mjpg_streamer を立ち上げるところで

pi@raspi01 ~ $ sudo mjpg_streamer -i "/usr/lib/input_uvc.so -f 30" \
    -o "/usr/lib/output_http.so -w /usr/www" &!   

とするだけで、Logitech カメラが動作し始め、受信 (Quadra) 側では、まったく同様にして OpenCV の Window に動画を表示できる。

Streaming over the network with openCV
Raspberry Pi Camera
Streaming over the network with Logitech Webcam
Logitech WebCam

この時のカメラの配置は以下の通り。(Display の右下の窓は streaming の表示画面。)

Logitech WebCam and Raspi Camera
Logitech WebCam と Raspi Camera (と Streaming 窓)

まとめ


2014-05-14 (Wed): Raspberry Pi と Webcam でストリーミング

Raspberry Pi (以下 RasPi) が動くようになったが、実はそれが最終目的ではなくて、それを使って IP camera (もどき)を作るためだった。 (さらに、それを使ってリモートの OpenCV で画像処理を、というホントの最終目標が有ったりする :-)

古いのはやっぱりうまく行かない

ともあれ、Feasibility Study なので、お金も時間も掛けられない。 で、とにかくばたばた動いてみたが、結局は「急がば回れ」だったかな? つまり、Web で「うまくいかないかも」となっている事も、 「ひょっとしたら」というスケベ心を出してやってみたのだが、「やっぱりな」 となったという次第。

mjpg-streamer は良さげ

次に試したのが、mjpg-streamer。Web での評判は上々だが、 自分でコンパイルする必要がある、というのでちょっと引いていた。 実際、どのソースが最新もしくは最適か、という事からしてはっきりしない。 その上、SVN server の URL が色々ある…… という事で、最初から暗雲が立ち籠める。 が、たまたまソースが GitHub にある事を見付けて、 とりあえずそれで始める事にした。 (cubic9.com さんが一番参考になったように思います。)
pi@raspi01 ~ $ sudo apt-get update
pi@raspi01 ~ $ sudo apt-get upgrade
pi@raspi01 ~ $ sudo apt-get install libv4l-dev libjpeg8-dev subversion imagemagick uvcdynctrl -y 
pi@raspi01 ~ $ sudo apt-get install cmake
pi@raspi01 ~ $ git clone https://github.com/jacksonliam/mjpg-streamer.git
pi@raspi01 ~ $ cd mjpg-streamer/mjpg-streamer-experimental/
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ make USE_LIBV4L2=true all
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ ./mjpg_streamer -i "./input_uvc.so -d /dev/video0" -o "./output_http.so"
MJPG Streamer Version: svn rev: Unversioned directory
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: -1
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
UVCIOC_CTRL_ADD - Error at Pan (relative): Inappropriate ioctl for device (25)
.....
UVCIOC_CTRL_MAP - Error at Raw bits per pixel: Inappropriate ioctl for device (25)
 o: www-folder-path...: disabled
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled 
こうしておいて、他の Mac のブラウザで http://rapsi01.otacky.jp:8080/?action=stream とやると、640x480, 20 fps (?) の動画が見える。 分解能、色調、レイテンシは、motion を遥かに凌いでおり、 web amera を Mac に直結した場合と殆ど遜色ないレベルになった。

やれやれ、 これでシステム構成のベースラインというかバックアッププランはできた、 と喜んでいたら、じわじわと動きがぎこちなくなり、レイテンシも増えてきた。 (Avserver でも同様の症状につきあたり、かつその後どうにもならなかった、 という経験が有るので、少々ショック。)ただ、そのうち Firefox そのものが応答しなくなるという事があって、「もしや」と確認したら、 案の定 Firefox が Mac のメモリが食い潰している。

それなら、という事で、Chrome にしてみた。が、

501: Not Implemented!
no www-folder configured 
とだけ表示されて、動画の表示に移らない……(motion では、Chrome でも表示はされていた。)

しかし、Safari ではちゃんと表示された。 その後 3時間程、Mac の Activity Monitor を監視しているが、 Firefox で見られたメモリリークは起きていないようだ。

Webcam Streaming with mjpg-streamer
mjpg-streamer で 640x480 の画面を表示中
この時の Raspi の CPU 利用率は、16-17% だった。

mjpg-streamer を極める

mjpg-streamer はどうやら使えそうだ、という事で少々頑張ってみた。

まずは、ちゃんとコンパイル・インストール

pi@raspi01 ~ $ sudo apt-get install libjpeg62-dev 
pi@raspi01 ~ $ cd mjpg-streamer/mjpg-streamer-experimental/
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ make USE_LIBV4L2=true clean all
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ sudo make DESTDIR=/usr install
pi@raspi01 ~/mjpg-streamer/mjpg-streamer-experimental $ cd    
pi@raspi01 ~ $ mjpg_streamer -i "/usr/lib/input_uvc.so" -o "/usr/lib/output_http.so -w /usr/www"
MJPG Streamer Version: svn rev: Unversioned directory
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: -1
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
UVCIOC_CTRL_ADD - Error at Pan (relative): Inappropriate ioctl for device (25)
    ..... snip .....
UVCIOC_CTRL_MAP - Error at Disable video processing: Inappropriate ioctl for device (25)
UVCIOC_CTRL_MAP - Error at Raw bits per pixel: Inappropriate ioctl for device (25)
 o: www-folder-path...: /usr/www/
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled
こうする事で、

2014-05-11 (Sun): Raspberry Pi

昔から SBC (Single Board Computer) は大好きで、 名刺大(名前を忘れてしまった)のを弄り回したのを皮切りに、 他にも何種類か弄らせてもらった。 その内、「インターフェース」誌についてくる NuBus の SBC のカタログを眺めるのが趣味になった……つまり実際に触らなくなって久しい。

そんなところに、 これを組込みで使ってみようという「正当」な目的ができたので、 評判の高い Raspberry Pi を触ってみる事にした。 例によってちゃんと調べないで、先輩達に聞いてなんとかしようと……

てなわけで、SD カード以外はありあわせのもので何とかなった—— 私の希望的観測(「なんとかなるやろ」)は外れる事が多いのだが。 (でも、AC アダプタとケーブルはどのみち必要なので買わないといけない。)

起動ディスクを作る

要は、OS を選んで、そのイメージを SD card に書き込むだけの事だが、 実はこれに一番まごついた。

OS は、使用目的から Raspbian と決まっていて、迷う事はなかった。 が、 Downloads サイトから取ってくるのに 1時間近くもかかってしまった。 以下は、SD card slot が備わている Mac-min (Mavericks) で実行した。

fukuda@mac-mini-3:~% scp quadra:2014-01-07-wheezy-raspbian.zip .
fukuda@mac-mini-3:~% unzip 2014-01-07-wheezy-raspbian.zip 
Archive:  2014-01-07-wheezy-raspbian.zip
  inflating: 2014-01-07-wheezy-raspbian.img
    
fukuda@mac-mini-3:~% diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Server HD               499.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD2           499.8 GB   disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *8.0 GB     disk2
   1:                 DOS_FAT_32 NO NAME                 8.0 GB     disk2s1
fukuda@mac-mini-3:~% diskutil unmountDisk /dev/disk2
Unmount of all volumes on disk2 was successful

fukuda@mac-mini-3:~% sudo dd bs=4M  if=2014-01-07-wheezy-raspbian.img of=/dev/disk2              
  ....
165+0 records in
165+0 records out
692060160 bytes (692 MB) copied, 474.124 s, 1.5 MB/s
278+0 records in
278+0 records out
1166016512 bytes (1.2 GB) copied, 797.339 s, 1.5 MB/s
706+1 records in
706+1 records out
2962227200 bytes (3.0 GB) copied, 2014.14 s, 1.5 MB/s
fukuda@mac-mini-3:~% diskutil unmountDisk /dev/disk2
Unmount of all volumes on disk2 was successful 
ここで、SD Card を引き抜いた。途中二回の経過報告は、別の shell から、下のように INFO singal を送ってやった事で表示される。 (転送に 30 分もかかるので、これは精神衛生上、必須のツール :-)
fukuda@mac-mini-3:~% ps ax
  PID   TT  STAT      TIME COMMAND
    1   ??  Ss     0:00.57 /sbin/launchd
   11   ??  Ss     0:00.35 /usr/libexec/UserEventAgent (System)
   12   ??  Ss     0:00.63 /usr/libexec/kextd
   13   ??  Ss     0:00.46 /usr/libexec/taskgated -s
   ....
  254 s000  S+     0:00.02 sudo dd bs=4M if=2014-01-07-wheezy-raspbian.img of=/d
  255 s000  U+     0:01.65 dd bs=4M if=2014-01-07-wheezy-raspbian.img of=/dev/di
   ....
fukuda@mac-mini-3:~% sudo kill -INFO 255
それにしても、素直にやっても 1 時間 と 30 分。 実は、ダウンロードがあまりに遅いので、途中 BitTorrent に変えてみたり、 SD への書き込みについては、そんなものが 30 分もかかる筈がない、と途中で止めたりして、 実際にはその倍以上かかっている。 (辛抱しきれなくて、SD への書き込みを途中でやめてしまったが、何とそれでも boot も、初期設定もできてしまう……しかし login prompt は出ないので結局やり直したりした。)

Raspberry のブートと所期設定

最初に上げた要素をみな接続して、最後に USB ケーブルを接続すると、 Linux の通常の dmesg が表示された後、所期設定画面になる。

そもそもの目的が「組み込み用途」なので、 ssh による remote login だけができれば良い。 そのための最小限の設定のみ行う。 画面のダンプのやり方がよく分らないので、おおまかな感じだけ……

  1. 1 Expand Filesystem: enable しておく
  2. 2 Change User Password: この設定は必須
  3. 4 Internationalization Options: locale: en_US.UTF-8, Time Zone: Asia/Tokyo, keyboard: これはどう設定しても何故か日本語配列になってしまう。
  4. 8 Advanced Options: enable して passwd を設定する
    1. A2 Hostname: 短かい名前をつけておく(本機は raspi01 とした。)
    2. A4 SSH: enable しておく(必須)
こうしておいて、reboot。

X11 Desktop

このように、SSH でログインする事だけを考える設定でも、startx で X11 を立ち上げる事ができる。お決まりの Desktop dump。 必要最小限のアプリのアイコンに加えて、Python3 の IDLE まで有って、とっても好感が持てる :-) 使う事はないだろうが、比較のために emacs をインストールして立ち上げてみた。 起動も、コマンドへのレスポンスも、Fusion 上の emacs より格段に速い。
Desktop of Raspbian
startx してみた。(scrot というツールでダンプできる。)

SSH

Ethernet だけ繋がった状態にして、reboot、Quadra から login してみた。
Desktop of Raspbian
Quadra から SSH で login した様子
とりあえず、組込み用に設定できた。

2014-05-03 (Sat): Cygwin on Windows 8.1

Win8 でちっとも動かなかった Cygwin が 8.1 で動き出した時はとっても嬉しくて、 もう暫くは弄るのはやめよう、と決心したのだが……

Win8.1 もやっぱり Cygwin に優しくない

しかし、shell prompt が
Taka Fukuda@S-1-5-21-3717807398-.....:~%
となるのはさすがに悲しくて、これを何とか元のように
fukuda@thrush:~% 
てな感じにできないかなぁ、と手を出したのが間違いの始まり。 とは言え、hostname ('@' の右側) をシンプルにするのは然程難しくなかった。 [Control Panel > System and Settings > System] で開かれるペインで、Change settings をクリックすれば変更する事が可能。

しかし、username の方はそう簡単ではなかった。 ただ、最初から

とやっておけば、然程「大変」という訣でもない筈。

「筈」というのは、実際には、Maicrosoft Account で Cygwin をインストールしてしまっていて、おまけに、 そのアカウントを消してしまったために、Cygwin のディレクトリを「合法的」には消去できなくなって……という大騒ぎをやったから。 「うう、また VM から作り直しかぁ」と暗い気持になったが、しかし(消す事はできなくても) rename はできたので、setup-x86_64.exe を再ダウンロード、 それを用いて最小限のインストールをしてみた (勿論 fukuda で login して)。首尾は上々で、zsh の prompt が所期の表示となった。

Cygwin Terminal on Windows 8.1
古い Cygwin の root directory を rename して、新規にインストール

少々グリッチ有り

また 0xC0000142 error が出たりしたら嫌なので、 DLL を弄りそうなモノは一切避けている。 つまり、ディフォルトの言語を English (US) にして、 SKKIME 等の追加の IME はインストールせず、等々。 だのに、偶に「がっかり」が見つかる。 前者については打つ手なし。(Cygwin Terminal の方を Shift-JIS にできるのだが、それはちょっと……。 他にもそういうコマンドが見つかったら、また考えよう。) 後者は実害はないもののちょっと気持悪いので、/etc/group を見て、Users の GID が 545 であるのを確認して、/etc/passwd の fukuda の Group を 545 に変更。結果の表示は下図のようになる。
Cygwin Terminal on Windows 8.1
Cygwin Terminal の表示

おまけ


2014-04-23 (Wed): Windows 8.1 on VMware Fusion

Windows 7 と VMware Fusion 5.0.x ではそこそこ快適に動いていたのに…… ちょっとリリース前の Windows 8 を弄ってみよう、なんてスケベ心を出したのが間違いの始まり。 いや、PR 版を使っていた間は然程の問題もなく、 むしろ正規版を購入して(3,300 円の値段に飛び付いた)からおかしくなったような気もする。 VMware Fusion のアップグレードのせいなのか、はたまた、 Win8 が悪いのか、とにかく二進も三進も行かなくなっていた。 最初の「レスポンスが遅い」以外は、総て 0xC0000142 error が関連している(ような気がする)。 つまり、こいつのせいで、どうにもならなくなっていた、という事。

という事で、「これはもうダメかも知れない」とばかりに放り出していたのだが、 VMware Fusion が 6.0.3 にアップデートされた上に、 ひょんな事で、Win8 を再ダウンロードするためのサイトを見付けたので、 またぞろ、四苦八苦してみる事にした。

  1. VMware を 6.0.3 にアップデート
  2. 旧バーチャルマシンを開き、そこから マイクロソフトのサイト にアクセス、ISO image をダウンロード→ save せずに、インストールを試みる。
  3. インストールはできたが、認証もできず(Product Key が正しくないと言われる) また、Win8 の最新版へのアップデートもできない。 (これは以前試みた事の再確認。)
  4. 再度、ISO image を download。新バーチャルマシンがアクセスできる場所 (~/Desktop) に移動。
  5. 旧 VM を止めて、新 VM を作り、それに 上の ISO image から、Win8 をインストール。
  6. 今度は、update ができた。(その他の設定変更は一切やらず。)
  7. Startup 画面にある「ストア」ペインで、8.1 への無料アップグレードを促されるので、 ストアからイメージをダウンロードしてきて、インストール。 今度はうまく行った。どうやら、新 VM に新規にインストールする、というのがミソらしい。
何とか 8.1 までインストールする事ができたが、 "0xC0000142 error" は出なくなったものの、 window の再描画はやっぱり遅い。 加えて、文字入力へのレスポンスがさらに遅くなっている。 普通のタイピングについて来れず、「やってられねぇ」レベル。

とりあえずは、この問題を何とかすべく、最小限の設定をやる。

  1. Virtual Machine の設定
    • Virutal Machine Tools のインストール
    • memory を 3072 MB, cpu core を 2 個に増強
    • Display の Accelerate 3D Graphics を OFF に
    これで、文字入力はかなり早くなった。
  2. Windows の設定:
    • screen resolution を 1440 x 900 に
    • Language Preferences を English (US) に。 (こうしないと、JIS 配列キーボードと看做される。Options から、library をダウンロードする必要あり。)
    • item/font size を 125% に
とりあえず、使い続ける気になる程度にはレスポンスが改善されたので、 恐る恐るながら、アプリケーションをインストールしてみた。 ここまでのところのスクリーンショットを示す。
Windows 8.1 on VMware
Windows 8.1 on VMware
ともあれ、レスポンスは「何とか使い続けられそう」というレベルになったし、 何より、恐怖の "0xC0000142 error" を克服できた。 で、Win8.1 on VMware, もうちょっと使ってみようかという気になりかけている。 (3,300 円で、ここまでできたら「めっけもの」——と思いたい。)

2014-04-19 (Sat): Ubuntu Server を 14.04 LTS に

現行の Ubuntu-13.10 (ThinkPad X200) は結構手間がかかっていた。 頻繁にパッケージの upgrade を促されるし、 その中にはかなりの割合で security update が含まれていたので、当然リブートを要求される事も多い。 その結果、uptime は最長でも 30日くらいだった。 前のサーバ(ThinkPad X22 +Fedora 7) では、uptime が 2 年位まで行った事もあるので、その意味では Ubuntu にして手間暇がかかるようになったとも言える。 とは言え、security update まで完全に無視するのはちょっとマズいので、 security update の「重大さ」をウォッチして、 最低限のものは upgrade する必要がある。 しかし、これもなかなか面倒な作業(長々と英文の ML を読まされる)なので、 何も考えずにその都度 update/upgrade するのと比較して大して負荷は減らないように思える。

となると予てからの目論見である「LTS にしてサーバ管理の手間を省く」は本当に実現できるかどうか、甚だ心許ない。 だとすれば、LTS にアップグレードするのは無駄ではないか……

等という至極まっとうな「懸念」は、たまたま見掛けた 13.10 の start-up 画面(下記)の "Run 'do-release-upgrade' to upgrade to it" を見た途端八割方蒸発し(おお、コマンド一発なんだ)、次いで、 とあるサイトの "Estimated completion time: 20-30m" との記述を見て雲散霧消してしまった (何、30分でできちゃうの?)

Old Ubuntu Start-up Screen
Ubuntu-13.10 の startup 画面
(さりげなく、upgrade を促してくる)

Install

上述のように、12.04 LTS もしくは、13.10 からのアップグレードは、
fukuda@lark:~% sudo do-release-upgrade 
一発で済む。大体の手順と、所要時間は次の通り。
14:16; 所要 package の確認開始
    *1)
14:24; package download 開始
15:06; package upgrade 開始
    *2)
    daemon の stop/restart 
    *3)
15:45; restart (reboot) 
この間のプロンプトと応答:
  1. *1) 最初に、ssh でログインして操作している事を検出して、 「問題が有った時に復旧が面倒だけど、それでも続行するか」と聞いてくる。 勿論 Yes と応える——これができなかったら、VPS で使えないではないか。 port: 22 に加えて 1022 も開くぞ云々と言ってくるが無視。 (iptables で port 1022 を開ける操作はしなかった。)
  2. *2) 各 daemon をリスタートする時、自動でやるか、 それとも毎回聞いてくるか、と尋ねられる。自動で行く。
  3. *3) dovecot, ssl, qemu, logind について、新旧の conf ファイルのどちらを選ぶかを聞いてくる。 いずれも、既存のファイルを選ぶ事にした。
「所要時間 20-30分」というのは、ちょっと(かなり)「ホラ」だったが、 全体としては「大したもんだ」と思う。 つまりこの間、サーバが落ちていた時間は合計で 1分以内、という事になる。 いや、本当に大したもんだ。
New Ubuntu Start-up Screen
Ubuntu-14.04 の startup 画面
(わずかだがコンパクトになった!)
こういう時は、この Startup 画面はとても便利で、 とりあえず、ちゃんとアップグレードされており、プロセス数は略同じ、 ディスクの占有容量は少し減っている事が分る。

構成

今のところ、conf ファイル他を一切触ることなく、従来の機能が再現されている。

動作確認

手早く、とりあえずの確認をした……

2014-04-13 (Sun): Wireshark 復活

ここぞ、という時に駄々を捏ねて、少々がっかりさせられた Wireshark だったが、その後もなかなか問題は解決しなかった。 つまり、(Mavericks の上で)「起動にやたら時間がかかる」 「キャプチャが始まらない事がある」 (Lion の上で)「anti-alias フォントが使われない」 等が、なかなか解消できないでいた。

で、今日になってそれらが解決できたのだが、 そのきっかけが何と「Wireshark の再インストール」だった……。 いや、もっと正確に言うと、再インストールそのものではなく、 使われる X11 を「確定」した後に、Wireshark をインストールする事が重要なのだった。 (「確定」する、というのは、MacOSX 附属の X11、MacPort 版 Xorg、 及び XQuartz、の内、Wireshark のインストール時、 どれが参照されるか決めておく、という事。)

例によって、必要十分な条件を切り出す手間を惜しんだので、 オーバキルになっている恐れはあるが……

  1. ~/.MacOSX/environment.plist から、LANG 及び LC_ALL の定義を一掃する。 (一旦ログアウトしないと有効にならない。)
  2. port 版の Wireshark, Xorg はアンインストール
  3. バイナリ版 XQuartz をインストール
  4. /usr/X11 /usr/X11R6 は(もしそうなってなければ)、どちらも /opt/X11 への symbolic link にする
  5. バイナリ版 Wireshark をインストール
ここで重要なのはこの順序(特に 3〜5)。 こうする事で、Lion (on MacPro) と Mavericks (on MBA) の両方で、 等を実現できた。有り体に言うと、Mavericks (MBA) の上では「元に戻っただけ」だが、まあしかし、とりあえずは良かった……
Revived Wireshark
復活した Wireshark (on MBA)
但し再度触ってみて再認識したのだが、いくらフィルタ等を工夫しても、 このままでは PER (Packet Error Rate) や混み具合 (back-off の頻度) を評価するのは難しく、 附属の統計処理のツールを極める必要がありそう。もし、それで駄目なら、 キャプチャファイルを解析するスクリプトを書かなければいけない?

2014-04-12 (Sat): HeartBleed Bug

一度は勉強してみなくてはと、無謀にも「Fermat の小定理」から始めて、「公開鍵・秘密鍵」の仕組を一応理解できた。 尤もその「理解」にはあまり自信がないが、しかし、OpenSSL が非常によくできたツールである事だけはようく解った —— というか、「そんなに大変な事やってたんだぁ」とようやく気が付いた。 つまり、OpenSSL が苦もなくやってのける「鍵生成」も、整数が 64 bit と決まっている言語ではすぐに行き詰まるし、 整数の精度(桁数)に制限がない Python でも、 長い鍵を作ろうとすると極端に処理が遅くなって、 512 bit の鍵ですら「とてもとても」という感じになる。まさに、偉いぞ OpenSSL! と。

で、その OpenSSL に重大なバグが見付かって大騒ぎらしい……。

私も一応はウェブサイト(Ubuntu-13.10 server) を公開しているので、 ちょっと心配になって調べてみたが、何のことはない、https じゃないサイトでは Apache はそもそも SSL を使ってないのだった(考えてみれば当り前…… *^^*。) Apache の他に無いか(公開しているかどうかを度外視して)確認すると、 我サイトではどうやら Mailman の qrunner/mailmanctl と Dovecot の imap/imap-login は OpenSSL を使っているようだ。

なので、とりあえず Ubuntu をアップグレード……

fukuda@lark:~% sudo apt-get update
fukuda@lark:~% sudo apt-get upgrade
fukuda@lark:~% aptitude show openssl
Package: openssl                         
State: installed
Automatically installed: no
Version: 1.0.1e-3ubuntu1.2 
    .... 
あれ、1.0.1e のままではないか(対応済みのバージョンは、1.0.1g から) と思ったが、Ubuntu さん、パッチを当てる事で対応したようで、
fukuda@lark:~% openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Apr  7 20:33:19 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
    ....
のように、built on date が 4月 7日 になってれば OK らしい。

ちなみに、MacPorts も早速対応したようで、通常の sudo port upgrade outdated の後、

fukuda@quadra:~% port installed openssl
The following ports are currently installed:
  openssl @1.0.1f_0
  openssl @1.0.1g_0 (active) 
となっていた。

それにしても「騒ぎ過ぎ」ではないだろうか。 メモリの内容は当然どんどん変わっていくのに、一度に読めるのはそのほんの一部だけなので、 そう簡単にパスワードが収集できる訣もないだろう —— そもそも、ある人がたまたまパスワードを使ってログインしたばかりでないと、 それがメモリ上に残ってないだろう。 実際、これまで被害は一件も報告されていなようだし。 それに、 bug が見付かって (fix されて) 公開されるまで、一週間弱、 その間に件の「印象的」な呼称(「心臓出血」!)やロゴを作るなど、 なんだか「ちゃっかり商売にしているなぁ」という気がする。


182/1,073,980 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2014-08-28 (Thu) 13:43:02 JST