Linux » かけまわる子犬。

ubuntu で VRF 使ってみました。

7月 272017

ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほうには setfib コマンドでルーティングテーブルを操作して正しいルーティングができるのか試しているのですが、結局はダメだったのであります。

Linux 方面では ip route+ip rule でのポリシールーティングの運用となりますが、カーネルのバージョン 4.4 から VRF が利用できる。というので setfib と比較してどれくらい効果的に機能するのか試してみました。
Linux カーネルが 4.4 以上なディストリビューションには何があるのか調べてみると ubuntu-17.04 が対応しているようなので ISO イメージをダウンロードしてインストールし、実際に設定までしてみます。

僕自身 ubuntu はあまり使ったことが無いディストリビューションで Raspberry Pi の Volumio に続き二個目のインストール環境です。仕事でもデスクトップでも使ったことがありません;-)。

それにしても ubuntu のネットワーク設定である /etc/network/interfaces の記述方法が相変わらず解らないので、いつものように /etc/rc.local でやってしまえ。などと思っても ubuntu にはこのファイルが無いし、起動時に利用できないのですねぇ。

以下の URL を参照させて頂き /etc/rc.local を動くようにしました;-)。

http://qiita.com/msrks/items/5201ae15d0e1f8de5946

簡単に書いておくと

o. /etc/systemd/system/rc-local.service を作成

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
# disable timeout logic
TimeoutSec=0
#StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

o. enable する

systemctl enable rc-local.service

これで /etc/network/interfaces と /etc/rc.local にコマンドを書いて、起動時に実行されるようになりました。

と、いうことで、以降は VRF を利用するネットワークの設定を行います。

まず、ネットワーク構成ですが、この前のエントリ「FreeBSD でポリシールーティング。」で書いた CentOS 6.9 を ubuntu-17.04 にリプレイスして ip route+ip rule をやめて VRF を利用してみます。

Server1 が Linux (CentOS 6.9) だったので、これを設定します。以下はネットワークの情報です。

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

これを VRF を利用するように設定します。が、その前に注意点を。

NIC が二個あるのでそれぞれの NIC を VRF にしてルーティングテーブルを二つ別々に持たせよう。などと思ってはいけません。
NIC が二個の場合、一個は default のルーティングテーブル(ip [-6] route list で表示されるルーティングテーブル)を参照するようにして、もう一個の NIC は別のルーティングテーブルを持ち、かつ参照する構成が良いです。ここ、ハマリ道というか思い違いの点ですね。
この点については下のほうに詳しく書きます。

では、設定を上から順に見ていきます。

0). /etc/network/interfaces にネットワークの設定のみ書く
lo の他にインターフェース二つ分を書き gateway の設定は書かない

auto ens160
iface ens160 inet static
address 192.168.22.10
netmask 255.255.255.0
iface ens160 inet6 static
address 2001:470:fe36:beef::2:1
netmask 64

auto ens32
iface ens32 inet static
address 192.168.1.10
netmask 255.255.255.0
iface ens32 inet6 static
address 3ffe:6580:aa40::2:1
netmask 64

多分、/etc/resolv.conf が作られないので、以下のコマンドを /etc/rc.local に書いておくと良いかもしれんです。

cp -pr /etc/resolv.conf.SV /etc/resolv.conf

/etc/resolv.conf.SV は好きに書いてください;-)。
しかし、ディストリビューションの正しい設定方法を無視しているなぁ;-P。

1). IP アドレスの付加
僕の場合、/etc/network/interfaces に書いた IPv6 アドレスが自動的に付加されなかったので /etc/rc.local に書きました。
以降の設定は全て /etc/rc.local に書くと楽ちんです;-)。

ip addr add dev ens160 2001:470:fe36:beef::2:1/64
ip addr add dev ens32 3ffe:6580:aa40::2:1/64

2).ルーティング情報の付加
今回は Server-Zone 側を default のルーティングテーブルとして利用します。

route add default gw 192.168.22.1
route add -A inet6 default gw 2001:470:fe36:beef::1

3). VRF の設定
いよいよ、VRF の設定です。VRF は LAN-Zone 側に設定します。
ip [-6] route list コマンドで表示される default gateway は上でコマンドを打っています。グローバル側の設定ですね。
VRF はマネージメントポート側で利用する。と、いう意味合いを込めて Cisco 風に mgmt という名にします;-)。

ip link add dev mgmt type vrf table 10
ip link set dev mgmt up

type は vrf で table 番号は 10 を利用しました。複数個の VRF を生成する場合はこの番号を増やしていけば良いです。

4). VRF と NIC の結びつけ
作成した VRF インターフェースと NIC を結びつけます。つまりは、マネージメントポート用の VRF は mgmt として LAN-Zone の NIC と結びつける。と、いうことですね。

ip link set dev ens32  master mgmt up

リモートから ssh で作業していて dev で指定する NIC からアクセスしていた場合、このコマンドを投入した段階でネットワークが切れます。なので反対側の NIC からアクセスして作業するか、コンソールからコマンドを叩く必要があります。
起動時の /etc/rc.local 読み込み時には問題はないんですけどね。

