FreeBSD 8.0 がリリースされました。そこで我が家のサーバーをようやくバージョン 6.4 から 7.2 へ引き上げることとしました。
取り合えずcsupのsupfileの設定を変更してcvsupを実行します。新しいバージョンへ置き換えることからいつもより時間がかかっていました。
build中に問題が発生しないように/usr/objをディレクトリを綺麗さっぱりと消去してbuildworldから作業を開始しました。
２種類のマシンでworldをbuildする処理時間です。
pentium3 1GHzのマシンで3時間33分の作業時間となりました。
11102.251u 1055.167s 3:33:02.19 95.1% -1334+1469k 43480+5261io 3429pf+0w
pentium2 530MHzのマシンで8時間15分ぐらいです。
25318.128u 2794.628s 8:15:44.54 94.5% -606+212k 69681+5128io 34758pf+24w
pentium3 800MHzのマシンで5時間9分ぐらいです。
16177.483u 1772.411s 5:09:45.76 96.5% 750+-153k 67228+5256io 28690pf+24w
pentium4 2.2GHzのマシンで1時間53分ぐらいです。
5776.975u 577.756s 1:53:05.84 93.6% -1080+-1811k 38889+5448io 5038pf+0w
これからじっくりとカーネルをビルドします。
ついでのkernelのbuildも終了しましたので処理時間の報告を。
pentium3 1GHzのマシンで1時間10分の時間となりました。
3708.510u 313.423s 1:10:51.49 94.6% -4852+2707k 15682+8064io 156pf+0w
pentium2 530MHzのマシンで2時間45分ぐらいです。
8614.701u 846.911s 2:45:45.34 95.1% 1065+-2012k 26676+8027io 570pf+0w
pentium4 2.2GHzのマシンで0時間30分ぐらいです。
1527.591u 127.273s 29:52.21 92.3% 5938+2340k 12133+1622io 15pf+0w
pentium3 800MHzのマシンで1時間24分ぐらいです。
4530.692u 417.570s 1:24:49.60 97.2% -2924+2295k 18384+1590io 310pf+0w
そしてinstallkernelを実行すると" file isn't dynamically-linked "と大量に表示されて驚かされます。バージョン6系から7系へアップグレードする時の通過儀礼らしいです。そしてそのままrebootして再度ログインするとちゃんとカーネルは 7.2 へとアップグレードされていました。
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.2-RELEASE-p4 (GENERIC) #0: Sun Nov 29 17:39:34 JST 2009
Welcome to FreeBSD!
このあとinstallworldを行って、mergemasterを実行します。mergemasterの実行の前に必ず"/etc"をバックアップしておきます。ついつい忘れがちなものです。
# cd /usr/src
# make installworld
# cp -Rp /etc /etc_back
# mergemaster -Ui ------注1
# reboot
"portupgrade -af"でインストールしてあるソフトのすべてを再ビルドとインストールする。このときruby関係でトラブルが発生しやすいので、rubyの部分だけ先にビルドしておくことが吉！
再度マシンを立ち上げ直した後、古いライブラリなどを削除しておく。ただし全てのソフトが正常に稼働することを確認しておくことが必要です。これでライブラリを削除してしまうので、アップグレードが完了する前に行うとportupgradeをするとライブラリ不足で悩まされることとなります。
# cd /usr/src
# make delete-old ---------注2
# make delete-old-libs ----注2
# reboot
再度のマシン立ち上げ直しで無事ログイン出来て、各部の動作に問題なければシステムまわりのアップグレードは終了です。
注1：mergemasterでの問い合わせで一番多いのでは、どれを残してどれをインストールするかです。"-Ui"オプションでは、定型的な変化のものを自動的にインストールしてくれて、判断がつかないものを問いあわせてくれます。本当に必要か不要かの判断ができない場合、"d"を押してインストールしない選択にしましょう。passwordやgroupなどの間違っても新しいファイルをインストールしてはいけないものがインストールされる心配がありません。
注2：問い合わせが半端無く多いです。面倒なので以下の方法で一括して"yes"と返事しましょう。
# yes | make delete-old
# yes | make delete-old-libs
2009年11月29日日曜日
2009年11月14日土曜日
Willcom WX310K で PPP 接続 (3)
Willcom WX310K で PPP 接続が出来るようになって、ブラウザで各種のウェブサイトを閲覧して回ってみていることでしょう。しかし異常な通信の遅さに驚いていませんか？私も驚きました。Willcom WX310K 本体だとここまで遅くないからです。
原因はもちろん基本的な通信速度の遅さ（32kbps or 64kbps）なのですが、さらにパケットの応答の遅さも原因となっています。
さらに DNS の名前解決でも通信の反応が遅くなっているようです。ブラウザの通信ステータスの部分を観察していると「アドレス解決をしています」の文字が頻繁に、それも数秒間にも渡って見られます。
IPv6対策
IPv6の接続でも DNS の名前解決で時間がかかることがあることが知られていますが、debian-lennyでは ppp 接続では問題はないようです。
がしかし、念のためにIPv6の動作を停止させておきました。WX310Kで通信をするノートパソコンなどでは当分 IPv6 は必要ないと思われるからです。
/etc/modprobe.d/aliases の中の "alias net-pf-10 ipv6" の項目を "alias net-pf-10 off"に変更します。これでOSを再起動させれば IPv6 が無効になっているはずです。試しにスーパーユーザーになって ifconfig のコマンドを実行すると LAN の eth0 の項目にあった IPv6 アドレスなどが表示されなくなっているはずです。
mdns4(マルチキャストDNS)対策
それから DNS の名前解決で時間がかかっている理由にmdns4(マルチキャストDNS)も悪さをしているようです。/etc/nsswitch.conf を修正して mdns4 を利用しないようにします。
/etc/nsswitch.conf を以下のように修正します。これで hosts などの files を検索した後、resolv.conf にある DNS を検索するようになります。
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
↓
hosts: files dns
以上の対策で随分と通信が速くなったように感じます。しかし ping コマンドを IP ではなくドメイン名で行うとパケットロスが異常に発生していることが判ります。
以下は一例です。
IP で ping を実行した場合
# ping 125.1.152.139
PING 125.1.152.139 (125.1.152.139) 56(84) bytes of data.
64 bytes from 125.1.152.139: icmp_seq=1 ttl=51 time=562 ms
64 bytes from 125.1.152.139: icmp_seq=2 ttl=51 time=237 ms
64 bytes from 125.1.152.139: icmp_seq=3 ttl=51 time=233 ms
64 bytes from 125.1.152.139: icmp_seq=4 ttl=51 time=228 ms
64 bytes from 125.1.152.139: icmp_seq=5 ttl=51 time=226 ms
^C
--- 125.1.152.139 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 226.181/297.635/562.011/132.243 ms
ドメイン名で ping を実行した場合
# ping tatsuya.dnsalias.com
PING tatsuya.dnsalias.com (125.1.152.139) 56(84) bytes of data.
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=2 ttl=51 time=238 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=4 ttl=51 time=239 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=6 ttl=51 time=219 ms
^C
--- tatsuya.dnsalias.com ping statistics ---
8 packets transmitted, 3 received, 62% packet loss, time 21796ms
rtt min/avg/max/mdev = 219.281/232.374/239.428/9.267 ms
なんとドメイン名で ping を実行した場合には、一つおきにしかパケットが返ってきませんでした。"icmp_seq=" の文字のところの数字が何番目の通信かを示しています。この例では 2,4,6,と偶数番目のパケットしか返ってこなかったわけです。
この状態では上手く通信ができません。パケットロスが大発生している状況だからです。これは DNS の名前解決の応答に時間がかかっているためです。検証には "ping -n ドメイン名" のコマンドで調べることができます。IP で ping を実行した場合と同様の結果が得られます。
応答時間の問題からくる DNS の名前解決の問題対策
この応答時間の問題からくる DNS の名前解決の問題対策は簡単です。単純に DNS の名前解決をキャッシュしておけばよいことなのです。一般的な Linux ディストリビューションでは、通信の度に DNS の名前解決を行っています。この DNS の名前解決をキャッシュで行ってしまえば、レスポンスが改善されるはずです。
DNS の名前解決をキャッシュすることとして、ネット上では "dnsmasq" を使う方法と "NSCD" を使う方法が紹介されています。両方を確かめたところ、NSCD の方が設定などの面で楽だと判断しました。ここでは NSCD による方法を紹介します。
NSCD は aptitude でインストールしました。
# aptitude install nscd
NSCD がインストールされると、各種設定ファイルなども一緒にインストールされます。この中で、"/etc/nscd.conf" の中にある "hosts" の項目が "no" になっているのを "yes" に変更しておきます。
これで DNS の名前解決で得られた IP がキャッシュされることとなり、何度も DNS へ問い合わせを行って無駄な時間を使ってレスポンスが低下するのを防ぎます。
NSCD の設定を変更したら、NSCD のデーモンを再起動させておきます。
# /etc/init.d/nscd restar
この状態で無駄な DNS の問い合わせがなくなり、通信がかなり改善されていると思います。
Willcom の端末を使って通信をしている人で通信速度に不満のある人は試してみては如何でしょうか？
原因はもちろん基本的な通信速度の遅さ（32kbps or 64kbps）なのですが、さらにパケットの応答の遅さも原因となっています。
さらに DNS の名前解決でも通信の反応が遅くなっているようです。ブラウザの通信ステータスの部分を観察していると「アドレス解決をしています」の文字が頻繁に、それも数秒間にも渡って見られます。
IPv6対策
IPv6の接続でも DNS の名前解決で時間がかかることがあることが知られていますが、debian-lennyでは ppp 接続では問題はないようです。
がしかし、念のためにIPv6の動作を停止させておきました。WX310Kで通信をするノートパソコンなどでは当分 IPv6 は必要ないと思われるからです。
/etc/modprobe.d/aliases の中の "alias net-pf-10 ipv6" の項目を "alias net-pf-10 off"に変更します。これでOSを再起動させれば IPv6 が無効になっているはずです。試しにスーパーユーザーになって ifconfig のコマンドを実行すると LAN の eth0 の項目にあった IPv6 アドレスなどが表示されなくなっているはずです。
mdns4(マルチキャストDNS)対策
それから DNS の名前解決で時間がかかっている理由にmdns4(マルチキャストDNS)も悪さをしているようです。/etc/nsswitch.conf を修正して mdns4 を利用しないようにします。
/etc/nsswitch.conf を以下のように修正します。これで hosts などの files を検索した後、resolv.conf にある DNS を検索するようになります。
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
↓
hosts: files dns
以上の対策で随分と通信が速くなったように感じます。しかし ping コマンドを IP ではなくドメイン名で行うとパケットロスが異常に発生していることが判ります。
以下は一例です。
IP で ping を実行した場合
# ping 125.1.152.139
PING 125.1.152.139 (125.1.152.139) 56(84) bytes of data.
64 bytes from 125.1.152.139: icmp_seq=1 ttl=51 time=562 ms
64 bytes from 125.1.152.139: icmp_seq=2 ttl=51 time=237 ms
64 bytes from 125.1.152.139: icmp_seq=3 ttl=51 time=233 ms
64 bytes from 125.1.152.139: icmp_seq=4 ttl=51 time=228 ms
64 bytes from 125.1.152.139: icmp_seq=5 ttl=51 time=226 ms
^C
--- 125.1.152.139 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 226.181/297.635/562.011/132.243 ms
ドメイン名で ping を実行した場合
# ping tatsuya.dnsalias.com
PING tatsuya.dnsalias.com (125.1.152.139) 56(84) bytes of data.
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=2 ttl=51 time=238 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=4 ttl=51 time=239 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=6 ttl=51 time=219 ms
^C
--- tatsuya.dnsalias.com ping statistics ---
8 packets transmitted, 3 received, 62% packet loss, time 21796ms
rtt min/avg/max/mdev = 219.281/232.374/239.428/9.267 ms
なんとドメイン名で ping を実行した場合には、一つおきにしかパケットが返ってきませんでした。"icmp_seq=" の文字のところの数字が何番目の通信かを示しています。この例では 2,4,6,と偶数番目のパケットしか返ってこなかったわけです。
この状態では上手く通信ができません。パケットロスが大発生している状況だからです。これは DNS の名前解決の応答に時間がかかっているためです。検証には "ping -n ドメイン名" のコマンドで調べることができます。IP で ping を実行した場合と同様の結果が得られます。
応答時間の問題からくる DNS の名前解決の問題対策
この応答時間の問題からくる DNS の名前解決の問題対策は簡単です。単純に DNS の名前解決をキャッシュしておけばよいことなのです。一般的な Linux ディストリビューションでは、通信の度に DNS の名前解決を行っています。この DNS の名前解決をキャッシュで行ってしまえば、レスポンスが改善されるはずです。
DNS の名前解決をキャッシュすることとして、ネット上では "dnsmasq" を使う方法と "NSCD" を使う方法が紹介されています。両方を確かめたところ、NSCD の方が設定などの面で楽だと判断しました。ここでは NSCD による方法を紹介します。
NSCD は aptitude でインストールしました。
# aptitude install nscd
NSCD がインストールされると、各種設定ファイルなども一緒にインストールされます。この中で、"/etc/nscd.conf" の中にある "hosts" の項目が "no" になっているのを "yes" に変更しておきます。
これで DNS の名前解決で得られた IP がキャッシュされることとなり、何度も DNS へ問い合わせを行って無駄な時間を使ってレスポンスが低下するのを防ぎます。
NSCD の設定を変更したら、NSCD のデーモンを再起動させておきます。
# /etc/init.d/nscd restar
この状態で無駄な DNS の問い合わせがなくなり、通信がかなり改善されていると思います。
Willcom の端末を使って通信をしている人で通信速度に不満のある人は試してみては如何でしょうか？
Willcom WX310K で PPP 接続 (2)
Willcom の WX310K で PPP 接続が前回までに出来るようになりましたが、接続後2分で接続が切れてしまいます。今回はこの対策を行います。
/etc/ppp/options の "lcp-echo-failure" の項目を "0" に変更します。なおファイルの変更はスーパーユーザーになって行います。
lcp-echo-failure 0
ここはモデムの通信が生きているかどうかを判定するものですが、これを無効にします。これで2分を越えて接続が出来れば大丈夫です。なおモデムの通信が途絶えても検知することができません。通信が停止したと思ったらWX310Kの画面で接続の有無を確認することとなります。
/etc/ppp/options の "lcp-echo-failure" の項目を "0" に変更します。なおファイルの変更はスーパーユーザーになって行います。
lcp-echo-failure 0
ここはモデムの通信が生きているかどうかを判定するものですが、これを無効にします。これで2分を越えて接続が出来れば大丈夫です。なおモデムの通信が途絶えても検知することができません。通信が停止したと思ったらWX310Kの画面で接続の有無を確認することとなります。
2009年11月13日金曜日
Willcom WX310K で PPP 接続 (1)
Puppy Linux で Willcom の WX310K を使用して PPP 接続をしていましたが、debian linux (lenny) でも PPP 接続をしてみました。ここでは接続までの手順を備忘録として書きました。debian linux で PPP 接続をするときの参考にしてください。
pppd を直接コマンドラインで打ち込むのもせっかくのデスクトップがもったいないので、gnome-ppp をインストールしました。インストールはいつものaptitudeを使って一発導入です。gnome-ppp と一緒に ppp も一緒にインストールされると思います。
gnome-ppp を起動させて、初期設定を行います。
まずは基本的なユーザー名やパスワード、アクセスポイントの電話番号の入力です。アクセスポイントの電話番号の前には "DT" をお忘れ無く。次に "Setup" のボタンを押して各種の設定を行います。
まず WX310K を USB ケーブルでパソコンと接続しておきます。次に "Detect"(検出) のボタンを押して WX310K を USB モデムとして認識しているか確認します。通常は /dev/ttyACM0 として認識されます。そして "Analog Modem" と認識しますが、ここで "ISDN Modem" に変更しておきます。"Init Strings" は "Init 2 ATZ" , "Init 3 ATS0=0" としておきます。
次に "Networking" のタブを開きます。ここではIPやDNSの設定を行いますが、プロバイダから指定されたものを設定します。
次に "Options" のタブを開きます。"Check defaut route" と "Ignore terminal strings(stupid mode)" へチェックを入れます。これで gnome-ppp での設定は終了です。このまま "Connect"（接続）のボタンを押しても各種のエラー表示が出て、接続出来ないものと思います。それは pppd が一般ユーザーに開放されていないからです。
本当はセキュリティ上問題があると思われますが、以下の方法で pppd や pppd が使うファイルの属性を変更して、一般ユーザーからも使用できるようにします。
pppdの属性変更
属性変更はスーパーユーザーとなって行います。
# ls -l /usr/sbin/pppd
-rwsr-xr-- 1 root dip 269156 2008-11-29 02:48 /usr/sbin/pppd
# chmod o+x /usr/sbin/pppd
# ls -l /usr/sbin/pppd
-rwsr-xr-x 1 root dip 269156 2008-11-29 02:48 /usr/sbin/pppd
pap-secrets , chap-secrets , peers のファイルやディレクトリの属性変更
# chmod 666 /etc/ppp/pap-secrets
# chmod 666 /etc/ppp/chap-secrets
# chmod 777 /etc/ppp/peers
これで gnome-ppp の "Connect" ボタンを押して接続を確認してください。接続が出来れば終了です。
もちろんのことですが、この接続の前に LAN が接続されているならば、この LAN を解除しておく必要があります。一番手軽で確実なのは LAN ケーブルを抜くことです。ケーブルを抜かなくても標準的な gnome でデスクトップを使用しているならば、右上にあるパソコンが二台重なったような LAN のアイコンを右クリックして "ネットワークの有効化" のチェックマークを外すと LAN 接続が解除されます。