10月 162015
 

FreebSD の ports-CURRENT を追いかけていると、時々はまります。今回は graphics/dri のコンパイルが通らないので、その回避策について書いておきます。

まぁ、こーいうネタは時間が経つと解決するので、エントリを書いてもあまり意味は無いとは思うのですけどね。

今どきですと /usr/ports/ 辺りで svn update を実行すると dri 周りは 10.6.9 になります。 libGL 周りなど mesa-10.6.9 を利用する ports は全部で六個くらいでしょうかね。

FreeBSD/amd64 ではコンパイルの途中で止まってしまいます。 FreeBSD/arm ではとあるライブラリがねーぜ。とか言われて configure 辺りで止まってしまいます。今回は両方のアーキテクチャの回避策について書いてみたいと思います。

 
o. FreeBSD/amd64
mesa-10.6.9 からなる dri 系の ports は llvm36+clan36 が必要になりました。関連性で devel/llvm36 と lang/clang36 がインストールされるのですが、こいつらのインストールがちゃんとできていても失敗しているような感じでコンパイルが途中で止まるようです。

以下のエントリで話し合われていて、既にクローズになっているようですね。

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203192

手順としては

# pkg delete -f llvm36-3.6.2_2
# pkg delete -f clang36-3.6.2
# rm -r /usr/local/llvm36/

 
してから再度インストールして、それから graphics/dri をコンパイルすると無事に通るようです。

どーしてこうなるんだろうなぁ? と、思うのですが、思い当たる点としては llvm35 既にインストールされている状態で llvm36 がインストールされて、『二個もいらねーじゃん。』とか思い llvm36 は残して llvm35 だけ削除したのですが、もしかしたらそれが原因かもしれません。

と、いうことで llvm* の痕跡を全て削除してから再インストールすると mesa-10.6.9 系の ports 一式がインストールされるようになります。

めでたしめでたしですね。

 
o. FreeBSD/arm
こちらのほうは、まず、上記の問題を解決し、llvm36+clang36 をサラな状態でインストールしてあっても、 make が通りません。

以下は graphics/dri を make したときのログですが、

# cd /usr/ports/graphics/dri/
# make
        :
checking for RADEON... no
configure: error: Package requirements (libdrm_radeon >= 2.4.56) were not met:

Package libdrm_radeon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libdrm_radeon.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libdrm_radeon', required by 'world', not found
        :

 
こちらについても以下の URL で既に問題提起されているのでその内に解決されるかと思いますが、どーしても最新版を使ってみたい方はコンパイルを通した packages を作ったのでダウンロードしてみてください。

https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg247413.html

この件の問題点としては FreeBSD/arm においては lib/libdrm_radeon.so がインストールされない点にあります。
では、そもそも lib/libdrm_radeon.so はどの ports がインストールするのだ? と、うことになるのですが、 graphics/libdrm でインストールされます。 Makefile を見てみると以下の部分になります。

.if ${ARCH} == amd64 || ${ARCH} == i386
PLIST_SUB+=     INTEL_DRIVER=""
PLIST_SUB+=     RADEON_DRIVERS=""
.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS=""
.else
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS="@comment "
.endif

 
FreeBSD/arm のアーキテクチャは armv6 なので .else のロジックを走り pkg-pllist を見ると INTEL 系と RADEON 系がインストールされないんですね。たけど、 FreeBSD/arm 上で graphics/dri をコンパイルしようとすると libdrm_radeon.pc がねーよ。って言われます。

なので上記の Makefile の部分を変更してあげる必要があります。雰囲気的には ia64 や powerpc などと同じ処理をして上げる必要があります。

.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64 || ${ARCH} == armv6

 
この一行だけ直してあげると libdrm_radeon 絡みのファイルが一式インストールされるようになります。

http://distfiles.icmpv6.org/distfiles/packages/All.armv6/libdrm-2.4.60,1_add_radeon.tbz

に上記の改修を入れて libdrm_radeon* がインストールされる packages を用意しておきました。最新版を利用してみたい方はご利用ください。

 
とわ言いつ、 FreeBSD/arm に radeon は必要ないので ports のメンテナは libdrm の ports を直すのか mesa-10.6.9 系の ports 一式を直すのか、わかりませんね。 mesa 系 ports を直すのは大変そうなので、多分 libdrm 系を直して libdrm_radeon 周りをドドドとインストールするようにするかもしれませんが。

実際に OpenCL とか利用できない Raspberry Pi 2 の FreeBSD/arm なのに、なんか冗長ぎみなインストールのような気がしないでもありませんが・・。

 
以上、今回は FreeBSD の ports-CURRENT で dri 周りの ports のコンパイルが通らない人用のてっぷすでした;-)。

8月 302015
 

と、いうことで、ちょっと前に掲載した「FreeBSD/arm のクロスコンパイル環境をもっと簡単に作る。」では ports のクロスコンパイル環境が整ったので、早速 X と xfce4 のコンパイルに挑んでみました。

Raspberry Pi 2 で X を動かすためにインストールした主なものは以下の通り。あ。 ports の枝番は削っています。

・xorg-7.7
・xfce-4.12
・emacs24-24.5
・zh-fcitx-4.2.8.6
・ibus-1.5.9
・ja-mozc-server-2.17.2106.102

X はウィンドマネージャも含めてフルスペックで、更に日本語入力もできないとダメだよね。と、いうことで ibus と fcitx と mozc までコンパイルしました。あと、xfce4 は Thunar をインストールし、デスクトップに必要なマルチメディア系のアプリまでインストールしています。
コンパイルした ports の総数は 大体 490 個くらいっ!! 自分でいうのもなんだけど、すげーすげー;-)。

ちなみに FreeBSD/arm は 8GB の MicroSD に Xorg と xfce4 をインストールして / パーティションは約 30% ほど消費しています。

クロスコンパイル環境では portmaster -D -a も動作するのでバージョンアップにも対応しています。コンパイルしたバイナリは以下の URL にあるので良かったら持って行ってください。

http://distfiles.icmpv6.org/packages/All.armv6/
ftp://ftp.icmpv6.org/packages/All.armv6/

今後、 ports-CURRENT を追いかけて行って portmaster -D -a してバージョンアップしたものもどんどん追加していく予定です。

 
さてと。先に ports/packages の内容を書いてみましたが、実際にクロスコンパイル環境でコンパイルしたので、そのことについてちょっと書いてみます。

 
1). クロスコンパイル環境の準備
以前のエントリで ports の ports-mgmt/poudriere-devel/ を試したと書いているのですが、そのとき

# poudriere jail -c -j CURRENT-armv6 -m svn -a arm.armv6 -v head

 
を実行したので FreeBSD/arm CURRENT の jail 環境ができてしまいました。これを tar で固めて、最速の仮想マシン上に持って行ってクロスコンパイル環境を構築しました。FreeBSD/amd64 10.1-RELEASE-p16 の環境に tar で固めた FreeBSD/arm 環境を展開し、前回記載した chroot 用スクリプトで環境を整えて、実際に ports の make install を行いました。

母艦の FreeBSD/amd64 10.1-RELEASE-p16 上に qemu をインストールして FreeBSD/arm CURRENT に chroot します。 /usr/ports は母艦側のディレクトリを mount_nullfs して利用し、ひたすら make という、以前書いたのを実際にやってみた。と、いうことですね。

環境の作り方は前回のエントリを参考にしてください。

 
2). chroot はネットワークが使えない
chroot した FreeBSD/arm の環境で ports を make しようとしても make fetch でエラーになりソースコードを取りに行ってくれません。
chroot した状態で ifconfig -a とか打つと解りますが qemu が Qemu unsupported ioctl などというメッセージを出します。と、いうことで chroot した環境ではネットワークは使えないと認識したほうが良いでしょう。

では、ports のソースコードはどうやって取りに行くかというと、母艦側で揃えるしかありません。そもそも /usr/ports/ は母艦側のディレクトリを FreeBSD/arm のディレクトリに mount_nullfs しているので見ているところは一緒です。

母艦側でコンパイルしたい ports で以下のコマンドを打ちます。以下は editors/emacs/ のコンパイルの例です。

# cd /usr/ports/editors/emacs
# make fetch-recursive

 
ports のコンパイルのオプションには fetch-recursive というのがあるんですね。依存関係でインストールされる ports も含めてソースコードをダウンロードして来てくれます。 make config-recursive ってのは依存関係にある全ての ports の make config を実行しますが、それと似たようなモノですね。それにしても嬉しい make のオプションです。

母艦側でソースコードがゲットできたら FreeBSD/arm 側で実際に ports の make に入ります。
以前のエントリでも書きましたが遅いのでひたすら待ちましょう・・。

 
2). クロスコンパイル環境でコンパイルできないモノがある
いやー。さすがに 490 個くらいコンパイルすると qemu+chroot の環境でコンパイルが通らない ports が何個かありました。以下はそのリストです。

・emacs-nox11-24.5,3
・emacs24-24.5_1,3
・jsoncpp-0.6.0.r2_2
・py27-cairo-1.10.0_2
・tdb-1.3.4,1
・talloc-2.1.2
・tevent-0.9.24
・ja-mozc-server-2.17.2106.102

有名どころでは emacs ・ mozc 辺りでしょうか。 samba 辺りで利用される t シリーズ(tdb ・ talloc ・ tevent)も make が通りませんでした。

原因としては chroot 下で動作している qemu が make の実行時に core dump してしまいます。なのでクロスコンパイル環境では make が通りませんでした。

上記の ports の場合、実機 (Raspberry Pi 2 上の FreeBSD/arm) では make が通ったので、実機で作成した packages をクロスコンパイル環境に pkg add してあげて make を続行します。

 
クロスコンパイル環境で make が通らなくても実機でコンパイルが完走すれば良いのですが、実機でもコンパイルが通らないものがありました。
lang/spidermonkey170 です。これは困った。 FreeBSD の ML でも話題に上がっているようです。

FreeBSD/amd64 では問題なくコンパイルが通るのに FreeBSD/arm では通らない。なんでやねん?! と、いうことで試行錯誤を重ねた結果 FreeBSD/arm でむりくりコンパイルを通しました。

