LFSに挑戦1(準備段階)

LFS(Linux From Scratch)に挑戦してみます。目的は、Linuxの起動シーケンスの理解です。
母艦環境は先にインストールしたDebian7.1(Wheezy)です。
基本的にLFS Bookに沿って進めて、実際の作業のみメモを残します。
まずは第4章の準備段階の完了までです。

<追伸>
入力するコマンドのコピペをする場合には、HTML版で行う。PDF版では行の終わりにゴミがついてしまうようで、複数行に渡る場合に正しく入力されません。

“LFSに挑戦1(準備段階)” の続きを読む

Xubuntu13.04+OpenCV2.4で顔認識してみた

久しぶりにOpenCVを動かす必要があり、試しにOpenCV2.4で顔認識を動かしてみました。
まず、C言語版。

1.OpenCVのインストール

これまでと手順は一緒。バージョンは2.4になっているので、それに応じた変化のみ。

  • opencv-doc
  • python-opencv
  • libcv2.4
  • libhighgui2.4
  • libcvaux2.4
  • libcv-dev
  • libcvaux-dev
  • libhighgui-dev
  • libopencv-dev

2.プログラムの作成

これも前回までと同じ。opencv.jp のサンプルプログラムをコピペして、main.cという名前で保存する。
元のままだと、大きなサイズの画像は画面をはみ出してしまうので、ウインドウサイズを指定するように変更・追加した。(cvNamedWindow の第2パラメータ変更、cvResizeWindowの追加)

// (6)画像を表示,キーが押されたときに終了
 cvNamedWindow ("Face Detection", 0);
 cvResizeWindow("Face Detection", 640, 480);
 cvShowImage ("Face Detection", src_img);
 cvWaitKey (0);

3.コンパイル

これも前回までと同じ。以下のコマンドによりコンパイル。インクルードファイルやライブラリの位置は pkg-config で勝手に探してもらう。

$ g++ -o main main.c `pkg-config --cflags opencv` `pkg-config --libs opencv`

4.カスケードファイルの準備

ここは前回とことなる。カスケードファイルは一つになっている。

$ cp /usr/share/opencv/haarcascades/haarcascade_frontalface_default.xml .

としてローカルディレクトリにコピーした。

5.動作テスト

$ ./main ファイル名.jpg(pngでもOKでした)

でWindowが表示されて検出された顔に◯がついた。

6.Python版

opencv.jp のサンプルプログラムのところにある「Python版に切り替え」というボタンを押した後、コードをコピペして、main.pyという名前で保存して、

$ chmod 755 main.py

として実行権限をつけて、

$ ./main.py ファイル名.jpg

と実行したところ、冒頭のimportで失敗します。原因調査の時間はないので、また今度・・・。

Debian Wheezyをインストール

今更ながら、素のDebian(gnome版)をインストールしてみました。普段はWindows7で使っているマシンなので、USB-HDDにインストール。インストールしてみたのですが、gnome shell版はやっぱり扱いにくいので、XFCEかLXDE版にすればよかったか・・とも思いましたが、とにかくこのまま使ってみることにしました。

とりあえず、最低限の初期設定の方法をメモ。

  1. ディスプレイの解像度変更
    「アクティビティ」→「アプリケーション」→「システム設定」→「ディスプレイ」
  2. 漢字入力の設定
    インストール直後では漢字入力もできません。
    https://wiki.debian.org/JapaneseEnvironment
    を参照しながら日本語環境をセットアップする。パッケージのインストールはSynapticで行う。
    ところどころちょっと違う(OpenOfficeじゃなくてLibreOfficeだとか・・・)
  3. 自分をsudoグループに追加
    $ su
    # adduser <自分のアカウント> sudo
  4. ファイアウォールのインストール・設定
    $ sudo apt-get install gufw
    $ sudo gufw
  5. rkhunterのデータベースアップデート

こんなところですかね・・・。

SDRがAndroidで動かないか試してみた。

Androidに移植している人がいるのではないかと思い、Google Playストアを検索してみました。

