4月 052017
 

FreeBSD の ports CURRENT を追いかけていると svn update したあとに portmaster -D -a するクセが付いているのでそれをやってバシバシ最新の ports/pkg を利用しているんだけど・・。

だいたい、時期を同じくして portmaster -D -a してのバージョンアップと Xming の利用が一緒になり、前のエントリの中で『Xming では mozc で日本語入力ができない。』などと書いていたのですが、なんとっ!! よくよく調べてみると GTK-3.0 を利用しているアプリの日本語入力ができなくなっていることがわかった。

KDE 系のアプリは Xming 経由や、素の Xorg 上では日本語入力ができるけど GTK-3.0 なアプリが日本語入力できなくなっていた。

最近は GTK-2.0 から 3.0 への過渡期で、僕の場合は GNOME3 は使ってないんだけど emacs や firefox は GTK-3.0 を明示的に指定して ports のコンパイルをしているし xfce4-terminal も default で GTK-3.0 を利用するようになっている。

と、いうことで今更ながら GTK-2.0 の IM 周りの設定を見直してもショウガない。 xfce4-terminal などは ldd で確認すると libgtk-3.so.0 を利用しているしね。
と、いうことで GTK-3.0 の日本語入力の設定の見直しです。

あ。 GTK-3.0 のアプリで日本語が入力できなくなったのは 03/31 に svn update して portmaster -D -a してからですね。その前まではちゃんと日本語が打てていました。

 
GTK-3.0 の設定はインストールすると、以下のディレクトリに散りばめられます。

・/usr/local/lib/gtk-3.0/3.0.0/
・/usr/local/etc/gtk-3.0/
・$HOME/.config/gtk-3.0/

この中に IM に関する設定ファイルが必要なります。

ちなみに GTK-2.0 の場合には日本語入力するためのファイルは以下になります。

・/usr/local/etc/gtk-2.0/gtk.immodules

このフアイルのおかげで、環境変数に以下を設定した場合に GTK アプリで日本語入力ができるようになります。

export QT_IM_MODULE=xim
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec mozc start
exec fcitx

 
僕の場合は QT_IM_MODULE を設定して KDE アプリで xim を利用し、 GTK_IM_MODULE も同様で、日本語入力には fcitx を mozc 経由で利用しています。

今回は GTK-3.0 のアプリについてですが、 GTK-2.0 の頃には /usr/local/etc/gtk-2.0/gtk.immodules があったのですが /usr/local/etc/gtk-3.0/ の下にはそんなファイルがありません。

なので作ってあげる必要があります。その場合、以下のコマンドを打ちます。

# cd /usr/local/etc/gtk-3.0/
# gtk-query-immodules-3.0 > gtk.immodules

 
さてと。準備完了。では xfce4-terminal を起動して Shift+SPACE を押してと。あれま。ダメだ・・。
と、いうことで上記の設定ファイルを用意してもダメなようです。

しょーがないので GTK-3.0 のドキュメントを読んでみることにしましょう。

https://developer.gnome.org/gtk3/unstable/gtk-running.html

上記の URL に書かれている説明では immodules の設定ファイルは immodules.cache という名になっているようです。では先程作成したファイルを mv して名前を変更して再度トライ。

しかし、ダメなようです。あれま・・。

上記のドキュメントを読むと直接ほーりむようなことが書いてあるので ports がフアイルをインストールしたディレクトリに直接用意してみることにします。

# cd /usr/local/lib/gtk-3.0/3.0.0/
# gtk-query-immodules-3.0 > immodules.cache

 
これで再度 xfce4-terminal を起動して Shift+SPACE を押してみます。おぉっ!! 今度は無事に fcitx の画面が表示されて日本語が打てるようになりました。メデタシメデタシ。

と、いうことは ports のバグっぽいので、今後バージョンアップされたときには直ることでしようなぁ。 ちなみに 03/31 の ports でインストールされた GTK-3.0 のバージョンは gtk3-3.18.8_4 です。
次にバージョンアップするとしたら gtk3-3.18.8_5 かな? 😉

 
GTK-3.0 のアプリで日本語が今まで打てていたのに急に打てなくなった。と、いう方は上記のように試してみてください。

7月 112016
 

今年の四月くらいに FreeBSD でも Let’s Encrypt が利用できるようになった。と言う話を耳にして、当時は letsencrypt コマンド(当時の ports 的には security/py-letsencrypt) を利用するとサクサクっと Let’s Encrypt な証明書を利用したSSL サーバが利用可能な状態となりました。
それから約三ヶ月が過ぎて Let’s Encrypt 的にもコマンドが letsencrypt-auto から certbot-auto になって、 FreeBSD の ports 的には security/py-certbot もしくは security/letsencrypt.sh という二つの実装が提供されるようになりました。

