今まであんまりチェックしていなかったのだけど、Webブラウザのプロキシ設定を自動的に行なってくれるという、proxy.pacを自宅内でも用意してみた。
詳しい書式は、下記を参照のこと。

• Proxy Client Autoconfig File Format

うちの環境用に準備したのは、次の通り。

nexus01:~# more /var/www/proxy.pacfunction FindProxyForURL(url,host) {	if (isInNet(host, "172.16.0.0", "255.255.255.0") || dnsDomainIs(host, ".local.downtown.jp"))		return "DIRECT;"	else	if (isInNet(host, "218.219.149.232", "255.255.255.248") || dnsDomainIs(host, ".downtown.jp"))		return "DIRECT;"	else		return "PROXY proxy.local.downtown.jp:3128; DIRECT";}

内部ネットワークと自分のところに割り当てられているグローバルIPにあるサーバについては、ダイレクトにアクセスするように書いたのだけど、もしかしたら2つある"if (isInNet(host, 〜"のところは1行でいいかもしれない。
あとは、最後に使わせたいプロキシサーバとそのポート、そのプロキシサーバが使えない状態でもアクセスできるように"DIRECT"と書いておく。こうしておくとWebブラウザ側が状況に応じて切り替えてくれるみたい。

で、このファイルを"http://172.16.0.254/proxy.pac"といった形でアクセス出来るように配置すれば準備完了。
このへんはWebサーバのログでチェックしてもいいですな。実際のログはこんな感じで出てくる。

172.16.0.101 - - [23/Feb/2012:23:35:38 +0900] "GET /proxy.pac HTTP/1.1" 200 532 "-" "Evernote/221382 CFNetwork/520.3.2 Darwin/11.3.0 (x86_64) (Macmini4%2C1)"172.16.0.101 - - [23/Feb/2012:23:35:57 +0900] "GET /proxy.pac HTTP/1.1" 200 532 "-" "WebProcess/7534.54.12 CFNetwork/520.3.2 Darwin/11.3.0 (x86_64) (Macmini4%2C1)"172.16.0.101 - - [23/Feb/2012:23:35:57 +0900] "GET /proxy.pac HTTP/1.1" 200 532 "-" "Safari/7534.54.12 CFNetwork/520.3.2 Darwin/11.3.0 (x86_64) (Macmini4%2C1)"172.16.0.101 - - [23/Feb/2012:23:36:56 +0900] "GET /proxy.pac HTTP/1.1" 200 506 "-" "Safari/7534.54.12 CFNetwork/520.3.2 Darwin/11.3.0 (x86_64) (Macmini4%2C1)"172.16.0.101 - - [23/Feb/2012:23:36:57 +0900] "GET /proxy.pac HTTP/1.1" 200 506 "-" "WebProcess/7534.54.12 CFNetwork/520.3.2 Darwin/11.3.0 (x86_64) (Macmini4%2C1)"

ソフトによっては、ネットワークにアクセスに行くたびに、proxy.pacを読み込んでいるみたい。

実運用では、proxy.pacの配置場所を、ローカルネットワークだけにアクセス許可するような設定を、Webサーバにしておく必要はあるかもしれないので、そのあたりはそれぞれの事情に合わせて、ということで。

多分、ネットワークをバイパスする部分をソフトウェア的に設定変えてやらんといけないじゃないかという線が濃厚です。