事実上、該当するのは1件だけのようです。

  1. RTL2832U driver
    rtl_tcpのAndroidへの移植版だそうです。ライセンスはGPL2+でソースはこっち(https://github.com/martinmarinov/rtl_tcp_andro-)にあるそうです。ルート権限はAndroid3.1以降は不要・・・だそうな。
  2. SDR Touch
    こっちがSDR本体のようです。検索すると SDR Touch Key というのが別に出てきます。インストールして起動してみると「DEMO MODE」。上記RTL2832U driverは起動してあるので、動きそうなものだが操作ができるだけ。受信できず?
    ただ、動いている人もいるみたいなのでよくわかりません。

・・・というわけで、残念でした。

SDRに挑戦してみました

aitendoのサイトを見ていたら、特売品の中にRTL2832Uを用いたUSBワンセグTVチューナーがアンテナ+リモコン付きで999円、どうも別の機種っぽいUSBチューナー単体が666円で出ていました。

海外のワンセグTVチューナーが広帯域受信機として使用可能、いう話を以前から見かけていたので、調べてみたらどうもチップも一致、しかも、ダイレクトサンプリングという手法(というか、RF飛ばして入力する?)で、RTL2832UでLF~HF帯も受信可能なようです。

こちらのサイトで非常に詳しく色々と解説されていて、とても参考になります。そして、ポチッとしたい衝動を抑えられなくなりました(笑)

で、届いたのがこれ。

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA

さすがaitendoです。シンプルな包装です(^^;。ま、必要なのは中身だけなんでそれでいいんですけどね。

で、動かすためのソフトウェアですが、どうもこんな感じみたいです。

  • Gqrx SDR receiver
    GNU RadioとQtをベースにしたグラフィカルで綺麗な表示のSDRです。
  • GNU Radio
    ソフトウェア無線のためのツールキットです。名前からわかる通りオープンソースです。
  • RTL-SDR
    OsmoSDRは安価に実現可能なSDRソフトウェア開発プロジェクト・・・と書かれています。
    このプロジェクトの中にRTL-SDRというソフトウェアがあって、RTL2832Uに対応したコマンドライン版ソフトウェアのようです。
    このRTL-SDRはクライアント-サーバに分かれていて、サーバ側に受信機(USBワンセグチューナ)を設置します。
    このサーバにはRaspberryPiを使うことも可能なようで、実際に試されています

この中からまずはGqrxを動かしてみることにしました。ダウンロードはsourceforge.netのプロジェクトページから。環境はLinuxMint13 32bit版です。

  1. 軟弱者なのでバイナリパッケージ(gqrx-2.1.251-i686.tar.xz)を持ってきます。
  2. 展開して、README.txt を読むと、いくつか依存するものがあるようです。
    ・GNU Radio 3.6以降
    ・「gnuradio-fcd」「gnuradio-uhd」「RTL-SDR」「Osmo SDR」のどれか
    ・gnuradio-osmosdr
    ・pulseaudio
    ・Qt 4.6以降と Qt Creator
  3. ・・・が、下の方を読むと、バイナリパッケージには必要なGNU Radio、UHD、rtlsdr、Boostライブラリが含まれているそうです。

展開したファイルの中に「gqrx」という実行ファイルがあるので、とりあえずこれをroot権限で起動すると動作できます。

※追伸
lubuntu13.04ではlibqtgui、Qt Creator、pulseaudioをSynapticでインストールする作業が必要でした

root権限ないではUSBチューナが見えない、というのはイマイチなので、/dev/udev/rules.d の下にルールを追加します。
具体的には、/etc/udev/rules.d/20.rtlsdr.rules として以下の内容のファイルを作ります。

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2832", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"

作成後、「$ sudo restart udev」とした後、一旦USBチューナーを抜き差しすると、ユーザー権限で起動しても動作するようになりました。

Screenshot-Gqrx 2.1.251 - rtl=0

これはFM東京を受信している様子です。ごく簡単なアンテナで、しかも鉄筋コンクリートの室内、普通のポータブルタイプのFMラジオだとほとんど受信できない環境なのにFM局が何局か受信できました。

<参考>
Computer Radio RF Techさん
ダイレクトサンプリング、アップコンバータの適用、RaspberryPiでSDRサーバなど
ゆうちゃんのパパさん
ダイレクトサンプリングやアンプ搭載、LPF搭載、など

AVR関連小物工作

久々にハンダごてを握ってみました。

今回作ったのは最小Arduinoを基板化したもの2つと、AVRISP mkIIでATmega328pにブートローダを書き込むためのアダプタ、最小Arduinoでプログラムをダウンロードするためのアダプタの4つです。

DSC_0218

左から AVRISP mkII 、ブートローダ書き込み用のアダプタ、最小Arduino×2個です。
すべて秋月の小型のユニバーサルボードの上に組んであります。電源はACアダプタとかを使うのが面倒なので、電池1本を含めてオンボードでHT7750A(ブートローダ)やHT7733A(最小Arduino)を載せてあります。コンデンサやダイオードはチップ部品で裏面に実装してあります。上方の8pinのコネクタはSPIです。

DSC_0219

そしてこちらが最小Arduinoに書き込み・デバッグをするためのアダプタで、写真のような感じでデバッグ・書き込みを行います。ATmega328pをICクリップでつまんで接続しますが、11~18pinは書き込み・デバッグには不要なので20pinのICクリップで済ませています。(秋月で売っている28pinのICクリップはワイドタイプ用なので、ナロー28pinには向かない、というのもあります)

 

 

FreeNASのディスクをフォーマットしなおす

出張中にrsyncによるバックアップが終わっていたので、元のミラーディスクを消去します。
(ちなみにバックアップはLinux上でも別にrsyncで取ってありますので、二重化はされたままです)

ストレージを表示し、先にバックアップをとったボリュームのところの赤×がついたアイコンをクリックしてボリュームを削除します。この時、Windows共有(CIFS)の設定をクリアするか聞いてきますが、クリアしないで残しておきます。(CIFSの共有自体はrsyncでバックアップを取る前に停止してあります)

改めてボリュームマネージャで同じボリューム名で2本のHDDをミラーリングにてZFSボリュームを作成します。この時の設定として暗号化を追加します。

ボリューム作成が終わったらバックアップからの復元のためにrsyncで逆方向のコピーを行ってデータを復元しますが、また長い長い時間がかかります。放置しておくしかありませんので、今日はここまでです。

あとはCIFSのサービスを再開させればいいのだと思いますが、どうでしょうかね。

<追伸>
CIFSサービスを再開させるだけで無事にファイルサーバとして復帰してくれました。

FreeNASにディスクを追加する

Microserverで快調に動いているFreeNASにディスクを追加してみました。

目的は万が一空き巣にでも入られてHDDを持ち去られた場合に備えて、FreeNAS8.3.1で追加された暗号化を適用したいということです。全領域を暗号化するには一旦中身をバックアップしないといけないので、まずは外付けディスク以外に内蔵ディスクでもバックアップをとることにしました。

4本ある3.5インチベイのうち、すでに2TB×2でRAID1によるミラーリングで2本、初めからついてきた250GBの作業領域で1本使っていますので、残りの1本に新たに買ってきた2TBのHDDを取り付けて電源ONしました。

暗号化ボリュームの取扱いになれるのを兼ねて、バックアップ領域も暗号化を適用してみます。

1.ボリュームの作成

ボリュームマネージャでバックアップ領域としてボリュームを作成します。

Screenshot-3

ボリューム名に「BACKUP」、メンバディスクは今回追加した ada3(2.0TB) を選択、ファイルシステムはZFSを選択、ZFS選択後に出てくる「Enable full disk encryption」を選択して「ボリュームを追加」を押します。

Screenshot-4

この時点でシェルから今回のディスクにアクセスが可能になります。

/mnt # rsync -av /mnt/DATA/ /mnt/BACKUP/

として、データを丸ごとコピーします。

2.パスフレーズの設定等

※暗号化鍵やパスフレーズ、リカバリキーは厳重に保管する必要があります。

1)パスフレーズの設定

ストレージのレポートから追加したボリュームの右の方の鍵のマーク(鍵だけのマークで下記の画面コピーでは右から5番目のもの)をクリックして、パスフレーズを設定します。

Screenshot-6

2)リカバリ鍵の設定

