unos.biz » Network

opensolaris/rgeドライバ

ゆのじ — Tue, 06 Jul 2010 22:34:34 +0000

ファイルサーバに大量にファイルを突っ込んでいると、転送が途中で中断されてしまう。そのときすぐにサーバにsshしてもつながらない。しかしエラーログには何も残っていない。そんな状態になっていて、何が原因なのかさっぱりわからなかった。

どうも、これ(というかDuplicate/closeされているがこっち)が原因なんではないかという気がしてきた。曰く、

During a large file transfer, a card using the RGE driver drops off the network. Its not related to the hwchecksum bug (I’ve tried with and without that option in /etc/system) On 106 it happens after 25-30 gigs, on 101 (2008.11) it happened between 10 and 15 gb transferred.

とのこと。うちでも数GB以上の転送でひっかかったりして困っていた。うちのファイルサーバのOSはopensolaris snv111bなのだが、修正はsnv131にコミットされたとある。

次の公式リリースはいつか調べていたのだが、どうもSun Microsystemsがオラクルに買収されたりした関係できな臭いにおいが漂ってきている気がしてならない。wikipediaが先走っているだけかも知れないが、ここによれば次のリリースは2010.03だったようでもう四半期も放置されてしまっている。

あまり良いとは思わないが、devを追うべき、なのかもしれない。やれやれ。

VMWare with ESET Smart Security

ゆのじ — Thu, 13 Nov 2008 23:33:28 +0000

VMWare上のFedora9で、eth0(bridge)、eth1(NAT)設定をしているとき、DHCPでのIP取得を行おうとすると、eth0がDHCPに失敗する、という問題がでていた。

結論からいうと、下記許可ルールを追加すると解決する。

ローカル側：UDP 67-68ポート
リモート側：UDP 67-68ポート信頼ゾーン

非常に気持ち悪いのだが、ひとまず解決策。

追記：
VMWareのIP幅を信頼ゾーンに加えてないと、失敗するかもしれない。未検証。

追追記：
サポートに推奨設定を問い合わせていたが、その返答がきた。曰く、

プロトコル：UDP
方向：内向き
アクション：許可
ローカルポート：68
リモートポート：67

を追加するようにとのこと。これで変なところで引っかからずきちんとファイアウォールを使うことができる。ありがたい。

またThinkPadに締め出された

ゆのじ — Tue, 13 May 2008 18:58:36 +0000

　またやってしまった。ThinkPadにパーソナルファイアウォール入りの製品をインストールしたあと、ローカルポートの通信を許可せずに再起動。これをやるとClient Securityに締め出されてしまう。原因は、前にも散々調べた結果、おそらく(というのは起動時のシーケンスのために裏側で何かできないため、外形から推測するしかない)127.0.0.1同士の通信で、エンベデッドセキュリティチップ関連のソフトとClient Securityのログインウインドウアプリが通信していて、それをパーソナルファイアウォールがブロックしてしまうからだと思う。

　これは、HDDをはずしてどうこうする、というようなアグレッシブな方法を除くとほとんど対処法がなくて、そのまま放置して待つしかない。寝て起きるとタイムアウトするらしく、通常のログインウインドウが出てきてくれる。このタイムアウト時間が実際のところどれだけかはこれまでぜんぜん知らなかったが、ちょっと調べてみると Client Security バージョン5.4 インストールガイドなる資料にあたった。
　この資料にも、今回のようなケースでタイムアウトが何時間なのかについては触れられていない。だが、タイムアウトしているということはこれまでの体験的にわかっていて、この中の下記の記述を見る限りは、おそらく4.7時間かそれに若干追加した程度なのだろうと推測する。

Atmel TPMシステムでは、ユーザー・パスフレーズと管理者パスワードを区別していません。IBMエンベデッド・セキュリティー・サブシステムを使用する認証は、いずれも同じポリシーに従っています。最大タイムアウトは4.7時間です。Atmel TPMシステムは、4.7時間を越えて遅延することはありません。

やらかしたのが今から２時間程度前。4.7時間=4時間42分までにはまだまだ遠い。

自戒を込めてメモ。

翌日追記：がーん、ぜんぜんタイムアウトしない。しかもここ(T60とZoneAlarm)の情報によると５分程度でファイアウォールがあって使えない旨のエラーメッセージが出るらしいが、ぜんぜんでなかったぞ…。結局再度入れなおし中。うちのこのポストは間違っている虞がある。

ひとまず、うちのThinkPad T60(262325I)は、ほかにもATIのCCC(Catalyst Control Center)もローカル間で通信するし、127.0.0.1:* <-> 127.0.0.1:*の通信は無条件に許可しておいてもいいのかもしれない。今回の問題は、Windows NT Loginとtvttcsdの２つを許可すれば良いらしいのだが。

Linuxでproxy

ゆのじ — Sat, 10 May 2008 18:48:28 +0000

親玉側(Apacheでproxy)


ProxyRequests On

    Order deny,allow
    Deny from all
    Allow from 192.168.0.

ProxyVia Block

子分側(yumで使ったり)

環境変数に設定すればいいのだが、面倒なので下記のような感じで一括してprofile.dに書いておくと楽ちん。

vi /etc/profile.d/proxy.sh

export http_proxy = http://oyadama:80/
export HTTP_PROXY = http://oyadama:80/

で再度loginし直すと環境変数が有効になって使えるようになる。

手元環境でPROXYが必要なときには一瞬で設定できるしかなり便利だ。もっと活用していこう。

VMWareとPersonal firewallとの相性

ゆのじ — Wed, 07 May 2008 04:48:30 +0000

　毎度毎度、VMWareとPersonal firewall製品との相性には泣かされる。bridgeとして設定したNICが、promiscuos modeで動作することと、(恐らく)Personal firewallが、自身の動作する宛先IP以外を宛先とするパケットを拒否してしまうからなのだが、理由がわかっても回避方法がないことが多い。

　今使っているのは、ESET Smart Security。その昔、NOD32があまり知られていなかった頃に価格.comでの問題を見つけて中の人に連絡したのが懐かしいが、そのNOD32を出しているところのFirewall込み製品だ。これまでは全体的に悪くないなと思って使っていたが、今回VMを外から叩く必要が出てきて問題が発覚した。これも駄目っぽい。
　昔、NOD32＋outpost(だったかSygate Personal firewallだったかどちらか)との組み合わせだとこの問題は回避できたように記憶している。やはり餅は餅屋、Firewall製品はFirewall製品屋で、ということなのだろうか。

　ひとまず今回はfirewall設定を切ることで対処した。やれやれ・・・。

参考サイト：Firewallと森で遊ぼう　このサイト、更新されていないのが本当に惜しい。