2013年3月31日 (日)

SL6.3+kernel 3.4でOpen vSwitchを動かす

KernelコードにマージされたOpen vSwitchを動作させた際のメモです。

Kernelのビルド。まず、オプションを有効にしてカーネルをつくります。Networking support>Networking option>Open vSwitchにチェックを入れビルドします。
これで出来上がるのはopenvswitch.koというローダブルモジュールだけなので出来上がったら、modules_installして、modprobe openvswitchしてもちゃんとうごきます。つまり、既存のbridgeと干渉したりはしません。
その代り、brcompatというモジュールはできません。
さて、モジュールを組み込んだだけでは使えません、制御するためのソフトはディストリビューション側で用意するものなのでしょうが、red hat系には既成のバイナリはないようです。
なので、ソースからこれらを作る必要があります。後々のメンテナンスを考え、サイトからダウンロードして、いったんrpmを作った後にインストールすることにします。今回は1.9を使いました。
アーカイブをダウンロードしたら展開して、rhelディレクトリにあるopenvswitch.specをとりだします。ソースアーカイブをrpmbuild/SOURCESに入れ、rpmbuildするのですが、openvswitch-kmod-rhel6がないと言ってエラーになります。上でも書きましたが、カーネルモジュールはすでにあって、このrpmは作る必要がないので、ここは削除します。
無事rpmができたら、yum localinstallでインストールします。
スイッチの設定を行うにはコントローラを動かす必要があるのでovsdb-toolを使って初期化します。この辺は本家のインストールガイドを始めあちこちに書かれているので割愛します。
dbができたらservice openvswitch startしてコントローラを立ち上げ、スイッチをコンフィグします。
前のエントリで書きましたが、すでにブリッジ構成なのでそれを手直ししてopenvswitchに移行するのを前提にスイッチを組みます。
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 wlan0
そして、/etc/sysconfig/network-scriptsのファイルを手直しします
ifcfg-br0
TYPE=Bridge > TYPE=ovsBridge
ifcfg-eth0
BRIDGE=br0 > コメントアウト
つまり、eth0,wlan0といったポートはコンフィグですでにつながっているのでifupする際にさらにブリッジに接続する必要はないのです。そして、br0インタフェースですが、TYPEにovsBridgeと指定するとbr0という仮想スイッチのbr0というポートにつながります。これで、bridge互換モジュールをがなくてもちゃんと従来のbridgeと同様に使えます。
準備ができたらservice network restartして、OKならchkconfig openvswitch onした後に再起動すると新環境で使う使うことができます。
めでたしめでたし。と思ったのですが、hostapdがちゃんと動かないようです。具体的には接続したあとすぐにパスワードを再要求されるようになってしまいます。
もしかしたら続編があるかもしれません。

2013年3月30日 (土)

Logitec W150N/U2がホストモードで動くまでの長い道のり(3)

さて、最後はhostapdです。

残念ながら、hostapdはScientific Linuxのリポジトリにはモジュールがありません。外部リポジトリにあるようなのですが、ソースがあるのは2.0でコンパイル済はatrpmsの0.5.8です。
どっちにしようか迷ったのですが、コンパイルすることにしました。
実はhostapdは今風の./configure一発なソフトではなくて、作るのは今日的な感覚でいうとかなり面倒な部類です
ここでもまた先人の知恵を借りてなんとかコンパイルし、モジュールを作ります。参照先にもありますが、依存するパッケージを持ってこないとエラーになります。特にlibnl-develは盛大にスクロールするのでうんざり気分になります。そうこうしつつコンパイルし、動かすと色々でてきます。
nl80211が使えないと言われたのでnetworking support>Wireless>nl80211 testmode commandを有効にしてカーネルのビルドを再度やったり。細々としたパラメータ調整をして、そして
country_code=JP

をconfigに入れるのをお忘れなく。

