■掲示板に戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50
レス数が1000を超えています。残念ながら全部は表示しません。 |
初心者もOK! FreeBSD質問スレッド その18
- 1 :2ch BSD USERS GROUP :02/06/02 23:55
- FreeBSD 関連の質問はここで。
○過去ログ dat落ち救済サイト
初心者もOK! FreeBSD質問スレッド 過去ログ置き場
http://bird.zero.ad.jp/~zau60806/FreeBSD/
過去スレ15_1 の 962,967さんに感謝!
http://pc.2ch.net/test/read.cgi/unix/1019199395/962-967
オリジナルの歴代スレッドは 1 から10 までは >>2, 11以降は >>3
FreeBSD 関連サイトへのリンクは >>4,
FreeBSD 関連の検索は >>5
FreeBSD 関連のスレッドへのリンクは >>5
FreeBSD 関連のお勧めサイトは >>6
FreeBSD 以外の UNIX 関連の初歩的な質問は
くだらない質問はここに書き込め!なんでもアリ10
http://pc.2ch.net/test/read.cgi/unix/1022769156/
くだらない質問はここに書き込め!なんでもアリ10
http://pc.2ch.net/test/read.cgi/unix/1022769156/
- 953 :名無しさん@お腹いっぱい。 :02/06/19 23:47
- >>944
世の中には例えとしての表記で意味が通じない人もいるので、誤解されぬよう
注釈を加えると良いと思います。 "eth1 = sis1"みたいにね。
まぁ、ツッコミ入れなければならないほど解釈できない表現ではないと
思いますけど。
>>948
ベンダーで一括りにするとちょっとマズくないですか?
realtek 80xx系 -> ed
realtek 81xx系 -> rl
になりますし。(realtek 80xx系はNE2000互換チップ)
"チップ[コントローラ]の種類によって変わる"の方が誤解されないと
思います。
- 954 :2BUGs :02/06/19 23:52
- 次スレです。
初心者もOK! FreeBSD質問スレッド その19
http://pc.2ch.net/test/read.cgi/unix/1024497990/l50
- 955 :初期不良 :02/06/19 23:57
- >>947
すみまそん、その通りです...
CATV 回線になってから FreeBSD 使っているもので...
- 956 :942 :02/06/20 00:29
- >>951
そういうことです。謎です。
>>952
やってみます。
- 957 :名無しさん@お腹いっぱい。 :02/06/20 00:42
- >>932
ppp + IPFW + natd より、ppp(-nat) + IPFW でいいんじゃないかな?
natd(8) もそう言ってるし、IPFWのルールに divert はいらなくなるよ。
プロセスも一個節約できる。
- 958 :名無しさん@お腹いっぱい。 :02/06/20 00:53
- FreeBSDで、Windows NTのtreeコマンドと同等な働きをするコマンドはありませんか?
- 959 :名無しさん@お腹いっぱい。 :02/06/20 01:01
- NTのtreeコマンドがどんなのだか知っている人はどれくらいいるのだろう?
俺は知らん
- 960 :名無しさん@お腹いっぱい。 :02/06/20 01:01
- >958 find . -type d
- 961 :名無しさん@お腹いっぱい。 :02/06/20 01:01
- >>958
/usr/ports/syutils/tree は?
試してみようと思ったけど面倒だからやってねぇけど。
- 962 :名無しさん@お腹いっぱい。 :02/06/20 01:16
- >>961
ツリーのパーツの表現が違うか。まぁ当然だけど。
ってか、非日本語の NT ではどうやって表現してるんだ……?
- 963 :958 :02/06/20 01:32
- >961
ありがとうございます。早速
portupgrade -N /usr/ports/sysutils/tree
してみました。
% tree --help
usage: tree [-adfgilnpqstuxACDFNS] [-H baseHREF] [-L level [-R]] [-P pattern]
[-I pattern] [-o filename] [--version] [--help] [<directory list>]
% tree ~/public_html
|-- daemon.gif
|-- index.html
`-- site.rdf
- 964 :932 :02/06/20 05:51
- ipfw+natd、どうしても理解できなかったので、ipfwでlogをとりつつ、natd -verboseでnat変換をモニタしてみました。
>>936
言い切られたので自分が勘違いしてるんだとおもってけど…やっぱり当初の予想通りnatdにdivertされたパケットはnat変換後ipfwに戻る際にdivertされた位置の次のルールからマッチングが開始されてるようですよ。
add 100 deny log all from any to 192.168.0.0/16 recv tun0
add 200 divert natd all from any to any via tun0
add 300 allow all from any to 192.168.0.0/16 recv tun0
add 400 allow all from 192.168.0.0/16 to any
このルールでnat変換後、ルール100でパケットが落とされていたと思っていた問題はipfwの動作を見落としていました。
ルール200のnat変換後、ルール300でtun0から入るパケットは受付けていました。(logで確認)
その後、eth1(=sis1)からlan内に送られる際に再度ipfwを通るので、そのときにルール100にマッチして落とされていました。
一度受付けたパケットにもかかわらず、送り出されるときには再度正当性が確認されるんですね…。
>>938
調べてみたんですがnatの場合にestablishedを通さないといけない理由がわかりません。
add allow all from 192.168.0.0/16 to any
このルールがnatdへのdivertより前にあるとソースアドレスが外にでていっちゃいますけど、natdにdivertした後に置いてあると問題ないように思えます。
実際ちゃんとアドレス変換されてるのがモニタできました。
establishedってコネクションを張るサービス毎にrecvルールを書かなくても良いとか、コネクション中のパケットを優先的に受けるようにする為の物じゃないんですか?
>>957
しばらくppp(-nat)+ipfwでやってましたがポートリダイレクトのやり方が探せなくてnatdに逃げてました。
今調べたらppp(-nat)でもnatdとほとんど同じですね(^^;
natdの動作もだいたいわかった(つもり)なのでppp(-nat)に戻ろうかとおもいます。
- 965 :名無しさん@お腹いっぱい。 :02/06/20 06:32
- >>964
ちみの例の場合で、例えば内側の他のマシンからのパケットに対しては、
ipfw の機構は sis1 からの入力と tun0 への出力の計2回の評価を行う。
再度と言うよりは、man ipfw の Implementation notes(実装に関する注意) に書いてある通りだ。
漏れなりに 938 と同じ事を、逆の観点から言おう。
外からの SYN だけを防いで他のパケットは全部通しておけば、
とりあえづそこそこ安全に目的を達成できる筈だ(大抵は)。
お勧めの選択肢は、何も考えずにとりあえづ外からの setup は防いどくか、
TCP の 3way handshake の類の事を調べるか、深く考えずに幸せになるかの3択だ。
ここからは、漏れの独断と偏見によるお勧めだ。
add allow ip from any to any via lo0 を頭に書くべし。
自分から自分への IP のルール評価が速く終わる。
ちみの 100 のルールを漏れ流に書くと、
add deny log ip from 192.168.0.0/16 to any in via tun0
add deny log ip from any to 192.168.0.0/16 out via tun0
になる。
これ以上はネット板へGO だ。
- 966 :名無しさん@お腹いっぱい。 :02/06/20 06:55
- >>964
ほんとだ。
add 100 deny log all from any to 192.168.0.0/16 **in** tun0
add 200 divert natd all from any to any via tun0
add 300 allow all from any to 192.168.0.0/16 recv tun0
add 400 allow all from 192.168.0.0/16 to any
で、192.168.0.3から外にpingうったら
ipfw: 300 Accept UDP <routerのIP>:53 192.168.0.3:1829 in via tun0
ってなった。
- 967 :966 :02/06/20 07:13
- >>966
add 100 deny log all from any to 192.168.0.0/16 in via tun0
- 968 :名無しさん@お腹いっぱい。 :02/06/20 07:21
- http://www.h4.dion.ne.jp/~juupp/pcunix/usage/freebsd/samples/ipfwdivert.rules.txt
http://www.tac.tsukuba.ac.jp/~hiromi/ipfw4.html
パクった方がはええよ・・・
- 969 :名無しさん@カラアゲうまうま :02/06/20 07:29
- 厨房ですまそ。
ThinkPad240でFreeBSD4.5 installしたらXウィンドウが256色表示になるんです。
kernelを再構築するべきなのでしょうか?それともXF86configあたりをいじるべき
なのでしょうか?インストールはFTP経由で特に設定なんかは触ってません。
- 970 :名無しさん@お腹いっぱい。 :02/06/20 07:30
- eth1(=sis1)を通るパケットはどう考えても100にマッチしないじゃん?
400はgatewayの設定がまともなら通らないかもしれないけど、
まともじゃないルールだろう。
- 971 :966 :02/06/20 07:32
- divertのLOOP AVOIDANCEのセクションにそれらしいことがかいてあるね。
結局実際にはdivertで変換された後は
次のruleからマッチングを再開されることになるらしい。
ipfwのmanはmisleadingだ。
- 972 :名無しさん@お腹いっぱい。 :02/06/20 07:35
- >>969
大抵は XF86Config をいぢれば 16bit色 とかに出来る。
XFree86-4.2.0 だったら、Section "Screen" の中の Identifier、Device、Monitor と同じ階層に DefaultDepth 16 とかを書く。
- 973 :972 :02/06/20 07:43
- しまた、漏れ人の話聞いてねぇな・・・
FreeBSD4.5 で FTPインストール しっぱなしで XF86Config の事を知ってるとなると、
FreeBSD4.5 付属の XFree86-3.3.6_? か。
http://www.jp.freebsd.org/QandA/HTML/450.html
- 974 :942=956 :02/06/20 07:46
- >>952
set -x
したら色々出てくるんですね(echoが)。とりあえず結果報告。
+ network_gif_setup
+ ifconfig -l
の後やっぱり無反応になりました。ちくしょー。なんなんでしょう?
>>969
XF86Configのビデオチップとかの指定がおかしい場合もあり得るよ。
- 975 :974 :02/06/20 07:48
- >>972
あ、漏れも気がつきませんでした。
4.5をインストールするとXF86は3系の可能性が高いですね。
逝ってきます?
- 976 :972 :02/06/20 07:58
- 新スレも勃ってるしどうせそろそろげったーが来るだろうから書いちまえ(藁
>>969
本当はぐぐれば出てくる筈なんだけど、もう少し補足だ。
3.3.6 とかだったら XF86Setup 一発で大抵は事が足りる。
4.2 とかだったら XFree86 -configure した後、所定の位置に XF86Config でコピーして 972 に書いた通りだ。
>>975
男だったら逝って良し。
女だったら漏れも同罪だから、漏れと一緒に(略
- 977 :名無しさん@お腹いっぱい。 :02/06/20 08:50
- >969
X on TP240の3.3.6と4.2.0で使えてたXF86Configあるんで指定してくれれば貼るよ
- 978 :名無しさん@お腹いっぱい。 :02/06/20 10:22
- FreeBSD4.6にしようと思って、
cd /usr/share/examples/cvsup/
vi stable-supfile
(以下のように書き換える。
*default host=cvsup2.jp.FreeBSD.org
*default release=cvs tag=RELENG_4)
cd /usr/src
cvsup stable-supfile
make buildworld buildkernel
shutdown now(シングルユーザモード)
cd /usr/src
make installworld installkernel
まで行ったのですが、
なぜか、
make installworld installkernel
におきまして、
ERROR:Required smmsp user is missing
***ERROR code1***
stop in /usr/src
というエラーがおきて止まってしまいます。
smmspというのはsendmail専用ユーザ?らしいのですが、
僕はsendmailはFreeBSDインストールのままで、なにも
触っていません。
このエラー
を回避する方法はどうしたらいいでしょうか?
(後、NISクライアントの設定もしているのですが、アップデート
の時は設定切った方がいい?)
- 979 :名無しさん@お腹いっぱい。 :02/06/20 10:44
- >>978
なぜハンドブックの順番通りにやらないの?
あと、RELENG_4)の ")" はtypo?
- 980 :名無しさん@お腹いっぱい。 :02/06/20 10:59
- >>979
>なぜハンドブックの順番通りにやらないの?
どこか順番おかしいとこあります?
>あと、RELENG_4)の ")" はtypo?
そうです。みすりました。
- 981 :979 :02/06/20 11:04
- >>980
ハンドブックを読む限り
make buildworld
make buildkernel
make installkernel
reboot
make installworld
こう書いてある。
- 982 :名無しさん@お腹いっぱい。 :02/06/20 11:09
- では、それでやってっます!
- 983 :名無しさん@お腹いっぱい。 :02/06/20 11:17
- それではworldというターゲットは何のためにあるのだろう?
- 984 :名無しさん@Emacs :02/06/20 11:27
- ハンドブク讀めや、ゴルアァ
- 985 :名無しさん@お腹いっぱい。 :02/06/20 11:34
- >>946 CVSup サーバの負荷状況
http://home.jp.freebsd.org/stats/mrtg/cvsup/
- 986 :名無しさん@Emacs :02/06/20 11:34
- /usr/src/UPDATING も読もう.
NO_SENDMAIL=true でも必要なのは納得いかん気もするが...
20020217:
sendmail 8.12.2 has been imported. The sendmail binary is no
....
Due to the import of sendmail 8.12.2, a new user and group are
required in order for sendmail to run as a set-group-ID
binary. A 'make installworld' will use the new user and group
to set the owner and group of /var/spool/clientmqueue and will
fail if the new user and group do not exist. The 'smmsp' user
and group must be merged from src/etc/group and
src/etc/master.passwd before using 'make installworld'.
'mergemaster -p' will do this. You may need to install
- 987 :985 :02/06/20 11:36
- スマソ、ガイシュツだった
- 988 :名無しさん@お腹いっぱい。 :02/06/20 11:37
- >>978
mergemaster でユーザとグループ追加しときな
- 989 :932 :02/06/20 12:18
- >>965
内側から外へ向かうパケットはsis1とtun0と2度通るということは理解してるつもりでしたが、
add dely all from any to 192.168.0.0/16 recv tun0
このルールはtun0からの受信時だけに働くと思っていたのです。
log取ってみると外から戻ってきたパケットがnat変換されてtun0で受付けています。
次にsis1を通って内側に送られるわけですが、なぜかsis1を通るはずのパケットがこのルールにマッチして落とされてしまうのです。
ということはsisi1を通って内部に送られるパケットがどこから来たのかまでこのルールでチェックしてると解釈しました。
だけど、 >>970 でもつっこまれてるようにやっぱり変ですよね?
それと >>964 で書いたルールはあくまでipfwとnatdのパケットの流れを説明するために作った物で実際にはそんなルールで使ってません。
フィルタルールについての質問ではないとしっかり書いておくべきでした。手間とらせてすいません。
>>968
もちろん他のページのルールを参考にしてますけど、そのサイトが100%信頼できるとは限りませんよね?
理解して使わないといつか痛い目にあいそうな気がして…。
>>970
調べてくれてありがとう。
man natdではdivertされた位置の次のルールからファイアウォールに戻ると書いてるんですけどね。
いろいろありがとうございました。
これ以後のこの件に関しては次のスレッドに移行します。
(これで終わりのつもりだけど)
- 990 :名無しさん@お腹いっぱい。 :02/06/20 12:46
- >>957
punch_fwできない罠
- 991 :名無しさん@お腹いっぱい。 :02/06/20 12:56
- 重箱。誰も話題にしてないじゃん。
- 992 :932 :02/06/20 13:05
- レスミス
>>989 の最後 >>971 さんに対してお礼いったつもりが970さんになってた…。
- 993 :名無しさん@お腹いっぱい。 :02/06/20 13:14
- PCV-MXS1にFreeBSDを導入した方いますか?
- 994 :誘導 :02/06/20 13:20
- >>993
http://pc.2ch.net/test/read.cgi/unix/1024497990/l50 へ
- 995 :名無しさん@お腹いっぱい。 :02/06/20 15:17
- 995
- 996 :名無しさん@お腹いっぱい。 :02/06/20 15:23
- はい、それから〜
- 997 :名無しさん@お腹いっぱい。 :02/06/20 15:24
- 質問あるひと言ってくれよな〜
http://pc.2ch.net/test/read.cgi/unix/1024497990/l50
- 998 :名無しさん@お腹いっぱい。 :02/06/20 15:25
- ズザー
- 999 :名無しさん@お腹いっぱい。 :02/06/20 15:30
- 999
- 1000 :名無しさん@お腹いっぱい。 :02/06/20 15:31
- 1000
- 1001 :1001 :Over 1000 Thread
- このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
掲示板に戻る 全部 前100 次100 最新50read.cgi ver5.26+ (01/10/21-)