2015年8月24日月曜日

FreeNX で新規セッション生成時の不具合を解消する

いまごろ FreeNX 使っているところはそう多くないだろうし、完全に手元のメモだけど。


nx ユーザとしての localhost SSH 接続時にホスト鍵が一致しない場合の問題


FreeNX の認証方法にもよるが SSH 認証を使う場合、一度 NX ユーザとしてログインし、その NX ユーザから実際のユーザ権限で目的のサーバ(localhostかもしれない)に対して SSH ログインする仕組みになっている。

OS のイメージをコピーしたりする際、 ~nx/.ssh/known_hosts に localhost の鍵が含まれている。このため、 同ファイル中の「localhostの鍵」と/etc/ssh/の下にあるホスト鍵が一致しなくなると認証エラーとなりログインできない。うっかり設定をコピー展開したりSSH鍵を作り直したり、イメージを作成して展開した場合に嵌まる。

 対策としては ~nx/.ssh/known_hosts を消す。(と現行の鍵が勝手に書き直される)

 X ディスプレイのロックファイルが蒸発した場合に、新規セッションのディスプレイIDが既存セッションと衝突する


該当箇所は /usr/bin/nxserver のココ


FreeNX や X Window System の何かが /tmp/ 以下にロックファイルを作っている。 FreeNX の新規セッション作成時は、これらのファイルからディスプレイ番号の利用状況を判断して新しいディスプレイIDを割り当てる。

たとえば nxserver --list コマンドで下記のセッションがあるとして

127.0.0.1    1005    hasegaw    192.168.x.x    23BC130AD583AD79F715814CE73972B5

以下のロックファイルがひとつも見つからないと、NX Clientから接続された FreeNX は、重複したディスプレイ番号をセッションに割り当てようとして突然死し、ユーザから見ると何もわからない状況になる。
  • /tmp/.X1000-lock
  • /tmp/.nX1000-lock
  • /tmp/X11-unix/X1000
対策として、下記のワンライナーで、 nxserver --list の結果から、足りないロックファイルを生成するシェルスクリプトを生成させてシェルに流し込む。ひどいけど動いてる。


本当は nxserver を直さないとダメかと思ったけど、RPMから導入してるものをいじらずに対策できてよかった。っていうか自分でディスプレイ番号わかってるのに重複割り当てするとか情けない。。。。

おもうこと


Linux 向けのリモートデスクトップ環境として FreeNX(や X2GO)は割と快適なんだけど、いろいろ罠があってつらい。もっと鉄板なソリューションはないものか。。。

2015年6月8日月曜日

fluent-bit 用 AM2320/AM2321 Input Plugin

LinuxCon 2015 Tokyo の発表を見ていたら、今後、 IOT デバイスや組み込み機器などを想定した fluent-bit で、センサ関係をサポートしていくらしい。折角なので、とりあえず自宅の温度・湿度計測に利用している AM2320 の Input Plugin を書いてみた。

AM2320 は秋月電子で入手可能な温湿度センサ。 I2C 準拠なので Raspberry Pi に 4 線つないであげれば利用できる。たぶん AM2321 というのは AM2320 のピッチ違いバージョンだと思う。 AM2320 が 2.54mm なのでブレットボードやユニバーサル基板に実装できる。

※ Raspberry Pi のユニバーサル基板に真面目に実装すると RPi 側の発熱を拾ってしまうのでアレ。

もともとは Raspberry Pi で AM2320/AM2321 を使うプログラムの Mackerel対応版 をベースに温度、湿度が取得して、それをエージェント経由で Zabbix に突っ込んでいたんだけど、記録だけなら fluent-bit のほうがシンプルな ので、プラグインを起こしてみた。

Raspberry Pi の I2C ドライバをロードしておき /dev/i2c-1 が見えている前提で、下記の要領で利用できる。

2015年3月31日火曜日

rm -rf が怖かったので chroot した

Linux ベースのファイルサーバでいらなくなったディレクトリを削除しようかと思ったけどうっかり必要なデータまで消してしまうのが怖かったので、チキンな私は chroot した。

以前、データを移行したディレクトリは .migrated に移してあった。
 
# mkdir .migrated
# mv hoge fuga .migrated

なので .migrated/ に chroot する。
 
# cd .migarated
# ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fff36fff000)
        libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000037d1a00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000037c7600000)
        libc.so.6 => /lib64/libc.so.6 (0x00000037c7200000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037c6e00000)

# ldd /bin/rm
        linux-vdso.so.1 =>  (0x00007fffbf1ff000)
        libc.so.6 => /lib64/libc.so.6 (0x00000037c7200000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037c6e00000)