以下、手順です。

o. FreeBSD/arm 側で以下のコマンドを実行

# cd /usr/ports/lang/spidermonkey170
# make configure

 
o. 母艦側で続けて実行

# cd /usr/ports/lang/spidermonkey170/work/mozjs17.0.0/js/src
# gmake clean
# configure

 
FreeBSD/arm で実行した make configure の結果を母艦側で全てぶっ飛ばしてソースに対して FreeBSD/amd64 側で configure を実行します;-)。
その後 FreeBSD/arm 側に戻って make install を実行すると無事に make が通ります。これで ports 自体はインストールできるので、まぁヨシとしておきましょう;-)。

あ。僕は mozjs17.0.0 ってのはどこで利用されているのか知らないので実際に正しい動作をしているのか、よく判りませんf(^^;;。

関連性でインストールされるので必要だからとりあえず ports でコンパイルを通すワザを発見した。と、いう感じですf(^^;;。

 
と、ここまで書いたと、いうか、コンパイルを通したのですが、その後、原因が判明したようですね。どうやら llvm のバグで ARM の場合に発生するようです。

FreeBSD では gcc を使うようにするとコンパイルが通るようですね。

再度書きますが、僕の make の方法は ports の関連性に必要な他のプログラムのコンパイルを進ませるためにむりくりの方法を編み出した。と、いうことにしておいてくださいf(^^;;。

http://comments.gmane.org/gmane.os.freebsd.devel.cvs.ports/349757

ちゅーこって FreeBSD/arm 用に gcc-4.8.5 を make しないと・・。 orz

 
とまぁ、こんな感じで地道に qemu+chroot の環境で ports をじっくりと make していきます。 490 個程度の ports をコンパイルするのに、途中で make fetch やコンパイルエラーで止まることもあるので、大体一週間程度でしょうかねぇ。 ひたすらがんばります。

 
3). Raspberry Pi 2 で X 起動
一通り packages 化された ports が出来上がったので全てを実機にインストールして実際に X を起動してみます。
今回、僕がチョイスしたバージョンは FreeBSD 11.0-CURRENT r286285 です。このバージョンの CURRENT は HDMI にディスプレーを接続するとフラッシュのようにブラックアウトする場合があるのでちょっと困りもの。 OS と、いうか CURRENT の問題なのか、ハードウェアの問題なのかは良く判りません。
あと、 r286285 は default の root のパスワードが設定してない!! ので シングルユーザに落として /etc/master.passwd の :*: の * を消してあげる必要があります。 orz
ちなみに r286893 では root のパスワードが設定してありました;-)。

 
さてと。気を取り直して ~/.xinitrc に xfce4 を起動するように記述して startx です。

おぉーーっ!!

IMG_2407_RPi2_FreeBSD_X_1

ディスプレーのすぐしたにあるのが Raspberry Pi 2 の FreeBSD で HDMI で表示しております。

xorg.conf のディスプレードライバには scfb を指定します。 ports 的には x11-drivers/xf86-video-scfb をインストールしてあげます。 vesa ではないです。

xfce4-terminal で文字を打つとぬるぬると動いていく感が良いですね。 NoAccel 感満載です;-)。

hald を動かすと USB のキーボード・マウスも無事に動作します。なので X の環境で利用する分には問題は無いですね。あとは細かいところの設定をしていくと xfce4 は無事に動作するようになるのではないでしょうか。

あ。mozc がどうも起動しないんですよね。 core dump する。まだ深くは追ってないのですが、環境整わせつつ、おいおい見ていきたいと思います。

多分 mozc_server を FreeBSD/arm でコンパイルして動かしたのは、僕が世界初ではないかなぁ;-)。

 
と、いうことで今回は ports のクロスコンパイル環境で make したものを利用して Raspberry Pi 2 上の FreeBSD/arm で X まで動かしてみました。

これでバリバリと Raspberry Pi 2 を利用するようになるかな? データセンタに行った時とかに NotePC の代わりに Raspberry Pi 2 を取り出してバリバリ仕事する。とか、良いかも;-)。

 
Raspberry Pi 2 に FreeBSD/arm インストールしたけど ports のコンパイルが大変なので断念している方、 packages を作ったので是非 X が起動するところを見てみてください。ただ、さすがに KDE4 を packages 化しようとは思わないですがf(^^;;。

僕はこのあと、どうしようかなぁ・・。

8月 172015
 

前回のエントリは「FreeBSD/arm の ports コンパイル環境の作成。」というヤツを書きました。

ports の ports-mgmt/poudriere-devel/ というのを利用すると FreeBSD/arm のクロスコンパイル環境ができますよ。っていうやつです。

しかし、環境構築が大変すぎる。もっと簡単にできないのか?などと思うわけですね。環境構築に時間が掛かり過ぎる点は以下の辺り。

・FreeBSD のソース一式を svnweb から取ってきて make buildworld する。
・ports ツリー一式を portsnap で取ってきてインストールする。

時間が掛かり過ぎるよー。ってんで、今回はもっとお気楽に環境を構築する案を思いつきました。

ports-mgmt/poudriere-devel/ は jail に FreeBSD/arm のバイナリの環境を構築して qemu でエミュレートして動作しているようです。そのためにソースコード取ってきたり ports ツリー取ってきたりしているんですが、既にあるものを使おう。ってのが今回の趣旨です。

 
1). 準備するモノ
まずは Raspberry Pi 2 に FreeBSD をインストールします。多分 CURRENT が良いのかもしれないです。
Raspberry Pi 2 用の img を用意して SD カードに dd したら、同じバージョンの FreeBSD/amd64 の iso イメージもダウンロードしてきて、仮想環境に FreeBSD/amd64 をインストールします。あ。実機にインストールしても全然良いんですけどね;-)。

僕の場合、は以下のような環境を作りました。

o. Raspberry Pi 2 の FreeBSD/arm

FreeBSD wanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 19:36:01 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2  arm

 
o. 仮想環境上の FreeBSD/amd64

FreeBSD nyanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 12:24:12 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

 
ちなみに、仮想環境上の FreeBSD/amd64 が母艦になります。ここで FreeBSD/arm の ports の make をする予定です。

この後、母艦側で ports の emulators/qemu-user-static/ をインストールします。

これで、ほぼ九割の環境が整いました;-)。

ports-mgmt/poudriere-devel/ とかインストールする必要はありません。 jail 環境用に make buldworld もする必要はありません。

と、いうことでここでだいたいの構成がわかってきたと思いますが;-)。

 
2). 環境構築
まず、 Raspberry Pi 2 側の FreeBSD/arm で nfsd を起動します。

以下は /etc/exports の設定内容。

/   -network 192.168.1.0 -mask 255.255.255.0 -maproot=root
/   -network 2001:470:fe36:1234::/64 -maproot=root

 
強引ですねぇ。 / を NFS mount するようにします;-)。
あ。/etc/rc.conf の設定は今回は書かないです。

 
続いて母艦側の FreeBSD/amd64 側で nfs client を有効にします。こちらも /etc/rc.conf の設定は書かないですが、大丈夫ですね?

あとは母艦側で mount_nfs を実行します。

# mount_nfs -o rw wanchan:/ /home/armv6

 
うひょー。これで ports-mgmt/poudriere-devel/ でいうところの jail 環境ができてしまいました。ちょっと強引ですが。しかし、 make buildworld したのと一緒の状態ですね;-)。

一個、そして一回だけ、以下のコマンドを打ちます。

# cp -pr /usr/local/bin/qemu-arm-static /home/armv6/usr/local/bin/

 
FreeBSD/arm 側の /usr/local/bin/ に FreeBSD/amd64 上でコンパイルした qemu-arm-static をコピーしてあげます。これで準備は全て整いました。

 
まぁ、FreeBSD/arm の環境一式は色々抜き出すことができます。例えばインストールの iso イメージを mount して抜き出すとか、 ports-mgmt/poudriere-devel/ をインストールしてできた jail 環境を tar で固めて持ってくるとかですね。

しかし、 make buildworld を走らせるのは辛すぎる・・。ってのが今回の根本にあります。
make buildworld するより OS 二つインストールしたほうが速くないかい? みたいな;-P。

 
3). 環境構築スクリプト
まずは下に起動用のサンプルを書きますね。

#!/bin/sh

HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin/:/usr/local/bin
export HOME PATH

export LC_CTYPE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

ARMV6DIR='/home/armv6'

kldload imgact_binmisc.ko

binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static" --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled

mount_nullfs -o rw /usr/ports ${ARMV6DIR}/usr/ports
#mount -t devfs devfs ${ARMV6DIR}/dev

chroot ${AMD64DIR}

 
解る人は何をしているか解ると思います。

jail 環境作るの大変なので直接 Raspberry Pi 2 の FreeBSD/arm の環境を利用してしまいます。
そして chroot しています。 jexec でなくとも chroot で十分なのでそうしているんですが。

ちと説明をすると、

kldload は自動的にしてくれると思います。

binmiscctl add armv6 の行は qemu を使うおまじないです。このコマンドを叩かないと chroot したときに /bin/tcsh えぐぜっくふぉーまっとえらー。とか言われます。

FreeBSD/arm 側に母艦の /usr/ports を mountしてあげます。これで portsnap で ports ツリー一式取ってくる必要がなくなります;-)。

mount -t devfs は多分必要ないと思います。 jail 環境の場合は必要なのですが、今回は nfs mount した環境なのですねぇ。

と、いうことで最後に chroot します。

うひひ。これで FreeBSD/amd64 上に FreeBSD/arm の環境が整いました。ports のコンパイルや(多分)カーネルのコンパイルなど、もう何でもできます;-)。

このスクリプトは別途置いといたのでダウンロードしてください。ブログだと binmiscctl add armv6 の行が全部表示できないので・・。

 
ちなみに FreeBSD/arm 側が CURRENT で母艦側が 10.1-RELEASE だったりすると ports のコンパイル時に uname -r のチェックでエラーになってしまいます。 chroot した FreeBSD/arm 側で uname -r すると母艦側のバージョン情報を返してしまいます。あたたた。なので、 FreeBSD/arm 側と母艦側では FreeBSD のバージョンを揃える必要があります。