何とか起動できたら、先ほどのサイトからリンクしているサイトでhostapd用のiniスクリプトをもらってchkconfig --add hostapdすれば何とか出来上がりです。
とりあえずAndroidをつないでみてアプリの更新などをやった範囲では問題なく動いているようです。
しかし、150mbpsと書いてあるもののn技術(=n technology?)は802.11gらしい。いったいどれくらいスピードでるのやら。まぁ、どうすればいいかはわかったのでスピードが問題ならまたその時かんがえましょう。とりあえず今はWiMaxのルータから無線を切り離すのが優先事項なので。

Logitec W150N/U2がホストモードで動くまでの長い道のり(1)

ことの始まりはいつものように電気屋だった。近所の巨大電気店をフラフラ歩いていたらPCをスマホのアクセスポイントにして快適ネットワーク、という触れ込みの無線LANドングルが売られていた。お値段680円。裏を見るとホストモードもサポートしていると書かれている。

まぁ680円だし、ダメ元でLinuxに突っ込んで無線LAN APにしてみよう、と思ったのが長い戦いの始まりだった。
さて、まずこのドングルをUbuntuをインストールしたノートに差し込む。あっさり認識し、接続できる。Linuxってもう一部の特殊な人が使うものではないんだな、なんて感慨にふける。しかし、これが罠だとはまだ気が付いていない。
lsusbすると
Bus 001 Device 002: ID 0789:0168 Logitec Corp. LAN-W150N/U2 Wireless LAN Adapter
というIDが表示される。どうやらドライバはrt2800usbというものらしい。
さて、このままノートにさしておくわけにも行かないので本来APにしたいターゲットに刺す。ものはShuttle XS35、Atomベースの省スペースPCで中身はScientific Linux 6.3だ。
lsusbに刺すとIDは表示されるので認識しているようだが、うんともスンともいなわい。rt2800usbというドライバも影も形もない。とりあえずドライバを用意しなければいけないので情報収集。ralinkのrtシリーズはかつてstagingで存在したが今はmainlineにマージされている。ネットを漁ると両方の情報が入り混じって出てくるので混乱する。
今更stagingでもないのでmainlineのrt2800usbを使う方向で考えると、結局ソースからビルドするということになる。だったらもうちょっと新しいのにしたいね、ということで今回は思い切ってバージョンを上げ、Longtermの中では一番新しい3.4にすることにした。
3.4はOpen vSwitchがマージされているなどネットワークデバイスとして魅力が大きいこともバージョン更新の理由の一つ。
さて、kernel.orgからソースをダウンロードし、make oldconfig、make menuconfigをやって新しいカーネルをインストールする。
カーネルとドライバができた。modprobe rt2800usbするとちゃんとドライバは読み込まれる。だけどwlanは出てこない。ファームウェアなるものが要るらしい。先人の情報によればralinkのサイトからダウンロード、と書かれているけどそのサイトはすでになくて、別のサイトに飛ばされる。まぁ、ちょっと名前とか入れるフォームが出るけどなんとか入手できた。
実は、ここにも落とし穴がある。Ubuntuなどに添付されているファームウェアはホストモードにはならないらしい。確かに、バイナリダンプを見るとUbuntuのrt2870.binとサイトからダウンロードしたrt2870.binは別物だった。
さて、ファームも手に入った、けどやっぱりwlanは現れない。これまた先人の知恵によるとecho "ベンダid プロダクトid" > /sys/bus/usb/drivers/rt2800usb/new_idというおまじないが目に入る。なにこれ?公式ドライバなのにidを教えないと動かないの?(詳細は後でわかるんだけど)
とりあえずやれば動く。
実際はこのあとしばらくこの状態でhostapdとかセットアップしていたのですが、話のまとまりが悪いので種明かしをすると、rt2800usbを作るときにInclude support for unknown deviceにチェックを入れていなかったのがいけないのでした。
デバイスドライバは自分がサポートするidの一覧というものを持っていて、これはソースにハードコーディングされています。今回の場合、0789,168というのがそれにあたるのですが、このIDは
#ifdef CONFIG_RT2800USB_UNKNOWN
:
#endif
で囲まれた中に入っているグループで、上記のチェックを入れないとここがコンパイルされない、よってノードも作られない。というわけでした。そして、/etc/udev/ruls.dにルールを追加して、OSとデバイス関係はひとまずおしまい。