# mkdir bin lib64
# cp /lib64/libtinfo.so.5 /lib64/libdl.so.2 /lib64/libc.so.6 \
        /lib64/ld-linux-x86-64.so.2 lib/
# cp /bin/bash /bin/rm bin/ 
# chroot . 
 
# echo * 
bin fuga hoge lib64  
 
# pwd 
/
 
# bin/rm -rf hoge/ fuga/
# exit

2015年1月9日金曜日

音楽プレイヤー

電車の中でとあるブログを読んでいて、音楽プレイヤーのことをいろいろと回想していた。思い出したついででブログに駄文をかいてみようかと。

はじめてのCDラジカセは小学生時代に親に買ってもらったと思う。でも、思い出すのは中学生の頃に手に入れたポータブルMDからでいいかな。

ポータブルMDをはじめて見たのは従兄弟の部屋でだった。従兄弟はソニーの初代カセットウォークマン、MDウォークマンを持っていた。音楽の記憶メディアといえばテープが当たり前の時代にランダムアクセスができるディスク。すごい、かっこよかった。

中学2年のときにアマチュア無線局を開局した。あの一年は時間さえあればひたすら 50MHz で交信していた。一年間で QSL カードのやりとりが500枚越えていた気がする。まあ、365日で500枚だったらそれほどハイペースでもないけど、今はアマチュア無線人口少ないだろうから一年で500枚交換するのはけっこう大変なんじゃないだろうか。突然アマチュア無線の話をしてるけど、私が手にした最初のケンウッドのポータブル MD は ALL JA コンテストかなんかで抽選にあたって送られてきた物だった。当時の CQ 誌を掘り返せば当選者として私の名前が載っている。

あまり音質に興味がなかったので ATRAC が音質悪いとかどーとかいうのは、あまり興味なかった(今あらためて使うとやっぱり音質悪いな)。ケンウッドのポータブルMDはけっこう大事にしていたんだけど、中学校に何かの理由で持っていった際に、帰りがけに地面に落としてイジェクト操作がひっかかるようになった。親が修理に出してくれたので、その後も使っていた。

高校に入学するタイミングで、なぜか母親にVictorのMD/CDコンポを買ってもらった。私は、先の理由からポータブルオーディオは完全にMDに移行していて、カセットテープを使うことはなくなっていた。私が持っていたコンポは、ラジカセといえば大量にボタンがついている製品がまだ多かった中、1997年当時でありながら、MD/CDだけですごくシンプルなデザインが気に入っていた。

 この頃になると世の中はエヴァンゲリオンとか小室ファミリーとかが盛り上がっていて、先進的(?)なユーザはMP3をインターネットからダウンロードしてきてジュークボックスが充実しはじめる前夜。はじめて MP3 を再生したときは衝撃的だった。たった数MBであの音質の音楽が保存できるだなんて。必死にCD-DAをリッピングしては Pentium Pro 200MHz で L3ENC を走らせ、WinAmpで聞いたりしていた。今の自分のオーディオライブラリで一番古いのはそのへんの音源。

この頃に衝撃を受けたのが empeg というスタートアップ。ある日、インターネットを徘徊していたら、車載用の MP3 プレイヤーを作っている人の日記を見つけた。PowerPC かなんかのプロセッサを搭載して、ハードディスクに何千曲も保存できるカーオーディオ。



まだカーオーディオといったらラジオ、カセットテープ、一部の車はCDが再生できるという時代で、MP3プレイヤーなんてものは電気屋に売ってなかったと思う。そういう状況で、MP3をカーオーディオに使うという empeg の発想に、この人は今までにないものを作ってる、と感じた。しかし、そのとき一番仲良しだった奴に「俺、車買ったらコレ付けるんだ」と言ったら、バカにされた。

「そんなの付けてどーするんだよw」


その後、私の地元、名古屋の電気街 大須でも、フラッシュを使った MP3 プレイヤーをよく見かけるようになり、 Apple は iPod なるものを発売した。 iPod の最初のモデルは 5GB 、第二世代では 10GB 。これまた衝撃。自分はそう多く音楽聴かないけど、自分が持っている音楽データを全て持ち歩けるだなんて。

10GB の iPod が発売された頃、私は初めて IT 系のバイトをしていた。 Ultima Online を通じて知り合った人がゲーム会社をやっているという。打ち合わせのためにその会社にお邪魔すると、竹内さんというディレクターがバイトの内容を説明してくれた。 いわゆる milktub の bamboo 氏だった。