が、uname には裏ワザがあるようで、

$ uname -r
10.1-RELEASE-p16
$ setenv UNAME_r 11.0-CURRENT
$ uname -r
11.0-CURRENT
$

 
おやおや。環境変数で uname -r が変更できるのね。と、いうこで母艦が 10.1-RELEASE-p16 で FreeBSD/arm 側は 11-CURRENT の状態で ports を make してみましたが ports のコンパイルが始まって configure の実行中に「存在しないシステムコール (core dumped)」などと言われてコンパイルが途中で止まってしまうのでありました。

ふむ。10.1-RELEASE から 11-CURRENT で機能が追加された分があったりして、その辺りが問題となってしまうのでしょうなぁ・・。まぁ、取り合えずはこの環境で利用するのはやめて、母艦側も FreeBSD/arm 側もバージョンは揃えた。と、いうことになります。

 
2015/08/18 加筆
母艦側の FreeBSD/amd64 と FreeBSD/arm 側でバージョンが違っていてもコンパイルできることが解りました。 母艦側の /usr/local/bin/qemu-arm-static と FreeBSD/arm 側のヤツを同じモノにすると無事に動作します。
母艦側の /usr/local/bin/qemu-arm-static は 10.1-RELEASE-p16 で make したモノ、 FreeBSD/arm 側のヤツは 11.0-CURRENT で make したモノ。と、いうふうに異なるバージョンで make したものがインストールされていると「存在しないシステムコール (core dumped)」と出て動作しません。
/usr/local/bin/qemu-arm-static は母艦側で make したものを FreeBSD/arm 側に cp してあげましょう。

 
4). 実際に使ってみると
ports の make は一応問題無しですね。母艦側で make install したやつは FreeBSD/arm で pkg info で見るとちゃんと見えます。 portmaster -D -a も無事に動きます。

しかし、遅い・・。今回の母艦側仮想マシンは CPU 4Core に 1GB のメモリを用意したのですが遅いです。
FreeBSD/arm を NFS しているし SD カード上に入っているのでディスクアクセスが遅いのかもしれません。

それにしても chroot した先で色々動かすと全て qemu がワンクッション入るのでそれが遅いのかもしれません。僕はまだ本格的に qemu を使ったことが無いのでアレですが、パフォーマンスチューニングすればもっと速くなるのかな?

28468 1 I  0:01.76 /usr/local/bin/qemu-arm-static /bin/tcsh -i
28672 1 S+ 0:00.83 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make install
28689 1 R+ 0:00.48 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make config

 
母艦側で ps -ax するとこんな感じで chroot 先の全てのプロセスが qemu 経由で動いております。

 
母艦側で ports のコンパイルとかすると、遅いけど律儀に進んでいきます。そのとき FreeBSD/arm 側では CPU ロードアベレージは低いままなので、頑張っているのは母艦側。と、いうことになり、遅いけど Raspberry Pi 2 は無傷な状態ですね。

 
とまぁ、こんな感じの FreeBSD/arm のクロスコンパイル環境なのですが、それにしても qemu が絡むと遅くてしょうがない(と、僕は思っているんだけど、本当に qemu が原因なのか、僕はまだ特定していません・・f(^^;;)。

その昔、 Linux で BB ルータ作っていたんですが、組み込み Linux の ARM のバイナリを i386 の Linux 母艦で作っていたときは qemu 使ってなくて、もっとサクサクとコンパイルができていたんだけど・・。
qemu を使わずに ports をコンパイルする方法をやっぱり見つけないとダメっぽい。ってのが、今回の結論でしょうかねぇ。

それにしても ports-mgmt/poudriere-devel/ で色々仕掛けが解ったので良かったです。そして、それを参考にして ports-mgmt/poudriere-devel/ を使わない、もっと楽したコンパイル環境構築がこうして解ったわけですしね。ネタになったかぁ? ;-)。

次回、qemu を使わない ports のコンパイル環境の構築について掲載できるか?! (多分無理;-)

実は某所で発表した FreeBSD/arm に関する資料があるのですが ports のコンパイル環境構築についても触れています。その時は qemu を使わずに頑張ったのですが、結局ダメでした。その資料を一応おいておきますね。

FreeBSD/arm Raspberry Pi 2 ModelB で動作確認

 
ちなみに文章は Microsoft Office2013 で作りましたが、資料の発表は okular (KDE 4 universal document viewer) で行いました。 calligrastage (KDE graphic art and office suite) では文章を作成するのに苦痛でして・・f(^^;;。
そして、okular は pptx をサクっと開けてしまうすぐれものです;-)。

8月 152015
 

ちょっと前に Raspberry Pi 2 を購入して、FreeBSD を動かした「Raspberry Pi2 で FreeBSD。」と、いうエントリを書きましたが、 FreeBSD/arm が動いておしまい。 ports のコンパイルは大変だぁ。などと書いていますが FreeBSD/amd64 で ports のクロスコンパイル環境が整ったのでちょっと書いてみたいと思います。

英語の文章はあちこちにあるようですね。あと、日本語のウェブもちらほらあるようです。

今回参考にさせてもらったのは以下の二つのサイトです。

http://www.textplain.net/tutorials/2015/cross-compiling-freebsd-ports-for-the-beaglebone-black/
http://www.dvatp.com/tech/armv6_freebsd_poudriere

このサイトを日本語化した。と、いうような感じでしょうかねf(^^;;。

で、結論から先に申しますと『クロスコンパイル環境で ports をコンパイルしても遅いよね。』ですX-(。 と、いうことで、ここから始まりです。

 
1). ports のインストール
母艦は FreeBSD/amd64 10.1-RELEASE です。ここに FreeBSD/arm CURRENT の ports コンパイル環境を構築します。カーネルの構築はしません。カーネルはブートイメージを利用します。

と、いうことで FreeBSD/amd64 や FreeBSD/i386 上で FreeBSD/arm の ports をコンパイルする環境を構築するには ports が用意されているんですね。それを利用します。

ports 的には ports-mgmt/poudriere-devel/ というのを利用します。こいつを make install すれば環境が整います;-)。ただ make config のオプションでは QEMNU を [X] する必要があります。
poudriere は jail と qemu の連合軍で FreeBSD/arm の packages を作るんですな。

無事にインストールできれば準備は完了。

 
2). poudriere の環境設定
ports から ports-mgmt/poudriere-devel/ をインストールしたら準備完了というのは大きな間違いでして、ここから長い道のりが待っております。orz
まず poudriere の設定フアイルとして /usr/local/etc/poudriere.conf というフアイルを用意してあげます。以下は僕が用意したそのファイルの中身です。

ZPOOL=zroot
ZROOTFS=/poudriere
FREEBSD_HOST=ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/
BASEFS=/usr/local/poudriere
SVN_HOST=svnweb.icmpv6.org
POUDRIERE_DATA=${BASEFS}/data
NOLINUX=yes
USE_COLORS=yes
PRESERVE_TIMESTAMP=yes
BUILDER_HOSTNAME=build
DISTFILES_CACHE=/usr/ports/distfiles

 
BASEFS= は環境を構築するディレクトリ。
SVN_HOST= は svnweb を指定します。おーーっとっ!! ここで登場だぁ;-)。
DISTFILES_CACHE= は ports のソース置き場ですね。

こんな感じでしょうか。

一個前のエントリで「svn:// に対応しました。」と、いうのを書いているのですが、 poudriere はソースコードを取りに行く時に port 3690 にアクセスします。 http:// で用意した svnweb にアクセスするとエラーになるんですね。なので、今回、僕は svnweb.icmpv6.org を svn:// 対応にした。と、いうことなんですけどもね。

と、いうことで config ファイルの準備が整いました。

 
3). qemu の設定と poudriere の実行
poudriere は qemu を利用しているので、先に qemu の設定を行います。

以下の呪文のようなコマンドを打つようです。あー。コマンドが突き抜けてしまっていますねf(^^;;。マウスでつかんだときに –set-enabled がついていれば OK 一番最後のオプションです。
このコマンドは QEMU に対するコマンドで、色々やるときに qemu-arm-static が呼ばれるようになります。

# binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static" --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled

 
これで準備は完了。続いて poudriere なコマンドを打ちます。

# poudriere jail -c -j CURRENT-armv6 -m svn -a arm.armv6 -v head

 
poudriere は合わせて jail 環境も構築するのですが、その時 CURRENT-armv6 が生成されます。任意の文字列で問題はありません。
アーキテクチャは arm.armv6 で、今回は CURRENT の環境を構築するので -v で head を指定しました。
10.1-RELEASE の環境を作りたい場合には release/10.1.0 とか指定します。 http://svnweb.icmpv6.org/base/release/ 配下にあるヤツを -v で指定します。 stable/10 とかでも良いと思います。

で、このコマンドを実行すると、なんとっ!! svnweb からソースコードを svn co して来ます。そして make buildworld が走りますっ!! 半日くらい放っときましょうかねf(^^;;。

あ。コンパイルが完了したファイルは母艦側の /usr/obj/arm.armv6/ に一式 obj ファイルが生成されます。

 
4). ports 環境の準備
上のコマンドが走っている最中でも ports の環境は生成できます。並行してやっても良いかも知れないですがディスクアクセスが大変なことになっているかも・・。仮想マシン上であると随分と遅くなります。

ports 環境を生成するためには以下のコマンドを打ちます。

# poudriere ports -c

 
こいつもまた冗長ぎみで、 portsnap とか動いて ports の環境一式持ってきて差分比較して展開するというだいそれたことをしてくれます。 orz
僕的には素直に母艦の /usr/ports を symlink もしくは mount_nullfs すれば済むじゃないかっ!! と思うんですけどもね。
けど、それをやってこの工程を省くと /usr/local/etc/poudriere.d/ports/default/mnt がねーぞ。ぼけっ!! などと怒られるのであります。 orz

と、いうことで、これで ports の環境が整いました。ここまででシーケンシャルにやると大体八時間位かかりますかねぇ。ひたすら待つことになります。

 
4). さて。いよいよ ports のコンパイルだっ!!
準備が整ったのでいよいよ ports の make をします。コマンドは二つ。

