初心者もＯＫ！ FreeBSD質問スレッド その18
952 ：名無しさん＠お腹いっぱい。：02/06/19 23:37
>942 /etc/rcの2行目にset -xと書いてみる。
953 ：名無しさん＠お腹いっぱい。：02/06/19 23:47
>>944
世の中には例えとしての表記で意味が通じない人もいるので、誤解されぬよう
注釈を加えると良いと思います。 "eth1 = sis1"みたいにね。
まぁ、ツッコミ入れなければならないほど解釈できない表現ではないと
思いますけど。
>>948
ベンダーで一括りにするとちょっとマズくないですか？
realtek 80xx系 -> ed
realtek 81xx系 -> rl
になりますし。（realtek 80xx系はNE2000互換チップ）
"チップ[コントローラ]の種類によって変わる"の方が誤解されないと
思います。
世の中には例えとしての表記で意味が通じない人もいるので、誤解されぬよう
注釈を加えると良いと思います。 "eth1 = sis1"みたいにね。
まぁ、ツッコミ入れなければならないほど解釈できない表現ではないと
思いますけど。
>>948
ベンダーで一括りにするとちょっとマズくないですか？
realtek 80xx系 -> ed
realtek 81xx系 -> rl
になりますし。（realtek 80xx系はNE2000互換チップ）
"チップ[コントローラ]の種類によって変わる"の方が誤解されないと
思います。
956 ：942：02/06/20 00:29
957 ：名無しさん＠お腹いっぱい。：02/06/20 00:42
>>932
ppp + IPFW + natd より、ppp(-nat) + IPFW でいいんじゃないかな？
natd(8) もそう言ってるし、IPFWのルールに divert はいらなくなるよ。
プロセスも一個節約できる。
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
962 ：名無しさん＠お腹いっぱい。：02/06/20 01:16
>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
ありがとうございます。早速
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)に戻ろうかとおもいます。
>>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 への出力の計２回の評価を行う。
再度と言うよりは、man ipfw の Implementation notes（実装に関する注意） に書いてある通りだ。
漏れなりに 938 と同じ事を、逆の観点から言おう。
外からの SYN だけを防いで他のパケットは全部通しておけば、
とりあえづそこそこ安全に目的を達成できる筈だ（大抵は）。
お勧めの選択肢は、何も考えずにとりあえづ外からの setup は防いどくか、
TCP の 3way handshake の類の事を調べるか、深く考えずに幸せになるかの３択だ。
ここからは、漏れの独断と偏見によるお勧めだ。
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 だ。
ちみの例の場合で、例えば内側の他のマシンからのパケットに対しては、
ipfw の機構は sis1 からの入力と tun0 への出力の計２回の評価を行う。
再度と言うよりは、man ipfw の Implementation notes（実装に関する注意） に書いてある通りだ。
漏れなりに 938 と同じ事を、逆の観点から言おう。
外からの SYN だけを防いで他のパケットは全部通しておけば、
とりあえづそこそこ安全に目的を達成できる筈だ（大抵は）。
お勧めの選択肢は、何も考えずにとりあえづ外からの setup は防いどくか、
TCP の 3way handshake の類の事を調べるか、深く考えずに幸せになるかの３択だ。
ここからは、漏れの独断と偏見によるお勧めだ。
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
ってなった。
ほんとだ。
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
ってなった。
>>966
add 100 deny log all from any to 192.168.0.0/16 in via tun0
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
パクった方がはええよ・・・
http://www.tac.tsukuba.ac.jp/~hiromi/ipfw4.html
パクった方がはええよ・・・
969 ：名無しさん＠カラアゲうまうま：02/06/20 07:29
厨房ですまそ。
ThinkPad240でFreeBSD4.5 installしたらXウィンドウが２５６色表示になるんです。
kernelを再構築するべきなのでしょうか？それともXF86configあたりをいじるべき
なのでしょうか？インストールはFTP経由で特に設定なんかは触ってません。
ThinkPad240でFreeBSD4.5 installしたらXウィンドウが２５６色表示になるんです。
kernelを再構築するべきなのでしょうか？それともXF86configあたりをいじるべき
なのでしょうか？インストールはFTP経由で特に設定なんかは触ってません。
970 ：名無しさん＠お腹いっぱい。：02/06/20 07:30
eth1(=sis1)を通るパケットはどう考えても100にマッチしないじゃん？
400はgatewayの設定がまともなら通らないかもしれないけど、
まともじゃないルールだろう。
400はgatewayの設定がまともなら通らないかもしれないけど、
まともじゃないルールだろう。
divertのLOOP AVOIDANCEのセクションにそれらしいことがかいてあるね。
結局実際にはdivertで変換された後は
次のruleからマッチングを再開されることになるらしい。
ipfwのmanはmisleadingだ。
結局実際には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 とかを書く。
大抵は XF86Config をいぢれば 16bit色 とかに出来る。
XFree86-4.2.0 だったら、Section "Screen" の中の Identifier、Device、Monitor と同じ階層に DefaultDepth 16 とかを書く。
しまた、漏れ人の話聞いてねぇな・・・
FreeBSD4.5 で FTPインストール しっぱなしで XF86Config の事を知ってるとなると、
FreeBSD4.5 付属の XFree86-3.3.6_? か。
http://www.jp.freebsd.org/QandA/HTML/450.html
FreeBSD4.5 で FTPインストール しっぱなしで XF86Config の事を知ってるとなると、
FreeBSD4.5 付属の XFree86-3.3.6_? か。
http://www.jp.freebsd.org/QandA/HTML/450.html
>>952
set -x
したら色々出てくるんですね（echoが）。とりあえず結果報告。
+ network_gif_setup
+ ifconfig -l
の後やっぱり無反応になりました。ちくしょー。なんなんでしょう？
>>969
XF86Configのビデオチップとかの指定がおかしい場合もあり得るよ。
set -x
したら色々出てくるんですね（echoが）。とりあえず結果報告。
+ network_gif_setup
+ ifconfig -l
の後やっぱり無反応になりました。ちくしょー。なんなんでしょう？
>>969
XF86Configのビデオチップとかの指定がおかしい場合もあり得るよ。
新スレも勃ってるしどうせそろそろげったーが来るだろうから書いちまえ（藁
>>969
本当はぐぐれば出てくる筈なんだけど、もう少し補足だ。
3.3.6 とかだったら XF86Setup 一発で大抵は事が足りる。
4.2 とかだったら XFree86 -configure した後、所定の位置に XF86Config でコピーして 972 に書いた通りだ。
>>975
男だったら逝って良し。
女だったら漏れも同罪だから、漏れと一緒に（略
>>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あるんで指定してくれれば貼るよ
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クライアントの設定もしているのですが、アップデート
の時は設定切った方がいい？)
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
980 ：名無しさん＠お腹いっぱい。：02/06/20 10:59
>>980
ハンドブックを読む限り
make buildworld
make buildkernel
make installkernel
reboot
make installworld
こう書いてある。
ハンドブックを読む限り
make buildworld
make buildkernel
make installkernel
reboot
make installworld
こう書いてある。
982 ：名無しさん＠お腹いっぱい。：02/06/20 11:09
では、それでやってっます！
983 ：名無しさん＠お腹いっぱい。：02/06/20 11:17
それではworldというターゲットは何のためにあるのだろう?
984 ：名無しさん＠Ｅｍａｃｓ：02/06/20 11:27
ハンドブク讀めや、ゴルアァ
985 ：名無しさん＠お腹いっぱい。：02/06/20 11:34
986 ：名無しさん＠Ｅｍａｃｓ：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
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
スマソ、ガイシュツだった
988 ：名無しさん＠お腹いっぱい。：02/06/20 11:37
>>978
mergemaster でユーザとグループ追加しときな
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された位置の次のルールからファイアウォールに戻ると書いてるんですけどね。
いろいろありがとうございました。
これ以後のこの件に関しては次のスレッドに移行します。
(これで終わりのつもりだけど)
内側から外へ向かうパケットは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できない罠
punch_fwできない罠
991 ：名無しさん＠お腹いっぱい。：02/06/20 12:56
重箱。誰も話題にしてないじゃん。
992 ：932：02/06/20 13:05
993 ：名無しさん＠お腹いっぱい。：02/06/20 13:14
PCV-MXS1にFreeBSDを導入した方いますか？
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
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 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。