初めてコンピュータスキルで稼いだバイト代を握りしめて、最初に買ったのは液晶ディスプレイ、そしてはじめての Apple 製品として iPod 10GB を買った。 2002 年、第二世代 iPod はまだ IEEE1384 にしか対応しておらず、手元の Windows マシンには直接接続できなかったので、 Logitec 製の 1384 カードをそのためだけに追加した。初めて買った iPod は確か79,800 円した。たかが音楽プレイヤーのためにあんな額出した自分には割と信じられないけど、自分のライブラリがポケットに入るのはやっぱり魅力的だった。同級生の女の子に「タケシがそんなのに興味もつなんて、意外だね」と言われた。失礼だなあと思ったけど、実際、自分でも意外だった。

iPod (Classic)はその時点で音楽プレイヤーとして完成していたけども、とてもストレスな点があった。ホスト側のプログラムだ。 iTunes には何も不満はない。私が iPod を手にした頃は、まだ iTunes が Windows に上陸していなくて、 Sony かどっかの MusicMatch とかいう名前のクソ使いづらいソフトウェアのアドオンとして iPod に曲を転送するクソ仕様だった。

MusicMatch は本当にひどかった。 iPod を IEEE1394 で接続した後、1分ぐらいフリーズして、それから曲の同期がはじまった。たかだか曲を転送するために1分待たないといけないのは本当に鬱陶しい。しかも iPod のファイルシステムは FAT で、普通に MP3 ファイルがコピーされているんだから、なんとかならないものか。 iPod のインターフェイスはあんなにシンプルなのに、曲をドラッグ&ドロップで登録できない iPod には、すごい苛立っていた。

調べたら、 gnupod という名前の iPod 転送ツールが Perl ベースであることが判った。 iPod 上にある iTunes データベースファイルと gnupod のソースコードから、 Delphi ベースで iPod 上のデータベースを再構築するプログラムを作りはじめ、一週間後にはとりあえずドラッグ&ドロップすると曲を iPod に転送できる自作ツールが誕生していた。

ID3タグぐらいならフォーマット情報やライブラリはゴロゴロしてるだろうけど、ただ曲長を決定したいがためだけにMPEG 1.0 Audioのフレームを自前で解析したりしていて、あまりプログラムを書い ていない私としては割と頑張った自作プログラムだった。ドラッグ&ドロップが快適になるように GUI スレッドとワーカースレッドを分けるなど改良して楽しく過ごしていた、が、ある日 iTunes の Windows 版がリリースされ、これなら純正ツールを使えばいいと思ったので、そこで開発はほぼ打ち切った。

この頃になると例の empeg は買収されて Rio ブランドになっていた。私が MP3 カーオーディオが欲しいと話したのを大笑いした彼は、初代 MR2 を中古で入手し、私より先に MP3 HDD プレイヤーを車に載せていた。

2004年、就職した後でカラー液晶つきの 4G iPod に乗り換え、2006 年には出張先の新潟市で iPod が壊れて、現地のビックカメラで 5G iPod を買った。今でも 5G iPod は健在だけど、120GB 程度の容量だと、今では iPad mini のフラッシュ容量のほうが多いぐらいなので、 2014 年になって、 iPad mini の 128GB モデルを買って iPod Classic の持ち歩きはやめることにした。

MDもMP3オーディオもかなり早い時期から触っていた方だと思うけど、特にiPodはプログラミング含めて、とても楽しいデバイスだった。10年ちょっとの間、ありがとう。

2014年10月24日金曜日

退職ナウ



10月17日付けで、3年半務めさせていただいた某社セールスエンジニアのポジションを resign しました。

この三年半はとても刺激的でした。きっかけは2010年の夏、ポジションのオファーの連絡をいただいた際には、それまでの話とは違い、オファーが目に入った三秒後には「これは面白い、やりたい!」という気持ちが溢れていました。 HR 担当者との Skype 越しでのインタビューでは、「ウチの会社は昼メシ時に一本スキー滑ってる人もいるよ」「うわぁ!オレ絶対入社したいです!」「おいおい、これは面接だからそこは忘れるなよ?」 「で、あなたはこの会社で何をするの?」「私は御社の日本チームを代表するエンジニアになりたいです!」「、オーケー!オーケー!」みたいな、英語が話せないなりにアレな感じではじまりました。

 自身の能力不足で色々なチャレンジがありましたが、恐らく同社のAPACのセールスエンジニアとしては、少なくとも社内のセールスエンジニア組織ではもっとも認知された一人になれたと思います。当初の requirement を満たさないなかで採用としてくださった当初の SE マネージャ、また、採用当初から退職時までワガママを聞いていただいた VP には感謝の言葉しかありません。