2011年4月24日 (日)

WiMAXモバイルルータ

以前、USBのアダプタを買ったことは書いたのですが、

昨日、ようやくルータを買いました。

IO-DATAのWMX-GW02Aというものです。

さて、このルータですが、はっきり言って使えないヤツです。

具体的には

  • なぜか、ルータにつなぐとWiMAXアダプタの感度が落ちる
  • 再接続が非常に遅い
  • DHCPがLANとWLANを共通でしかOn/Offできない

まず、感度ですが、PCにつなげば部屋の中でアンテナ2本、窓際で3本ですが、ルータにつなぐと窓際で1-2本、部屋の中だと圏外です。なぜ、この違いが出るのかよく分からないのですが、どうも、無線LANの電波と干渉している気がします。ルータのパッケージにUSB延長ケーブルが付いているのでそれを使ってできるだけ本体から離しているのですが。

そして、よく切れます。そのたびに再接続するのですが、プラウザで管理画面を開いていると、延々再接続しています。これらが複合しているのか、ルータにつないでダウンロードすると40KB/sくらいしか出ません。USBでPCにつないでいたときには400KB/sくらい出たように思うのですけど。

そして、DHCPですが、そもそも別のネットワークがある環境で使うことは想定していないのか、DHCPはOnとOffしかありません。できればアドレスの発行は今の環境を引き継ぎたいと思うのですが、DHCPを止めると、無線LAN側にアドレスが配られなくなってしまいます。

実は、白と黒のバリエーションがあったようです。白はDisconnなのですが、スペック的にはまったく同じものです。どうも不具合解消のために色違いを出したのではないかと勘繰ってしまいます。私が買ったのは黒ですが、それでもかなり使えないです。

ファームのアップデートが出ていて、変更内容は接続性の改善とあったのでアップグレードもやったのですが、気休め程度しかよくなっていないです。

どうやら、夏の停電はしない方針といってるようなので、使わなくて済むのかもしれませんが、ADSLを解約してこっちに移行というのはちょっと無理のようです。

2011年4月 3日 (日)

WiMaxを導入してみました

バタバタなどといいながら、WiMaxを導入しました。

理由はいくつかあるのですが、

  1. どうも、夏は大規模に停電しそう。今のADSLをバックアップするのもいいけど、どうせなら移動できるようにしたい。
  2. ADSL、そろそろ10年くらい使ってる。なんか、新しいのないの?という、単純な好奇心。
  3. 前に中華Padのところで書きましたが、中華Padで使えるんじゃない?という淡い期待

こういったものが入り混じって、WiMax導入の運びとなりました。NiftyでやってるサービスでIO-DataのUSBタイプの端末です。モバイルルータにしなかったのは、お届けが4月上旬以降というスケジュールだったのと、中華Padに使えるのではという淡い期待でUSBにしました。

で、中華Padで使えるか、ですが、残念ながら動きませんでした。最近のUSB端末は、ドライバやソフトのインストール用にストレージと通信アダプタが一体化した構造になっていて、Linuxから見るとストレージだけしか見えないという、まさにアレで使えません。

とりあえず、VistaのノートPCやら、Windows7のデスクトップでは普通に使えました。もうインストール用のストレージは見えなくていいので無効化できるかどうか試してみるのもいいかも、とは思うのですが、手をつけていません。

気になるスピードですが、400KB/sちょいは出ます。スループットならADSLも同じくらいなのですが、WiMaxはラウンドトリップが国内でも150msくらいあります。方やADSLは15msなので、ゲームだとか、そういう用途にはちょっと無理があるでしょう。試しにUOにつないでみたのですが、1秒程度固まることがたびたびあって、狩りができるとか、対人戦ができるといった状態ではないです。まぁ、マジンシアで種を植えられるらしいので、ひたすら種集めしていました。シビアでない用途ならそこそこ使えます。感度ですが、鉄筋コンクリートの部屋の中でも速度が落ちる感じはしません。机の下のUSBハブに差し込んだ状態でも400KB/sでます。さすがに部屋の隅のPCラックの陰では通信できませんでした。きっと、南に基地があって、南の大きく開いた窓から電波が入ってくるのでしょう。