5). VRF に default gateway を設定
Server-Zone は default のルーティングテーブルを参照しますが、 LAN-Zone は個別の VRF のルーティングテーブルを参照します。なので別途 default gateway を設定します。 VRF の table 10 に対して route add します。

ip route add default via 192.168.1.103 table 10
ip route add default via 2405:6580:aa40::fffe table 10

6). 外部からのアクセスを可能にする
最後に sysctl で以下の MIB 値を変更し、外部から VRF 側のネットワークアクセスを可能にします。これをしないと ssh などで接続することができません。

sysctl -w net.ipv4.tcp_l3mdev_accept=1

以上で VRF の設定は完了です。

確認方法は以下になります。

ip route list もしくは ip -6 route list
default のルーティングテーブルを確認すときに利用
ip route list vrf mgmt もしくは ip -6 route list vrf mgmt
設定した VRF の mgmt のルーティングテーブルを確認

その他、インターフェースの確認として ip link や ip addr を利用します。

さて。最初のほうで『二個の NIC に VRF を二個用意してはいけません。』と書いていますが、例えば二個の NIC それぞれで VRF を利用した場合 /etc/resolv.conf を参照しないなど、問題点も多いです。
そりゃそうでしょうなぁ。どっちの NIC から出ていくかわからないですし、リゾルバは正しく動作してくれないんでしょうな。

例えば NIC が ens160 と ens32 の二つがあった場合以下のコマンドを打ったとします。

ip link set dev ens160 master vrf0
ip link set dev ens32  master vrf1

この場合、二つの NIC でそれぞれ個別のルーティングテーブルを持つことになるんですが、

ping -I vrf0 IP アドレスもしくは ping -I vrf1 IP アドレス

では到達性があります。しかし、以下のように pingすると到達性がありません。

ping -I vrf1 FQDN

ルーティングテーブルが VRF のみになると DNS を引きに行ってくれないんですね。なので、 NIC が二個の場合は一個の VRF を設定するのみで、もう一個の NIC は default な ip [-6] route list で表示してくれる経路が必要になります。

二個の NIC で二個の VRF を設定すると netstat -nr や ip route list では何も表示してくれなくなります。

ループバックに IP アドレスとか記載できるのかな？ lo:1 とか書けるのかな？そこまで試していませんが。

さてと。ここまで来て VPF の環境設定が終わりましたが、実際に利用してみるとやはり中々楽しいですね。
Cisco ルータの場合、 VRF は interface mgmt で動作することが多々あるんですが、今回は L3 ルータを作る。と、いう目的ではなく、サーバのポリシールーティングのかわりに VRF を利用してみた。と、いう感じですね。

ip [-6] route list で表示されるルーティングテーブルは、サービス側で利用し、マネジメントポート (今回はそれを LAN-Zone と呼んでます) で VRF を利用し、サービスセグメントのルーティング情報とは混在させないで通信を行う。こんな時に必要な機能だと思われます。

僕はこのあと VRF を利用しつつ、ウェブサーバを起動して CentOS 6.9 を引退させようと考えています;-)。

FreeBSD の setfib もここまで動いてくれると嬉しいのですが、そこまで到達していないのと、そもそも setfib は IPv6 が動かないので、今の所、僕の環境ではまるで使い道が無い・・。orz

FreeBSD でポリシールーティング。

7月 182017

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの？って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら？その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな？

設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう？ fib はインターフェースとリンクしなくて良いのかな？不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら？

ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

tcsh で systemctl や service をタブキーで補完。

7月 132017

systemctl ってのは Linux の新しいシステムの systemd 由来のコマンドですね(この辺りの言い回し、正しくないかも;-)。
つい最近になって CentOS7 を利用し始めたので /etc/init.d/hoge restart とかできなくなって驚いていたんですけども。