いまから一年ほど前、自分が扱っている商材はなんだろうかという、心の中での自問自答に一つの答えが得られました。

時は1990年前半、私が小学生のときまで遡ります。当時、私は父親の仕事用マシンである PC-9801VM2 を”乗っ取り”、そのマシンに乗っていた 2MB のバンクメモリに魅せられていました。

PC-9801VM は 16 ビットのコンピュータで、メモリのアドレスは合計 20 ビットの幅で、最大1MBのメモリ空間しかアドレッシングできない制約がありました。一般的に MS-DOS の 640KB の壁という制限です。当初は「640KB? いったいそんな大量のメモリ、一体何に使うんだよw」という会話が普通にありましたが、今となっては 640KB ごときでは本ブログ記事のレンダリングすら不可能なほどの、限られたキャパシティです。

当時のエンジニアもやはりメモリ不足を感じており、 Intel や Lotus などの企業が協力して EMS (Extended Memory System) という規格を作り出し、私が実家で弄っていたバンクメモリボードは EMS 標準化の過渡期にあった製品でした。

そのバンクメモリは衝撃的な経験でした。当時といえば不揮発層はフロッピーディスクがガシャガシャ音を立てて数秒後に漢字変換の候補があらわれ、ハードディスクといえども100ミリ秒単位のアクセス時間があったように思います。そのような中でほとんどI/Oの時間が感じられない「バンクメモリ上のRAMディスク」がやはり快適なしくみで、 2004 年の就職に際しての上京直前にバンクメモリカードを「あ、これは大事なものだから残しておこう」と箱にしまってきたのを今でも憶えています。

私が3年間(、ないしは1990年から)かけて得た答えは、コンピュータのシステムメモリに対して、追加のメモリ空間で容量をブーストをすれば、コンピュータが快適に利用できる、ということです。

MS-DOS 時代は 20ビットのアドレスバス制限のなかで 640KB を超えるメモリ空間の扱いに対して技術的なアプローチが採られました。対して Windows 95 から 32 ビットのオペレーティングシステムになり、現在のプロセッサは 48 ビットのアドレスバスで DRAM をアドレッシングできるため、バンクメモリのような発想は不要だと思われたのですが、しかし取扱データ量の増加に伴い、必ずしも DRAM で全てのデータをカバーできなくなりました。

私が 2011 年から扱っていたデバイスは、 640KB 制限時代のバンクメモリの生まれ変わりでした。フラッシュはストレージとして考えれば高いですが、しかしDRAMやSRAMと比べると恐ろしく安価です(散々”高い”と言われた取り扱い製品は、DIMMと比較すると、定価ベースで5〜6分の1のバイト単価で買えるのです)。この特性を活かして、コンピュータのアーキテクチャでメモリといえばDRAM、二次記憶といえばHDD、が常識になったときに、フラッシュによるメモリ階層の可能性を思い出させてくれたのが、自分が3年間関わったデバイスでした。ヘネパタを読んでも出てこない、今後は DRAM だけではなく容量重視のフラッシュを不揮発層を併用するコンピューティングの時代が訪れる足音を、私は聞いていたのです。

私のなかでは、この結論を得た段階でたぶん満足していたのだと思います。今後、わたしたちはどれだけ抵抗しようが、DRAM, Flash, 磁気メディアを組み合わせてシステムを構成せざるを得ない時代に突入しつつあります。現時点で私は MacBook Air, iPhone, iPad mini を持ち歩いていても全て不揮発層は Flash であり、私を含むユーザ層が Flash を搭載したデバイスでがんがんサーバに負荷をかければ円盤を回している余裕なんてあるわけがありません。 Flash が円盤を置き換えるのはもう完全に時間の問題で、プロセッサ、DRAM、その他I/Oデバイスと二次記憶、という50年来のコンピュータアーキテクチャが変わりはじめる瞬間に立ち会ってきたのだと思います。



なんとなく自分のなかで一つの満足に到ったわけですが、いまの自分は何をしたいんだろう、という問いに対して暫く悩んでいました。まだこの答えははっきりと出ていませんが、その一部は「これは面白い、やりたい!」という4年前の自分の”想い”です。嫁も彼女もナシで、ワンコのラピスも天に召され、守るものが何もない立場の特権かと思いますが :) 自分がやりたい事に時間を費やしてみたいという気持ちに正直になることにしました。

