少し前にDEC 21140-ACのNICを手に入れて、Win98SE、Win2k、FreeBSD、Linuxのクァッドブート環境な実験機につけた所、4つすべてのOSでさくさく簡単に認識して動いてくれた。Win2kでは認識した事すら気付かない程あっさり動いていて、一瞬、取り付けミスかと思った程だ。あまりの素性の良さに感動し、ディスプレイを買いに行った時にもう1枚入手しておいた。
我が家のLANは6MB/sが頭打ちで、先日ハブを交換することで8.5MB/sまで上げる事に成功。メイン機はもちろんLinuxなのだが、NICはNetGearのDEC互換だった。もしかしてこのNICの限界速度が8.5MB/sなのかもしれないと、こちらも21140-ACに交換してみた。
そしてさっそくLinux側のProFTPdにWin2kのFFFTPでアクセスすると、なんと上り下りともにおよそ10MB/sを叩き出した。100Base-TXの理論値が12.5MB/sだから、これは相当速い部類じゃないだろうか。
ちなみにネットの速度の話に必ず出てくるのがHDDの速度だったりするのだが、これはもはや問題じゃないと思う。今時のHDDは30MB/sくらいで読み書きしてるのだから。

＠ 大失敗:

ふと見たら空いてたので、うっかりドメイン取っちゃった。IRCチャンネルの#テロックノールのサイトとして使って行こうかと。ちょっと狐志庵は忙しいギミだし、デザインセンスも無いので さかどん にウェブページ書いてもらうことに。準備中ページだけど、名前が引け次第見れるようになると思うので、よろしくなのです。
また、画像は#テロックノールの創始者 いぬ が提供してくれたとのこと。ありがいぬ!
(@240)

どーもPostfixは起動時にDNSのIPを覚え、その後は更新しない模様。うちはローカルのキャッシュ用DNSにすべて向けてるのだが、今回ネットワーク構成変更でDNSを上げるホストを変更し、各マシンのresolv.confを書き換えたのだ。そして半日たって日記が届いてないことに気付き、ログを見てみると相手のホストが見付からんと申す。どういうことかわからなくて、とりあえずpostfixを再起動したら直った。
そうすると今までエラーで弾いてたメールを続々送り出している。今日の日記は何度か送り直したので、アレゲなことになるかもしれない(苦笑) *1
(@244)

先日悩んでた問題 の続きなのだが、1つのファイルシステム上のexportされるディレクトリは、1行に書かなければならないらしい。 「銀河の歴史」 をお書きになられてる Georgeさん にメールをいただき、教えていただいた。ありがたい。
詳しくはGeorgeさんの記事 「続mountポイントとexport」 を見るとわかるが、「マウントしてない/cdrom」の罠などは実に興味深い。これはQandAにあってもおかしくない罠だと思うのだがなあ。

FreeBSDネタのついでに書いてみるテスト。ちょっと検索すると、/etc/make.confに

WRKDIRPREFIX=	/hoge/fuga

と書いておけばいいらしいということがわかった。portsをNFS共有すると、workディレクトリが掘れなくてうまく行かないのだが、こうしておけば/hoge/fugaをworkディレクトリにするのでOKとのこと。
しかし、これでもLinuxマシンのNFS領域にcvsupしたりはできないのでどーしたもんだか。Linuxでcvsupっつー邪道なことでもしてみますかねえ。
(@248)