じゃぁ、/etc/init.d/ の下にあったのはどこに行ったのだ？と思い調べてみると /usr/lib/systemd/system/*.service というのがそのようですね。このファイルを利用して systemctl が start/stop をやってくれる。と、いうことのようです。

Linux のシェルは基本的に bash なので以下のファイルをダウンロードしてきて /etc/bash_completion.d/ の中に入れてあげると TAB キーで補完してくれるので幸せになれるようです。 bash 用の systemctl 補完用スクリプトですね。

https://raw.githubusercontent.com/terralinux/systemd/master/src/systemctl-bash-completion.sh

では、普段から tcsh を利用している人 (それはつまりは Linux が流行る前から UNIX をいじっていた人。と、いうことになるのかや？;-) や Linux でも tcsh をメインで利用している人はどうしたらえーねん？て、ことになるのですが、せっかくなので ~/.tcshrc に以下の設定を書いてみましょう。 (ウェブ上では多分切れているね・・orz。フル HD の全画面で表示してぇ・・。)

complete systemctl 'p/1/(start stop restart status reload enable disable kill ..etc..)/' 'n@*@`/bin/ls /usr/lib/systemd/system | grep service | sed -e "/:/d"`@'

tcsh には complete というコマンド(？)があるので、それで TAB の補完の設定ができます。

上記を ~/.tcshrc に書いて systemctl と打ったあと TAB を打つとまず start/stop などの文字列が表示され、その後 *.service をドドドと表示してくれることでしょう。途中の sshd.s で TAB キーを押しても補完してくれます。

これで tcsh をメインのシェルとして利用している人は幸せになれるのではないかと思われます;-)。

ところで、 FreeBSD の service も似たように TAB で表示したい。と、いう場合はどうするのか？以下の設定をやはり ~/.tcshrc もしくは /root/.cshrc に書くと幸せになれます。

complete service 'n@*@`/bin/ls /etc/rc.d /usr/local/etc/rc.d | sed -e "/:/d"`@' 'p/2/(start stop restart onestart onestop onerestart)/'

FreeBSD の起動スクリプトは /etc/rc.d/ や /usr/local/etc/rc.d/ の中に入っているのでその中をごっそりと ls している。と、いうことになります。

bash の場合は専用のスクリプトを用意したりしますが tcsh の場合は強引に /bin/ls で実装している。と、いうことですなぁ。

tcsh が好きで好きで手放せない。もしくは bash なんて使ってらんねーぜ。けっ。はたまた zsh なんて遅くて使い物にならん。と、いう方は今後も多分ずっと tcsh を使い続けるかと思いますが、その場合 systemctl や service で TAB キーを使いたい方は是非お試しください;-)。
また、他のコマンドでも TAB を利用して補完したい場合には complete コマンド(？)で定義することができます。

2017/07/27 加筆
もう 20 年くらい tcsh 使っているけど、 tcsh を利用するときに complete な一覧が書かれているファイルがあるのね。知らなんだぁ。

o. FreeBSD の場合
/usr/share/examples/tcsh/complete.tcsh
/usr/src/contrib/tcsh/complete.tcsh

o. ubuntu の場合
/etc/complete.tcsh

これを ~/.tcshrc の中で source /usr/share/examples/tcsh/complete.tcsh とかすると色々なコマンドで TAB で補完してくれるので幸せになれます。
僕のは場合は mv cp ln など、二個目のパラメータを TAB キーで抽出できなかったので、一部変更して $HOME に置きました。

ubuntu の人が作ってくれたファイルのようです。感謝。 m(_ _)m。
加筆ここまで

Raspberry Pi 二つ購入。

5月 022017

ゴールデンウィークのお楽しみ用に Raspberry Pi を二個購入しました。一個は Raspberry Pi 3 Model B で、もう一個は Raspberry Pi ZERO です。二個合わせて 5,000yenちょっと出た程度。

正規代理店の株式会社ケイエスワイで購入しました。
5,000yen 以上だと送料無料だというので二個買ってしまった。と、いう話なんですけども。

これで Raspberry Pi は 2,3,ZERO と三つになりました。

左から RPi2 -> RPi3 (ハイレゾ音源ボード装着) -> RPi ZERO と並んでいます;-)。

Raspberry Pi 3 Model B は volumio2 で利用予定です。オンボードの Wifi チップは FreeBSD では利用できませんが、Linux では利用できるので。ちなみに volumio2 でも利用可能です。おかげで USB な Wi-Fi が余ったので他の RPi に回せます。

今まで利用していた Raspberry Pi 2 Model B は自宅で FreeBSD マシンとして動作させるべく FreeBSD/arm 11.0-RELEASE をインストールしました。以前このブログでもエントリを書いているのでサクっと動作します;-)。

ports のコンパイル環境も母艦側を FreeBSD/amd64 10.1-R から 11.1-R にバージョンアップして、 qemu 側も新たに FreeBSD/arm 11.0-R 用のを作成したのでコツコツと最新の ports-CURRENT を更新して行きたいと思います。

最近の FreeBSD/arm 11.0-R は pkg install が利用できるのでずいぶんと楽にはなりましたね。ただ、ちょっと古い。そんな場合は以下の URL を覗いてみてください;-)。

http://distfiles.icmpv6.org/freebsd:11:armv6:32/latest/All/

と、いうことで、今回のネタは Raspberry Pi ZERO についてです。

Raspberry Pi ZERO は値段が 600yen で非常に手頃な値段です。外部接続には電源供給用の MicroUSB と、USB 機器接続用の MicroUSB のポートがあります。ディスプレーは MiniHDMI ポート、これはちょっと痛かった・・。 MicroHDMI ポートだと Diginnos DG-D08IWBと互換があるので嬉しかったのですが・・。

今回は HDMI への出力を諦め、シリアルコンソールを利用しました。

そもそも RPi ZERO には GPIO ピンがなくて穴が空いているだけです。なのでシリアルコンソール用のピンをハンダで付けてあげる必要があります。

まず、ピンの手配ですが、昔利用していた PC のサウンドカードから 3 本ほど調達しました。下の写真のような感じ。

うまく固定もしたのでこれを穴の中に通します。ハンダ付けはしません。ちょっとななめにすると接触するのでハンダ付けしなくとも利用できました。

OS は FreeBSD/arm 11.0-RELEASE をチョイス。イメージは以下を利用しました。

FreeBSD-11.0-RELEASE-arm-armv6-RPI-B.img.xz

ちなみに RPi2 では以下のイメージを利用します。

FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz

RPI2 のイメージも RPi ZERO で試しまたがブートしませんでした。

RPI-B なイメージを MicroSD に dd し SD カードを差し込んで電源オンっ!! 無事に起動したのであります。

起動時の情報は以下になります。

dmesg
sysctl -a

僕は MIcroUSB -> USB 変換ケーブルで USB Wi-Fi や USB NIC を付けてネットワークリーチャブルにしたあとリモートからの SSH と NFS で作業を実施。環境構築が完了したのでありました。

そーそー。 RPi ZERO の ports/packages は FreeBSD/arm 11.0-RELEASE RPI2 の環境で作成したものがそのまま動作しました。 RPi2 と ZERO ではブート用イメージファイルが違うので ports/packages も違うのかな？などと思ったのですが、どちらも 32bit なバイナリで、同一のものが動作します。幸せなことです;-)。

と、いうことで特に問題もなく RPi ZERO は FreeBSD/arm が動作しました。

値段が 600yen で、約 5cm ほどの最小の FreeBSD 環境が整った。と、いうことですね。ゴールデンウィークの暇つぶしにピッタリなおもちゃです;-)。

Volumio でシリアルコンソールを使うよ。

4月 192016

Raspberry Pi 2 に Volumio をインストールしてハイレゾ楽曲を再生して楽しんでいる環境が整ったのですが、そのために Raspberry Pi 2 の 40PIN には「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」を挿しました。これでコンソールは使えなくなるんですね。

せっかく Raspberry Pi 2 用に USB シリアルコンソールケーブルを購入しているので、これを Volumio で利用できれば嬉しいです。

IMG_3997_RPI2_Volumio_csl_1

しかし「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」にはピンが出っ張ってないので USB シリアルコンソールケーブルを接続することができない。

それならば。と、いうことでハンダでピンを取り付けてみました。 40PIN スロットの 6,8,10 番にピンを立てて、ここにシリアルコンソールを接続できるように改造です。電子工作だぁ。非常に簡単だけど;-)。

IMG_3990_RPI2_Volumio_csl_2

完了後はこんな感じになりました。これでサウンドカードモジュールと USB シリアルコンソールケーブルの両方が利用可能になりました。ぱちぱちぱち。

と、いうことで、早速 Volumio を起動しましょう。もう HDMI とかディスプレーとか必要ないしぃー。みたいな。まぁ、 Volumio は zeroconf が動作しているのでアクセスに関しては楽なんだけどね。

FreeBSD から以下のコマンドでシリアルコンソールを利用します。

$ cu -l /dev/cuaU0 -s 115200

オプションに指定する速度に注意でしょうかね。そして Raspberry Pi 2 に電源を投入するとコンソールが流れ始めます。おぉ。無事に使えるねぇ。良かった良かった。なんてのはつかの間。表示されるだけで入力できないじゃーん。 orz
Volumio はシリアルコンソールの設定が完結してないのかい？などと思い、ここから先は、起動した Volumio のシリアルコンソールを有効化していきます。

Volumio は OS に Ubuntu を利用しているので /etc/default/grub 辺りか？などと思い眺めますが x86 アーキテクチャではないのでそんなファイルは無いようです。

ふむ。

コンソールを使うなら /etc/inittab に何かしらの設定が必要だべ。とか思い眺めると『あ。多分のこの辺りを有効にすると行けそうだね。』という行が現れます。この辺りは FreeBSD とかやっていると知らない OS (『そこはかとなく、良く解らない OS』と言ったほうが良いか;-) でもなんとかなります。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

上記の上の行をとりあえず 115200 にして設定してみした。

# Example how to put a getty on a serial line (for a terminal)
#
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

変更後は kill -HUP 1 で反映させます。間違っても kill -9 1 とかしないように;-)。その後 ps で確認すると getty のプロセスが起動するので設定は有効になったようです。

しかし、相変わらずキーボードからの入力は受け付けてくれない状態。うむー。
多分 -L ttyS0 の部分が合っていないのだろうというのは容易に想像が付くのですが、では何を設定したら良いの？ってことになります。 Ubuntu で利用できる tty の種類は /etc/securetty の中に色々書いてあります。ただ、色々たくさん書いて有り過ぎますf(^^;;。

一応 dmesg | grep uart や dmesg | grep tty などのコマンドを打って確認。情報を色々仕入れます。あぁ。なるほどー。
dmesg | grep tty すると表示される Kernel command line: の行にどの tty を利用したら良いか書いてありますね。これを指定してみましょう。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
T0:23:respawn:/sbin/getty  -L ttyAMA0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1   9600 vt100

設定完了。今度は kill -HUP 1 してもダメだったので再起動してしてみましょう。

お。コンソールに文字が表示され、おぉ。ログインプロンプトが出てきましたっ!! やった;-)。

これで Volumio でもシリアルコンソールが使えるようになりました。ハンダ当てて改造した甲斐が有りました。
今後はディスプレーも USB キーボードも必要なくなります。一件落着です;-)。

あ。最後にですが、今回利用した Volumio は 1.55 になります。

ラズパイオーディオでハイレゾ。

4月 092016

なんか、いろんな人が書いているようなタイトルだなぁf(^^;;。

本当は前回の「ハイレゾ楽曲を作ってみました。」のエントリでネタは完了する予定でしたが、プレーヤーについて色々調べていたらハイレゾ携帯プレーヤーや USB DAC を購入するより Raspberry Pi 2 でハイレゾ音源を再生するほうがずっと安上がりだ。と、いうことが解り、早速試してみました。

手元には去年購入した Raspberry Pi 2 があり今でも FreeBSD/arm CURRENT が動作していますが、そいつを利用することにしました。
Raspberry Pi 2 に接続するハイレゾ対応のチップを購入し 40PIN にサクっと刺すとハイレゾ再生が可能になる。と、いうので amazon で「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」と、いうのを購入しました。

Raspberry Pi 2 に接続すると、こんな感じになります。

RPI2_I2S_volmio_1

購入したモノが届いたときには本体のみでマニュアルやネジ類は一切ついていません。
僕は PC を自作していた時期があったので、マザーボードと ATX ケースを固定するネジをたくさん持っていて、それを利用し I2S ボードの 40PIN の反対側に取り付けて安定性を確保しました。
そして、40PIN をグイグイと押しこみます。

以上で準備は完了です。

MicroSD に OS を準備しますが、今回は Volumio を利用しました。

あ。Volumio は 1.55 を利用していますが、最新版の Volumio2 が出るようです。最新版が出たらそっちに乗り換えるかもしれません。
Volumio2 RC1 を試してみたところ、僕の環境では見事にカーネルパニックしたので、今回は Volumio1.55 がターゲットです。

実は Raspberry Pi 2 を購入したあとに FreeBSD/arm と一緒に Volumio も試していたんです。このときはハイレゾに染まっていなかったのでフツーの音楽プレーヤーとして利用していたのですが、 USB の無線 LAN と Bluetooth ドングルが利用できなかったのでお蔵入りしていんですけどもね。

さてと。 Raspberry Pi 2 に I2S ボードを接続し MicroSD にも Volumio が入ったので早速起動します。

他のサイトを眺めていると System メニューの「I2S driver」と、いうメニューを “Hifiderry+” にすると音が出るよ。と、書かれていますが、それだけでは情報がかなり足りないですね。

RPI2_I2S_volmio_4

他にもう 1,2 ヶ所設定を変更する必要がありました。と、いうことで、まずは PlayBack メニューの「Audio Output」を指定します。

RPI2_I2S_volmio_3

default では “ALSA” になっていると思いますが I2S を利用する場合には “sndrpihifiberry” に変更する必要がありました。

その次にその下にある「Volume eontrol mixer」の設定をしますが “Hardware” を指定すると、Main メニューのボリュームサークルからから音量が変更できないので “Software” を選択します。

RPI2_I2S_volmio_2

以上三つを設定すると音が出て、ボリューム調整もできるようになります。

ふぅ。最初音が出なかったので、壊れているのか？と思ってしまったのですが、これで一安心;-)。

しかし、これでも音が出ない場合には UNIX 系な解決方法を試みます(僕は FreeBSD ユーザなので『Linux 的な』とは書かないです;-)。まずは Volumio に ssh でログインして dmesg で確認してみてください。
以下の行が出力されていればデバイス的には OS から認識されていて利用可能な状態なので、じっくりと設定とかメニューを見なおしてみてください。

snd-rpi-hifiberry-dacplus sound: pcm512x-hifi <-> 3f203000.i2s mapping ok

このメッセージが出力されていてもなお音が出ない場合は Ubuntu のコマンドで確認してみる手もあります。
僕は Lunix のマルチメディア系のコマンドはいまいち解らないんですけどねf(^^;;。

 # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ HiFi pcm512x-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
        : (中略)
card 1: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# lsmod | grep pcm
snd_soc_pcm512x_i2c     1689  1 
snd_soc_pcm512x         6340  1 snd_soc_pcm512x_i2c
snd_soc_core          140253  4 snd_soc_pcm512x,snd_soc_hifiberry_dac,snd_soc_hifiberry_dacplus,snd_soc_bcm2708_i2s
snd_pcm_dmaengine       3359  1 snd_soc_core
regmap_i2c              2354  1 snd_soc_pcm512x_i2c
        : (以下略)

Volumio では Network メニューから Wi-Fi の設定もできるのですが、僕の持っている USB Wi-Fi インターフェースでは設定してもまともに動きませんでした。なので、こちらも実機に ssh して wpa_supplicant の設定を直接手でしてしまいました。基本的に wpa_supplicant は Linux も FreeBSD も一緒なので使い回しの設定で OK でした;-)。

ネットワークの設定は結局 Volumio からではなく /etc/network/interfaces を直接 vi で編集してしまいました;-)。

あと、 I2S インターフェースを付けたのでオンボードのサウンドチップは要らないので削除します。 /etc/modules の中に書かれている snd_bcm2835 の行をコメントアウトすれば OK です。とは言っても /etc/modules には snd_bcm2835 しか書かれていないと思いますけども。

音楽系の話だけでなく、こーいう、UNIX 系技術者向けな話も中々良いですね;-)。

さてと。話をもとにもどします;-)。

今回購入した「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」と、いう製品は PCM5122 というチップで 384kHz/32bit に対応しているそうで、もうバッチリとハイレゾ対応ですね;-)。

ここにヘッドホンを接続したりスピーカーを接続して mora の楽曲を再生してみました。

最近は通勤の往復の電車の中では ZTE Blade Vec 4G にイヤホンを利用して音を聞いているのですが、その時には 256bit/44.1KHz/16bit な m4a も mora のハイレゾ楽曲も聞きます。なので耳には慣れている音なのですが、このモジュールを利用して音を試聴すると、音質豊かで驚きます。

『人間の耳は 20kHz 以上は聞こえないんだからハイレゾは意味ねんじゃね？』とか言われていますが、聞こえる周波数・聞こえない周波数なんて関係無いですね。耳に入ってくる情報量がうんと多いのには唖然とします。ボーカルのうしろにはこんなに色々な音が隠れていたのかーっ!! って、音が耳に飛び込んでくる感じ。

ハイレゾな楽曲をハイレゾな環境で聞くとすごい音がする。ってことがよぉーく解りました。

それにしても Raspberry Pi 2 ってすげーなー。とか、思うんですが、結局のところ、行き着くところは Linux で PCM5122 のチップのドライバが書かれていて、ちゃんと音が出る。ってのがすごいねぇ。などと思えるんですけどもね。
FreeBSD では PCM5122 のデバイスドライバは無いようだしなぁ・・。

と、いうことで Raspberry Pi 2 + PCM5122 + Volumio でハイレゾ再生が可能になり、楽曲(五曲しかないけど、更に二曲追加されました;-)とプレーヤーとスピーカー・イヤホンの全てが揃いました。

CD から flac にリッピングする環境もできたのでハイレゾ環境はこれで一通り揃った感じになります。ただ、 CD -> wav -> flac 変換の楽曲が “なんちゃってハイレゾ” 以下の楽曲データであるとは多分思うのですけどね・・:-|。

さてと。これからは、楽曲をどうして行くか？と、いう点のみが残るな・・。やはり泥沼からは抜け出せないかな？ orz

ちなみに、今回のハイレゾ環境整えるのにかかった費用ですが、今のところはイヤホン・スピーカー・I2S インターフェースのみなので 23,000yen 弱でしょうかね。 Raspberry Pi 2 は最初から持っていたのでカウントされていません。

これだけの金額でハイレゾ環境が整って一安心。と、いうのが素直な気持ちですが、自分的には

ハイレゾを楽しむならまずはイヤホン・その次にスピーカ、楽曲は色々試して、最後にプレーヤーを揃える

って感じかなぁ。と、思っております。最初にプレーヤーを買っても、ハイレゾで音が聞こえないので。最初にイヤホン買うと Windows10 で試せるし。みたいな感じでしょうか。

と、いうことで、今回のハイレゾに関するエントリは全て終了です;-)。

ふぅ。

QtWeb というブラウザの ports 作ってみました。

6月 192014

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ？

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね？って感じはします。

こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

PC に色々ブラウザが入っていると楽しいですよ;-)。是非、試してみてください。;-)

MZK-W300NH2 に RS232C 付けてみました。

5月 242012

最近というか、かなり前から秋葉原の色々なショップでジャンク扱いで販売している PLANEX の MZK-W300NH2 という BB ルータがあります。

今回はこれが 500yen で売っていたので買って来ました。実は一年くらい前に 1,000yen で一個購入しているので今回が二個目の購入。ということになります。

個人的には二個目のヤツに OpenWRT をインストールして、その上で OpenFLOW などを動かしてみようかなぁ。などと思った次第です。

で、今回はその手順を見ていくことにしましょう。とは言いつつも一回では到底終わりそうにないので多分数回に分けて書いていくことになります;-)。

まず、 MZK-W300NH2 で OpenWRT が動作するか確認する必要があります。 OpenWRT のサポートしている機器の一覧を確認します。ふむ。 MZK-W300NH2 はリストアップされていませんね。と、いうことで MZK-W300NH2 の機器の情報を取得します。

・アーキテクチャは ramips
・CPU は RT3052
・FLASH は 4MB

これだけ解れば大丈夫か。似たような機器としては Allnet の ALL0239-3G などが掲載されているのでトライです。以下の URL からそれらしいファームを拾ってきます。

http://downloads.openwrt.org/snapshots/trunk/ramips/

で、ウェブインターフェースからファームウェアを更新しようとするんですが、チェックではじかれますね。アタタタタ。と、いうことでしゅーりょー。orz。

何か手段は無いものか？などと調べていたら MZK-W300NH2 にはマザーボード上にシリアルのコネクタというか、結線できるものはあるようですね。ウェブで調べてみると以下のようです。右から順に以下のようになっています。

・3.3V
・TXD
・GND
・RXD

では、ここに RS232C のチップと D-SUB 9pin オスを付けてしまいましょう。こんな感じになりました;-)。写真を 2,3 枚。

こっちがアップの図。

でもって、こっちが D-SUB 9pin がニョキっと生えた図。

今回利用したチップは ADM3202 です。ただし、僕が付けられるわけもなく、会社の同僚で仕事が電子工作という人に付けてもらいましたf(^^;;。ありがとうございました。

さてと。今回の話はようやっとここから;-)。シリアルコンソールが付くと、もう何でもできるような気分になります。まずは電源投入してプロンプトなどを表示してみます。

U-Boot 1.1.3 (Nov 25 2008 - 16:46:30)

Board: Ralink APSoC DRAM:  16 MB
relocate_code Pointer at: 80fa8000

Please choose the operation:
0: Load ucos code to SDRAM via TFTP Client.
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
9: Load Boot Loader code then write to Flash via TFTP.

最初にメニューが出力され選択できるようになっています。メニュー画面の表示時間は一秒なので二秒後には 3: が動作し BB ルータとしての OS が起動してしまいます。なので、電源投入後はすかさず 4 を押します。

するとコマンドプロンプトが出てきます。

RT3052 # ?
?       - alias for 'help'
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cp      - memory copy
echo    - echo args to console
erase   - erase FLASH memory
help    - print online help
loopback   - Ralink eth loopback test !!
md      - memory display
mdio   - Ralink PHY register R/W command !!
mm      - memory modify (auto-incrementing)
mw      - memory write (fill)
nm      - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
spicmd  - read/write data from/to eeprom or vtss
tftpboot- boot image via network using TFTP protocol
version - print monitor version

なるほど。こんなコマンドがサポートされているのね。で、プロンプトから操作するときのの情報を知るには printenv コマンドを実行します。

RT3052 # printenv
bootcmd=tftp
bootdelay=2
baudrate=57600
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=10.10.10.123
serverip=10.10.10.3
preboot=echo;echo
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):\
$(gatewayip):$(netmask):$(hostname):$(netdev):off
addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate)\
ethaddr=$(ethaddr) panic=1
flash_self=run ramargs addip addmisc;bootm $(kernel_addr)¥
$(ramdisk_addr)
kernel_addr=BFC40000
u-boot=u-boot.bin
load=tftp 8A100000 $(u-boot)
u_b=protect off 1:0-1;era 1:0-1;cp.b 8A100000 BC400000¥
$(filesize)
loadfs=tftp 8A100000 root.cramfs
u_fs=era bc540000 bc83ffff;cp.b 8A100000 BC540000 $(filesize)
test_tftp=tftp 8A100000 root.cramfs;run test_tftp
stdin=serial
stdout=serial
stderr=serial
ethact=Eth0 (10/100-M)

Environment size: 783/65532 bytes
RT3052 #

なるほど。tftp の設定とか、FLASH の扱い方とか設定できますね。ウェブインターフェースでイリーガルなファームウェアを更新するとガードがかかってできませんが、 tftp サーバから持ってきてブートするともしかしたら OpenWRT がブートするかもしれないですね。

と、いうことで第一回目は終了です;-)。 MZK-W300NH2 にシリアルポート付けたぜーっ。ってのが第一回目だったりします。それにしても RS232C のチップ埋め込んでハンダ当てて色々やるのは随分と敷居が高いですよね。

で、こーいうのを見つけました。

UART(3.3V)-RS232C変換モジュール内蔵コネクタケーブル

D-SUB 9pin コネクタの中に RS232C チップが最初から埋め込まれていて、伸びたケーブルをマザーボードのピンに何らかの手段で接続すれば良いだけ。と、いう非常に簡単なモノです。ただ、これをどうやってマザーボードに固定もしくは接触させるかを考える必要はあるかと思いますけどね。

それにしてもシリアルコンソールがあるといきなりワクワクしてしまいますね。後は tftp サーバからファームウェアをダウンロードしてブートできれは良いだけになりました。とは言いつつ、ファームウェアを作らなければならないわけでして。それについては上にも書きましたが次回以降で;-)。

次回があるか分かりませんがf(^^;;。

tacacs+ + MySQL な ports。

3月 112010

最近の tacacs+ は x86_64 対応ってのが(あんまり)無いのねぇ。その昔の tacacs+ のコードってのは x86 向けなので x86_64 上でコンパイルすると、随分色々なソースのコードを書き換えなければならない。

幸いにして FreeBSD には ports で net/tac_plus-libradius ってのがあるのですが、こいつは tac_plus.F5.0.0.alpha.tar.gz と言うソースコードを使っていて、このバージョンのソースコードは色々問題もあるんだけど、radius・LDAP、そして MySQL に対応している。なおかつ、FreeBSD/amc64 でも make が通るので非常に嬉しいのであります;-)。

書き出しの「x86_64 対応ってのが(あんまり)無いのねぇ。」ってのは外部のツールを使って管理する tacacs+ のソースコード。って意味です;-)。

net/tac_plus-libradius な tacacs+ は radius サーバと連携するように特化されているみたいなので、MySQL サーバに接続できる版の ports を作ってみました。以下の URL に転がしておきます。

http://www.icmpv6.org/Prog/FreeBSD_ports/ports-tac_plus-mysql-20100311.tgz

make install ができて、デーモンが起動したことは確認していますが、激しく使い込んではいないのでもしかしたら何かあるかもしれません。その場合はソースコードを見直してください(^^;;。

後、上にも書きましたが、そもそも元祖となる tacacs+ のコードは x86_64 に対応してないので随分と改修が必要です。Linux で make する時は随分苦労するでしょうねぇ。と、言うことで Linux 版のパッチも書いておきました。

http://www.icmpv6.org/Prog/Linux_x86_64-tac_plus.F5.0.0.alpha.patch.bz2

Centos5.4 ですけど、こちらも一応 make は通るようにて、起動までは確認しました。 Linux の x86_64 で tacacs+ と MySQL を連携したシステムを構築してみたい方、試してみてください。色々動かない場合はソースコードを見直して頂ければと思います(^^;;。

あ。見直して更新したソースコードは是非頂けると嬉しいです。宜しくお願いしますf(^^;;。

apache で Proxy を作ってみた。(3)

7月 232009

まさか三回目を書くとは思いもしませんでした・・。apache ベースで作成したキャッシュ用 Proxy サーバですが、設定に問題があり無事に動作していたのは約一ヶ月半ほど・・。あまりにも情けないので、ちょっと書いておくことにします。

今回は第一回目のネタを参照する必要があります。第二回目の掲載はこちら。

さて、二回目にまとめたことで apache の Proxy サーバは mod_cache を利用してディスク上にキャッシュして行くことができたのだけど、運用してしばらくしたら error.log に以下のメッセージが出力されるようになってきた。しかも大量に・・。orz (長いので改行しています)

[warn] (2)No such file or directory: disk_cache:
rename tempfile to hdrsfile failed:
/data/httpd/cache/aptmp6ac9NS -> /data/httpd/cache/ASm@m/8xF@v/7XxKH/X8yCPfQ.header

よくよく調べてみると、サブディレクトリがもう作れない状態になっているらしい。なので、これ以上はディクス上にデータをキャッシュをできない状態になっている。と言うメッセージが延々と error.log に出力されている状態。

/data/httpd/cache の下にディレクトリが 32,000 個できている。と言う状態なんですねー。Linux では一つのディレクトリの下には 32,000 個しかディレクトリが作れないそうです。 /usr/include/linux/ext3_fs.h の以下の行がまさしくそれ。

#define EXT3_LINK_MAX           32000

でもって 32,000 個のサブディレクトリのあるディレクトリで mkdir すると Too many links. mkdir: cannot create directorys と言われて怒られる。うひー。

と、言うことで、僕はこの上限 32,000 と言う値を知らなかったのでありました。

愕然としつつ httpd.conf の設定を見直します。第一回目に書いた設定では以下のように記述していました。抜粋です。

<IfModule mod_disk_cache.c>
:
    CacheDirLevels      3
    CacheDirLength      5
</IfModule>

ディレクトリの深さは三階層、ディレクトリの文字列は五文字。この「五文字」と言うのは簡単に 32,000 を超えてしまうのですね。

ディレクトリにランダムに利用される文字は A-Z,a-z,0-9 と一部の特殊文字で約 80 個位と想定した場合、五文字と言うのは 80^5 通りあるので、こらー簡単に 32,000 個を超えてしまいます。 32,000 個以内に抑えるのは CacheDirLength は 2 を指定しなければならない。3 を指定したとしても 80*80*80=512,000 個のディレクトリが作成されることになります。あれー・・。

/data/httpd/cache の下には 80*80=6,400 個にしてその下の階層を深くしたほうが良いと言うことなんですねぇ・・。

ディレクトリを自動生成してくれるアプリケーションの場合、ディレクトリ長は二文字にしないと簡単に 32,000 個があふれてしまう。今後はこれを頭の片隅に入れておきたいと思います。

以前のエントリー

		running-dog.net。しかし、自分が一番落ち着かない。かけまわっている子犬のような状態。そんな毎日をブログで綴ってみました。 FreeBSD・MacOSX・UNIX・PC・プログラム・iPhone(iOS)・Android ネタなど技術的・趣味的なネタについて色々書いてみたいと思います。
		From 18.206.76.226

2021年7月
日	月	火	水	木	金	土
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31