1年縛りで月々3600円を現状上乗せで払い続けるのはちょっとつらいので、USBを差して使えるモバイルルータを常時使ってADSLは解約の方向で考えています。今のADSLはIPv6とか、面白そうなことはできないですし、WiMaxなら、停電してもバッテリで動作させるか、ノートに刺して使えばなんとかなるので。UOで対人しなければ特に問題はないです。

2011年1月18日 (火)

つくるJukebox(3)

少し前にやって、ショックのあまり記事をかけなかったのですが、

ようやく記事にする気力が整いました。

ええと、scsi-target-utilsのCDROMデバイスはaudioコマンドを扱えるというプロファイルをもっていません。どういうことかというと、ISO形式のデータROM専用ということです。Windowsだと、音楽CDはTOCを読んでWAVファイルがあるようにマウントできますが、tgtdにはというか、Linuxのドライバそのものにそういった機能が無いということです。

今のDVDドライブでcdparanoiaなどのツールを使えば音楽CDのイメージというものを作り出すことはできます。不思議に思ったので中を見たのですが、cdparanoiaもSCSI Generic Deviceにioctlで直接SCSIコマンドを発行しているようです。

カーネルのソースはまだ調べていないのですが、tgtdはDVDROMとDVD-plusのプロファイルしかサポートしていません。iso形式のバッキングストアが指定された場合はDVDROM、そうでない場合はDVD-plusとして動くように作られているようです。実際、音楽CDイメージをバッキングストアに指定したドライブをWindowsからiSCSIでマウントするとRWデバイスのように振舞います。確かに、実デバイスはメディアの種別を判定できるかもしれませんが、HDDのファイルからはメディア種別は取れないので、妥当な仕様なのでしょう。

ちょっと困ったことになってしまいました。自分でパッチ当てて、書き込み機能を捨てて音楽CD用プロファイルを返すように改造しようかとも思うのですが、Androidの相手で手一杯なので進められそうな状況にないです。そろそろCentOS6が出そうな状況でもあることですし、できれば今のFedoraをCentOSに入れ替えてからやることにします。

2011年1月10日 (月)

つくるJukebox(2)

前回作ったiSCSI Jukeboxですが、リブートしたら消えました。

信じられないのですが、tgtadmは入力されたコマンドを使ってターゲットをセットアップしますが、それはtgtdと通信してセットアップするのであって、ファイルのような永続的なものが残るわけではないのです。
なので、リブートすれば設定は消えてしまいます。

どうやら、設定を保存する目的のためにtarget-adminというコマンドがあって、これでxmlに書き出しなさいということのようなのですが、このコマンド、チェンジャ関連のパラメタは一切生成しません。どうやら、target-adminというのがscsi-target作成当初からあったもので、今はもうメンテナンスされていないというのが現実のようです。

それでも、ディストリビューションの設定としては、target-adminでxmlを作り、それを起動時に読み込ませるというのが本来の手続きのようです。なんか、この適当さにiSCSIがなぜここまで一般化しないか、その理由を見た気がしました。

まぁ、ガタガタ言っても仕方ないので、ブート時に必要なtgtadmをまとめて叩くように起動スクリプトを変更することにしましょう。チェンジャのスロット設定さえtgtadmなので、結構面倒ですが。

2011年1月 9日 (日)

KVMとAFT

KVM(というかXen)のimg形式のファイルをファイルシステムとしてマウントするには

ちょっとやってみたくて調べました。loopback mountするときにoffsetを指定すればいいそうです。

# mount -o loop,offset=32256 some.img /mnt

こうするとマウントできる、ということです。確かにマウントできるんですが、マウントポイントに見えるのは/bootの内容です。

つまり、imgファイルの内容はディスクのイメージそのままなので、ブートセクタなどを読み飛ばして、最初のパーティションが始まるのが32256バイト目ということです。