まずは make config に相当するコマンドになります。

# poudriere options -j CURRENT-armv6 dns/libidn

 
-j で jail の環境を指定します。その次にコンパイルしたい ports を指定します。今回は dns/libidn/ をコンパイルする予定です。
上記で make config 相当がはしります。あ。正確に言うと make config-recursive が走ります。関連性でインストールされる ports の全ての make config が走ってくれます。
続いていよいよコンパイル。

# poudriere bulk -j CURRENT-1armv6 dns/libidn
[00:00:00] ====>> Creating the reference jail... done
[00:01:04] ====>> Warning: !!! Jail is newer than host. (Jail: 1100078, Host: 1100077) !!!
[00:01:04] ====>> Warning: This is not supported.
[00:01:04] ====>> Warning: Host kernel must be same or newer than jail.
[00:01:04] ====>> Warning: Expect build failures.
[00:01:05] ====>> Mounting system devices for CURRENT-armv6-default
[00:01:05] ====>> Mounting ports/packages/distfiles
[00:01:05] ====>> Stashing existing package repository
[00:01:05] ====>> Mounting packages from: /usr/local/poudriere/data/packages/CURRENT-armv6-default
[00:01:05] ====>> Copying /var/db/ports from: /usr/local/etc/poudriere.d/CURRENT-armv6-options
[00:01:06] ====>> Raising MAX_EXECUTION_TIME and NOHANG_TIME for QEMU
[00:01:06] ====>> Starting jail CURRENT-armv6-default
[00:01:17] ====>> Logs: /usr/local/poudriere/data/logs/bulk/CURRENT-armv6-default/2015-08-14_12h50m22s
        :

 
こんな感じで始まります。

がっ!! しっかしっ!! 遅いっ!! japanese/nkf とかコンパイルしても全然遅い。ヘタしたら FreeBSD/arm 上で make install したほうが速いんじゃね?と思えるくらい遅くてうんざりです。 orz

あと、 DISTFILES_CACHE=/usr/ports/distfiles を指定しているんだけど、この中に無いヤツは勝手に取ってきてくれないようで、事前に入れておく必要があったりします。

思いの外使えない状態かなぁ・・。

 
5). 環境についての説明
poudriere は設定フアイルとして /usr/local/etc/poudriere.conf と /usr/local/etc/poudriere.d/ を利用します。 /usr/local/etc/poudriere.d/ のほうは下を覗くと色々あります。 jail 環境を作り直したい場合には jails/ ディレクトリをサクっと rm すれば良いです。あ。これはイリーガルなやり方で、上記の URL では以下のコマンドを打て。と、書いてありますね;-)。

# binmiscctl remove armv6

 
僕はこのコマンドは打ったことないです;-)。

 
実際にできた ports ですが、設定ファイルで指定した BASEFS=/usr/local/poudriere の中にできます。
/usr/local/poudriere/data/packages/CURRENT-armv6-default/.building/All/ の中とかですね。途中のディレクトリに All@ とか symlink されたものがあり、その中を見ても良いかと思われます。

poudriere ports -c で生成した ports ツリーは /usr/local/poudriere/ports/default/ にあります。僕は portsnap とか使ったことないので、このディレクトリで svn co 叩いても良いかと思われます。

# cd /usr/local/poudriere/ports/default/
# svn co http://svnweb.icmpv6.org/ports/head ./

 
これでいつも最新の ports-CURRENT が手に入る。しかし、その分コンパイルしないとダメですけどね・・。

 
5). ports 一括コンパイル
最後にですが、必要な ports 一括コンパイルの方法を書いておきます。

まず、ports の一覧が書かれているファイルを用意します。仮に /root/pkglist.txt としておきましょうかねぇ。

japanese/nkf
games/sl
misc/lv
japanese/w3m
editors/emacs-nox11

 
自分の FreeBSD/arm で動かしたい ports をドドドとリスト化すると良いですね。

その後まずは make config-recursive に相当する以下のコマンドを実行します。

# poudriere options -j CURRENT-armv6 -cf /root/pkglist.txt

 
上にも書きましたが、関連性を含めて make config を実行してくれます。それにしても /etc/make.config に相当する指定はできないのかなぁ? jail の中に用意すればよいのかな?

続いて make します。

# poudriere bulk -j CURRENT-armv6 -cf pkglist.txt

 
あとは時間が掛かるので寝てしまい、うまくいけば朝には完成している。と、いう感じでしょうか。

 
とまぁ、こんな感じで FreeBSD/amd64 上で FreeBSD/arm-CURRENT の ports が packages として構築できると思います。

それにしても遅いのでどうしようか悩み中なのですけど・・。

皆さんも時間があったら試してみてください。

8月 132015
 

以前のエントリで「SVN サーバを構築して FreeBSD のソースをミラーする。」と、いうのを書いたのですが、これはプロトコル的には http:// にしか対応していないんですね。svn co には http: とか https: で十分なのですが、そーではなく、ちゃんと port 3690 に対応したデーモンも起動してあげる必要がある。と、いうことですね。

と、いうことで今回は port 3690 で svn co できるようにします。

なお、 svn のミラーサイトの構築に付いては上の「SVN サーバを構築して FreeBSD のソースをミラーする。」をまず初めに読んでたください。その環境ができあがったあとの話として、今回のエントリとなります。

 
1), /etc/service の確認
default の FreeBSD の設定で入っているので、どーでも良い話なのですが、一応、以下のコマンドを叩いて確認します。

$ grep svn /etc/services
svn             3690/tcp   #Subversion
svn             3690/udp   #Subversion

 
大丈夫そうでしょうかね。

 
2), デーモンの設定
subversion をインストールすると svnserve というのが /usr/local/bin/svnserve としてインストールされています。こいつに -d オプションを指定してあげるとデーモンモードで起動して port 3690 に対してアクセスできるようになります。

/usr/local/etc/rc.d/svnserve と、いうファイルがあると思うので、そこの上の部分を持ってきて /etc/rc.conf に設定します。

僕の場合は以下のように指定しました。

svnserve_enable="YES"
svnserve_flags="-d --listen-port=3690 --listen-host 0.0.0.0"
svnserve_data="/home/svnweb"
svnserve_user="svn"
svnserve_group="svn"

 
svnserve_data で svn 用のディレクトリを指定します。
svnserve_user と svnserve_group の svn というのは存在していなかったのでユーザとグループを作成しました。

以上で設定は完了。あとは service svnserve start とすれば起動することでしょう。
telnet で port 3690 が開いているか確認します。

 
3), inetd での起動
svnserve は inetd 経由でも起動できるようです。 /etc/inetd.conf には以下の行を追加してみてください。

svn stream tcp nowait svn /usr/bin/svnserve svnserve -i
svn stream tcp6 nowait svn /usr/bin/svnserve svnserve -i

 
なんとっ!! svn は IPv6 には対応してないようで、実際には tcp6 という行は必要ないですね・・。orz
と、いうことで inetd を再起動して再度 telnet で port 3690 が開いているか確認します。
無事に接続できるようなのですが svn で取ってこようとするとエラーになるんですね。どうやら svnserve.conf という設定ファイルを用意すると、それを参照してくれるようなのですが FreeBSD の ports の devel/subversion は svnserve.conf を無視しているようです。

ports やソースコードを眺めたのですが conf/svnserve.conf というのが曖昧で、どこを指しているのか解らないんですね。あたた・・。

と、いうことで inetd モードは断念しました。

 
4), と、いうことで
デーモンモード起動して、とりあえずはヨシとしておきました。

今までは svn のミラーサイトは以下があったのですが、

http://svnweb.icmpv6.org/
http://svnwebv4.icmpv6.org/
https://svnweb.icmpv6.org/
https://svnwebv4.icmpv6.org/

これからはここに以下の URL も加わります;-)。

svn://svnweb.icmpv6.org/
svn://svnwebv4.icmpv6.org/

全部で三つのプロトコルに対応しました。ただし、 https の場合はヲレヲレ証明書なので、「証明書を無視する」オプションを有効にして利用して頂ければと思います;-)。

 
さてと。どうして svn:// に対応するようにしたか? というと、このあと書くであろうと思われるエントリで利用して行きたいと思います;-)。

7月 082015
 

今回は Zeroconf (zero-configuration networking) について考察してみたいと思います。と、言っても OS X でのお話ではなく FreeBSD でのお話になります。

そもそも Zeroconf とは Apple が考えたプロトコルで OS X に実装されました。どうして『ゼロコンフと言うのだ?』と言えば『一個も設定しなくてもネットワークが色々使えるようになるからだ。』ということらしいのですが、詳しいことについては Apple のドキュメントや(多分あると思うけど) Wiki などを見てください。

今回は FreeBSD で利用する Zoroconf についてのお話です。

なお、文中「mdns」などと書かれている部分がありますが Zeroconf のプログラムが起動してマルチキャスト DNS を受信するモノという認識でお願いします。特定のアプリケーションやデーモンではありません。

僕の知っている(利用している)かぎり Zeroconf の実装は二つあります。 ports 的には

net/mDNSResponder/
net/avahi-app/

ですね。今回はこの二つを比べながら見ていきたいと思います。

 
1). どちらを利用するか?
mDNSResponder も Avahi も Zeroconf の実装なので基本的にやっていることはどちらも一緒です。ただ、 net/mDNSResponder/ のほうが軽量で ports からインストールする分には関連性でインストールされるモノが少なくて済みます。

かたや net/avahi-app/ は dbus や glib などを巻き込んでのインストールとなるので結構大げさになってきます。なので、デスクトップで利用している PC では net/avahi-app/ を、サーバなどで動作させたい場合には net/mDNSResponder/ をインストールするのが良いかと思われます。

例えば最近の net/samba41/ や net/samba42/ の場合は Zeroconf にどちらかを指定できるようになりました。 サーバの場合には mDNSResponder を、 KDE4 などのデスクトップを利用している場合には Avahi を利用するのが良いでしょう。

ちなみに両方インストールして両方起動すると「似たようなのが既に動いているよん。」などと syslog に出力されます。

 
2). インストールについて
実際にコテコテに利用する場合にインストールするモノについて説明します。