栃木県では車が無いと生きて行けない。ちょっと買い物へと思っても、自転車で行ける範囲で済ませようと思うと、かなり選択肢が狭くなる。また何かと物入りなので、車じゃないと運びようが無い事もままある。そんなわけで我が家は特に裕福なわけでも無いのだが、一人1台の車が割り当てられている。3人家族なので2台あればなんとかならなくもないのだが、やはり3台あるといざというときに乗れないということが無くていい。また、この地域で親が子供に車を買い与えるということは、酔っ払っても迎えに来させられるというメリットも考慮に入っている。
そんなわけで強引に免許を取らされ、車を与えられているわけだが、車やバイクの好きな家系のおかげか、事故や破損とは無縁の生活を送っていた。無事故無違反はちょっとした自慢でもある。どっこい、世の中には悪い奴もいるもので、車の鍵をこじ開けようとする奴等が多いらしい。俺の車もやられたようで、運転席側のドアにキーが刺さらなくなってしまった。父の知り合いで以前少しだけコンピュータ操作を教えた事のある自動車屋さんに相談したら、全部交換となると高いし時間もかかるとのことで、運転席側だけキーを交換して済ませてくれた。ありがたいことではあるのだが、やはりエンジンキーとドアキーが別というのもいささか不便である。
しかし、不幸というのは重なるもので、二つの鍵にもやっと慣れて来たかという昨日、とある店に入ろうとしたら、妙な位置に車が止まっており、それを避けるように入っていった所、ゴリっと腹を思いきりこすってしまった。見ると何やら液体が垂れている。ちょうどこすったあたりだったので、これはオイル洩れであろうと、今日になって例の自動車屋さんに持っていった。
ところがどうも洩れてる気配が無い。自動車屋さんはピンと来たのだろう。エアコンをかけてみろと言うのでその通りにすると、見事オイルが洩れてたと思ってた場所から水が出て来た。エアコンの水が出てただけだったのだ。
俺はよくコンピュータを自動車に例える。交通事故が減らないのは車を理解して使ってないからだと主張している。だからコンピュータをできる限り根本から理解していくことが、安全で快適なコンピュータ生活を送る上で重要な事だと。
しかし、そう主張する自分自身のていたらくはどうだ。段差に腹をこするというミスはまあ、たまにはあることだとしても、エアコンの水とオイル洩れを勘違いしてしまうという大ポカをかましてしまった。もちろん運転に問題ない程度には車というものを理解しているつもりだ。どういう操作をすればどういう挙動をするかを知り、公道レベルの速度であれば、それをコントロールする自信はある。だが、メカニカルな部分は全く知りもしなかったというわけだ。最初に車を見せた時、ちょっとボンネットを開けてみろと言うので開けようとしたが、開け方を思い出せなかった。考えたらボンネットなんて開けた事など無い。自動車屋さんには「なんでこんな機械オンチがパソコンいじれるんだ」と笑われてしまった。奥さんにも「先生ったらパソコン以外はダメなのねえ」と言われる始末。先生と呼ばれたのは一応パソコンの先生という事になってる(らしい)からだ。
現状、コンピュータのハードウェアに関してはさほど知識は要らないとは思う。基板単位で捉え、問題のあるボードを特定する程度の知識があればいいだろうし、ユーザーランドでそれ以上を求められる事も無いだろう。この程度の知識を自動車に例えるとどうなるだろう。車が何を装備し、それがどういう挙動をするか理解し、日頃のメンテナンス程度は自分でできる、それくらいだろうか。せめてその程度には、車にも親しんでおきたいと強く思った日であった。
(@371)

どうやらDNSの設定間違えてたようで、ずっと名前が引けてなかった模様。さっき直したらものの6〜7分で俺が使ってるISPのDNSにまで浸透した。今時のDNSの浸透って早いのねえ。
というか、設定ミスっててすんません。
(@967)

先日、年初に決めた通り、ISDNでIPを8個取って設置した。ホントはADSLが繋がってからと思ってたのだが、まあこういう状態になってしまったのでしかたがない。
それで今、iptablesでフィルタの設定をしているのだが、ネットワーク知識が少ないせいか、合点のいかないことがある。

cmd=`which iptables`
$cmd -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/24 -d ! 192.168.0.0/24 \
	-j MASQUERADE
$cmd -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/24 -d ! 192.168.0.0/24 \
	-j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
$cmd -N ppp-in
$cmd -A INPUT -i ppp0 -j ppp-in
$cmd -A FORWARD -i ppp0 -j ppp-in
$cmd -A FORWARD -i eth1 -j ppp-in
$cmd -A ppp-in -p tcp --dport ssh -j ACCEPT
$cmd -A ppp-in -p icmp -j ACCEPT
$cmd -A ppp-in -m state --state ESTABLISHED,RELATED -j ACCEPT \
	--modprobe=/sbin/modprobe
$cmd -A ppp-in -j LOG --modprobe=/sbin/modprobe
$cmd -A ppp-in -j DROP

ppp0にはISPからもらった8個のIPのうち、一番最初のIP、つまりネットワークアドレスが割り振られてる。eth0はローカルIPになっており、我が家のLANへ繋がっている。eth1がISPからもらったネットワークへの接続だ。
その上で上記の設定をほどこすと、ISPからもらったネットワークにあるホストから、ローカルIPのネットワークへpingが通ってしまう。FOWARDで許可してるので当り前といえば当り前だが、同じように許可を与えてるsshは通らないのである。これってどういうことなのだろう。
(@952)

そえりん の 日記[2002/10/3] より。
俺も天秤座A型なのだが、典型的な日本男児なのだろうか。うむ、きっとそうに違いない。俺を普通じゃないと言い切る皆の衆よ! ほれみろ、やっぱり俺はふつーじゃねーか!
(@978)