さて、32256バイト、ちょっと半端ですね。つまり、512バイトセクタが63個で32256バイトです。
勘のいい方は気づいたと思います。つまり、CHSトランスレーションは255トラック63セクタなので、で0シリンダの1トラックの最初のセクタが64番目のセクタ、つまり、32256バイト目です。

実際、イメージをfdiskで見ると

# fdisk go200.img

Command (m for help): p

Disk go200.img: 12.9 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders, total 25165824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bca53

    Device Boot      Start         End      Blocks   Id  System
go200.img1   *          63      512064      256001   83  Linux
go200.img2          512065    23060639    11274287+  83  Linux
go200.img3        23060640    25157789     1048575   82  Linux swap / Solaris

こんな結果が返ってきます。2番目のパーティションにアクセスしたければ、512065に512をかけて262177280をオフセットに指定すればマウントできます。

さて、さらに勘のいい人はもう気づいたかとおもいます。WDのディスクはAFTという仕様でできていて、ディスクの物理セクタは4096バイトです。そう、このimgファイルをAFTなディスクで使うと、やっぱり性能が劣化するのです。

AFTとは、つまり、見かけのセクタと実際のセクタサイズが違っていて、ディスクの入出力は4096バイト単位ですが、OSからの要求には512バイト単位で答えます。しかし、今日的なOSは4096バイトより小さい単位の入出力を行うことはないので、OSが要求する4096バイトのクラスタがHDDの物理セクタと一致している分には何の問題もありません。
では、違うとどうなるかというと、HDDは2つのセクタを読み出して、それぞれのセクタにまたがった入出力要求を実施して、命令がWriteなら2つのセクタを書き戻します。この動作が、性能が落ちるといわれる原因です。

じゃぁ、imgは全部だめかというと、どのインストーラを使ったかによります。

# fdisk test1.img

Command (m for help): p

Disk test1.img: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00075096

    Device Boot      Start         End      Blocks   Id  System
test1.img1   *        2048     1026047      512000   83  Linux
test1.img2         1026048    16777215     7875584   8e  Linux LVM

最初のimgはMeegoをインストールしたものですが、こちらはFedora14のimgです。これはちゃんと4k境界にそろえてパーティションが作られています。
そう、このimgをloopback mountするときにはoffsetの値もそのように指定しなければいけません。

Meegoネタは後のために取っておくとして、Meegoのような比較的新しいOSでもCHSトランスレーションそのままです。仮想計算機なので、別のimgをパーティション切って詰め直せばいいのですが。AFT、現状では使いこなすのは結構大変なようです。

2011年1月 8日 (土)

小ネタ:32bitOS用プログラムのコンパイル

某所でiscsi-initというプログラムを見つけました。

この詳細はまた別の機会に書くとしてmake時に引っかかったことについてのメモ。

このiscsi-init、つまりはinitrdの中で呼ぶとrootfsをマウントしてくれるというものなんですが、モノがモノだけに、スタティックリンクなわけです。さらに、自分が64bitOS使ってても、32bitモードで作るほうがいいよね、と思ったのですが、gccのくそ長いhelpからは見つけだせなかったのでwebを漁った内容。

つまり、-m32オプションをつけばいい。MakefileでCFLAGS=を指定するなら、LDFLAGSにも-m32が必要。そうしないと、64bit用のリンカが呼び出されて、オブジェクトの形式が不正といって怒られる。

だけど、リンクするにはライブラリが必要なので、glibc.i686が必要。スタティックリンクしたいならglibc-static.i686も必要

実は、meegoをネットブートにしたいと思って持ってきたのですが、meegoにはそもそもinitrdがありませんでした。高速化のために、実ディスクのinitを直接呼び出すらしいのです。
まぁ、もともとそうだったわけで、先祖帰りというのでしょう。

scsi-target-utilsとmtxで作る仮想CDライブラリ

最近は何でも仮想化するのがはやりで、仮想テープライブラリなどというものまであります。

つまりは、保存する記憶装置はディスクなのですが、インタフェースはテープのそれで、ロボットアームがテープを入れ替える操作もエミュレートして、ディスクの塊をテープライブラリのように見せかけるという装置です。