さて。今年の四月くらいに letsencrypt コマンドで生成した証明書が有効期限切れになるのでアップデートしようと思い、普段からこまめに portmaster -D -a している環境においては既に letsencrypt がなくなっていたので certbot で実行したら以下のようなエラーが出てまるで動作しなくなってしまった・・。 orz

SSLError: ("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",)

 

なんかねぇ。おかしいんですよ。で、色々聞いたり調べたりしたところ、どうやら security/ca_root_nss のインストールが変なんじゃないか? という結論に達したのであります。

security/ca_root_nss をインストールするときの make config で 以下のように ETCSYMLINK のオプションを [X] にしてあげないとダメなようです。

ca_root_cert

上記オプションを有効にして make install すると /etc/ssl/cert.pem が sysmlink で生成されるようになります。 ETCSYMLINK のオプションは以前は [ ] な時期(それはつまりはオフになっている状態。と、いうことです)もあったりしたので古い make config の情報を使いまわしている人は ずっとオフのまんまで来ていたりするので『自分の make config の結果はどっちだったかな?』などと、確認するのも良いかもしれないです。

letsencrypt コマンドのときは /etc/ssl/cert.pem が無くとも大丈夫だったのに certbot コマンドを利用するようになったら /etc/ssl/cert.pem が必要になりました。ふむー。

/etc/ssl/cert.pem と同じファイルは全部で以下が存在します。

/usr/local/share/certs/ca-root-nss.crt
/usr/local/openssl/cert.pem
/usr/local/etc/ssl/cert.pem
/etc/ssl/cert.pem

うーむ。 ports からインストールしたものは素直に /usr/local/etc/ssl/cert.pem を参照してくれれば良いのになぁ。などと思うのですが、この辺り、見事に『はまり道』です。

ports から security/py-certbot をインストールして上記のようなエラーメッセージが出てまともに動作しない場合には是非 /etc/ssl/cert.pem があるかを確認してみてください。

 
あと、 /etc/ssl/cert.pem はあるけど、それでも上記のエラーメッセージが出て certbot コマンドが動作しないことがあるかもしれませんが、それは多分、過去に letsencrypt コマンドで既に証明書を発行してもらい、その後の証明書ファイルの更新時にcertbot コマンドを利用しようとすると発生するのではないかと思われます。
その場合は悲しいけれども、一旦 /usr/local/etc/letsencrypt/ ディレクトリを削除もしくは名前変更してから再度、新規に /usr/local/etc/letsencrypt/ ディレクトリを作成すると無事に動作します。古いコマンドを実行したときに参照した cert.pem ファイルの情報を保持しているのでしょうなぁ。

以上、FreeBSD において certbot を使ったときの『はまり道』についてなのでありました。

あ。 certbot の使い方とか書いてないですが、大丈夫ですよね?;-)。

2月 202016
 

いやぁ。一月は全くエントリがなかったのに二月はドドドと連チャンになってしまいました;-)。

と、いうことで本題。

FreeBSD で Thunderbird を利用していると、一緒にカレンダーアプリである Lightning を make config の時に指定することができます。あ。ports で make するときのお話です。
しかし、ports から Thunderbird と一緒にインストールした Lightning は日本語化されてないんですね。 Windows 版などはインストール後に Lightning も日本語表示できるのに・・。

と、いうことで以前「Lightning の自動日本語化。」と、いうエントリを書いてしばらくは対応できていたのですが thunderbird-38 系になって、このスクリプトを動かしても日本語化してくれなくなりました。モロモロ状況が変わったのでしょうなぁ。

と、いうことで久しぶりに Thunderbird と Lightning を調査した結果、以下のことが解りました。

  • FreeBSD の ports からインストールした Thunderbird は Lightning が以下のディレクトリにインストールされる。

    /usr/local/lib/xpi/lightning@thunderbird.mozilla.org/

  • この中の chrome.manifest をいじって chrome/ ディレクトリの中に locale ファイルをほーりこんでも日本語化されない。
  • FreeBSD の ports からインストールした Thunderbird は Lightning が上記ディレクトリにインストールされる他に、以下のディレクトリにも合わせてインストールされる。

    $HOME/.thunderbird/乱数.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/

以上の調査結果から、日本語 locale ファイルをインストールするのは ~/.thunderbird/ の中の Lightning エクステンションの中にインストールして上げなければならない。と、いうことが解りました。

いやぁ。ハマりますなぁ。これは・・。まさか二箇所にインストールされている(もしくは、バージョンアップした Thunderbird の最初の起動時に $HOME 配下にコピーする)とは思っていなかった。

 
と、いうことでサクっと日本語するスクリプトを更新したので、必要な方は以下の URI からダウンロードして試してみてください。

http://icmpv6.org/Prog/lightning-ja-20160219.tgz

簡単なスクリプトなので、詳しい説明はしません。中を覗いてください;-)。