Screenshot-7

上記アイコンのうち、「+」と「-」のついた右の二つをつかってリカバリ鍵の追加と削除ができます。追加したリカバリ鍵はパスフレーズを忘れてしまった際にパスフレーズの代わりに使うことができます。

3)暗号化鍵のダウンロード

Screenshot-7

上記アイコンのうち、左から2番目の「↓」がついたボタンを使うと、暗号化鍵のコピーをダウンロードできます。

4)暗号化鍵の変更

Screenshot-7

上記アイコンのうち、真ん中のものを使うと、暗号化鍵を再生成することができます。再生成には現状のパスフレーズが必要です。暗号化鍵が漏洩したと思われる場合に暗号化鍵を変更するために使用します。

3.あまりに遅い??

・・・ここまで終わったところで、rsyncの状況を確認したところ、30分で40GB程度の進捗。計算すると、20MB/s程度しか出ていません。これだと1.4TB=1400GBコピーし終わるのは18時間後になってしまいます。AESによる暗号化処理をハードウェアでサポートするAESーNIがCPUで持っていないと非常に遅くなる、とは書いてありましたが、20MB/sではあまりに遅すぎます。
一旦 rsync を中止しして、あらためて暗号化無しでボリュームを作成して転送してみると、20分で46GB程度の進捗ですので、暗号化を行うと半分強くらいまでスループットが落ちてしまうようです。

これだとrsyncが遅いだけかもしれませんので、簡単に速度の比較をしてみることにしました。

まず、FreeNAS上にWindows共有を2つ用意しました。片方は暗号化無しの250GBのHDD上のボリューム、もう片方は暗号化ありの2TBのHDD上のボリュームです。

ここにトータル600MB、3000個のファイル(大きなPDFからデジカメの写真など適当なファイルです)を書き込んでみました。先に暗号化無しの方に書き込むと141秒かかりましたので、4.25MB/sということになります。次に暗号化有りの方に書き込むと120秒で終わってしまいましたので、5.0MB/sということにないました。

次に各種Linuxディストリビューションファイルを3.85GB書き込んでみます。今度は先に暗号化有りの方から書き込んでみたところ108秒かかりましたので35.6MB/sということになります。次に暗号化無しの方に書き込んで見たところ73秒で終わりましたので52.7MB/sということになります。

この結果からすると、大きなファイル中心の書き込みは影響を受けてしまいそうですが、細かいファイル中心の場合にはディスクの性能の方が効いてきそうな感じです。

今日のところはここまでにして、とりあえず rsync でバックアップが取り終わるのを放置して待つことにします。