バックアップ用としては、テープをハンドリングするソフトは世代の管理に一日の長があるので、エンタープライズ向けにはこういうのもいいのでしょう。

個人的にはテープのライブラリには興味はないですが、家に溜まる一方のCDをなんとか仮想ライブラリ装置に入れたいなぁと日ごろから思っていたのでした。

実CDをそのまま掛けかえるジュークボックスもあるにはある(あった?)のですが、全部のCDをライブラリ化するとなると結構な台数が必要にってしまうくらいCDがあるので購入に踏み切ることはありませんでした。

しかし、最近のディスクの低価格化は恐ろしいものがあります。CD1枚が750MBくらいあったとしても、たった0.75GBでしかないわけです。2TBのHDDが8000円そこそこで買えるわけですから、2600枚以上をひとつの箱につめて、そのコストは1枚あたり数円です。

ずーーっと、仮想CDライブラリのソフト、ないかなぁと思って探していたのですが、なんと、身近なところにありました。

きっかけは別件でscsi-target-utilsのメーリングリストを漁っていたときに目に付いたのですが、つまりは、scsi-target-utilsのiSCSIドライバはライブラリのエミュレーションをすることができて、構成さえすればCDライブラリになるのです。ただし、あくまでもSCSI装置の真似をするので、もともとSCSIにできないことはできないという弱点がありますが。これについては後述。

まず、必要なのはscsi-target-utilsとmtx、それにテストするにはiscsi-target-utilsもとりあえずあったほうがいいでしょう。そうです、同じホストにiSCSIのターゲットとイニシエータをセットアップするのです。

さて、詳しい内容は/usr/share/doc/scsi-target-utils*/README.mmcをご覧ください。結構長いのでここに転記するのは止めます。

一連のコマンドを入れてターゲットをセットアップして、iscsiadmでdiscoveryしてloginすると/dev/sg?と/dev/sr?ができます。sgはSCSI genericの略で、テープでもディスクでもない装置はsdなりstというデバイスは作られないので、ロボットアームのような装置はこのsgを使ってアクセスします。sgは定義したLUNの数だけできるので、READMEのとおりにLUNを定義した場合、一番最後のsgデバイスがアームです。

イニシエータがloginした結果としてsr?も作られます。ここからジュークボックスのデータを読み出します。すでにCDが1台付いているPCならsr1が増えているはずです。

さて、適当なisoファイルを持ってきて、その名前をバーコードラベルの名前に指定します。
この、バーコードの内容がそのままディレクトリのファイル名として参照されます。
そして、mtxコマンドをつかってドライブにロードさせます。このmtxというのが、ロボットアームの操作コマンドです。
が、実際ロードさせると正しく認識できません。どうやら、バーコードは8文字でないといけないようです。確かにLTOのライブラリなども8文字でバーコードつけてますね。

しかし、今回作ったライブラリは1000スロットにしたので、8文字で中身を識別するのは非常に不便です。理論上の上限は全部のデバイスで65535。つまり、読み出し装置が10台くらあって、6万枚収容のチェンジャをつくることもできます。実際には、mtxが指定するのはバーコードではなくスロット番号なので、これを呼び出すフロントエンド側で、内容を説明する長い名前と、スロットの対応付けをするしかないでしょうね。でも、使いやすそうなフロントはまだ見つかってません。見方を替えれば、こんなに便利なジュークボックス機能がほとんど知られていないのは、この辺りの使いづらさによるのでしょう。iSCSIも一般になじみのあるものだとは言えないですし。

そんなこんなで1000スロットのCDジュークボックスにCDを突っ込んで実CDは倉庫にしまう計画が始動しました。
できれば、ジュークボックスはPCじゃなくて、NASのような装置にやってもらえるととってもうれしいなぁ。なんて夢を見ている今日このごろでした。実は昔使っていて今はほとんど使われていないHDL-GSがあって、そういうのをもっと活かせたらいいなぁと思ってます。(まぁ、このHDL-GSも、いったんディスク外してsshで入れるように中を書き換えてあったりするのですが)

より以前の記事一覧