・mDNSResponder
以下の ports をインストールするのが良いと思います。

# cd /usr/ports/net/mDNSResponder/
# make install
# cd /usr/ports/dns/mDNSResponder_nss/
# make install
# cd /usr/ports/net/howl/
# make install

 
合計三つの ports をインストールします。インストールされるモノが比較的少ないので助かります。 FreeBSD/arm などではこっちのほうが良いですね。

・Avahi
こいつは関連性でドドドと『こんなん要らんっ!!』と、いうモノまでインストールしてしまいます。デスクトップ環境でインストールするのにおすすめです。

# cd /usr/ports/net/avahi-app/
# make install
# cd /usr/ports/dns/nss_mdns/
# make install

 
こうしてみると net/avahi-app/ のほうが楽そうに見えますけどね;-)。 しかし、サーバに cairo とか要らんし・・。

net/avahi-app/ は net/howl/ に相当する部分を内包しています。 libhowl.so などは net/avahi-app/ をインストールすると入ります。 net/mDNSResponder/ をインストールする場合には個別に net/howl/ をインストールする必要があります。

 
3). 設定
何はなくとも OS X のように ping hostname.local とか打ってみたいですよね。その場合は /etc/nsswitch.conf に以下の設定を行います。「クライアント側の設定」という位置づけでしょうかね。

 :
hosts: files mdns dns
 :

 
hosts: の行は標準であれば /etc/hosts を参照するための “files” と named を参照するための “dns” が書かれていると思います。ここに mdns を参照するための “mdns” を追加します。上記設定では “dns” よりも先に “mdns” を参照することになります。

 
続いて mDNSResponder や Avahi のサーバ側の設定をしていきます。

がっ!!『をいをい。ぜろこんふ ってのは設定無しで利用できるんだろう? どうして設定するんだぁ?』などと思います。『全然ぜろこんふじゃねーじゃんっ!!』みたいな・・。
しかし mDNSResponder のほうは本当に “ぜろこんふ” です。設定する必要はありません。さすがは Apple 謹製;-)。とわ言いつつ、実際は設定できるんですけどね。あとで、その設定方法について書きます。

Avahi のほうは /usr/local/etc/avahi/avahi-daemon.conf をちょっとだけ変更します。以下は設定変更の例です。

[server]
host-name=wanchan
domain-name=local
browse-domains=running-dog.net, icmpv6.org
use-ipv4=yes
use-ipv6=yes
allow-interfaces=bge0
deny-interfaces=re0
 :

 
これくらいで良いでしょうかねぇ。 host-name= domain-name= browse-domains= はまぁ、お約束で書いていきます。 IPv6 を利用している人は use-ipv6=yes にしてと。

あと、 mdns はマルチキャスト DNS (port:5353 の UDP) を流すので PC に NIC が複数ある場合にはどこのインターフェースにマルチキャストを流すのか許可・拒否設定ができます。

これらの設定が終わったら起動します;-)。一応 /etc/rc.conf の設定などを。これは FreeBSD の設定なので “ぜろこんふの設定” とは関係ない;-)。

・mDNSResponder

mdnsd_enable="YES"
mdnsresponder_enable="YES"

 
・Avahi

avahi_daemon_enable="YES"
avahi_dnsconfd_enable="YES"

 
あとは起動して完了です。

 
4). 確認方法
確認方法についてですが、以前「iOS4.2・AirPrint で体験する avahi。」というエントリで Avahi に付いては書いています。なので、この項は先に Avahi のほうから書きましょう;-)。

・Avahi

 $ avahi-browse -art

 
このコマンドを叩くと mdns が動作していて、提供されているサービスの一覧やホスト名が表示されます。

Avahi の場合には /usr/local/etc/avahi/services/ に ssh.service と sftp-ssh.service があるのでそれらのサービスが _ssh._tcp とか _sftp-ssh._tcp で見えますね。 このディレクトリに XML 形式の設定ファイルを突っ込むと他のサービスも見えるようにすることができます。 PDF プリンタとかですね。

一方 mDNSResponder のほうはそれらのサービスが登録されてないので上記コマンドでも見えません。

例えば net/samba42/ をインストールして make config のオプションのところで Zeroconf に mDNSResponder を指定した場合は _smb._tcp というサービスが見えるので、一応、正常に動いていることは確認できると思います。

 
と、ここで話は前後して申し訳ないですが mDNSResponder の設定について書きます。 Avahi みたいに _ssh._tcp. と _sftp-ssh._tcp. は表示してもらいたいぜぃ。と、いうことで設定ファイルを一個書いてみます。
例えば /usr/local/etc/Bonjour.conf というファイルを用意します。記載する内容は以下の要領で。

wanko
_ssh._tcp. local
22
wanko ssh server

wanko
_sftp-ssh._tcp. local
22
wanko sftp server

 
一行目は name=[] に相当します。今回はホスト名を書きました。
二行目はサービス。 Avahi と一緒にしてみましょう;-)。
三行目はそのサービスのポート番号。
四行目は説明文。TXT=[] で利用されますが、好きな文字列をどうぞ。

になります。他にもどんどんサービスを追加できます。 _smb.tcp. とかもね。けど、既に net/samba42/ で利用しているので書く必要は無いです。逆に net/samba42/ で Zerobof をリンクせず、このファイルに書いても良いわけですね。
けど、どうせ mDNSResponder をインストールするのであれば samba にリンクしたほうが良いような気はしないでもないです;-)。

設定ファイルが出来上がったら /usr/local/bin/mDNSResponderPosix に食わせます。 起動用スクリプトとして /usr/local/etc/rc.d/mdnsresponderposix というのがあるのですが、こいつはオプションにファイルを指定できないので以下のように改修します。

#!/bin/sh
 :
(略)
 :
load_rc_config $name

: ${mdnsresponderposix_enable="NO"}
: ${mdnsresponderposix_pidfile="/var/run/${name}.pid"}
: ${mdnsresponderposix_flags=""}

command="/usr/local/bin/mDNSResponderPosix"
command_args="-b -P ${mdnsresponderposix_pidfile}"

run_rc_command $*

 
mdnsresponderposix_flags を新規に定義しました。あとは /etc/rc.conf に以下のように書きます。

mdnsd_enable="YES"
mdnsresponder_enable="YES"
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-f /usr/local/etc/Bonjour.conf"

 
これで起動しますが mDNSResponder のプロセスは全部で三つ起動することになりました。あとは別の PC 上の avahi-browse コマンドで届いた情報を確認すれば良いですね;-)。

 
さてと。ここで話をもどしてと;-)。

Avahi の場合は他にもコマンドが色々あるので試してみると良いです。例えば DHCP で動作している PC があったとして、ホスト名は解るが IP アドレスが解らない場合は

$ avahi-resolve-host-name wanchan.local
wanchan.local  192.168.1.153

 
が有用です。 cat /var/db/dhcpd.leases しなくても IP アドレスが確認できるようになります;-)。 あ。 avahi-resolve-host-name -6 ってオプションもあるのでご安心を;-)。
Avahi の場合はコマンドラインインターフェースの他に GUI の ports もあるので色々試してみるのも良いかもしれません。

・mDNSResponder
mDNSResponder の場合は利用できるコマンドがあまりないんですよねぇ・・。まずは mDNSIdentify というコマンドです。

$ mDNSIdentify wanko.local
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
gonta.local. AAAA 2021:1470:FFFF:FEE1:0000:0000:0000:0001
gonta.local. Addr 192.168.1.129
gonta.local. AAAA 2021:1470:FFFF:FEE1:0201:0BFF:1110:2C98
HINFO Hardware: AMD64
HINFO Software: FREEBSD
mDNS_PurgeCacheResourceRecord: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
mDNS_PurgeCacheResourceRecord: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
mDNS_PurgeCacheResourceRecord: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
mDNS_PurgeCacheResourceRecord: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
No response after 4 seconds
_services._dns-sd._udp.local. PTR Trying multicast
No response after 4 seconds
_services._dns-sd._udp.local. PTR *** No Answer ***

 
ホスト名が解るとそれをオプションに指定すると情報が表示されます。なんかエラーになっているところもありますけどねf(^^;;。

もう一個。実行形式は記載しませんが mDNSNetMonitor というコマンド。

これを実行しておいて、別の PC から avahi-browse -art を叩くとドドドと表示されます。また Mac は定期的にマルチキャスト送ってくるのね。など、パケットキャプチャ的に利用できます。

 
とまぁ、基本的にはこんな感じで。
利用する側は /etc/nsswitch.conf の hosts: 行に mdns と指定するために マルチキャスト DNS 用の nss 系の ports をインストールする必要があります。

あとは上にも書いた通り DHCP で利用している PC や IoT 機器の探査などに利用することも可能です。

 
ユーザに見える部分としてはこんな感じでしょうか。あとは Mac などの OS や KDE4 などの統合デスクトップ環境に組み込まれている場合、アプリ側で良きに計らってくると思います。例えば Finder (OS X のファイルマネージャ) や dolphin (KDE4 のファイルマネージャ) などではルチキャスト DNS でホスト情報を収集し左側のメニューに表示してくれたりとか、 _ipp._tcp に対応しているプリンタを発見してくれるとか。

そー言えば以前 Windows7 を利用しているときはわざと Apple の Bonjour をインストールしていたなぁ。プリンタの探査が早くなるので。

と、いうことでそーいう感じで Zoroconf の実装を利用するのも良いかと思われます。

 
最近の Raspberry Pi2 の OS なんかは『一番最初にウェブにアクセスする場合には hoge.local でアクセスしろ。』みたいに書かれているモノがあったりするのですが、それって、アクセスする側は mdns が動いてないとダメじゃん。となるのであります。
最近の Linux (ubuntu かな?) は default で mdns が動いているのかな? そー考えると FreeBSD でも稼働しているものは mdns を動かしておいたほうが良いのかもしれないですね。

 
内容的にはまだ浅いのかも知れませんが、今回はこんなところでおしまいにしましょうf(^^;;。

 
2015/07/09 加筆
mDNSResponderPosix って core dump するじゃん・・。orz FreeBSD/amd64 や FreeBSD/arm で core dump する。場所は libc の中で。しかし、ちゃんと動作する場合や環境もあるので何が悪いのか、解らない。 orz

mDNSResponderPosix は -f でファイル名を指定できるし、 -n からドドドと他にオプションも指定できます。

 # mDNSResponderPosix -name wanchan  -t _ssh._tcp -p 22

 
と、いう起動の方法もありますが、サービスが一個しか指定できない・・。
しかし、この場合も core dump する場合があります・・。orz

 
と、いうことで素直に mDNSResponder を使ってみましょう。こいつも -f で設定ファイルを指定することができます。その設定ファイルの中身は以下のような感じです。

wanchan        _ssh._tcp.      local   22
wanchan        _sftp-ssh._tcp. local   22

 
これで OK。 mDNSResponder はマルチキャスト DNS を流すインターフェースも指定できるようです。それらを合わせた起動オプションは以下で良いかな。

# mDNSResponder -i bge0 -f /usr/local/etc/mDNSResponder.conf

 
これで Avahi で設定した動作と同じことができるようになったはずです。 mDNSResponderPosix の設定ファイルの記述方法よりも mDNSResponder の設定ファイルの記述のほうが直感的ですよね;-)。

 
せっかくなので mDNSResponder を利用した場合の avahi-browse -art に相当する(かもしれない)確認方法についてちょっと書いておきます。 dns-sd というコマンドを利用します。 -B がそれに近いでしょうかね。

$ dns-sd -B _ssh
Browsing for _ssh._tcp
DATE: ---Thu 12 Jul 2025---
22:44:14.360  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
22:88:14.301  Add        2   1 local.               _ssh._tcp.           wanton
22:88:14.419  Add        2   2 local.               _ssh._tcp.           wanko
22:88:14.588  Add        3   1 local.               _ssh._tcp.           wantaro

 
オプション無しで dns-sd を叩くとコマンドオプションが表示されます。 -B で Browse 機能。ただオプションにサービス名を指定する必要がありますが。
他に dns-sd -G オプションも役に立つかも知れません。

 
と、いうことで、これが、僕の知っている Zeroconf のほぼ全てです。

Zeroconf の設定ができると bind9 の name.conf で色々設定する view “internal” { } って要らねんじゃね? などと思えてきました。まぁ、全部の PC や端末が Zeroconf をしゃべれるわけでは無いのですけどね。
しかし、今回はデスクトップ機もサーバも Zeroconf がしゃべれるようになったので中々良い感じです。
あ。当然 mDNSResponder と Avahi 間でも通信は行えるのでどちらをチョイスしても全然問題ありません。

皆さんも自宅もしくは職場・データセンタのネットワークにマルチキャスト流してみませんか? ;-)。