某所で見付けたのでメモ。

$ cmd=`which mmencode || which mimencode`; head -c 6 /dev/urandom | $cmd

(@74)

バナー規格の中に「縦型ナビゲーション付きフルバナー」というのがあるのだが、この「縦型ナビゲーション」ってなんだろうと思って調べてみた。どっこい、 「バナー広告入門vol2」 によると、どうやら昨年、バナー規格が改定されて、この「縦型ナビゲーション付きフルバナー」は削除されてしまったらしい。さらに追加された規格がいくつかあるとのこと。このページのIAB Banner Standardsへのリンクは死んでるが、 IABのページ に現在の規格は載っている。うーむ、けっこういっぱいあるなあ。
(@112)

inetdを使用するデーモンで、動かしたいものはqpopperだけだった。APOPが簡単に使えるというのが理由だったが、courier-imapdのコンポーネントでSSL対応POP3が使えるので、乗り換えればinetdも止められて嬉しい事になるだろうと実行してみた。
どっこい、netkit-inetdをremoveすると、依存関係にあるnetbaseが引きずられてremoveされ、さらにnetbaseに依存してるcourierシリーズやapacheやpostfixが続々と削られてしまう。これじゃどーにもならん。
Provide: netbaseなパッケージがあるのかと思いきや、どうにも見付からない。起動スクリプトで止めておくしかないのかなあ。うーむ、困ったもんだ。
(@148)

inetdに頼らないpopサーバを探す。pop over sslが使えるので、courier-popを使用することにしたのだが、よく見るとpop over ssl対応のメールクライアントがかなり少ない。ということでAPOPに切替え……と思ったら、courier-popはAPOP未対応。solid-pop3dはAPOP対応のようだが、standaloneで動作させるのはけっこう骨。 d-uの過去ログ にsolid-pop3dをデーモンモードで使うスクリプトを書いてる人がいたのだが、なんか中途半端にスレッドが切れてるのでにんともかんとも。さらにうちにあるwoodyでまともにパッケージのリビルドできる環境が無かったりもする。マジでめんどくせえ。
ということで、おとなしくqpopperでAPOPに決定。くそ、また元の黙阿弥かよ。popだけのためにinetd起動するの嫌なんだけどなあ。courier-ppにしろsolid-pop3dにしろ、ちゃんとコンパイルする環境作って、パッケージにパッチあててrebuildして使えばいいんだろうけど……あんまり管理に手間割きたくないしねえ。
(@762)

昨夜からこのモジュールを調査。DCC送信できるようになるらしい。
だがどーしてもできない。 l-uのこちらの投稿 を読むと、指定したポートへのIRCのコネクションを追跡してDCCをその関連した接続として認識し、自動的にパケットを通してくれる、というものらしい(たぶん)。
ということは、

通常の接続
IRC server:6667-------------[IP MASQ]
                            |       |
                            |       |
                       client A   client B
                    192.168.0.10  192.168.0.11

この場合、IP MASQがIRC serverのport 6667への接続を確認してるので、IRCサーバからくると思われるDCCコネクションのリクエストの返事を関連として認識してくれる。故にclient Aからでもclient BからでもDCC送信が可能になる(はず)。

Plumを経由した接続
IRC server:6667-----IRC bot:16667----------[IP MASQ]
                                           |       |
                                           |       |
                                      client A   client B
                                  192.168.0.10  192.168.0.11

この場合、IP MASQはIRC bot:16667への接続しか見えてない。なのでIRC server:6667からのDCCリクエストの返事は関連接続として認識できないのだ(ろう、たぶん)。
うーむ、おとなしくルータにplumを建てる方が楽そうな気がして来た。irchatやlieceがDCC時にグローバルIPと受け入れポートを指定できれば普通にNATするだけですむのだが……
(@350)

ここ一ヶ月ほど、休むまもなく作業に追われてたので、昨日と一昨日は休みと決めていたのだが、結局ルータの設定やらなにやらやってしまって作業量が少し減っただけという有り様。そのせいか、今日はなんかやる気が出ないで作業も進まん。まあ、そろそろサーバ側の設定は終って来たので、気分転換も兼ねてコンテンツ制作のための素材集めにそのへんドライブでもしようかなあ。写真が何個か欲しいのよね。使えるかわからんけど。
(@603)

昨日のDCCの話の続きになるのだが、DCCが通ったのはlieceだけで、irchat-pjでは通らなかった。どうやらどっちみっちこの方法ではirchatのDCCはダメなようだ。他の方法考えるかのう。
(@663)