[From 【人柱】バイパス機能付きのNICを手に入れてみた、が... | Hardware - Soukaku's HENA-CHOKO Blog]

ということで、色々と探し回ったけど、「ドライバ類がやっぱりメーカに頼まなくちゃいけないのかなぁ〜」という流れになって、メーカサイトにある登録フォームで登録をしてみたら、日本の代理店からメールが来たでざるよ。

結局、

いつもなら、gogocクライアント自体が再接続してくれたり、手動で再接続したりしているのだけど、今日に関しては全然ダメな状態。

[From gogoNET/Freenet6に繋がらない | Network - Soukaku's HENA-CHOKO Blog]

どうなったかというと、あんまりにも繋がらないので、gogoNETのディスカッションボードに書きこみをしてみたら、「まぁ、もちつけ。少し待ってから接続してみろ。」的なコメントが付いたので、そのとおりに素直にgogocとradvdをkillして、8時間ぐらいほっといて、再接続してみたら...。
あら繋がった、という感じで、一応は復旧していたりします。

でも、1日1回、トンネルが落ちるのは、相変わらず。ま、仕方ないよねと思いつつ使ってますです。

ヤフオクをつらつらと眺めていたら、聞いたことがないメーカー製のNICが出品されているのを見つけた。
とりあえず、メーカーのサイトでスペックを確認してみたら、

Niagara 2265 is designed with a built-in programmable bypass circuit to provide maximum up time for the network. The bypass circuit takes the Niagara 2265 ports off line in case of either power or software failure. The bypass circuit works in absence of power.

[From Niagara 2265 - Bypass Network Interface Card - PCI-express Dual Copper Giga bit NIC with Failover / Network Bypass for Network reliability and Security appliances]

このNICを挿したサーバがトラブった時に、ネットワークを止めないためにバイパスする機能が付いているというものらしい。
バイパス機能を持ったNICの存在は知っていたのだけど、実物を確認したのは初めてということもあって、とりあえず様子をうががっていたのだけど、やっぱりやっぱり入札は無い。

「Intelの82571EBが載ってるし、最悪デュアルポートNICとして使えるでしょ？」ってことで、ヒトバシラーとなるべく、締め切りギリギリで応札して無事確保。
色々手続きを終えて、ブツが届いたのが今朝だったので、早速ごそごそと取り付けてみたんだが...。

TwitterのWeb UIがずいぶん変わって、まだちょっと慣れないところはあるけど、個人的には

なんだ、随分変わったな、Webインタフェース。

-- Soukaku (@Soukaku) February 14, 2012

って、感じでtweetを引用するための仕組みが、標準で入ってくれたのは、歓迎したいな。
ちょっと前までは、結構めんどくさかったんだもん。

1日1回ぐらいのペースでgogoNET/freenet6へのトンネルが、朝から繋がらない。

2012/02/14 18:38:00 I gogoc: Establishing connection to server sydney.freenet6.net using reliable UDP.2012/02/14 18:38:00 I gogoc: Using TSP protocol version 2.0.2.2012/02/14 18:38:00 I gogoc: Retrieving TSP capabilities from Server.2012/02/14 18:38:00 I gogoc: RUDP packet 0, RTO 2.000000, sequence 0xf00000f0 timestamp 192.2012/02/14 18:38:00 I gogoc: Reply: RUDP packet 0, RTO 2.000000, sequence 0xf00000f0 timestamp 192.2012/02/14 18:38:00 I gogoc: Authenticating...2012/02/14 18:38:00 I gogoc: Using PASSDSS-3DES-1 authentication mechanism.2012/02/14 18:38:00 I gogoc: RUDP packet 0, RTO 2.165375, sequence 0xf00000f1 timestamp 497.2012/02/14 18:38:00 I gogoc: Reply: RUDP packet 0, RTO 2.165375, sequence 0xf00000f1 timestamp 497.2012/02/14 18:38:00 I gogoc: RUDP packet 0, RTO 2.304453, sequence 0xf00000f2 timestamp 639.2012/02/14 18:38:00 I gogoc: Reply: RUDP packet 0, RTO 2.304453, sequence 0xf00000f2 timestamp 639.

いつもなら、gogocクライアント自体が再接続してくれたり、手動で再接続したりしているのだけど、今日に関しては全然ダメな状態。
フリーで使わせていただいている、とはいえ、トラブル時のアナウンスはどっかでして欲しいけど、そういったページが見当たらない気がするんだよなぁ...。

ESXi上のVMの1つとして動かしているOpenfiler、インストールしたときは2.3だったのだけど、2.99にマイナーバージョンが上がっていたので、アップグレードしてみたら、案の定ハマった(w)のでエントリー。

まず、アップグレード

conaryというパッケージシステムを使っているのは知っていたので、それでアップグレードできるんだろうなぁと予想はついたのだけど、やり方はよくわからなかったので、とりあえずサポートフォーラムを覗いてみたら、まさにドンピシャリのポストを発見。

ポストされてる書き込みに書いてあるとおりにコマンドを、Openfilerが動いているサーバのコマンドラインから

[root@openfiler ~]# conary migrate group-openfileresa-appliance=openfileresa.rpath.org@esa:openfileresa-3.0 --interactivePreparing changeset request...

実行して、しばらく待つ。

Job 166 of 166:    Update  group-core (/openfiler.rpath.org@ofns:2/2.3-36-3[X,~!alternatives,~!bootstrap,~buildtests,~!cross,desktop,~!dietlibc,emacs,gcj,~glibc.tls,gnome,~grub.static,gtk,ipv6,~!kernel.debug,~!kernel.debugdata,~!kernel.numa,~!kernel.pae,~kernel.smp,krb,ldap,nptl,~!openssh.smartcard,~!openssh.static_libcrypto,pam,pcre,perl,~!pie,~proftpd.auth_pam,~proftpd.ifsession,~proftpd.ipv6,~proftpd.rewrite,~proftpd.tls,python,readline,sasl,~!selinux,~sqlite.threadsafe,ssl,tcl,tcpwrappers,tk is: x86(i486,i586,i686) x86_64] -> /openfileresa.rpath.org@esa:openfileresa-3.0/2.99.2-5-1)    Erase   group-openfiler=2.3-36-3[~kernel.smp,~proftpd.auth_pam,~proftpd.ifsession,~proftpd.ipv6,~proftpd.rewrite,~proftpd.tls,sasl]    Install group-openfileresa-appliance=2.99.2-5-1** The update will restart itself after job 16 and continue updatingMigrate erases all troves not referenced in the groups specified.continue with migrate? [y/N] 

待っていると「続けるか？」と聞かれるので、ココで"y"と入力する。