3月 162015
 

さくらインターネットが「さくらのレンタルサーバ」を契約している人を対象として iPhone・Android アプリである「さくらぼけっと」を提供し始めました。

プレスリリースはこちら

「さくらの VPS」ではなく「さくらのレンタルサーバ」であるところがミソか;-)。ちなみに僕はもう随分と長いこと「さくらのレンタルサーバ」を契約しているので今回の「さくらぼけっと」が利用可能な人です。
「さくらのレンタルサーバ」は 100GByte の HDD 容量が利用できますが、ウェブコンテンツと各種ログやメールなどでも 100GByte というのは到底使い切れる容量ではないのですねぇ。
今回のアプリはそんな状況においては渡りに船。と、いうことで早速 iOS 版と Android 版をダウンロードして実際に利用してみました。

IMG_1058_sakura_pocket_1

今回はコテコテの FreeBSD ユーザ的な「さくらぼけっと」の使い方についてそこはかとなく書いてみます。

 
1). スマートフォン用アプリの利用
iOS 版も Android 版もログイン用ドメインとパスワードを利用することにより利用可能な状態となります。
写真のアップロードとダウンロードなど、スマートフォンユーザの利用形態としては特に問題は無く、フツーに動作すると思います。

ただ、気になるのが一点。Wi-Fi ではログインできるんだけど、携帯電波ではログインできないことがありました。 どうしてログインできないのか表示してくれないのが悲しいところか。もしかしたらコンテンツの .htaccess の “deny from all” の行でも見ているのか? とか思えるんだけどどうなんだろう?

 
2). ssh して ls してみたらっ。ん!?
スマートフォンでしかアクセスしないのであれば全然問題ないんだけど、そもそも「さくらのレンタルサーバ」は ssh が利用できるし scp も利用できる。普段から FreeBSD を利用している人は scp で Microsoft Office Word の文書をサーバ上にアップして さくらぼけっと アプリ経由でアクセスし、その後 Word で開いたらいんじゃね? とか、パっと思うので、勢いそのままに実際に試してみました。

あいや・・。 orz

日本語は文字化けして全然ダメじゃん。状態。どーして文字化けが起きるのだっ!! 早速調査開始です。

あ。さくらぼけっと アプリは ~/sakura_pocket/ に対してアクセスしますね。この中で色々やるのが良いかと思われます。

 
3). アプリの文字コードと端末の文字コード
「さくらのレンタルサーバ」では僕は ssh したときには tcsh を利用していて文字コードは UTF-8 を利用しています。以下は ~/.tcshrc の抜粋です。手元で利用している FreeBSD でも同じ設定をしているので、僕の環境は全ての OS においては既に UTF-8 になっています。

# SETENV Japanese
setenv LC_TIME C
setenv LANG     ja_JP.UTF-8
setenv LC_CTYPE ja_JP.UTF-8

 
通常、この状態で日本語名がついたファイルを scp すると、無事に保存できて「さくらのレンタルサーバ」上で ls するとちゃんと表示できます。
あ、利用している端末(ターミナルソフト)は xfce4-terminal だったり konsole だったり OSX の iTerm だったりしますが、全て UTF-8 です。

しかし、さくらぽけっと アプリからアクセスすると文字化けするし、さくらぽけっと アプリで作成した日本語ディレクトリは ssh で ls すると文字化けしていて ???? となる。どうやらファイル名の日本語文字コードが合ってないようですねぇ。と、いうことで色々調べ出しました。

 
4). 文字コードの確認
まず、判りやすいこととして さくらぽけっと アプリからアクセスして “あ” というディレクトリを作成します。そして、そのときの状況を ssh して調べてみます。

$ ls -1
??/

 
ふむ。見事に文字化だ。ちなみに ssh で “い” というディレクトリを作って確認してみると以下のようになります。

$ mkdir い
$ ls -1
??/
い/

 
ふむー。困った。それにしても さくらぽけっと アプリが吐き出す文字コードは一体何なのだ? と、いうことで hexdump というコマンドで調べてみます。

$ ls -1 | hexdump -C
00000000  a4 a2 2f 0a e3 81 84 2f  0a                       |../..../.|
00000009

 
ふむ。 a4a22f0a とかいう文字コードが並んでいますね。

文字コードをちょっと確認してみると・・。

文字 UTF-8 UTF-16 S-JIS EUC-JP JIS
E38182 3042 82A0 A4A2 2422
E38184 3044 82A2 A4A4 2424

 
ふむー。これを見ると、 さくらぽけっと アプリが吐き出す文字コードは EUC-JP のようです。これまた随分と前時代的な文字コードを利用しているようですねぇ・・。
ls -1 | nkf -w8 するとちゃんと表示してくれるので何かしらの文字コードなのは解るんだけど、しかし「文字コードは何を利用しているの?」状態に陥るのであります。

と、いうことでどうやら EUC-JP を利用しているらしい。と、いうことが解りました。

 
5). アプリから見えるようにする。
と、いうことで話はそろそろ佳境です。普段から UTF-8 で生活している人が持っている日本語ファイル名を持つファイルの文字コードは UTF-8 になります。 UTF-8 でも BOM あり/なしなど話がややこしくなるのですが、話によると、ふつー、アプリなどで利用する文字コードは UTF-8-BOM らしいのですけどね。でもって FreeBSD で LANG=ja_JP.UTF-8 を設定していると UTF-8 BOM 無し になります。

しかしまぁ EUC-JP とわかれば、あとはなんとかなるでしょう。

まずは convmv というのをインストールします。 ports 的には converters/convmv になります。これを手元の FreeBSD で make install します。インストールされた convmv コマンドはライブラリは特にリンクされていないようなので、アーキテクチャが合えばそのまま「さくらのレンタルサーバ」に scp して利用可能です。僕は FreeBSD/amd64 10.1-RELEASE 上で make したものを「さくらのレンタルサーバ」に持って行ったら無事に動作しました。
ASP キャリアと同じ OS を利用しているとこーいうことができるので嬉しいですね;-)。

ちなみに「さくらのレンタルサーバ」には nkf はありますが convmv はありませんでした。 nkf だと以下のコマンドでファイル名の文字コードを変えてくれるみたいなんだけど、今回はうまく動きませんでした。

$ nkf --overwrite --oc=EUC-JP い

 
と、いうことで convmv を実際に利用してみます。「さくらのレンタルサーバ」に ssh でログインしてディレクトリを一個作ります。その作ったディレクトリは さくらぽけっと アプリでは文字化けしてディレクトリとして認識されています。

$ mkdir  い
$ ls -1
??/
い/
$ convmv -r -f utf-8 -t euc-jp い --notest
mv "./い"      "./??"
Ready!
$ ls -1
??/
??/

 
ファイル名の文字コードが UTF-8 のモノを作成し、それを EUC-JP に変換します。ターミナルの表示的には文字化けしてますが さくらぽけっと アプリから参照すると無事に見えるようになると思います。

と、いうことでスクリプトを書いてみました。

#!/bin/sh

export LC_CTYPE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

case $1 in
'-s' )
    convmv -f euc-jp -t utf8 * --notest
    ;;
'-p' )
    convmv -t euc-jp -f utf8 * --notest
    ;;
* )
    echo "usage : encChange.sh {-s|-p}"
    echo "           -s : ssh mode"
    echo "           -p : Pocket mode"
    ;;