スクリプトの lightningversion=’4.0.3.1′ は狙い撃ちしています。 install.rdf のバージョンを確認すると 4.0.6 になっているのですが、そのディレクトリが ftp.mozilla.org のサイトに見当たらないんですよね。
なので、新しいバージョンが出たら lightningversion=’4.0.3.1′ を変更してください。

 
と、いうことでカレンダーの日本語化、復活です;-)。

10月 182015
 

ちょっと前のエントリで「Zeroconf 考察。」というのを書きました。デスクトップで利用する場合には Avahi を、サーバで利用するなら mDNSResponder+howl で。って感じのエントリでした。

さて。サーバ側で利用している mDNSResponder (正確には mdnsd のこと) ですが、こいつは非常にお行儀の悪いプログラムですねぇ。さすがは Apple 謹製って感じでしょうか;-P。

どの辺りがお行儀悪いのか?

mdnsd は起動してからのログが随分と出力されます。例えば、サーバの場合は複数のインターフェースを持っていて、アクセスされたくないインターフェースには ipfw などで止めたりします。しかし、 mdnsd はそんなのお構いなしにサーバの全てのポートにマルチキャスト DNS パケットを port:5353 に流しまくりなんですね。

挙句の果てには『bge1 にパケット投げたら Permission denied だった。』とかログを出しまくりで、ヘタしたら /var/log/messages は mDNSResponder のログで溢れかえっしまいます。

これは非常にウザいので今回はログを一つのファイルに集約するようにして /var/log/messages には出力しないようにしてみましょう。
まずは syslog の設定から。あ。ターゲットは当然 FreeBSD です;-)。

 
o. syslog の設定
今回は mdnsd のログは今回は LOCAL4 に出力するようにします。なので、LOCAL4 に飛んできた syslog の扱いについて設定します。

まずは /etc/syslog.conf の設定変更です。

        :
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local4.none       /var/log/messages
        :
#
local4.*        /var/log/mdns.log
#
        :

 
/var/log/messages に出力されたくないので local4.none を追加します。そして LOCAL4 ファシリティ用のログファイルを設定してあげます。

次に /etc/newsyslog.conf も編集しましょうかね。

        :
/var/log/mdns.log                       644  7     100  *     JC
        :

 
まぁ、こんな感じで登録します。あとは syslod と newsyslog を restart すると準備は完了です。

 
o. mDNSResponder のソース改修
mDNSResponder は ports 的には net/mDNSResponder/ になります。ここでまず make patch とか打ってソースを展開したうえでソースコードを覗いてみます。今回は syslog に関わる部分ですね。

と、いうか mDNSResponder (バイナリ自体は ports の net/howl/ でインストールされる) と、いうか mdnsd (こちらが ports の net/mDNSResponder/ がインストールする) は syslog プライオリティなどを変更するオプションが無いんですね。なのでソースコードを眺めんですけども。

それで、ソースコードを眺めいたらありましたね。 syslog の openlog は mDNSShared/PlatformCommon.c でやっているようですね。

以下はパッチです。

--- mDNSShared/PlatformCommon.c.orig    2012-06-30 13:52:35.000000000 +0900
+++ mDNSShared/PlatformCommon.c 2015-10-16 10:57:01.595162000 +0900
@@ -184,7 +184,7 @@
             fflush(stderr);
         }

-        if (!log_inited) { openlog(ident, LOG_CONS, LOG_DAEMON); log_inited++; }
+        if (!log_inited) { openlog(ident, LOG_CONS, LOG_LOCAL4); log_inited++; }

 #if APPLE_OSX_mDNSResponder && LogTimeStamps
         if (ident && ident[0] && mDNSPlatformClockDivisor)

 
openlog() のオプションで LOG_DAEMON と書かれているので syslog.conf では daemon.none を設定すれば良いような気がしないでも無いですが LOG_DAEMON なプライオリティは他のアプリケーションもドカドカと利用しているような気がするので、今回は LOG_LOCAL4 に変更してみます。

上記パッチは net/mDNSResponder/files/ の中に patch-mDNSShared-PlatformCommon.c としてほーり込むと ports の make 時に毎回有効になるかと思われます。自分の好みでどうにかしてください。

また、僕は LOG_LOCAL4 にしましたが、自分の都合のようプライオリティに変更しても良いのではないかと思われます。

あとは make して deinstall して reinstall 、そしてデーモンを再起動すると全ては完了です。 /etc/syslog.conf に指定した情報の通り、 /var/log/messages 以外のファイルに蓄積されるようになるかと思われます。

 
mDNSResponder と mdnsd は非常に良いのですが、出力されるログが非常に気になるのですが、これで問題解決;-)。

ports の Makefile 自体を改修して make config でログのプライオリティを変更するようにもできるなぁ;-)。
機会があれば書いてみよう;-)。

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

avahi_daemon_enable="YES"
avahi_dnsconfd_enable="YES"

 
・Avahi

mdnsd_enable="YES"
mdnsresponder_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 間でも通信は行えるのでどちらをチョイスしても全然問題ありません。

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