トップページ⇒unix
1001コメント297KB

NetBSD その10

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。05/01/22 04:44:31
　　 　,,-‐''""''ー--е　　　　　　　　巛 ヽ
　　..|"" 　 　 　　.　.||　　　　　　　　　〒　!
　. .;;|.　　NetBSD　.|| イヤッッホォォォオオォオウ！
:.:　.;;| 　　　　　　　...||　　　　　　　　　/　/
.::..::;:;|　　　　,ノ""""||　　　 ∧＿∧ /　/
.:::::;;:| ,/"　∧＿∧ｎ||　　　（´∀｀　/　/
　 ""　　 （　´∀｀/　）　 　,-　　　　　ｆ
　　　　 　/　 .＿/ /|| 　 / ｭﾍ　　　　|
　　　　　/　 ＿＿/(　） 〈＿｝ ）　　　|
　　　　 /　　　（ と）　　∧＿∧　　　!
　　　　/　/￣＼ ＼＼（´∀｀　）,ﾍ　 | 　n
　　___/　/　　　 ＼ ＼　 　　　　ヽ 　　 （ E）　　　　　``もちろんNetBSDです。''
　 （＿_/　　　　 　 ＼ | 　　　 /ヽ　ヽ_／／　　　　　 http://www.netbsd.org/

お約束、関連リンクは>>2-10あたり
0287名無しさん＠お腹いっぱい。05/02/16 15:17:41
>>286
ポータブルならそうなのだが．．．．
>>281さんがああ言ってるがOSで実装した方が
アプリがするより効率はよいはず。

もしかしたらLinuxも対応するかもしれん(議論中なのだが．．)
0288名無しさん＠お腹いっぱい。05/02/16 15:21:29
> OSで実装した方がアプリがするより効率はよいはず。

どうして？ コリジョンが起きない限り効率は変わらないのでは？
0289名無しさん＠お腹いっぱい。05/02/16 15:25:01
>>288
無駄なコンテキストスィッチが減る
0290名無しさん＠お腹いっぱい。05/02/16 15:28:51
>>289
減らないよ。
ユーザランドの場合、まず乱数計算してから bind(2) 呼ぶだけ。
カーネルでやる場合、カーネルの bind(2) の処理の中で乱数計算
する。
どちらもシステムコールは1回で済むから、コンテキストスイッチ
の回数はまったく同じ。
0291名無しさん＠お腹いっぱい。05/02/16 15:42:30
まあ、こうして本来ユーザランドでやるべき機能もカーネルで
抱えて、カーネルがどんどん肥大していく運命なわけでつよ。。

ﾌﾞｸﾌﾞｸ
0292名無しさん＠お腹いっぱい。05/02/16 15:46:38
だから結局>>285の結論に行き着くのでは？

仮にもしOSが実装してれば、現在実装してないアプリにも自動的に対応tできるって狙いではないかと。
0293名無しさん＠お腹いっぱい。05/02/16 15:48:53
>>291
コンパイルオプションで選択的にすればいいような気も駿河
0294名無しさん＠お腹いっぱい。05/02/16 15:49:16
それって要はアプリのバグでしょ。
本来直すべきところを直さずに、他のレイヤで解決するって
美しくないなあ。
で、いったい全体、どこにそういうアプリがあるっていうの？
0295名無しさん＠お腹いっぱい。05/02/16 15:52:42
なんかいきなり的外れなのが出てきたぞ。294は例のヤシか?
0296名無しさん＠お腹いっぱい。05/02/16 15:54:28
とりあえずlibutilあたりに突っ込んでおけばいいんじゃねーの?
0297名無しさん＠お腹いっぱい。05/02/16 15:55:59
>>294
>で、いったい全体、どこにそういうアプリがあるっていうの？
俺は知らねーけど、そういう機能を入れるってことは、
OS側がアプリの出来不出来に左右されなくていいってことでしょ
(ようはアプリを信用してないってこと)
0298名無しさん＠お腹いっぱい。05/02/16 15:59:05
>>295
ん？ ランダム化しなきゃいけないところをしてないって
のは、アプリケーションのバグじゃないの？
本来あるレイヤですべき仕事を他のレイヤでやることが
ソフトウェアの無駄な肥大化を招いて美しくないってのも
常識だと思うし。
0299名無しさん＠お腹いっぱい。05/02/16 16:01:58
>>298
でも実際にランダム化しなきゃいけないってきまりはないし．．．。
セキュリティ上した方がいいんでないのって感じだし．．．。
0300名無しさん＠お腹いっぱい。05/02/16 16:03:45
>>299
どうしてした方がいいの？
いったいどういう攻撃を想定してるの？
0301名無しさん＠お腹いっぱい。05/02/16 16:04:00
>>298
美しいっていう定義とは何か？
030229805/02/16 16:05:41
たとえば無駄な重複がないとか。
030329905/02/16 16:08:15
>>300
>どうしてした方がいいの？
OSによる実装が一番簡単で即効性がある解ではないかと思っているが

>いったいどういう攻撃を想定してるの？
ポートへのRST攻撃とか
0304名無しさん＠お腹いっぱい。05/02/16 16:13:33
>>298
はぁ? 各アプリに対策を求めるほうがよほどアレだぞ。
そして、しったか飛ばしたあとは質問厨かよ。消えろバカ。
0305名無しさん＠お腹いっぱい。05/02/16 16:15:46
>>302
それって現実的には難しいと思うよ
カーネルだけならまだしも、オープンソースなアプリを統一的に管理するって話になるし
0306名無しさん＠お腹いっぱい。05/02/16 16:20:52
>>304
> はぁ? 各アプリに対策を求めるほうがよほどアレだぞ。

だから、そもそも ftp のようなアプリ側はとっくに対策済みだってば。

そもそもカーネル側だけで全ての攻撃に対処するなんて原理的に不可能
なんだから、どこまでをカーネルで対策すべきで、どこからはアプリで
対策すべきかってことを、ちゃんと切り分けることが大事でしょ？
でないとあっちとこっちで無駄に同じことをやっていて、遅くて肥大
した醜いシステムになるだけでは？

>>303
> OSによる実装が一番簡単で即効性がある解ではないかと思っているが

そもそも問題がない(既に対策済みで脅威がない)んだから、それは解
じゃないと思うけど。たんに物理メモリの無駄では？

> ポートへのRST攻撃とか

それは違うでしょ。FreeBSD が 4.11 でやったみたいに RST で受け入れる
シーケンス番号の範囲を狭くすることとか、あとは推測されないように
初期シーケンス番号を割り当てることっていのなら分かるけど。
だいたいサーバ側のポート番号は割れてるんだから、anonymous port の
側の番号をランダムにしたところで、まったく耐攻撃性は向上しないよ。
030730605/02/16 16:21:58
> だいたいサーバ側のポート番号は割れてるんだから、anonymous port の
> 側の番号をランダムにしたところで、まったく耐攻撃性は向上しないよ。

う、済まん。これは間違い。
0308名無しさん＠お腹いっぱい。05/02/16 16:22:14
カーネルの肥大化はUNIXの宿命
0309名無しさん＠お腹いっぱい。05/02/16 16:25:37
ﾌﾞｸﾌﾞｸ
0310名無しさん＠お腹いっぱい。05/02/16 16:28:20
>>306
>そもそも問題がない(既に対策済みで脅威がない)んだから、それは解
>じゃないと思うけど。たんに物理メモリの無駄では？
ずいぶんな自信ですね
0311名無しさん＠お腹いっぱい。05/02/16 16:30:13
NetBSDは>>306さんによって守られております
0312名無しさん＠お腹いっぱい。05/02/16 16:33:51
>>311
それ聞いて安心しますた
0313 ◆ogaWFi0wUo 05/02/16 16:39:54
アプリ側で対応した方が言いに決まってんだろ
OS側で対応してたら 他の対応していないOS側で使おうとしたときに使えないだろが
考えて発言しろや
0314名無しさん＠お腹いっぱい。05/02/16 16:44:52
まぁ、ランダムポート化することだけが安全なわけではないしね。
0315名無しさん＠お腹いっぱい。05/02/16 16:45:58
>>313
スレガ止まったからって煽るなw
0316名無しさん＠お腹いっぱい。05/02/16 16:47:35
>>315
まぁ、>>313の言う通なんだがな
0317もうどうでもいい05/02/16 16:48:36
もうどうでもいい
0318名無しさん＠お腹いっぱい。05/02/16 17:00:02
>>313
OSごとに処理を書けば対応できるじゃん
0319名無しさん＠お腹いっぱい。05/02/16 17:01:29
まあアプリケーションの機能拡張競争と同じことがカーネルにも
あるってことだよね。
新機能がないと売れないから、ベンダはとにかく新機能をつけて
新バージョンを出して売ろうと宣伝する。
その機能が本当に役に立つのか、それとも無駄な機能かは別問題。

「××にはセキュリティに有効な○○機能が」って宣伝されると、
機能の数で判断するユーザーは、それに飛びつくと。
その機能が本当に役に立つのか、それとも無駄な機能かは別問題。
0320名無しさん＠お腹いっぱい。05/02/16 17:02:29
>>319
Theoに言ってくれば?
0321名無しさん＠お腹いっぱい。05/02/16 17:04:41
Theoも常にセキュリティを優先にしてくれればまだ分かりやすい
んだけど、実はそうでもないからなあ。
0322名無しさん＠お腹いっぱい。05/02/16 17:08:19
>>313
はぁ? APIかなにかと勘違いしておらんか?
0323名無しさん＠お腹いっぱい。05/02/16 17:10:21
Theo:「OpenBSDは、もう 8 年以上もの間、デフォルトのインストールでの
リモートセキュリティホールはたったひとつだけでした !」
0324名無しさん＠お腹いっぱい。05/02/16 17:11:24
>>322
君の方が勘違いしてると思うけど。
OSの方でランダムにポートを割り当ててくれると仮定した
ftpソフトウェアは、他のOSに持ってくと、セキュリティ
問題が発生するでしょ。だからポータビリティを考えるな
ら、ユーザランド側で対処する他ないよ。
OpenBSD でしか動かさないことを前提としたソフトウェア
では、手抜きできるけど。
0325名無しさん＠お腹いっぱい。05/02/16 17:13:33
しったかがファビョってるなぁ
0326名無しさん＠お腹いっぱい。05/02/16 17:15:15
>>323
・デフォルトのインストールのみが対象
(注: OpenBSD でデフォルトで動くのは sshd のみ)
・ここで言うリモートホールには、カーネルを落すことが
できるホールは含まない
・新しい OpenBSD がリリースされた後は、古いバージョン
で発覚したリモートホールはホールと数えない。
ってのがミソだよね。
0327名無しさん＠お腹いっぱい。05/02/16 17:16:42
やはり、NetBSDとOpenBSDの考え方は違うんだね。
NetBSDはポータビリティでOpenBSDはセキュリティ。

ようするにNetBSDはランダムポート化を実装する意志が無いって事でFA？
0328名無しさん＠お腹いっぱい。05/02/16 17:17:13
>>324
ホント頭悪いなぁ。脆弱性を抱えかねないアプリにもOS側が何とかしてくれるから
ありがたいんだろ。
0329名無しさん＠お腹いっぱい。05/02/16 17:17:50
>>327
なんで日本の2chでの議論が本家の意思決定に反映すると
思うのよ?
0330名無しさん＠お腹いっぱい。05/02/16 17:19:14
まあ、321=326がTheoには直接いえないチキンなのと、すぐにボロを出す
しったかなのは確かかな。
0331名無しさん＠お腹いっぱい。05/02/16 17:21:53
まあ、本家がポート番号をランダムに割り当てたって、実質的な
意味はあまりないと考えてるのは確かだろうけどね。
このスレでも誰も穴を指摘できないようだしな。

>>328
で、その脆弱性を抱えかねないアプリって何よ？
ftp みたいに別のポートを認証なしで利用するアプリはむしろ
例外的では？ 今時設計するアプリなら、どんなポートでも
認証は行なうべきで、そうする限りは ftp みたいな問題は
発生しないよ。
頭のいい君なら、具体的に問題を指摘できるよね?
033232705/02/16 17:22:34
>>329
いや、単にこのスレにNetBSD JPの中の人が見てるかなって思って聞いてみただけさ
0333名無しさん＠お腹いっぱい。05/02/16 17:23:26
>>331
頭を冷やしたほうがいいぞ
0334名無しさん＠お腹いっぱい。05/02/16 17:24:27
〜なら〜すべきで済んだら、セキュリティホールなんぞ生まれない罠。馬鹿すぎ
0335名無しさん＠お腹いっぱい。05/02/16 17:25:19
これまでに OpenSSH のリモートホールがいくつ見つかったかを数えれば、
「リモートホールが1つだけ」っていう宣伝文句がどういう意味なのかは
誰にでも分かるのでは？
0336名無しさん＠お腹いっぱい。05/02/16 17:29:15
>>331
悪意を持ったアプリ作成者ならできちゃうね
0337名無しさん＠お腹いっぱい。05/02/16 17:31:21
そりゃそうだ。
fgets(line, sizeof line, sockfd);
system(line);
みたいなアプリを書かれれば、OpenBSDだろうが
なんだろうが、間違いなくオダブツ。
悪意のあるバイナリを動かした時点で既に終ってる。
0338名無しさん＠お腹いっぱい。05/02/16 17:34:19
良スレのやかん
0339名無しさん＠お腹いっぱい。05/02/16 17:36:03
実際、configure から呼ばれるプログラムに >>337 のような
仕込みの入った openssh が、クラックされた ftp.openbsd.org
で配布されてた事件だってあったわけだし。
あの事件って、結局詳細の発表はなかったけど、どういう経緯
で侵入されたんだろう？
0340名無しさん＠お腹いっぱい。05/02/16 17:38:48
悪意のあるバイナリって話が明後日の方向に飛んで行ったな。
そういうのに対してはTrusted SolarisやSE Linuxのように
RBACやMACが必要になるだろ。*BSDでは実装するなんて話すら
出ていないな。
0341名無しさん＠お腹いっぱい。05/02/16 17:41:51
ちなみにSolaris 10ではTrusted Solarisの機能が一部入っている。
LinuxだとRHELにはSE Linuxの機能がフルに入っている。
0342名無しさん＠お腹いっぱい。05/02/16 17:41:55
ちょっと待ってくれよ。
NetBSDって逐一アプリの検閲してるって事なの？

もしそうでなければアプリに今回のようなポートの問題があった時に
ランダムポートを実装してるかしてないかで変わってくるはずだが．
0343名無しさん＠お腹いっぱい。05/02/16 17:42:25
RBAC や MAC って、カーネルにローカルホールがないことが
前提で、もしカーネルにローカルホールがあれば簡単に迂回
できるので、特に単機能サーバーではあまり意味がない機能
では？
0344名無しさん＠お腹いっぱい。05/02/16 17:43:12
そういえば今日もまた Linux カーネルにローカルホールが
複数報告されてますね。
0345名無しさん＠お腹いっぱい。05/02/16 17:44:34
>>342
当然ながらportsに対してはそんなことやっちゃおらん罠。
userlandに対してもOpenBSDのように徹底してやっているわけではない。
そして、たとえやっていたところで、穴がある可能性は常にあるし。

あと、武器がなければ戦争は起きないというのに等しい机上の空論を振り回す
バカは放置しとけ。
0346名無しさん＠お腹いっぱい。05/02/16 17:45:58
>>343-344
ファビョっているねぇ
0347名無しさん＠お腹いっぱい。05/02/16 17:47:08
>>343
お前、セキュリティのこと位置から勉強したほうがいいぞ。
0348名無しさん＠お腹いっぱい。05/02/16 17:47:35
>>342
「アプリに」じゃなくて、「プロトコルとアプリの両方に」でしょ。
そもそもそういうプロトコルがあまり存在しない。ftp くらい?
0349名無しさん＠お腹いっぱい。05/02/16 17:48:22
kernelに穴があると使えないんだとわめくヤシに
どう対処すればいいんだろう?
0350名無しさん＠お腹いっぱい。05/02/16 17:49:51
>>348
何度も同じことを口にするようになったか。頭を冷やせ
0351名無しさん＠お腹いっぱい。05/02/16 17:50:44
>>350
ファビョったヤシに何をいっても無駄。放置しとけ
0352名無しさん＠お腹いっぱい。05/02/16 17:52:20
>>349
穴があっても入られないように毎日祈る
0353名無しさん＠お腹いっぱい。05/02/16 17:52:22
>>349
kmem 書き換えられたら、SE Linux 的やり方では乗っとられるでしょ。
仮想マシン方式なら大丈夫だから、usermode linux とか xen とか
勧めたら？
xen の方は NetBSD でも使えまつ。
0354名無しさん＠お腹いっぱい。05/02/16 17:53:15
IDがないんでアルファベットの前後にスペース置くヤシ以外の固体判別ができない…
0355名無しさん＠お腹いっぱい。05/02/16 17:55:06
>>345
portsって… 君 NetBSD 使ってないアルね。
0356名無しさん＠お腹いっぱい。05/02/16 17:55:10
>>354
それがUnix板
0357名無しさん＠お腹いっぱい。05/02/16 17:55:12
>>353
つける薬が見当たらん…
0358名無しさん＠お腹いっぱい。05/02/16 17:56:03
NetBSDユーザ抜きで伸び続けるスレ
0359名無しさん＠お腹いっぱい。05/02/16 17:57:11
実は自分Linuxerですた
0360名無しさん＠お腹いっぱい。05/02/16 17:57:35
>>357
SE Linux だと kmem 書き換えタイプのカーネルローカル
ホールが生じないって保証ができるの？
もちろん可能性は SE Linux の方が減るけど、絶対的な
保証は無理だと思うけど。
0361名無しさん＠お腹いっぱい。05/02/16 17:59:38
この世に万能な薬など存在しない
0362名無しさん＠お腹いっぱい。05/02/16 18:01:31
「セキュリティは製品じゃない、プロセスだ」
0363名無しさん＠お腹いっぱい。05/02/16 18:06:27
Kyoto Protocol は NetBSD で使えますか？
0364名無しさん＠お腹いっぱい。05/02/16 18:16:17
> RBACやMACが必要になるだろ。*BSDでは実装するなんて話すら
> 出ていないな。

そりゃ君が無知なだけ。TrustedBSDでMACを実装してるし、その
成果はFreeBSDの方にマージされてきてる。
それに安全性を特に重視するなら、>>353の言うように、仮想
マシン方式の方がよりセキュアでしょ。
0365名無しさん＠お腹いっぱい。05/02/16 18:24:21
NetBSD 1.6.2 のセキュリティ
http://bsdcon.jp/docs/netbsd-updates-2004/mgp00006.html
0366名無しさん＠お腹いっぱい。05/02/17 14:42:01
NEW_BUFQ_STRATEGYって廃止された？
0367名無しさん＠お腹いっぱい。05/02/17 19:29:13
>>366
そうでもない
0368名無しさん＠お腹いっぱい。05/02/17 22:11:33
あれ、どこで参照されてます？
うちのcurrentでは src/sys で grep -R NEW_BUFQ_STRATEGY * しても見つからなかったです。
opt_bufq_*.h opt_new_bufq_strategy.h とかも読まれてないし。
0369名無しさん＠お腹いっぱい。05/02/18 00:34:17
昔の NEW_BUFQ_STRATEGY は今は BUFQ_READPRIO だな。
あと BUFQ_PRIOCSCAN っていうのもある。こっちの
方がいい？
0370名無しさん＠お腹いっぱい。05/02/18 01:16:50
>>369
options(4)が直ってないんですけど……
uvm(9)もmergeする前に書いておいて欲しいな。
0371名無しさん＠お腹いっぱい。05/02/18 01:38:04
>>369
なんかdefaultでBUFQ_PRIOCSCANを使うようになっているような気がする。
options NEW_BUFQ_STRATEGYかなんかでbufq_disk_default_stratを変更するように
なってないといけないような気もする。
0372名無しさん＠お腹いっぱい。05/02/18 01:45:00
> options(4)が直ってないんですけど……

一応、今でも NEW_BUFQ_STRATEGY は使えると思うよ。
sys/conf/files で
file kern/bufq_readprio.c bufq_readprio | new_bufq_strategy
ってなっているから。そういうわけで、options(4) の記述自体は一応
まだ通用するから、問題ないと言えば問題ない。
まあ options(4) を直した方がいいのは確かだけど。
下書きだけして kill -1 `cat /var/run/wizd` するのがいいと思うんだが。

> なんかdefaultでBUFQ_PRIOCSCANを使うようになっているような気がする。

あれ、そう？
BUFQ_PRIOCSCAN って、デフォルトでは定義されてないから使われないと
思うけど。で定義すると、linker_set に入って使われるようになるん
じゃない？
0373名無しさん＠お腹いっぱい。05/02/18 01:55:07
>>372
ぐは、link_setか。了解。読む方にとってはわかりにくいぜ。
でも、結局bufq_disk_default_stratが_BUFQ_DEFAULTのまま変更できないから
methodを複数定義したときBUFQ_METHOD_MASKして一番大きいstratが使われるとすると
DISKSORTは標準で入っちゃうからFCFS使いたいぜと思ってもできないじゃん
という気もしないでもない。
0374名無しさん＠お腹いっぱい。05/02/18 02:07:40
FCFS はユーザーが好きこのんで使うものじゃなくて
(たぶん性能が悪くなるだけ)、FCFS を使いたいドラ
イバなりが明示的に使うだけだから、それでいいん
じゃないの？
ufs/mfs/mfs-vfsops.c とか、dev/ の下とかで、
ぼちぼち使ってるみたいよ。
0375名無しさん＠お腹いっぱい。05/02/18 02:20:56
>>374
うーん。buf_alloc()を呼ぶ側で決める話ならbufq.hで
extern int bufq_disk_default_strat;
#define BUFQ_DISK_DEFAULT_STRAT() bufq_disk_default_strat
という感じにdefault値が変数になってるのはほとんど意味なくて
直接_BUFQ_DEFAULT渡せばいいじゃんという気が。
つーか、ターゲットのデバイス別でどのmethodが最適なのかが
変わるのならDEFAULTなんて名前がよくないのかしら。
0376名無しさん＠お腹いっぱい。05/02/18 02:34:46
> ほとんど意味なくて

でもまあ、カーネルをリンクし直さなくても、
gdb かなんかでパッチ当てるだけで済むというぐらいの
意味はあるよね。
マクロに直接定数が埋まっていると、そうはいかん。

> つーか、ターゲットのデバイス別でどのmethodが最適なのかが
> 変わるのならDEFAULTなんて名前がよくないのかしら。

どっちかっていうと FCFS が特殊なんだと思うけど。
選ぶのは DISKSORT vs READPRIO vs PRIOCSCAN の３択で、
それを決めるのがDEFAULTだと。
0377名無しさん＠お腹いっぱい。05/02/18 02:58:06
NEW_BUFQ_STRATEGYとBUFQ_READ_PRIOが同じ扱いになってから変な感じがするのかな。
options BUFQ_*はbufq_alloc()でどのmethodをサポートするかを指定するoptionで、
options NEW_BUFQ_STRATEGYは(名前はともかくとして)物理ディスクでどのmethodを
使うか選択するoptionであるべきだという気がしないでもない。
0378名無しさん＠お腹いっぱい。05/02/18 03:12:22
うーん、「NEW_BUFQ_STRATEGYは互換性のために残っているだけで
deprecated (BUFQ_READPRIO の単なる別名) だから、新しく
config 書くなら BUFQ_READPRIO か BUFQ_PRIOCSCAN のどちらかを
選んで指定しろ」でいいと思うけどなあ。
で、両方(あるいはDISKSORT)を一つのカーネルで試したい変な人は、
両方を config に書いて、bufq_disk_default_strat にパッチを当
てて選択すると。
0379名無しさん＠お腹いっぱい。05/02/18 03:27:17
>>378
つまりそれをoptions(4)に書いとけよ、という結論ですかな。

link_setの使い方に慣れてないせいかもしれないけど、
標準のbufq_disk_default_stratだと一番大きい値のBUFQ_*が使われる
ってのがなんか変な感じがしちゃうなあ。
0380名無しさん＠お腹いっぱい。05/02/18 04:01:46
BUFQ_PRIOCSCAN は議論の末にできたものだし、
BUFQ_READPRIO よりは素性が良さそうだから、
こいつが一番大きい値なのはまあいいんじゃないの？
BUFQ_READPRIO (というかその頃は NEW_BUFQ_STRATEGY)
の方は、30秒ぐらい止まってハングしたかと思った…
みたいなトラブルレポートもあったことだし。

そういえば、delayed write の書き込み待ちで、その
ページの読み込みまで待たされる問題を解決するために、
PG_BUSY を書き込み向けと読み込み向けで分離する話って
どうなったん？
0381名無しさん＠お腹いっぱい。05/02/18 09:04:47
>>380
どうもなってません。
0382名無しさん＠お腹いっぱい。05/02/18 21:45:10
Erik Reid (-人-)
0383名無しさん＠お腹いっぱい。05/02/18 23:02:59
なになに? Erik Reid がどうかしたの?
0384名無しさん＠お腹いっぱい。05/02/19 15:38:15
命日？
0385名無しさん＠お腹いっぱい。05/02/19 23:35:08
fwaudio きぼんぬ
0386名無しさん＠お腹いっぱい。05/02/20 01:35:24
ftpだけじゃなくてwww.jp.netbsd.orgも落ちてる?
■ このスレッドは過去ログ倉庫に格納されています