esac

 
-s オプションは ssh モード。ssh でログインしたときにファイルを操作したい場合に -s オプションを付けて UTF-8 なファイル名にします。
-p は さくらぽけっと モード。 ssh での作業が完了したあと、さくらぽけっと アプリからアクセスするときに文字コードを変換します。
あ。僕は convmv は ~/bin/ に置いて PATH を張っています;-)。

 
ふぅ。今回やりたかったのはまさしくこれで、 FreeBSD からファイルを scp で送って、それを iPhone6 や Android アプリで閲覧することができるようになりました。
これでアプリと既存の UNIX 環境を上手に使い分けて作業を行うとシームレスにファイルが共有できて作業が捗りそうです;-)。

 
それにしてもクラウドなストレージサービスというのは OneDrive Dropbox BOX など有りますが、ファイルが貯蔵されているクラウド側をプロンプトから ls で見ることができるサービスというのは、今のところ「さくらぽけっと」のみ。と、いうことになります。さくらインターネットに拍手を送りましょう;-)。

と、いうことで「さくらのレンタルサーバ」を利用している人は是非とも さくらぽけっと アプリを使ってみてくだい。 100GByte のクラウドストレージが利用できることになります;-)。

3月 012015
 

最近はほとんどの NotePC にカメラが付いていて Windows とかだと Skype しよう。 Mac だと FaceTime しよう。などと言っていますが、普段はほとんど使わない(と、僕は思う)んだけど、実際にはどうなんでしょうか?

そんな感じの標準装備のカメラですが OS に FreeBSD を利用していた場合にどのような目的でどう使う? ってか、その前に「ここに付いているカメラは FreeBSD で動くの?」などと思ってしまうのですが、今回は実際に NotePC に付いているカメラを FreeBSD で利用してみるとこにしましょう。

 
今回登場する NotePC は僕の持っている ThinkPad Edge e145 です。このブログには何回か登場しているのですが FreeBSD がバリバリ動作しています;-)。この ThinkPad Edge e145 も最近の NotePC のトレンドを追いかけているようで、ディスプレーの上にカメラが付いています。

今回はこのカメラを利用して色々やってみたいと思います。もしかしたら、ネタ的にはもう既に枯れているかも・・f(^^;;。

 
1). カメラを認識させる
最近の NotePC に付属のカメラはほとんどが USB に接続されているようですね。 pciconf -lv とか usbconfig list コマンドを叩き、デバイス的に、どこにカメラが接続されているか確認しましょう。

 # usbconfig list
    :
ugen4.2: <Integrated Camera Vimicro corp.> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (256mA)
    :

 
ThinkPad Edge e145 の場合は USB の ugen4.2 として認識されているようですね。と、いうことでこいつを正しいデバイスとして認識させてみましょう。

 
2). デバイスドライバのインストール
FreeBSD の純正デバイスドライバというのは存在してないのですが、 Linux 方面で開発されたキャラクタデバイスを読み込むドライバを FreeBSD に対応させた Cuse4BSD を利用します。 ports 的には multimedia/cuse4bsd-kmod になります。
まず、これをインストールし、続いてキャラクタデバイスをビデオデバイスとして認識させる webcamd をインストールします。 ports 的には multimedia/webcamd になります。まぁ、 webcamd を make install すると関連性で cuse4bsd-kmod もインストールされますが;-)。

そして multimedia/cuse4bsd-kmod を make install したときにインストールされた cuse4bsd.ko を kldload します。

# kldload /boot/modules/cuse4bsd.ko

 
カーネルモジュールをロードしたあとに wbecamd を起動し /dev/video0 として USB カメラを認識させます。オプションに USB 接続のカメラの USB のデバイス名を指定します。

# webcamd -d ugen4.2
Attached to ugen4.2[0]
Creating /dev/video0
^Z
中断
# bg
# ls -l /dev/video0
crw-rw---  1 webcamd  webcamd  0x82 Feb 28 26:14 /dev/video0
# chmod 666 /dev/video0

 
webcamd を起動すると正しく動作する USB カメラであれば /dev/video0 が生えてきます。
その後、一旦バックグラウンドにほーり投げてパーミッションを確認します。今回は一般ユーザでも利用したいので 666 に変更しています。デバイス生成時にバーミッションを変更したい場合には /etc/devd.conf におまじないを書いてください。ここでは割愛します;-)。

以上で準備は完了です。

 
3). まずはローカルでカメラを利用してみる
/dev/video0 が生えてきたので、実際にカメラに写るモノを表示させてみたいですね。そんな時は pwcview を利用します。 ports 的には multimedia/pwcview になります。
こいつを make install したあとに特にオプションも付けずに起動すると X11 上にウィンドが現れてカメラから映る景色が表示されると思います。

しかし、ローカルな FreeBSD の X11 の画面にカメラから映る景色が表示されても「だから何?」で終わってしまいますよねf(^^;;。
僕自身もまさしくそのとおりでして。ただ単に「あ。 cuse4bsd.ko と webcamd でデバイスを認識したのね。ふーん。すごいね。いじょ。」みたいな・・f(^^;;。

この写真はまさしくそんな感じで、 ThinkPad Edge e145 上の FreeBSD で KDE4 が動いていて、そこで pwcview を起動させた状態です。

IMG_0968_NotePC_Cam_1

ディスプレーの上にカメラがあるのですが、その横にある黄緑色の LED が光っております。カメラが Ready 状態ですねぇ;-)。

と、いうことで何か別の利用方法を考えてみることにしましょう。

あ。 chmod 666 /dev/video0 しましたが、これしないと一般ユーザで起動する pwcview では 画像が読み込めない状態になります。

 
4). リモートからカメラの映像を確認する
ローカルな FreeBSD の X11 に画面が出力されたので、リモートの FreeBSD から ssh -CY し、手元の X11 に pwcview を表示させればいんじゃね? えぇ。まさしくそのとおりですね。それだとリモートの X11 にカメラに映された映像が表示されます。それもひとつの案ですね;-)。

今回は http で画像を転送してみましょう。 ports から mjpg-streamer をインストールします。 ports 的には multimedia/mjpg-streamer になります。 make config は default の設定で良いです。まぁ、強いて言えば “Linux-UVC V4L2 plugin” を有効にしてインストールしましょう。

インストールしたものの中で重要なのはプラグインがインストールされた場所でしょうか。 /usr/local/lib/mjpg-streamer/ の中を覗くと .so なファイルが入っていますが mjpg-streamer を起動するときに利用するプラグインになります。

では実際に起動してみましょう。

$ mjpg_streamer -i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -w /usr/local/www/mjpg-streamer'

 
/dev/video0 は chmod 666 しているので一般ユーザ権限で起動できます。

-i でカメラ側のオプションを指定します。 input_uvc.so プラグインを利用し、デバイスは /dev/video0 から入力します。
-o で出力側のオプションを指定します。 output_http.so プラグインを利用しコンテンツは /usr/local/www/mjpg-streamer にあることを指定します。
-o に output_file.so を指定するとカメラに写ったモノはファイルに出力してくれるのでしょうなぁ。僕は試していませんがf(^^;;。

ちなみに /usr/local/etc/rc.d/mjpg_streamer という起動スクリプトがインストールされるのですが、こいつは -i のオプションを指定する部分が無いんですよね。 rc.conf.local には以下のように書くと良いかな。

mjpg_streamer_enable="YES"
mjpg_streamer_flags="-i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -w /usr/local/www/mjpg-streamer'"

 
さてさて。あとはウェブブラウザで http://localhost:8080 とかリモートのマシンからアクセスしてみるとそれらしいウェブサイトが表示されると思います。

ちなみにポート番号を変えたい場合には以下のように設定するが良いです。

mjpg_streamer_enable="YES"
mjpg_streamer_flags="-i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -p 8081 -w /usr/local/www/mjpg-streamer'"

 
こんな感じで任意のポートに変更できたりします。

ただ、悲しいかな・・。 mjpg_streamer は IPv6 には対応していないようですねぇ。ソースコードの plugins/output_http/httpd.c の socket(PF_INET, …); の部分を書き換えると IPv6 対応になるかなぁ?暇なときにいじってみよう。

さてと。実際に表示される動画ですが、皆さんの目で確認してみてください;-)。
左のメニューから Static を選択すると写真が、 Stream を選択すると動画が流れ始めます。
僕の ThinkPad Edge e145 のカメラは pwcview ではまぁ、そこそこ綺麗に見えるのですが mjpg_streamer で見ると多少ちらつきますね。あと、ブラウザ側の PC の負荷が高くなるかな。

 
と、いう感じで NotePC に付いていたカメラが FreeBSD からでも利用できることが確認できました。しかもそのカメラがリモートからアクセスできて閲覧もできることが確認できたので、これで利用頻度がいっきにアップするのでは無いかと思われます。嬉しいことですね。

ただ、音を飛ばす時にはもっと別の技が必要になりそうな気がしますが、それはまた別の機会にでも:-|。

あと、カメラが付いてない FreeBSD がインストールされた PC には手元にある USB カメラを色々付けてみて cuse4bsd-kmod と webcamd で動作するか確認して見るのもよいかと思います。
もし動作する USB カメラだった場合、フツーの自作 PC にインストールした FreeBSD でも今回の組み合わせでカメラが利用できるようになるかと思われます。

ちなみに、僕は以下の二つの USB カメラを持っているのですが、こいつらをデスクトップの FreeBSD で利用してみました。

IMG_2228_NotePC_Cam_2

左側の白いのは FreeBSD というか webcamd で認識してくれませんでした。以下のようなメッセージが出力されます。

# webcamd -d ugen0.2
webcamd: Cannot find USB device

 
右側の黒いのは赤外線付きで暗いところでも良く見えるカメラなのですが、こいつは pwcview では動きましたが mjpg_streamer では動きませんでした(砂の嵐が表示されます)。
カメラによって動作が多少違うようですね。

 
と、いうことで、今回は NotePC に標準で付いているカメラで遊んでみました。 mjpg_streamer がちゃんと動いてくれると、利用価値は上がりそうですね。 また、 mjpg_streamer に変わる何か別のアプリを見つけてきて、それを試してみるのも良さそうですね。何か良い ports をご存じの方いましたら教えて下さい;-)。