これまで10年間、SIおよびコンピュータ向けのハードウェアベンダ ——つまりはIT業界の仕事に関わらせていただきましたが、今は、自分自身が一番興味があるテクノロジーに自分の時間を費やしたいと思い、ITとはちょっと離れた某スタートアップのお手伝いをすることにしました。まだ自分がどのように貢献できるかわかりませんが、SI時代の経験、ハードウェアベンダ時代の経験を活かして、新しい技術の発展や普及に貢献できれば、と思っています。

この3年半は色々な方にお世話になりました。また、割と時期的に盛り上がっている会社でもあり、会社名や名刺のパワーで IT 業界のさまざまな方とご挨拶ができ、時には吞みながら意見を交わせさせていただき今に到っています。様々な刺激をありがとうございました。

中期的、長期的に自分がどのようなキャリアパスをとるのかはノーアイデア感半端ないのですが、暫くは、IT業界をひとつ離れたところから見つめながら自身がどのように貢献できるのかを模索し、コンピュータの世界を盛り上げられる一人になれる日を向かえられるようにしたいと思います。

p.s.
楽しいお誘いはいつでも大歓迎です。

2014年10月20日月曜日

オープンソースカンファレンス2014 東京・秋で利用したEject-io LTプレゼンテーション

週末に明星大学で開催された OSC2014 初日の懇親会で利用した Eject-io のプレゼンテーションをアップロードしました。

昨年末からのネタで大したアップデートはありませんが、今回はトーマスが走るデモを実装しまして、自作OS界を牽引するあのお方のお子様が魅入ってしまうなど、確実に業界に対してのインパクトは増しております。

Eject-io の詳細についてはこちら(過去のブログ記事)をご確認ください。

次世代I/Oインターフェイス「Eject-io」

なお当日は懇親会を途中で離脱することになったため、前倒しでLT枠をいただきました。ご配慮いただきました @akkiesoft さん、また LT に誘ってくださった @akkiesoft さん、そして Eject でインスパイアしてくれた @akkiesoft ありがとう!

2014年10月17日金曜日

Software Design 2014年11月号に「サーバの目利きになる方法 後編」を寄稿させていただきました。



前回はバタバタしておりブログで紹介するタイミングを逃していましたので、今回はタイムリーに。。。。

先月号に続き「サーバの目利きになる方法」として20ページの記事を掲載していただきました。内容は、これまでのネットワーク技術の変遷(10BASE-5以降)と主要ストレージなストレージ技術(特に今後の普及が確定的なフラッシュストレージ、およびRAID関連の基礎知識)、そしてオマケ程度ではありますがサーバの管理機能について紹介しています。

ネットワーク技術は学生時代(10年以上前)の知識で書いているところも多いですし、前号同様、知っている方にとっては何も新しい情報はないかもしれませんが、限られたページ数と時間の中で「自分が一緒に働くITインフラエンジニアがいたとしたら、その人に知っておいてほしいこと」を優先的に詰め込みました。

今回も、アプリケーションよりのエンジニアにはあまり知られていない話だと思いますし、興味がないところかもしれません。そんな中でも「へぇ」「なるほどね」と思ってもらえたら、またITインフラエンジニアの方にも何か発見があったり、より専門的な知識の獲得のきっかけになったら有難いです。

今回の記事は、私一人でやらせていただくよりも、ひとつひとつの分野についてより専門的知識を持った方で担当を別けたほうが魅力的な記事になったのでは、という思いもあります。とはいえ、SD編集長さまより全編任せていただいたので、自分の視点から見た世界を、自分のこれまでの体験を振り返りながらまとめました。

各分野のエキスパートによる記事をまとめたければ、そもそも私の所に執筆の話はきていなかったでしょう。また、色々と調べなおして勉強になったので、この機会には感謝しています。今年の冬に向けての軍資金も手に入ります:)


今回の記事はページ数に対してカバーしなければならないエリアがとても広かったので、前編・後編に渡って多くの方にアイデア提供、査読、アドバイス、ご協力をいただきました。ありがとうございました。

執筆期間中にご協力、フィードバックをいただいた方々

石井 宏和さま
板谷 郷司さま
伊藤 宏道さま(日本仮想化技術株式会社)
海老澤 健太郎さま(Riava, Inc)
桑野 章弘さま(株式会社サイバーエージェント)
佐野 裕章さま
須藤 武文さま(さくらインターネット株式会社)
田中 邦裕さま(さくらインターネット株式会社)
東根作 成英さま(レノボ エンタープライズ ソリューションズ株式会社)
宮本 久仁男さま

また、2号とも脱稿が遅れ、技術評論社の Software Design 編集部の方々にはご負担をおかけしました。本当にありがとうございました。