また、最近流行の Raspberry Pi を FreeBSD/ARM で起動して USB カメラを接続し今回の組み合わせを利用すると、IoT な監視カメラができるかもしれません。

バッテリ運用で Raspberry Pi+USB Camera+FreeBSD+cuse4bsd-kmod+webcamd+mjpg_streamer+Wi-Fi な状態のヤツをラジコンカーに積んで走らせたら、録画ではなく、リアルタイムで動画が堪能できるような気がします。

面白そうだ・・;-)。

12月 182014
 

デスクトップとして FreeBSD を利用するとなると色々な ports がドドドと入るのですが、その中に coretutils というのがインストールされることに気がついた。 ports 的には sysutils/coreutils になるんですが、こいつは何かというと Linux で利用されているような GNU のコマンド一式なんですね。 FreeBSD 的には /usr/bin/ 配下にあるコマンドの先頭に g が付いて /usr/local/bin/ に大量にインストールされます。別に新規に GNU のコマンドを入れなくて良いよー。と、なるのでありますが・・。

そもそも coreutils はどの ports に関連付いてインストールされるのか調べてみると kdepim4 がインストールしているみたい。うひっ!! すると KDE4 をインストールしていない人にはまるで関係の無い ports と、いうことになるじゃん・・。orz

今回は、既に /usr/bin/ などにコマンドがあるのに、新たに GNU のコマンドを入れてしまう coreutils をインストールしないように kdepim4 の ports を書き換えてみたいと思います。
環境は FreeBSD 10.0-RELEASE で ports-current 、 kdepim4 のバージョンは kdepim-4.14.2_1 で coreutils のバージョンは coreutils-8.23 になります。

1). kdepim4 の Makefile 参照
まず、 kdepim4 が coreutils-8.23 をインストールしていることが解ったので deskutils/kdepim4/Makefile を覗いてみます。すると、以下の行ですね。

 20  RUN_DEPENDS= ${KDE4_PREFIX}/bin/accountwizard:${PORTSDIR}/deskutils/kdepim4-runtime \
 21               ${LOCALBASE}/bin/gmd5sum:${PORTSDIR}/sysutils/coreutils

 
20 行目で RUN_DEPENDS が設定してあって 21 行目で gmd5sum を利用するために coreutils-8.23 をインストールするようです。
では、実際にソースコードはどこで gmd5sum を使うのか確認してみましょう。

 
2). 設定ファイルで利用されている?
kdepim-4.14.2_1 の中では libkleo/libkleopatrarc.desktop というファイルの中でのみ gmd5sum が利用されているようです。ついでに gsha1sum も利用されているようです。他のソースコードでは全く利用されていないようですし、また、他の g シリーズのコマンドも利用されないようです。

これだけのために g シリーズのコマンド一式インストールするんかい!? となるので、是非ともなんとかしたいモノです。

 
3). md5sum と sha?sum のみインストールする ports を作る
coreutils の他のコマンドは要らないので md5sum と sha?sum のみインストールする ports を作りました。
実は FreeBSD の md5 や sha1 で代用できるんかな? とか思ったのですが md5sum や sha1sum には -c (–check) オプションがあって kdepim4 の kleopatra (これについては後で詳しく説明します;-) の中ではまさしく -c オプションを利用しているので FreeBSD に標準で付いているコマンドではダメなんですね。
あと、 openssl md5 オプションでも -c に相当するオプションはありませんでした。
なので、しょーがない。 md5sum と sha?sum のみをインストールする ports を作成しました。

http://icmpv6.org/Prog/FreeBSD_ports/ports-md5sum-20141216.tgz

ちなみに FreeBSD の md5 に -c 相当のオプションないんかい? などと思いウェブを色々調べたのですが、 BSD 系の人は、この -c オプションが無いためにスクリプト書いたりと色々ナンギしているようですね。

上記 ports は、もとは sysutils/coreutils を利用していますが、先頭の “g” を取って必要最小限なモノしかインストールしないように pkg-plist を書き換えました。
Makefile 中の CONFLICTS で coreutils-* も指定してあるので md5sum と coreutils の両方インストールすることはできません。

ダウンロードしたファイルは /usr/ports/sysutils/ に展開してください。

 
3). kdeppim4 の Makefile の編集と files/ の下のファイルを一個消す
上に掲載した kdepim4 の Makefile の 21 行目を以下のように直します。

 20  RUN_DEPENDS= ${KDE4_PREFIX}/bin/accountwizard:${PORTSDIR}/deskutils/kdepim4-runtime \
 21               ${LOCALBASE}/bin/md5sum:${PORTSDIR}/sysutils/md5sum

 
そして、不要となったファイルである deskutils/kdepim4/files/patch-libkleo__libkleopatrarc.desktop を削除します。

あとは kdepim4 を make && make deinstall && make reinstall し直せば OK。ノラ ports である md5sum も合わせてインストールされます。

 
4). kleopatra をちょっと説明
そもそも libkleopatrarc ってのは KDE の中で何をしているモノなのか?
コマンド的には kleopatra というのがあります。では kleopatra とはなんなのか? 基本的には証明書マネージャーの GUI 版で、ヘルプを見てみると「証明書マネージャと統合された暗号 GUI」とのことで PGP キーなどを管理するソフトウェアになります。

普段 PGP などはコマンドラインで利用しているかと思いますが、 kleopatra を利用すると GUI で鍵の作成・サイン・エクスポート・管理などが行えます。実際に利用してみると中々便利ですね;-)。

ちょっと kleopatra をコンソールから起動してみます。するとまず最初に「kleopatra セルフテストの結果」が起動し、そのときにコンソールにはログとして以下が表示されます。

    :
ChecksumDefinition[ "sha1sum" ] ("xargs", "-0", "sha1sum", "--") 
ChecksumDefinition[ "sha1sum" ] find -print0 |  "/usr/bin/xargs" ("-0", "sha1sum", "--") 
ChecksumDefinition[ "sha1sum" ] ("sha1sum", "-c", "--") 
ChecksumDefinition[ "sha1sum" ] "/usr/local/bin/sha1sum" ("-c", "--") "%f" () 
ChecksumDefinition[ "md5sum" ] ("xargs", "-0", "md5sum", "--") 
ChecksumDefinition[ "md5sum" ] find -print0 |  "/usr/bin/xargs" ("-0", "md5sum", "--") 
ChecksumDefinition[ "md5sum" ] ("md5sum", "-c", "--") 
ChecksumDefinition[ "md5sum" ] "/usr/local/bin/md5sum" ("-c", "--") "%f" () 
    :

 
セルフテストの結果に赤い NG のがあるのであれば、問題を取り除き、全部緑色にしたほうが良いでしょうね。
キャプチャはありませんが、例えば security/gnupg をインストールするときに make config のオプションで [x] SCDAEMON としてから再インストールする必要があったりします。

が、しかし、ログを確認すると今回の目的である md5sum と sha1sum のみのインストールができたので今回はよしとしましょう。

ちなみに md5sum と sha1sum が記載されているファイルは /usr/local/share/config/libkleopatrarc としてインストールされます。すると kleopatra は起動時のセルフテストにおいてはこのファイルを参照して動作しているようですね。

libkleopatrarc はインストールしたものを利用しても良いし、以下のように自分の設定として保存し、それを手で編集しても良いです。

$ cp /usr/local/share/config/libkleopatrarc $HOME/.kde4/share/config/

 
上記のコマンド実行後に自分の $HOME に置いた設定ファイルを手で編集し、 ports を利用せずに個別にインストールした md5dum と sha1sum を利用するように変更したりもできるようになります。

 
それにしても、どうして coreutils-8.23 を使うのがイヤかというと、とあるプログラムをインストールしようとして configure を走らせたのですが、これがなんと /usr/bin/install ではなく /usr/local/bin/ginstall を利用したりと FreeBSD 由来のコマンドではなく ports からインストールした GNU のコマンドを利用しているんですね。

そんなのはイヤだー。純粋な FreeBSD の /usr/bin/* なコマンドを利用したいよー。などと思ったのが今回のコトの発端なのであります。人によっては「そんなんどっちでもいーじゃん。」ってのがあるかもしれませんけどねぇ。

 
しかし、今回作成したノラ ports である md5sum は coreutils の中から一部のコマンドを切り出しただけの ports なので、似たようなのが色々できそうですね。例えば Linux の ls(1) を利用したい場合には ls のみをインストールする ports である gls とか簡単に作れそう;-)。

しかし、そんなことは、多分、僕しかしないだろうなぁf(^^;;。

12月 162014
 

以前のエントリで「KDE4 で VirtualBox を動かしたしたときに ISO がマウントできない件。」と、いうエントリを書きました。FreeBSD 上で動作する VirtualBox でゲスト OS はISO イメージを mount できない。 dbus が悪さしているようだ。って感じなんですけども。

で、そのエントリに対してコメントを頂きました。なるほど。 issetugid を undef すれば良いのですね。コメントくださった方、ありがとうございました。

で、 make configure 走らせて config.h 編集してから make && make deinstall && make reinstall するのは大変なので、 ports で選択できるようにしました。

dbus_VirtualBox_1

make config に ISSETUGID オプションを [x] にすると Support VirtualBox ISO image mount が有効になります。

gnome@freebsd.org に連絡する必要があるような気がするんだけど、きっとノラ ports のままにしておくと思いますf(^^;;。
コミットしてくださる方がいると非常に嬉しいですが VirtualBox を利用していて ISO イメージをマウントできないのは KDE4 を利用している人だけなのかな?

FreeBSD で VirtualBox 使ってて ISO イメージがマウントできない。と、お嘆きの方は以下の ports を利用してみてください。
あ。変更したのは dbus/Makefile のみです。

http://icmpv6.org/Prog/FreeBSD_ports/ports-dbus-VirtualBox_ISO_image_mount-20141215.tgz

ISSETUGID オプションを有効にすると configure ファイルの ac_func から issetugid を削除します。すると config.h では #undef HAVE_ISSETUGID になります。それで make すると VirtualBox のゲスト OS で ISO ファイルがマウントできるようになります。