07/10/25 10:50:37
NFSを想定したコードばかりとは限らない状況で
NFSを使うことになる、なんて話もあるだろう。
そういうときにハマるかハマらないかの差は大きいと思うんだよなあ。
151:名無しさん＠お腹いっぱい。
07/10/29 00:31:04
結局なにをどう実験すればいいんだろう。
(1)Solaris10
(2)FreeBSD 6.2(RELENG_6)
(3)NetBSD 3.1
(4)Linux（リリースが新しいもののうちどれか）
これらを混ぜたLANを作り順番にNFSサーバ役をやらせて、
いくつかのロック方法(lockf, flock, fcntl, あと他に何が？)を
使うCのコードを走らせて経過を観察する、でいいのかな？
誰かコード書いてくれないかな。
152:名無しさん＠お腹いっぱい。
07/10/29 07:40:49
>>151
flockはもともと単一ホストでしか使えないのでここでは関係なし。
fcntlの(F_SETLKWなど)は、lockfと同じ(というか、lockfがfcntlを呼び出してる)
ので、lockfのみテストすれば桶。
ほか、lockfを使わずに mkdirや symlink や link がロックとして機能するかどうかの
テストができればいいかな。
153:名無しさん＠お腹いっぱい。
07/10/29 10:41:18
>lockfがfcntlを呼び出してる
それは実装によって違うだろ
154:名無しさん＠お腹いっぱい。
07/10/29 13:52:29
>>152
- 誰かがロック中にサーバが落ちた後のリカバリがまともかどうか
- ロックを獲得したままのクライアントが落ちた後のリカバリがまともかどうか
も必要じゃない？
実装が難しくなるのもそのあたりを考えなきゃいけないからだろうし。
155:名無しさん＠お腹いっぱい。
07/10/29 15:02:09
>>154
それはどういう振る舞いをもって「まとも」と見なせばいいんでしょうか。
前者はサーバの落ち具合一つとっても、単なる回線障害なのか、
サーバ側のファイルシステムに絡む問題なのかで話が変わるだろうし。
後者はロックのタイムアウト処理が適切？か、とかですか？
156:名無しさん＠お腹いっぱい。
07/10/29 15:33:42
>>149
> その反論として >>143 が、lockf以外のロック方法を言ってるんじゃないか?
symlinkだのmkdirだのは排他制御の方法としてlockf以上に「お話にならない」。
書類審査で落とされる。
157:名無しさん＠お腹いっぱい。
07/10/29 15:42:43
>>156
でも、(少なくとも)Solarisだと、symlinkもmkdirもしっかりロックとして
機能するんだよ。
158:名無しさん＠お腹いっぱい。
07/10/29 15:56:52
FreeBSDはlockfがダメだからNFSが使いものにならない
↓
NFSでlockfなんか使うのは運用が間違ってる(mkdirやsymlinkを使えば良い)(>>by 141)
↓
symlinkだのmkdirだのはお話にならない(by >>156)
↓
FreeBSDではNFSは使えない。
結局こういうことになるじゃんｗ
159:名無しさん＠お腹いっぱい。
07/10/29 16:02:26
symlinkとかではお話にならないとか言ってる奴は……お話にならないな。
メール関係のデーモンやツールをソースからコンパイルする時に
気づくことすら知らないわけで……
160:名無しさん＠お腹いっぱい。
07/10/29 20:47:12
とりあえずポリシーとか仕様とか一切とっぱらいで、
ロックとして使えるもの、使われがちなもの、に対して、
各OSをサーバ、クライアントにしたときの動作相性表を書いてみろ、
ってことか？ 横方向クライアントOS、縦方向サーバOSにして、
lockf, flock, fcntl, symlink, mkdir
で表が５枚出来る、と。
161:名無しさん＠お腹いっぱい。
07/10/30 00:22:59
nfsv4だったらいいんじゃない。
162:名無しさん＠お腹いっぱい。
07/10/30 01:21:29
>>161
ｽﾚﾘﾝｸ(unix板:643-652番)n
163:名無しさん＠お腹いっぱい。
07/10/30 01:38:08
あるじゃんNFSv4
snowhite.cis.uoguelph.ca/nfsv4/
164:名無しさん＠お腹いっぱい。
07/10/30 12:39:49
サーバNetApp, クライアントTurboLinux Fujiという環境で
たまに下記のように .nfs～ で始まるファイルが出来ている
事あるのだけど、これはどういうタイミングで出来るのでしょうか？
また、消してかまわないのでしょうか？？
-rw-r--r-- 1 hogehoge admin 2253 10月 10 15:36 .nfs002d56600000001
165:名無しさん＠お腹いっぱい。
07/10/30 13:09:57
>>157
仕様上正しく動くことが保証されていないと、1億年と2000年前から動かしたときには
コケることになる。これは排他制御とはいえない。
NFS protocolのsymlinkは保証なんかしていない。
fcntlが使うlockd protocolは保証してるけど、こちらは伝統的にbuggyな実装が多かった。
>>158
なんでNFSで出来ない排他制御をやりたがるのか。問題に応じて解決法はいろいろある。
そもそも遅延とパケットロスのあるTCP/IP越しに排他制御やろうってのが性根が
腐ってるわけで、性能が問題にならないなら1台にまとめればいいし、
性能が重要ならcriticalな処理だけ切り出して1台にまとめ、残りを分散すればよい。
>>159
逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
前提に、それでも衝突することがないように(排他できなくてもよいように)
工夫して書かれている。
166:名無しさん＠お腹いっぱい。
07/10/30 13:16:18
>>164
UNIXでは、プロセスが開いているファイルでも削除できる。
そのとき、ファイルはすでに削除され見えないのだが、
オープンしたプロセスだけはファイルにアクセスし続けられる。
同じことはNFS上でもできるのだが、NFSでは見えなくするわけにはいかないので、
.nfsXXXX にリネームしてお茶を濁している。
これはプロセスがファイルをクローズしたときに削除される。
クライアントが削除を怠ると(=クライアントのOSが落ちると)
.nfsはストレージ上に残されたまま放置される。
167:名無しさん＠お腹いっぱい。
07/10/30 13:51:42
>>165 なんでNFSで出来ない排他制御をやりたがるのか。
だってNFSと銘打ってるのにそれが出来てる(ように見える)OSがあるんだもんよー。
FreeBSDで出来ないのは悔しくね？ という話だと思っていた。
168:164
07/10/30 19:31:59
>>166
ありがとうございました。
169:名無しさん＠お腹いっぱい。
07/10/31 02:24:25
出来ているように見えるだけで
本当に出来ているのかは定かではないｗ
170:名無しさん＠お腹いっぱい。
07/10/31 12:47:49
>>165
>逆。そういったコードは、NFS越しのファイル操作で排他が保証されないことを
>前提に、それでも衝突することがないように(排他できなくてもよいように)
>工夫して書かれている。
えー。
嘘書いちゃ、だめだよ。
171:170
07/10/31 12:53:50
ああ、プロトコル上だけで実現できるかどうかの話をしてるのか。
symlinkはロック機構じゃないんだから、symlinkの使い方を工夫しないで
実現できないのは当然じゃん。
172:名無しさん＠お腹いっぱい。
07/10/31 15:00:03
たとえばqmailのmaildir。
NFS環境下で安全にメッセージを配送するために、
ユニークなファイル名で衝突しないようにしている。
URLﾘﾝｸ(cr.yp.to) を見ると先頭に書いてあるのは、
> Two words: no locks.
173:名無しさん＠お腹いっぱい。
07/11/12 14:19:39
実家 in 四国にあるマシンのディスクを
俺んち in 大阪にあるマシンから nfs でマウントするのは無謀？
セキュリティ面はおいといて（ VPN 張るので）、
速度的にとか、ファイルの書き換えしてると不意に
ファイルがロストしちゃったりとか、そういうことってある？
174:名無しさん＠お腹いっぱい。
07/11/12 14:53:17
俺は東京にいるんだが普通にSan Joseのファイルサーバをマウントしてるぞ。
175:名無しさん＠お腹いっぱい。
07/11/12 15:07:04
>>174
そんな無謀な・・・
そういう時って TCP ベースの nfs 使うの？
それとも VPN 張った上でいつもの UDP なやつ？
そもそも NFS で TCP って聞いたときには
うへぇ、と思ったものだが。
176:名無しさん＠お腹いっぱい。
07/11/12 17:38:36
> NFS で TCP うへぇ
何で？
177:名無しさん＠お腹いっぱい。
07/11/12 19:10:29
>>176
NFS側にリトライ処理が付いてるのに
TCPにする事でTCP側の再送制御が増えるからではないかと。
1000/100Mbps混在でイーサネットスイッチが
バッファ溢れしてデータをポロポロこぼすような環境だと
NFS over TCPはそれなりに有効。
というかウチの社では推奨してる。
エラーフリー環境で使うなら、
TCPよりUDPの方が速いベンチ結果にはなるね。
178:名無しさん＠お腹いっぱい。
07/11/13 17:31:15
> 1000/100Mbps混在でイーサネットスイッチが
> バッファ溢れしてデータをポロポロこぼすような環境だと
まてまてIEEE802.3xのフロー制御あるんだからいまどきそんな環境ありえんだろ。
そんなとこでNFS使ったら再送発生するたびにどれだけつっかえるんだよ。
先にまずネットワーク直せよ。
179:名無しさん＠お腹いっぱい。
07/11/13 23:07:09
>> 1000/100Mbps混在でイーサネットスイッチが
>> バッファ溢れしてデータをポロポロこぼすような環境だと
>まてまてIEEE802.3xのフロー制御あるんだ>からいまどきそんな環境ありえんだろ。
普通そうだよな。
でも、そんなスイッチが半年前まで現行機種でな。
営業が安さにつられて構成勝手に変えて、
そのゴミスイッチ相手に格闘する羽目に orz
180:名無しさん＠お腹いっぱい。
07/11/14 00:33:23
flow controlで送信止められちゃうとnicの送信ディスクリプタが
足りなくなってOS内でパケット捨てることはあるかもしれない。
181:173
07/11/15 19:26:23
なんかうまくいかなかった原因がわかりました。
PPTP で Linux - Linux で VPN 張ってたんですが，
PPP での MTU のネゴシエーションがうまくできてなかったみたいで
1500 になってたのが原因でした．
思い切って 1400 にしたら問題なくなりました．
うむむ，NTT西日本のフレッツとケイオプティコムの
eo光の間の VPN なんですが，結構ヘッダついてるんだなぁ．
最適値は 1408 のような気もするけど面倒なので 1400．
普通は自動的にネゴってくれますよねぇ？
182:名無しさん＠お腹いっぱい。
07/11/19 13:13:21
URLﾘﾝｸ(www.linux.or.jp)
183:名無しさん＠お腹いっぱい。
07/11/20 11:13:29
NFSに強いスイッチを探してます。クライアントは６４台くらいです。
構成としては、クライアントとサーバを１つのスイッチに集約するのではなく、
２４ポートを数台使ってツリー型の構成にし、ツリーの上流にサーバを置く
形を想定しています。ネストは２段くらいです。
そのものずばりのお勧めより、こういう用途のときにスイッチに必要な機能は
どういうものかを教えていただけると、品定めするときに参考になるのですが、
お知恵を拝借できますでしょうか？
184:名無しさん＠お腹いっぱい。
07/11/20 11:39:49
普通にCatalystで良いジャン
185:名無しさん＠お腹いっぱい。
07/11/20 11:56:43
ワイヤースピード、ノンブロッキング
低レイテンシ
広帯域スイッチファブリック
186:名無しさん＠お腹いっぱい。
07/11/20 12:54:06
>>184
そこをもうちょっと安めでお願いできますか……
187:名無しさん＠お腹いっぱい。
07/11/20 20:32:18
NICは全てIntelで揃えるのが吉。
あと、サーバに極端な負荷がかからないよう、アップリンクだけ1Gにして
クライアントは全て100Mにするのが吉。
188:名無しさん＠お腹いっぱい。
07/11/21 08:56:03
Broadcom はだめですか？
AMD Opteron なサーバと Intel の NIC の
相性が悪いとかないかな？
189:187
07/11/21 10:09:53
>>188
> Broadcom はだめですか？
Broadcomは評価した事が無いので知らない。
190:名無しさん＠お腹いっぱい。
07/11/22 23:36:32
intelもだめだよなあ。相性悪すぎ。ギガビットは総じてダメ。
191:名無しさん＠お腹いっぱい。
07/11/23 01:10:20
蟹ギガ。これ、素人にはお勧めしない
192:名無しさん＠お腹いっぱい。
07/11/23 11:57:03
>>190
ちょ、んなこといったら使うものないじゃん。
193:名無しさん＠お腹いっぱい。
07/11/23 12:16:00
10Gbとか?
194:名無しさん＠お腹いっぱい。
07/11/23 12:18:50
>>192
Broadcomでいいじゃん
195:名無しさん＠お腹いっぱい。
07/11/23 23:24:06
broadcomは悪くないがvariantが多すぎて一口に語れないのが問題。
196:名無しさん＠お腹いっぱい。
07/11/24 00:21:00
なるほどね
197:名無しさん＠お腹いっぱい。
07/11/24 14:06:57
詳しい人に質問、unixでは次のプログラムで読取専用ファイルの作成が可能
int main() {
int fd; char buf[10];
int fd=open("poi", O_CREAT|O_TRUNC|O_WRONLY|O_EXCL, S_IRUSR|S_IRGRP|S_IROTH);
write(fd, buf, sizeof(buf)); /* creatを行ったfdは書き込みが可能 */
fclose(fd);
}
これをNFSv3マウントされたディレクトリ上で実行すると
CREAT, SETATTR, WRITEのprotocolが順に発行されます。
これをNFSサーバ側で問題なく扱おうとすると面倒があって
最後の読取専用へのWRITEを許可するかどうか、
WRITE要求のハンドルがCREATE時のものと一致するかで判断しないといけない。
このような判定の実装はNFSサーバにとって義務なのかな？
198:名無しさん＠お腹いっぱい。
07/11/24 14:11:09
>>197
当然義務。
読取専用かどうかは、creatまたはopenの際のみに有効な属性で、
一旦open(ハントル取得)してさえしまえば、
ファイル自体の読みとり専用かどうかに関係なく、
O_WRONLYとかでopenされたのなら書き込みができなければならない。
199:名無しさん＠お腹いっぱい。
07/11/24 14:11:38
>>197
プログラム中のfclose(fd)はclose(fd)の間違いです
200:名無しさん＠お腹いっぱい。
07/11/24 14:17:29
>>198
おー、こんなピンポイントで回答が来るなんて凄いです 流石unix板
ちなみにこれはCVSが実際にやってくれる操作です
201:名無しさん＠お腹いっぱい。
07/11/24 14:19:25
ちなみに、わざわざ C言語でプログラムしなくても、
シェル上で同じことができる。
umask 777
echo hoge > file
とやれば、fileは読み込みも書き込みも不許可で作成されるが、
echo hogeの内容はちゃんとfileに書き込まれる。
fileがNFS上にあっても当然動作しなければならない。
202:名無しさん＠お腹いっぱい。
07/11/24 14:21:35
なるほどumaskはそうやって使うんですね
203:名無しさん＠お腹いっぱい。
07/11/24 17:34:17
>>198
RFC1813, 4.4 Permission issues の第3段落に書いてありました
204:名無しさん＠お腹いっぱい。
07/11/25 15:06:35
RPC でつかうポートが変化するから、
NATルータ越しのNFSは㍉？
VPN 通すしかない？
205:名無しさん＠お腹いっぱい。
07/11/25 17:00:41
Intelの82573L で2.4系カーネルでNICのリセット多発した。
結局、NICのROMのアドレス1部変更で直った。
2.6カーネルでは解消された。
206:名無しさん＠お腹いっぱい。
07/12/06 13:41:08
>>204
実装によってはポート固定も無理ではないが、
ここで聞かないとわからないレベルならお薦めしない。
あと、WebNFSという選択肢もある。
207:名無しさん＠お腹いっぱい。
07/12/19 02:30:55
NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
NFSサーバに10GBのファイルがあって、それをNFSクライアントで読み込むときに
10GB全部をクライアントでリード・ライトしなきゃいけないとかそういうことなんでしょうか？
208:名無しさん＠お腹いっぱい。
07/12/19 09:08:58
>>207
> NFSとiSCSIでよくファイル単位と、ブロック単位という比較を聞くんですが、
どこであるいは誰に聞いた？
209:名無しさん＠お腹いっぱい。
07/12/19 09:21:46
>>208
google: NFS iSCSI ファイル ブロック
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞データ転送の単位は，NASにアクセスするときはファイル単位となる。つまり，NASへのデータ・アクセスでは，ファイル名や共有名などファイルを特定する呼び名で管理している。
＞これに対し，SANの場合はブロック単位の処理になる（通常1つのファイルは1つまたは複数のブロックで構成される）。SANでは，リモートにあるディスク装置内のディスクが，あたかもローカル・ディスク（RAWデバイス＊4）であるかのように振る舞う。
（略）
＞IP-SANには，「FCIP（Fibre Channel over IP）」「iFCP（Internet Fibre Channel Protocol）」「iSCSI（Internet SCSI）」という規格がある。この中で最も期待されているのがiSCSIである。
ってことじゃねーの？
210:名無しさん＠お腹いっぱい。
07/12/19 09:58:18
SCSIの復活キター？
211:名無しさん＠お腹いっぱい。
07/12/19 11:14:58
って事はiSCSIの方が巨大ファイルでは優位って事なの？
212:名無しさん＠お腹いっぱい。
07/12/20 16:46:40
何を持って優劣の指標としているのか明快に述べよ
213:名無しさん＠お腹いっぱい。
07/12/20 16:58:19
何を持って誤字の書込みをしているのか明解に述べよ
214:名無しさん＠お腹いっぱい。
07/12/27 14:42:36
NFSとiSCSIではファイルシステムの層が違う。
ファイル操作システムコール(API)
VFS
個々のファイルシステム(ext3,xfs,reiserfs,fat16,iso9660)
ドライバ
ハードウェア
NFSってのはファイル操作システムコールに相当、ファイル単位でも扱えるし、
バイト単位で読んだりもできる。VFSから下は考えなくてよい。
iSCSIってのはドライバに相当、ファイル単位では考えないで、
ハードウェアとのやりとりの最小単位(ブロック単位)で考えなければならない。
システムとして利用するには、ファイルシステム、VFS、システムコールも備えていなければならない。
215:名無しさん＠お腹いっぱい。
07/12/27 14:48:10
>>212-213
以って？
216:名無しさん＠お腹いっぱい。
07/12/27 19:59:34
RedHat Linux Enterprise Linux ES 4 2台で NFS サーバと NFS クライアントの設定をしました。
NFS サーバと NFS クライアント側では、それぞれの /etc/passwd にユーザが同じuid、gidで
登録されていて、group hoge に属するユーザだけに書き込ませたいです。
NFSサーバ側：
# mkdir -p /opt/share; ← NFS で共有したいディレクトリを作成
# chgrp hoge share
# chmod g+ws share;
/etc/exports の内容：
/opt/share 192.168.0.0/255.255.255.0(rw,sync)
NFS クライアント側
# mkdir -p /opt/share ← マウントポイントとなるディレクトリを作成
# chgrp hoge share
# chmod g+ws share;
mount -t nfs {nfs_server_name}:/opt/share /opt/share
ここまでは簡単にできたなのですが、nfs クライアント側から、umask が 0022 なユーザが
書き込みをすると、NFS サーバ側では -rw-r--r-- というファイルができます。
ここまではあたりまえですが、これを NFS 側で、強制的に -rw-rw-r として保存するような設定はありますか?
samba だと smb.conf で、公開ディレクトリのブロックの中で
directory mask = 0664
とできますが、これと同じようなことがしたいです。
217:名無しさん＠お腹いっぱい。
07/12/28 05:39:34
/opt/share のファイルシステムのマウントオプションのumaskしだいでは?
NFSサーバの実装によってはそういうのもありえるかもしれないけど、
NFSサーバでumaskを強制させてもあまり意味がないのかも。roかrwくらいだろうし…
218:216
08/01/05 07:48:19
>>217
レスどうもありがとうございます。遅くなってすみません。
結局以下の方法で対応しました。
NFS サーバ側で uid hoge / gid hoge という共通ユーザを作成し、
NFS サーバの /etc/exports で以下のようにした。
/opt/share 192.168.0.0/255.255.255.0(rw,sync,all_squash,anonuid=xxx,anongid=xxx)
↑ uid=xxx gid=xxx は、hoge:hoge の uid と gid
こうすることで、NFS クライアント側は gid hoge に属していれば、uid は別のユーザが
作成したファイルを、別のユーザが消すことができるようになりました。
理想は NFS サーバ側で、どの NFS クライアントのユーザがファイルを作成したか知れたほうが
よかったのですが、ここは目をつぶりました。
なお man mount すると、-t で指定するファイルシステムタイプの中で、
一部では -o に mask みたいなオプションが指定できるようですが、-t nfs のときは、
mask と行ったオプションは用意されていませんでした。
219:名無しさん＠お腹いっぱい。
08/01/06 11:20:48
そもそも論になるけど、NIS使えば?
220:名無しさん＠お腹いっぱい。
08/01/06 21:59:39
えーマジNISー？ｗ
NISが許されるのは10人未満のLANまでだよねーｗｗｗ
221:名無しさん＠お腹いっぱい。
08/01/06 23:17:07
>>220
じゃあなんNISればいいんですか？＞＜
222:名無しさん＠お腹いっぱい。
08/03/08 17:17:43
複数台のサーバ環境（自宅サーバ郡）でNFS使って共有するときって、どのディレクトリをシェアするのが効率的なんでしょ
みなさんの運用方法で「これはおすすめ！」っての、教えてもらえないでしょうか。
ちなみにうちはCentOS5の6台構成（Web 3台、Db1台、開発用1台、DB＆NFS＆Samba鯖機1台）
223:名無しさん＠お腹いっぱい。
08/03/08 17:39:30
WebサーバでNFSなんて使わないでくださいネ。
224:名無しさん＠お腹いっぱい。
08/03/08 17:43:03
>>223
え、そうなの？
/usr/local/libならシェアしてるけども。
225:名無しさん＠お腹いっぱい。
08/03/08 23:39:09
NFSっていらんやろ
226:名無しさん＠お腹いっぱい。
08/03/08 23:47:11
>>222
/homeのNFS共有は当然として、
OSのバージョンが同じなら /usr以下をすべてNFS共有する。
updatesとか、OSのバージョン管理が一元化できる。
ホストを1台増やす時でも、OSをインストールする必要はない。
もともとインストール済の/usrをNFS共有して、
ホスト毎に必要な/etcや/varなどを個別に用意するだけで済むから。
227:名無しさん＠お腹いっぱい。
08/03/09 13:46:30
>>223
ロードバランサーでWebサーバ束ねているような場合、コンテンツの
directoryをNFSで共有って、良くやるパターンだよね？
セキュリティの事を気にして言っているの？
だとしても、その対処法はあるわけで。
228:名無しさん＠お腹いっぱい。
08/03/09 21:25:20
たいていのパッケージシステムは、/usrのNFS共有を想定してないんじゃないかな。
少なくとも、 ベンダやメンテナによるテストはあまりされていないよね。
そもそも今はパッケージシステム(と安くなったディスク)のおかげで、/usrを共有する必要性って薄くない?
ロードバランサで分散しなきゃならないWebトラフィックって、CGI(CPU bound)なやつで、
その場合はRDBを共有するんじゃないかな。NFSサーバではなく。
NFSに限らず、ネットワークは不確かで、トラブルの発生源の代表格。
厄介なホスト間の依存性も発生するし、ホストローカルで完結するならその方がいいに決まってる。
このシステムにNFSって本当に必要なの? って自問してみるのは、管理コストを減らすのに役立つと思う。
個人的な感覚では、システムのメンテナンスのためにNFSをスポットで利用するのは便利だと思う。
(一般ユーザの/homeや/usr/portsみたいなのを共有するということね)
229:名無しさん＠お腹いっぱい。
08/03/09 22:31:09
Solarisでは、/usrはNFS共有することが前提で、
パッケージは SUNW**u が /usr用、SUNW**r が /usr以外用と、
きちんと分けて考えられてるね。
なるべく共有できるバイナリを増やすため、
/binを廃止して /binを /usr/binへのsymlinkにしてるくらいだし。
230:名無しさん＠お腹いっぱい。
08/03/09 23:41:52
つ、つまり共有すべきなのは/usr, /homeの二つが鉄板ということでおｋ？
ていうかNFSで共有してる時点でかなりアクセスのパフォーマンスが低下することは避けられないですよね、うーむ。
LAN内で共有してるのであればそんなに気にスンナってか。
231:名無しさん＠お腹いっぱい。
08/03/10 10:44:40
いまどきNFSなんて使ってるのか？
232:名無しさん＠お腹いっぱい。
08/03/10 11:13:09
>>230
日本語が読めてないな。
Solarisは/usrを共有することを想定して設計されているから共有できる。
おまえが使うOSはSolarisなのか?
233:名無しさん＠お腹いっぱい。
08/03/10 11:36:11
*BSD方面では、NFSは「無かったこと」にしたいんだろうなｗ
234:名無しさん＠お腹いっぱい。
08/03/10 11:42:27
よく知らんけど、Linux方面のNFS実装ってマシになったの?
235:名無しさん＠お腹いっぱい。
08/03/10 13:58:02
数年前にzero copyな実装になって今ではNFSv4まで対応してます。
236:名無しさん＠お腹いっぱい。
08/03/10 14:41:03
NFSでマウントしたディレクトリってやっぱりアクセス速度が低下するんですか
ってことはデータベース（MySQL)のデータ領域をNFS共有して運用するなんてしちゃだめですね。
でもなんでWebならいいんだ？
237:名無しさん＠お腹いっぱい。
08/03/10 14:53:29
書き込まないなら良いんじゃない？遅いけど。
238:名無しさん＠お腹いっぱい。
08/03/10 16:02:19
OracleみたいにNFS向けに最適化されているならともかく、
通常のデータベースはNFSファイルシステム上に置いてはいけない。
> でもなんでWebならいいんだ？
Webでもよくはない。NFSで複数のWebサーバがコンテンツを共有するのは、
導入費用も管理コストも高くつくアプローチだ。
239:名無しさん＠お腹いっぱい。
08/03/10 16:05:35
しちゃだめって言うより
意味なくね？
240:名無しさん＠お腹いっぱい。
08/03/10 16:08:35
>>238
> OracleみたいにNFS向けに最適化されている
そうなんか。
Windows 用のだとネットワークストレージ上に DB 作成するのは
やめとけ、みたいな感じだったけど(実際ごにょごにょしないと
作成出来ないし)。
241:名無しさん＠お腹いっぱい。
08/03/10 16:20:33
一万個の小さいhtmlファイルが1分ごとに更新されるとかの変なwebサイトで無い限り
NFSなんて使わないほうがいい
242:名無しさん＠お腹いっぱい。
08/03/10 16:36:32
>>236
>>227のことと合わせて考えると、Webの場合はCPUがボトルネックになりやすいから、
ロードバランサを導入する意味はある。ただし、変更されるデータの一貫性維持は
どこかで考えておかないといけない。ありがちなのは、そういうデータはDBサーバに
置いて、一貫性維持はアプリケーションとDBの合わせ技でまかなう感じ。
で、Webサーバと同じ理屈で、DBサーバのデータ領域をNFS上に置いて並列運用すると
どうなるかは…
243:名無しさん＠お腹いっぱい。
08/03/10 16:40:10
ちょうど今やろうとしてたことが話題にでてきたので教えてください。
サーバが自社内に10台あります、1台目（A）がDBサーバ兼Sambaファイル共有サーバ、もう一台(B)がログ解析＆バックアップ機、
残りの８台をWebサーバにしているのですが、この８台にWebコンテンツが分散しているのが運用上大変（めんどくさい)なため
Aのサーバサーバとして８台のWebをクライアントとしたNFSを構成しようと考えていました。
Webコンテンツは/home以下にHTMLファイルのほかPHPやJavaで書いたスクリプトやプログラムが含まれています。また、オリジナルで
書いたライブラリや、PEARなどの外部ライブラリを習慣として各Web機の/usr/local/libに格納しています。
これらそれぞれのバージョン管理などが非常にめんどくさいので、NFSを導入したいと考えているのですが、
↑のお話だとパフォーマンスが悪いので辞めたほうがよいということですか？
詳しいから、お知恵拝借させてください。
244:名無しさん＠お腹いっぱい。
08/03/10 17:01:22
>>238
WEBサーバの場合、どういう手法が良いんですかね？
rsyncとか？
245:名無しさん＠お腹いっぱい。
08/03/10 17:05:01
>>243
rsync3.0が出て速くなった(らしい)よ
246:名無しさん＠お腹いっぱい。
08/03/10 20:38:04
>>243
ここでそれを質問するということは、NFS環境下で障害を起こすアプリケーション・
ユーザコードの有無を検証できる人があなたの組織にはいないと見るけど、どうかな。
ならばrsyncで各サーバにファイルを配布するスクリプトを書いた方が安全だと思う。
コマンド1発で出来るようにしておけば管理の手間も生じない。
(バージョンに依存したアプリケーションが置かれているとかの理由で)共通化できない
特定のホストを個別に対応することも容易。
一般論として、すでに動いているサーバの構成を変えるのは上策じゃない。
NFSを入れるなら、運用を開始する前にテストするべき。
247:名無しさん＠お腹いっぱい。
08/03/10 21:37:33
NFSはもう古い、って広告、昔あったよね
248:名無しさん＠お腹いっぱい。
08/03/10 21:38:39
>>247
どんなん？
249:名無しさん＠お腹いっぱい。
08/03/10 22:05:11
>>242
DBにデータを書き込むアプリなら良いけど、ファイルシステム上に
ファイル生成したり、書き換えたりする奴もあるよね。
そうした場合は、NFS置くのが定石。
NetAppみたいの使えば、パフォーマンスもそれほど心配無いだろう。
250:名無しさん＠お腹いっぱい。
08/03/11 16:22:22
NetApp買えるなら、その金で1台に集約してNFS不要にする手もあるな。
251:名無しさん＠お腹いっぱい。
08/03/11 16:32:41
>>249
アプリケーションがちゃんと並列動作まで考慮してくれてるならいいけど、
通常ファイル使うことからしてあまり期待できないような。
アプリケーションの中身知ってるものならいいけど、自分は定石とまでは言いたくないな。
252:名無しさん＠お腹いっぱい。
08/03/11 23:07:04
いずれ結局中身を気にすることにはなる
253:名無しさん＠お腹いっぱい。
08/03/12 00:42:22
>>251
ここで言っているアプリは、ロードバランサーで負荷分散できる様な
Webアプリだからね。DBだけじゃなくて、ファイルに書く奴あるじゃん。
そう言うのは、NFSファイルサーバ立てて使うよね？
254:名無しさん＠お腹いっぱい。
08/03/12 08:27:40
まあそうだけど、それは「まずい設計をどうにか延命する方法」であって、定石と呼ぶのは抵抗あるなあ。
逆説的だけど、NFS環境を想定したコードが書ける人は、NFSに依存しないで済む方法も用意する。
NFSを使わざるを得ない、というのは、それが本当にNFS上で運用しても問題ないように出来ているのか、一沫の不安を感じるのだ。
NetAppまで導入してしまえば、バックアップ等の運用コストを下げられる余地がでてくるので、
NFSをデスクトップクライアント限定の技術だと考えるのは保守的な考え方かもしれないけどね。
255:名無しさん＠お腹いっぱい。
08/03/12 12:59:40
すくなくとも DBのID/PASSはファイル持ちだと思うな。
256:名無しさん＠お腹いっぱい。
08/03/12 13:04:17
アクセスをきっかけに変更されないデータならどうだっていいんだけどさー、
>>253はファイルに書くって書いてるじゃん……
257:名無しさん＠お腹いっぱい。
08/03/12 13:30:05
>>256
アプリケーションの設計の話だ。
ストレージはファイルシステムだけじゃないだろ?
複数ホスト間で変更の共有が必要な情報を、安易にファイルシステムに格納するアプリケーションは、
トラブルを潜在している徴候だ。
258:256
08/03/12 14:56:34
>>257
いやまぁ、だからそういうことを言いたいわけで。
書き込みするのにNFS共有するのは危ないだろうと。
259:名無しさん＠お腹いっぱい。
08/03/13 02:27:16
自宅で5台動かしてるCentOSサーバ（Webサーバ）それぞれにログインするのがめんどい…
/homeを一台でNFS共有して使いまわそうかなと思うのだけど、邪道かな
ついでに/usr/local以下も共有して、自作ライブラリやソースファイルをシェアするってのも検討中。
ガッコで教わったわけじゃないので、どういう風に使うのかが正道なのかわからず、すまんかった…
260:名無しさん＠お腹いっぱい。
08/03/13 10:22:35
/homeは共有してもいいんじゃないか？
261:名無しさん＠お腹いっぱい。
08/03/13 11:25:47
/homeやサイトローカルなディレクトリのNFS共有は真っ当だろう。
てか、自宅なら好きにやればいいと思うが、
システムのブートやデーモンの類はNFSサーバに依存させないのが吉。
ホスト間の依存関係が複雑になると管理がとてもとても面倒になるから。
あと卒直に言えば、ログインが面倒になるほどホスト増やす時点で
かなり間違った道を進んでいる。
262:名無しさん＠お腹いっぱい。
08/03/13 12:16:40
>>261
ログイン簡単にするって、どうすればいいの？
うちの会社は100台弱あって大変… /usr/localをシェアするのっていいなあ
263:名無しさん＠お腹いっぱい。
08/03/13 13:23:30
機械なんだから管理はどんどん自動化しろよ。
なんのためのUNIXだよ。
264:名無しさん＠お腹いっぱい。
08/03/13 13:29:48
シェアはしないけどNFSにする、って方法もあるぞ。
クライアントの /usr/local他のデータを個別に NFS鯖側に持つ。
すると、NFS鯖にログインするだけですべてのクライアントのデータをいじれる。
シェアはしていないので、書き込み競合とかの問題もなし。
265:名無しさん＠お腹いっぱい。
08/03/13 15:14:19
>>263
それ、俺もすげー興味ある。
どんな感じで管理してるの？ 参考にしたい。
266:名無しさん＠お腹いっぱい。
08/03/13 16:38:40
NFSにちょっと関係があるかと思い便乗質問で恐縮ですが、
NISも導入した方がいいでしょうか？ ひとつのサーバにパスワードやグループなどを
一括管理できるようになるのはメリットかと思うのですが、逆にデメリットって実運用
ではどんなことがあるのかと思い。 よろしくおねがいしまんこ。
267:名無しさん＠お腹いっぱい。
08/03/13 16:40:04
今更NISか？
LDAPで良いんじゃね？
268:名無しさん＠お腹いっぱい。
08/03/13 18:19:01
>>266 UNIXだけで組んだシステムならNISでも悪くないよ。シンプルだし。
デメリットとしては、古臭いというぐらいだと思うｗ ある程度の規模になると
LDAP + NSS + nscd の方が安定性も反応性も高い希ガスです。
>>262 100台って少ないね・・・
>>263 激しく同意。人間様のプライドとして単純作業はすべて機械にやらせる。
>>265 cfengine とか Puppet とか？
漏れは自作フレームワークでインスコからメンテから全部楽々運用だな。
人海戦術の手作業で鯖管理してるような DQN を見てると悲しくなる。
269:名無しさん＠お腹いっぱい。
08/03/13 19:14:31
自作フレームワークをオープンソースでうpしてくれ
270:名無しさん＠お腹いっぱい。
08/03/13 19:17:46
NIS使うとshadow passwdの意味がなくなるんだよな。いや、別にいいんだけど
271:名無しさん＠お腹いっぱい。
08/03/13 19:37:56
うちもNFS+NISだな。
/homeと/usrをNFSで共有。PXE Bootで/もNFS越し。
まあ、数値計算用でほとんど同じ構成だから、あまり凝ったことをしなくても管理は楽。
272:名無しさん＠お腹いっぱい。
08/03/13 20:48:20
>>270 C2セキュリティのオプションONにすればok
ypcatで表示しなくなる。
それでも気になる人はNIS+をどうぞ。
273:名無しさん＠お腹いっぱい。
08/03/13 21:16:38
NIS+はサポート終了だって
274:名無しさん＠お腹いっぱい。
08/03/13 22:41:03
めでたしめでだし
275:名無しさん＠お腹いっぱい。
08/03/15 01:07:04
NFSの転送速度って遅くないですか？
276:名無しさん＠お腹いっぱい。
08/03/15 05:48:30
いやーそれほどでも
277:名無しさん＠お腹いっぱい。
08/03/15 09:32:29
うちは50MB/secが限度だった
278:名無しさん＠お腹いっぱい。
08/03/15 15:36:04
うちは75MB/sぐらい。
279:名無しさん＠お腹いっぱい。
08/03/15 16:06:22
> UNIXだけで組んだシステムならNISでも悪くないよ。
悪いこといわんからLDAPにしとけ。
NIS/NIS+はobsolete technologyだ。
特に100台あると(>>262)、NISにはmap転送ストームの問題がある。
280:名無しさん＠お腹いっぱい。
08/03/15 16:56:06
NFS自体
281:名無しさん＠お腹いっぱい。
08/03/15 19:10:52
NIS+はobsolete technologyだが
NISは今も今後も現役。
282:名無しさん＠お腹いっぱい。
08/03/15 19:55:48
昔はうちでも/usr/localをNFSで共有してたけど、パフォーマンスが悪いので
rsyncで毎晩mirrorする設定にしてるよ。共有してるのは/homeだけ。
/usr/localを更新したら トリガーになるファイルのタイムスタンプを更新して
ＮＦＳ server側で
touch /usr/local/UPDATE
と印付けておく。
で、client側では、
if [ /mnt/local/UPDATE -nt /usr/local/UPDATE ]; then
DORSYNC="1"
fi
とかして実行させる。ここで全てのclientが同時にrsyncかけると負担がかかるので
そのへんはばらけるように工夫する。
283:名無しさん＠お腹いっぱい。
08/03/15 20:12:24
>>281
NISはレプリカが多い時に、
パスワードの同時変更が起きると悲惨。
まさにobsolete。
284:名無しさん＠お腹いっぱい。
08/03/15 20:14:03
NISではレプリカとは言わん。批判するなら正しい用語で。
285:名無しさん＠お腹いっぱい。
08/03/15 20:18:36
じゃあスレーブなw
286:名無しさん＠お腹いっぱい。
08/03/15 20:21:16
ここでhesiodの出番だな
287:名無しさん＠お腹いっぱい。
08/03/15 20:23:38
yppushが起きるだけだが? 何が悲惨?
288:名無しさん＠お腹いっぱい。
08/03/15 20:30:30
NISがだめだとおもうならnetinfoを使えばいいのに
289:名無しさん＠お腹いっぱい。
08/03/16 01:21:26
おっさんが多いスレなのかしら
290:名無しさん＠お腹いっぱい。
08/03/16 14:43:57
エクスポートする、またはマウントするパスで、効率的なやり方を教えてください
291:名無しさん＠お腹いっぱい。
08/03/16 15:30:25
/
292:名無しさん＠お腹いっぱい。
08/03/22 05:02:33
高スペック機1台をNFSサーバにして /export/各サーバ名/home それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンのLinux（centos5.1 x86_64）同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
293:名無しさん＠お腹いっぱい。
08/03/22 08:57:35
Linuxのネタをここでやろうとするのは変
294:名無しさん＠お腹いっぱい。
08/03/22 12:13:28
高スペック機1台をNFSサーバにして /export/各サーバ名/home それぞれを公開Webサーバ台分用意、
そして、各Webサーバ（ひとまず4台）からはそれぞれ/homeをマウントさせて運用したいのですが、変でしょうか？
いちお同バージョンの FreeBSD 6.3R同士なので/usrも共有しようかなと、これは全機共通で。
こういう使い方ってNFSのパフォーマンス悪いのでしょうか
295:名無しさん＠お腹いっぱい。
08/03/22 12:30:31
FreeBSDでNFSはヤツの召還呪文
296:名無しさん＠お腹いっぱい。
08/03/22 19:51:32
NFSは激遅
297:名無しさん＠お腹いっぱい。
08/03/22 20:56:27
>>294
そんなことしないでバックエンド側でファブリック組めばええんちゃう？
298:名無しさん＠お腹いっぱい。
08/03/23 03:07:14
>>262
1000台以上あるけど、適当な認証鍵つくって、ループスクリプトでsshでttyつかんで...
ちょいshellscriptを汎用的に書いておけば、一気に全台同じコマンドじっこうできるよん
299:名無しさん＠お腹いっぱい。
08/03/23 16:29:41
>>298 どの様に書くのでしょうか。教えていただけますか。ぜひサンプルを。
300:名無しさん＠お腹いっぱい。
08/03/24 16:42:59
NISよりも優秀なのってなんだっけ？
301:名無しさん＠お腹いっぱい。
08/03/24 19:57:40
>>300
Active Directoryです。
302:300
08/03/24 22:22:59
>>301
ありがとう、Active Directoryを導入しました
303:名無しさん＠お腹いっぱい。
08/03/25 10:57:40
>>292
Web公開ファイルを/homeで共有するってこと？ アクセス数次第だなぁ。
スタッフアカウントを/homeで共有するのは良いアイデア。
/usrを共有するのは悪いアイデア。rsyncで同期しておけば良い話だから。
304:名無しさん＠お腹いっぱい。
08/03/25 11:04:28
>>303
アクセスが多い場合、NFSの転送速度からするとよくないんじゃね？
/homeもrsyncかｗｗｗ
305:名無しさん＠お腹いっぱい。
08/03/25 12:13:21
Webコンテンツならローカルに置くだろうけど、
EtherもCPUも速くなった今の時代、単純にNFSだから遅いとはいいきれない。
ローカルの単体SATAとリモートのNetApp、どちらが平均アクセス速度が速いか。
実運用ならバックアップも考えないと。
306:名無しさん＠お腹いっぱい。
08/03/26 02:15:23
CODAも、AFSもどこ行っちまったのだろ。
教えてくれ。
307:名無しさん＠お腹いっぱい。
08/03/26 02:49:23
Webアプリのこの時代に分散ファイルシステムってもの…
Satyanarayananのページに久々に行ってみたら、
Internet Suspend/Resumeってのやってんのな。
これもGoogle Gear辺りと比べるとかなり低い階層でやってるな。
308:名無しさん＠お腹いっぱい。
08/03/26 08:48:24
W
S
I
こ
309:名無しさん＠お腹いっぱい。
08/03/28 01:17:22
URLﾘﾝｸ(lists.freebsd.org)
310:名無しさん＠お腹いっぱい。
08/03/28 14:26:06
nfsでマウントしているディレクトリに、100byte程度のデータを
細かく書いていくプログラムを走らせると、そのクライアント側の
ホストでnfsディレクトリにかなり長い時間アクセスできなくなるのですが
この現象の解決策に関する情報はありませんか？
OSはRedhatlinux4.6 64bit
カーネルは2.6.9-67.EL でも2.6.24でも起こります
同じことをRedhatLinux3.0 の64bit版でやっても起こらないのですが・・
311:名無しさん＠お腹いっぱい。
08/03/28 18:18:40
a) 100バイトずつ投げるな
b) ELなんだからベンダのサポートに投げろ
c) Linuxなんぞ投げ捨てろ
312:名無しさん＠お腹いっぱい。
08/03/28 18:42:22
どうでもいいが、RedHat4.xって、1998年かそれ前後頃、
3.xは1997年頃? すげー古いOSだよね?
313:名無しさん＠お腹いっぱい。
08/03/28 19:01:45
RHLに4.6なんてない。
314:名無しさん＠お腹いっぱい。
08/04/01 02:59:21
>>310
NFSをasyncにしてみたら?
315:名無しさん＠お腹いっぱい。
08/04/01 04:09:49
cacheも増やすべき。acdirmax辺り。
mountオプソンで指定。
316:名無しさん＠お腹いっぱい。
08/04/01 07:49:06
時間割くなら、try&errorの厨ニングよりプログラム直した方が幸せになれると思われ。
NFSだろうがなかろうが、バッファリングせず100byteずつwrite(2)ってのは頭おかしい。
データの整合性を維持する意図でそうしてるならasync mountで動かすのは本末転倒だしな。
ソースがないならご愁傷様。
317:315
08/04/01 08:49:29
あれ? 小さいファイルをたくさん作るのかと思ったよ。
どっちとも取れるけど、一つのファイルに少しづつ書くなら、
ディレクトリがアクセスできなくなるのはおかしいなあ。
318:名無しさん＠お腹いっぱい。
08/04/02 01:41:55
>>310
現状のマウントオプション晒しなYo!
319:名無しさん＠お腹いっぱい。
08/04/05 13:20:26
まあrhelなら4.6はあるけど板違いだしなあ
320:名無しさん＠お腹いっぱい。
08/04/09 09:41:04
NFSv3 で同じLANにつながっているマシン同士ではサクサク
ファイル公開できているんだけど、セキュリティ上の理由から
TCPしか通してくれないL3スイッチ越しの隣の部屋のNFSサーバの
ディレクトリを NFSv4 でマウントしたら ls に引っかかる。
ファイルの読み書き、でっかいファイルの転送速度に関しては
たいした違いも無いんだけど、 ls で引っかかる。数秒。
何が原因なんでしょうか？
当然 portmap なんかも通らないんですが、それが原因
なんでしょうか・・・でも NFSv4 だしなぁ。2049/tcp
だけで使えると思うんだけど。
321:名無しさん＠お腹いっぱい。
08/04/09 09:47:49
>>320
L3が糞
322:名無しさん＠お腹いっぱい。
08/04/09 09:55:21
>>321
id でも引っかかるんで、nsswitch.conf 見てみたら、
hosts に wins が指定されていた orz
samba とか使ってねぇのに。
323:名無しさん＠お腹いっぱい。
08/04/09 10:36:20
NFSv4のクライアントは何?
Solaris以外でまともに使えるのある?
324:名無しさん＠お腹いっぱい。
08/04/09 10:46:04
>>323
>>322 で自己解決したようです
>>321 ハズレ
325:323
08/04/09 11:58:15
いや、トラブルとは関係ない質問
326:名無しさん＠お腹いっぱい。
08/04/09 12:51:31
まともに使える=俺の環境・俺の使ってるアプリケーションが動く、だから
基準が人によって全然違うんだよな。
クライアントは1台なのか100台なのか、
テキストエディタでファイルが開けばいいのか、データベースが置けないとダメなのか。
327:323
08/04/09 13:09:20
基準は>>320の基準でいいや。
「～をこう使っていてトラブルなし」ってんで。
ちなみに俺は自宅のファイル共有で使うことしか想定してない。
v3→v4の移行するかどうか。
仕事ならクライアントサイドはSolaris以外でv4使わないし。
328:320=322
08/04/09 13:28:11
server Ubuntu 6.06.2 LTS / kernel 2.6.15
client CentOS 5 / kernel 2.6.18
329:名無しさん＠お腹いっぱい。
08/04/13 03:40:27
質問です、自宅のLANにCentOS5.1のマシンが4台入る予定なのですが、なるだけ
少ない台数で集中管理したいと思っています。
1台の/homeを他3台でシェアしようと思うのですが、自宅LANのような小規模な環境
だとあまり意味の無い方法でしょうか？
それか、みなさんの書き込みを読んでいると人気の、rsyncをつかって1台のデータを
共有しようかと思ったのですが、リアルタイムに同期してる訳じゃないですよね。
330:323
08/04/13 09:05:07
>>328
Linuxかあ。今度トライしてみるわ。
ちなみにサーバはOpenSolaris。
331:名無しさん＠お腹いっぱい。
08/04/13 09:08:15
>>329
全部、デスクトップ機なの?
ノートにNFSホームは良くないと思うけど、
デスクトップならオフライン利用考える必要ないしNFSでいいと思うよ。
332:名無しさん＠お腹いっぱい。
08/04/13 12:01:06
>>331 サンクスっ！
NFSでシンプルに構成しようと思います。
よく考えてみりゃ/homeだけってのももったいないから他のも共有マウントしよう
かと思うのだけど、みんなどんな感じでマウントしてるんでしょう？定石ってあるのでしょうか。
マウントする側（3台の方）のHDDって８０GBもあるんだけど、マウントしちゃうと余計HDD領域が余っちゃう
よね、なんだかもったいねえ。
333:名無しさん＠お腹いっぱい。
08/04/13 12:20:52
クライアントはHDD外してディスクレスだよ。
ネットブートして、/ 全体すべて NFSだよ。
LANが速いと、かえってローカルHDDより速い感じがするくらい。
334:名無しさん＠お腹いっぱい。
08/04/13 13:04:27
>>333
素人に無駄な期待を抱かせるような書き込みはよせ。
それはハイエンドのNFS専用鯖機のときの話だ。
335:名無しさん＠お腹いっぱい。
08/04/13 13:41:34
>>334
自宅のふつーのPCで >>333 みたいなことしてるけど、、
336:名無しさん＠お腹いっぱい。
08/04/13 14:22:05
>>335
さて、これが無駄な期待でない理由を説明してくれ。
「ローカルHDDより速い感じがするくらい。」
337:名無しさん＠お腹いっぱい。
08/04/13 17:00:31
誇張表現
338:名無しさん＠お腹いっぱい。
08/04/13 17:56:21
そりゃ、ユーザ一人とか、Ｎｅｔｗｏｒｋスカスカなら
そこそこ良いかもしれんけど・・・・・
339:名無しさん＠お腹いっぱい。
08/04/13 18:08:20
自宅でやっているときの話とかいているから
ユーザーは分かっている範囲だしネットワークはすかすかだろうな
340:名無しさん＠お腹いっぱい。
08/04/14 00:51:14
>>332
・/homeと/usr/localだけ共有。
相互依存が起きないように両方同じサーバに。
・システムが必要とする分だけを全て/パーティションに。
パッケージシステムに任せて決して共有しない。
・残りは別パーティションとし、nfs exportして、
画像、音楽データを入れたり、バックアップに使ったり。
341:名無しさん＠お腹いっぱい。
08/04/14 08:38:20
ぶっちゃけ自宅ならば/homeというよりも、/home/homepageだけをシェアして
基本的にワンユーザー（homepage)で運用したほうが効率いいんでないかい？
あとは>>340の言うとおり/usr/localもかなあ
個人的にはDNSやsambaを設定してる/etcの一部ファイルもうまくシェアできないかと悩み中
342:名無しさん＠お腹いっぱい。
08/04/14 08:40:19
>>341
おまえ家族いないのか?
343:名無しさん＠お腹いっぱい。
08/04/14 19:52:49
むしろ家族がいてNFSを使っているような奴が異常
344:名無しさん＠お腹いっぱい。
08/04/14 20:00:20
鯖なんか立てたら、
うるせーよとクレームくる。
345:名無しさん＠お腹いっぱい。
08/04/14 20:49:40
居間のPCでも寝室のPCでも子供部屋のPCでも、
どのPCからログインしても自分の$HOMEで同じ環境にするには
ふつーNFSだろ。
346:名無しさん＠お腹いっぱい。
08/04/14 21:03:29
寝室でエロ動画ばっか見てないで、たまには奥さんの相手してやれよ。
347:名無しさん＠お腹いっぱい。
08/04/14 21:32:01
恥ずかしがり屋の妻がPCの中から出てきてくれません
348:名無しさん＠お腹いっぱい。
08/04/14 22:19:54
君のPCの中にいてくれるならそれでいいじゃないか
349:名無しさん＠お腹いっぱい。
08/04/14 22:33:23
>>348
生きろ
350:名無しさん＠お腹いっぱい。
08/04/15 02:29:46
/homeを共有したとしてもログインするためのアカウントやパスワード情報がシェアできなきゃ意味なくね？
351:名無しさん＠お腹いっぱい。
08/04/15 03:40:35
ホームと比べて人力同期の手間が大した事ない上にスレ違い。
352:名無しさん＠お腹いっぱい。
08/04/15 06:27:47
>>350
だから NIS使うんだろ。
353:名無しさん＠お腹いっぱい。
08/04/15 07:42:33
NFSはv4でTCPだけで使えるようになったけど、
NISはやっぱりportmap必須でポートの制御が難しいね。
LDAPでもよくね？
354:名無しさん＠お腹いっぱい。
08/04/15 08:48:17
UDP通してなんか問題ある? ポートの制御? そのなの必要ある?
355:名無しさん＠お腹いっぱい。
08/04/15 13:48:51
ていうかエルダップ使えよ、
国民は全員使ってるぜ、おまえんち以外は。
356:名無しさん＠お腹いっぱい。
08/04/15 14:14:35
そもそもportmap(rpcbind)は、ポート番号を意識せずに、
さらに言えば、下位レイヤーがTCP/IPソケットかどうかすら意識せずに
通信できる上位レイヤーのための概念だ。
それを使わずにポート番号固定にしてTCP/IPに依存するのは昔の考え方。
357:名無しさん＠お腹いっぱい。
08/04/15 14:24:09
誰も固定にするなんて言っていない。
358:名無しさん＠お腹いっぱい。
08/04/15 14:47:45
そういう場合はどうすると言ったのかを言わないと「固定にする」と言ったとみなされたままになる。
359:名無しさん＠お腹いっぱい。
08/04/15 22:30:41
べつにNISでもLDAPでもNetInfoでもいいよ
360:名無しさん＠お腹いっぱい。
08/04/16 02:54:04
>>359
比較するとしたらどれが良いと思う？
361:名無しさん＠お腹いっぱい。
08/04/16 04:21:04
LDAP
362:impress入門者
08/04/16 16:14:03
>>682, 683
マイレイアウト追加って出来ますか?
数式の規定フォントの指定って出来ますか?
363:名無しさん＠お腹いっぱい。
08/04/16 16:25:44
NFSじゃ無理
364:名無しさん＠お腹いっぱい。
08/04/16 22:21:40
いや、なんとかすりゃできるかもよ？
俺は教えないけどね
365:名無しさん＠お腹いっぱい。
08/04/19 03:14:55
NFSで/usrをシェアするってどうなの？
366:名無しさん＠お腹いっぱい。
08/04/19 06:55:24
どうって、普通だよ
367:名無しさん＠お腹いっぱい。
08/04/19 13:57:21
や、/usr/localを共有するもんだと思ってたんだけど
>>365みたく/usrなんて共有していいものなのか？
368:名無しさん＠お腹いっぱい。
08/04/19 14:53:31
>>367
/usrだからこそ共有していい。
ホスト間で共有できるものは /usr以下(/usr/bin /usr/lib /usr/sbin等)に。
ホスト間で共有できないものは /etc /var /bin /sbin /lib等に
というルールになっている。
Solarisではホスト間で共有できるファイルを増やすため、
/binをsymlinkにして、すべて/usr/binに移動している。
369:名無しさん＠お腹いっぱい。
08/04/19 16:58:26
NFS鯖に障害が出たときにすげー面倒くさそう。/sbinだけあってもなぁｗ
用途や規模や更新頻度にもよるけど、漏れはrsyncとかパッケージの管理とかで
統一する方が好きかな。
370:名無しさん＠お腹いっぱい。
08/04/19 21:36:28
んじゃ、NFSじゃなくrsyncで全ホスト間の/usrで同期をとるならば
cronとかで定期的に親機から全ホストに対してrsyncするスクリプトを叩く、でおｋ？
一時間おきとかに。
371:名無しさん＠お腹いっぱい。
08/04/20 11:17:05
パッケージとパッチ使えよ。
372:名無しさん＠お腹いっぱい。
08/04/20 12:23:00
/usr以下なら、更新したタイミングで同期すればいいじゃない
373:名無しさん＠お腹いっぱい。
08/04/20 12:58:33
ガチで管理したいならもうpuppetとか導入しちゃった方がいいんじゃない？
374:名無しさん＠お腹いっぱい。
08/04/25 02:29:03
パペットってどうよ？
10台以下の環境で使うほどの必要あるかな
375:名無しさん＠お腹いっぱい。
08/04/27 10:35:38
RDISKはNFSですか？
376:名無しさん＠お腹いっぱい。
08/05/02 07:46:00
NFSでマウントしたボリュームについても，クライアント側で
通常のファイルシステムのようにキャッシュは有効なのでしょうか？
NFS 鯖においてあるファイルを NFSv3 でマウントして，
そこそこ大きなファイル（10M程度のログファイル）を
何度も読み込むとすると，何度もトラフィックが発生
するものなのでしょうか？
Linux ユーザなのですが NFS のスレが Linux 板にないのでここに来ました．
なお，FS-Cache とか cachefilesd は使っていません．
通常のディスクキャッシュの仕組みがNFSでマウントした
ボリュームでも働くかどうかということです．
377:名無しさん＠お腹いっぱい。
08/05/02 07:51:22
>>376
当然キャッシュされる。もちろん、クライアントの搭載メモリ次第だが。
同じファイルを読み込む場合、2回目は速い。
378:名無しさん＠お腹いっぱい。
08/05/02 09:19:12
>>376
man 5 nfsも読んどいてくれ
379:376
08/05/02 13:35:30
レスありがとうございます。最近NFSを利用している
クライアントマシンから「NFSが気絶してる」という
苦情を受けるので、使い方を聞いてみたら10000個ほどの
10MB程度のファイルを次々と grep しただけ、とのこと。
しかも1ファイルごとに100回くらい読み直したとのコト。
せめてクライアント側でキャッシュが有効なら同じファイル
100個読むのは別に負荷じゃないよなぁとおもったのです。
さきほど nfsstat をサーバ側でやってみたら、
Server nfs v3:
null getattr setattr lookup access readlink
6 0% 18278453 80% 143964 0% 781712 3% 2524218 11% 0 0%
read write create mkdir symlink mknod
352987 1% 455073 1% 54698 0% 6321 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
51737 0% 5598 0% 88 0% 0 0% 107265 0% 27950 0%
fsstat fsinfo pathconf commit
8 0% 2 0% 0 0% 17191 0%
うむむ、getattr だけで 80% らしい。80% というのが回数なのか
そのコールを処理するのにかかった時間なのかわかりませんが、
なんにせよ getattr 恐るべし。man 5 nfs によるとディレクトリ
エントリがらみのキャッシュ時間を設定しろということなのでしょうか。
うちの使い方では関係ないですが、ディレクトリエントリを
キャッシュしちゃうとロックファイルのような使い方を
してるアプリケーションにとってはまずいことがおきる？
380:名無しさん＠お腹いっぱい。
08/05/02 13:44:43
>>379
RHEL4ならbugzilla見にいけ
381:376
08/05/02 16:31:35
>>380
サーバは Ubuntu LTS 6.0.6 LTS です。が
今使ってるカーネルのバージョンに絡んだ何かが
あるかもしれないので時間のあるときに見てみます。
ところで、みなさん nfsd の数ってどうやって最適値を
見積もってらっしゃるんでしょうか？ デフォルトが 8
だし、デュアルコアだから 16、いや、20 くらいにしておこう
程度の発想しかできないんですが、たとえば /proc 以下の
何かをモニタしていればヒントが得られるのでしょうか。
382:名無しさん＠お腹いっぱい。
08/05/02 16:42:55
>>381
URLﾘﾝｸ(nfs.sourceforge.net)
383:376
08/05/02 18:48:15
>>382 THX
384:名無しさん＠お腹いっぱい。
08/05/03 01:38:24
>>379
NFSマウントしているところで、
シリアスな「ロックファイル」を使っちゃいかん。
firefoxの二重起動禁止程度の奴なら実用上問題ないけど。
385:名無しさん＠お腹いっぱい。
08/05/05 02:07:33
NFSで10台くらいとシェアするとやっぱりパフォーマンス落ちますか
386:名無しさん＠お腹いっぱい。
08/05/05 03:26:14
サーバによるよ。
ローカルディスクより速いサーバは一杯ある。
387:名無しさん＠お腹いっぱい。
08/05/05 12:57:28
ML115なんですが
388:名無しさん＠お腹いっぱい。
08/05/05 13:56:40
マウントするだけなら変わらない（当たり前？）。
少々のコマンドを読む程度ならそれもあまり変わらない。
I/Oを大量に発生させるクライアントが多ければ、下がる。
としか言いようがないよ。
ここ参考にならんかな？
URLﾘﾝｸ(www.spec.org)
ならんか。
389:名無しさん＠お腹いっぱい。
08/05/05 14:27:08
実際にやってみて問題がでたら、ひとつずつ解消してきゃいい。
そういう手間暇かけて試行錯誤するのが許されず、
一発で正着が欲しいなら、経験のある人に頼めばいい。
390:名無しさん＠お腹いっぱい。
08/05/05 17:06:14
NFSやるならNISも必須だろ
391:名無しさん＠お腹いっぱい。
08/05/05 18:03:12
いやそれほどでも
392:名無しさん＠お腹いっぱい。
08/05/05 19:49:13
NISとかLDAPとかNetInfoとかアカウント管理なくても、
NFSプロトコルは問題なく動きます。
393:名無しさん＠お腹いっぱい。
08/05/05 20:00:13
アカウント管理なんてする必要あるのか？
100台だろうが1万台だろうが、手作業でアカウント設定すりゃいいじゃん
394:名無しさん＠お腹いっぱい。
08/05/05 20:05:59
アイデンティティ管理って奴ですかな。
395:名無しさん＠お腹いっぱい。
08/05/05 20:07:52
認証したい時(UNIX認証は除く)はsecure RPCかKerberosが必要になる。
396:395
08/05/05 20:08:47
>>395
Secure RPCのDES認証かKerberos認証というべきだった。
397:名無しさん＠お腹いっぱい。
08/05/08 11:00:16
サーバ、クライアントともに
Ubuntu Linux 6.06 LTS
kernel 2.6.15
で nfs4 での利用を試みているのですが、
ブート後数日は普通に動いているのに
いつの間にか ls すると Input/ouptut error
と表示されるようになります。
でもディレクトリエントリが取得できないだけで
そこにあるはずのファイルは読み書きできます。
何が起こっているのでしょうか？
ちなみに Netfilter (iptables) や hosts.{allow|deny}
での制限は一切無しの状態です。
/etc/exports を書き換えて、同じ場所を
NFS v3 でエクスポートしてマウントすると
普通に ls できます。NFS において ls だけできない
（そこにあるはずのファイルにはアクセスできているのに）
というのはどんな状態なのでしょうか？
398:名無しさん＠お腹いっぱい。
08/05/08 11:05:27
>>397
>というのはどんな状態なのでしょうか
普通に、ディレクトリだけが読めない状態。
NFS関係なしに、
chmod a-r .
ってやると、カレントディレクトリをlsできなくなるが、
その下にあるファイルは(ファイル名がわかっていれば)読める。
399:397
08/05/08 11:12:12
複数台あるファイル鯖で、NFS v3 で普通はマウントしていて
幸せな暮らしを営んでいるのですが、ファイアウォールの関係で
隣の部署からは NFS v4 (proto=tcp) でマウントしています。
そいつだけたまにディレクトリエントリが見えなくなるのです。
ファイルにはアクセスできているので気づかないことも多いです。
障害発生時刻とログをつぶさに観察していると
nfs_update_inode : inode number mismatch
expected (0:14/0x2), got(0:14/0xb001)
がサーバ側で出たあとにクライアント側からディレクトリ
エントリが見えなくなるようです。それが出たあとも
気を取り直して NFS v3 でマウントしているクライアントからは
何も障害が見えません。
さらに NFS 鯖のログをさかのぼってみていると
nfs4_cb : server xxx.xxx.xxx.xxx not responding, timed out
が頻繁に出ています。これと関係あるのでしょうか。
nfs4_cb が何かこれからググろうと思いますが、
属性キャッシュがらみなのだろうか・・
400:名無しさん＠お腹いっぱい。
08/05/08 11:17:59
まずfirewallを疑えよ。
firewallの中でnfs4で確かめてみたら。
401:名無しさん＠お腹いっぱい。
08/05/08 11:18:43
スキルもなく実績もないUbuntuLTSなんか使うなよ。
402:397
08/05/08 11:42:00
>>400
ファイル鯖上で localhost がエクスポートしているものを
localhost でマウントしても同じ障害が発生します。
とりあえず週末に業務が終わったらカーネルを差し替えるべく
VMware 上で他のバージョンのカーネルでの挙動を確かめてみます。
403:名無しさん＠お腹いっぱい。
08/05/08 11:59:23
TCPにしたいだけなら、NFSv3のTCPにすればいいじゃないか。
404:397
08/05/08 13:06:30
>>403
できれば idmap も使いたく・・
405:名無しさん＠お腹いっぱい。
08/05/08 13:12:41
uid振り直して統一しておけばいい。
406:名無しさん＠お腹いっぱい。
08/05/08 13:19:01
Googleもいいけど、そこまでログ追ったならソースコード見た方が早いよ
407:名無しさん＠お腹いっぱい。
08/05/09 17:45:30
サーバをSolarisに変えろ! > NFSv4
408:名無しさん＠お腹いっぱい。
08/05/10 04:31:26
>>397
NFSv4 で認証した時のプロセスID が変わってたらそれが原因の一つでは？
任意の時間で、チェックしてアクティブに umount してからマウントしな
おすと何事もなかったように見えるのではないでしょうか。
409:名無しさん＠お腹いっぱい。
08/05/11 14:29:05
>>407みたいなこという人ってどこまで本気なんだろう？
410:名無しさん＠お腹いっぱい。
08/05/12 18:17:58
まじ
411:名無しさん＠お腹いっぱい。
08/05/13 15:31:21
LinuxでNFSサーバとかどこまでマジなの? という切り口もあるので
どっちもどっち。立ち位置の違いに過ぎない。
412:名無しさん＠お腹いっぱい。
08/05/13 16:10:19
NECと富士通の独自NFSサーバはLinux製。
ただしNFSモジュールは別途開発したものに差し替えてる。
413:名無しさん＠お腹いっぱい。
08/05/15 00:31:40
nfs mount 時の rsize, wsize ですが、これを指定しない場合は
いくらになるんでしょうか？
414:名無しさん＠お腹いっぱい。
08/05/15 07:00:16
>>413
指定しなければデフォルトの値になります。
指定しなかったからといって決して 0にはなりませんので、ご安心ください。
415:名無しさん＠お腹いっぱい。
08/05/15 08:55:59
>>414
あほか。wsize/rsizeをいじりたくなったらデフォルト値を知る必要があるだろ。
>>413
OS（とそのバージョン）による。
FreeBSDなら/usr/include/nfsclient/nfs.hにNFS_WSIZE,NFS_RSIZEで定義されてる。
他は知らん。
416:名無しさん＠お腹いっぱい。
08/05/15 09:27:37
>>414
Linuxなら、mountコマンドを引数なしで実行したら表示されるだろｗｗ
一般ユーザーでも可能。
417:名無しさん＠お腹いっぱい。
08/05/15 09:34:42
>>415
ソースを見るんじゃなくて、稼働中のカーネルで実際にマウントされている時の
wsize/rsizeはわからないんですか?
418:名無しさん＠お腹いっぱい。
08/05/15 12:28:33
Solarisならman mount_nfsに書いてある。
419:名無しさん＠お腹いっぱい。
08/05/15 12:34:17
>>418
それだと、mount後に「現在の」rsize,wsizeを知ることができないじゃん。
420:名無しさん＠お腹いっぱい。
08/05/15 13:16:50
もうさ、tcpdumpでNFS WRITEのサイズ見ればいいじゃん
421:名無しさん＠お腹いっぱい。
08/05/15 14:50:09
>>418
デフォルト値がわかるからいいじゃんか。
422:名無しさん＠お腹いっぱい。
08/05/15 16:00:17
>>418
Solaris なら nfsstat -m でずらっと出てくるお
423:名無しさん＠お腹いっぱい。
08/05/15 16:28:26
Linuxでも nfsstat -m で rsize/wsize 他のパラメータもわかる。
manの情報は実際のカーネルとは合ってないことがあるし、
やっぱり現物で確認する方法がいいよね。
424:名無しさん＠お腹いっぱい。
08/05/15 21:08:45
その知見は現物でしか使えないけどね。
425:名無しさん＠お腹いっぱい。
08/05/16 16:38:33
mountコマンドが、
コマンドラインオプションで指定されなかったnfs mountオプションを、
mount(2)に渡す時に、
・0にしてkernelに任せる
・具体的な規定値を設定する
と二種類あるから気をつけて。
426:名無しさん＠お腹いっぱい。
08/05/20 07:44:06
server1 --- server2 -- cilent
server1は指定のディレクトリをNFSで公開します。
server2はserver1のディレクトリをマウントし、NFSで公開します
clientはserver2のディレクトリをマウントします
これはできる？
427:名無しさん＠お腹いっぱい。
08/05/20 07:58:47
>>426
Linuxなら可能。一般には不可能。
428:名無しさん＠お腹いっぱい。
08/05/20 08:33:56
>>427に追加
server2がLinuxなら～
429:名無しさん＠お腹いっぱい。
08/05/21 12:53:23
>>426
ちなみにserver2でsmbでマウントしたディレクトリを公開したら
書き込みできなかった
430:名無しさん＠お腹いっぱい。
08/05/22 00:34:19
>>420
便乗質問
NFS WRITE のサイズって、具体的にどこを見ればいいの？
431:名無しさん＠お腹いっぱい。
08/05/22 01:40:19
汎用性あるかしらんが、Linuxなら、
/proc/mount
NFS-SERVER:/home /home nfs rw,v3,rsize=32768,wsize=32768
432:名無しさん＠お腹いっぱい。
08/05/22 06:31:01
>>431
/proc/mounts だな
433:名無しさん＠お腹いっぱい。
08/06/30 10:19:33
マシンA,B,Cがあったとして
AからBへnfsマウントして、さらに
BからCへnfsマウントできますか？
つまりCからAのディスクをnfsを２回中継してマウントしたいです。
434:名無しさん＠お腹いっぱい。
08/06/30 11:26:07
>>433
>>427
435:名無しさん＠お腹いっぱい。
08/06/30 11:32:13
Linuxでもできない実装なかったっけ
436:名無しさん＠お腹いっぱい。
08/06/30 11:41:00
knfsdは不可
unfsdは可
437:名無しさん＠お腹いっぱい。
08/06/30 12:01:58
いまどきunfsdなんて使われてないから、結局Linuxでも不可ってこと?
438:名無しさん＠お腹いっぱい。
08/06/30 12:10:00
あえてunfsd使えば可ってこと
439:名無しさん＠お腹いっぱい。
08/07/09 14:56:06
MACOSXServer10.4のフォルダをエクスポートして、Solaris9でNFSマウントする。
その環境で、Solaris9上でMacのフォルダの容量を取得したい。
そこで質問＞＞
Solaris9上でNFSマウントしたMacのフォルダをdu -skの値と、
Mac上でdu -skの値に差がある。
Solaris9：2676
Mac：892
NFSマウント方法や、他に容量の取得する方法があれば教えてほしい。
お願いします。
440:名無しさん＠お腹いっぱい。
08/07/09 15:28:30
>>439
つ du -sB 1 filename
441:名無しさん＠お腹いっぱい。
08/07/14 05:04:45
>216 >218 と同じことやってた。
NFS でマウントしたディレクトリ以下で、
mkdir した場合は、強制的に permission 775 に
するようにできないのかな。
exports しているディレクトリは 2775 にセットしているから、
直下に 755 なファイルを作られても、group ユーザは消せる
けど、directory を 755 で掘らて、その下に 755 なファイルや
ディレクトリを作られると、消せなくて不便。
anonymous にすると、group で共有ディレクトリを制御
できないし。
442:名無しさん＠お腹いっぱい。
08/07/14 06:43:05
>>441
クライアント側で mountする時に、-o grpid オプションを付ければ、
ディレクトリのgidはサブディレクトリに伝播するよ。
443:名無しさん＠お腹いっぱい。
08/07/14 23:59:16
ありがと。ただ、それは、export 元で permission
を 2775 の 2 (setgid) を立てておくのと同じです。
結局、 全員に permission 775 (umask 002) 以外に
設定することを禁止し、その代わり /usr/home 用に、
uid ごとの個別のgid を用意して、運用することにしました。
NFS をグループ別に共有することができるようになったけど、
なんか、車輪の再生産をした気分。
444:名無しさん＠お腹いっぱい。
08/07/15 11:32:01
君は何も生産してないよ。
445:名無しさん＠お腹いっぱい。
08/07/21 14:23:42
ちょいと質問。すべて同じOS・同じバージョンです。具体的にはCentOS5.1のx64版。
NFSで/usr/localを共有するのと、/usrを共有するのってどちらの方が運用上賢いでしょうか？
yum upgradeとかしたときに全てのサーバマシンに影響するのかな。
446:名無しさん＠お腹いっぱい。
08/07/21 19:54:13
CentOSとやらがどこまでNFS共有を想定しているのか知らんが、
NFSで/usrを共有すると、たとえばNFSサーバ上で何かパッケージをインストール
したとき、NFSクライアント側は、/usrが更新されて/varが更新されていないという
不整合な状態になると思われ。
パッケージシステムを使うなら、複数ホストのパッケージ管理を1操作で
できるようにするのが筋ではないかと。
447:名無しさん＠お腹いっぱい。
08/07/21 19:58:22
/usr/localが吉
448:名無しさん＠お腹いっぱい。
08/07/21 20:30:09
>>445
system-config-netbootで全部
449:名無しさん＠お腹いっぱい。
08/07/21 23:36:11
>>447
そんなの初耳なんだが
450:名無しさん＠お腹いっぱい。
08/07/22 07:24:50
>>446
NFS 鯖と心中という障害ポイントを作る以上のメリットがない。
そんな程度なら定期的に rsync とかで同期した方が安定かつ高速。
451:名無しさん＠お腹いっぱい。
08/07/22 08:16:30
>450
定期的にrsync、というのはどの程度の間隔が良いのでしょうか？
ていうか、障害ポイントを発生させたとしても、管理ポイントが共有によりひとつに
まとまるNFSの方が楽じゃない？ NFS鯖を極力落ちないよう準備しておけばいいだけだし。
あくまで確率論だとは思いますが。
452:名無しさん＠お腹いっぱい。
08/07/22 08:23:43
>>446は読んだんか?
パッケージ管理の整合性という本質的な問題が理解できてないように思うが?
453:名無しさん＠お腹いっぱい。
08/07/23 09:13:30
どんなに暗くても、明けない夜はない。
NFSサーバだってきっと落ちるさ。
454:名無しさん＠お腹いっぱい。
08/07/23 14:40:53
>>451
マスターサーバを更新したときに手動で実行するとか、
もしくはクライアントがマスターサーバに何らかの方法で問い合わせて、
更新フラグが立ってたら同期するとかね。
455:名無しさん＠お腹いっぱい。
08/07/23 17:53:21
/varも共有してしまえばOK。
456:名無しさん＠お腹いっぱい。
08/07/23 18:04:07
/var共有ということは、ほかにも/etcも共有するのですね、わかります
457:名無しさん＠お腹いっぱい。
08/07/23 18:17:14
素直にディスクレスクライアントにしてしまえ。
458:名無しさん＠お腹いっぱい。
08/07/23 18:28:45
ディスクレスクライアントにしてるよ。
パッケージアップデートとか、
NFS鯖上で各クライアントディレクトリにchrootしてやってる。
クライアントPCが電源OFFでも、NFS鯖上だけでアップデートできるので管理すごく楽。
459:名無しさん＠お腹いっぱい。
08/07/23 18:43:02
>>458
クライアントごとにインスタンス作ってるの？
すごく無駄な気が...
460:名無しさん＠お腹いっぱい。
08/07/23 18:48:04
>>459
クライアントごとにあるのは / (/var /etc /sbin等)のみ。
/usrは共有してる。共有後にパッケージ管理もしてる。
あ、/sbinのバイナリは個別にハードリンク共有してる。
461:名無しさん＠お腹いっぱい。
08/08/07 14:41:19
賢い人はyumを使うような環境で/usrをmountしたりはしない
462:名無しさん＠お腹いっぱい。
08/08/07 23:56:53
aufs+NFSで/ごとマウントしてマウント先で個別にyumしてもいいし、
逆にyumは一切しないで元ツリー側でのyumに任せる運用をしてもいいぞ。
463:名無しさん＠お腹いっぱい。
08/08/13 08:19:45
CentOS5.2入れて、mount -t nfs したんだけど
flock()使ってるPerlのCGI動かすと1分くらい無反応になって終了しちゃう
ファイルロックかからなくていいから、flock使っても無視するmount方法ってないかな?
ちょっと前のLinuxだと、ふつーにmountしてflockつかっても問題ないんだけど
464:名無しさん＠お腹いっぱい。
08/08/13 08:43:04
>>463
mount -o nolock
465:名無しさん＠お腹いっぱい。
08/08/13 11:17:26
>>463
ちょっと前っていつ頃？
466:名無しさん＠お腹いっぱい。
08/08/13 11:38:34
おれが夕焼けだったころ
467:名無しさん＠お腹いっぱい。
08/08/13 13:00:34
a)flockが動かないのに、なぜ動かないのか調べない
b)ファイルロックかからなくていい
c)スクリプトの方を書き換えようとしない
d)デフォルトでNFSマウントされたディレクトリでflockしようとする
いずれも俺には理解できない発想の集合体だ。
a)システムが正常に動いてないんだから、まずどこが異常なのか調べてくれ。
statdとかlockdとか動いてないんじゃないのか。他のアプリケーションの動作にも
支障があるだろう。
b)競合すればデータが壊れる。同時実行しないという仮定でCGI運用したって
必ずいつかどこかで隙を突かれる。
c)なんのためのスクリプト言語なんだ
d)たとえhomeとかNFSマウントしてても、CGIを実行するホストが単一なら
/varのようなローカルマウントしてるディレクトリ上のファイルに対する
ロックで排他するのが筋。
468:名無しさん＠お腹いっぱい。
08/08/13 14:12:26
cとdは連鯖なら普通だろ。
aはNFS鯖がFreeBSDとかじゃねーの？
469:名無しさん＠お腹いっぱい。
08/08/13 14:23:57
>>468
> cとdは連鯖なら普通だろ。
動かない規定scriptがあるレンタルサーバが普通なのか?
> aはNFS鯖がFreeBSDとかじゃねーの？
（ ﾟдﾟ）ﾎﾟｶｰﾝ
470:名無しさん＠お腹いっぱい。
08/08/13 14:30:07
>>469
おまいさんは客のスクリプトを勝手に書き換えるのか？
>（ ﾟдﾟ）ﾎﾟｶｰﾝ
このすれを>>1から読んでこい
471:名無しさん＠お腹いっぱい。
08/08/13 14:43:34
質問に回答して、解決すればそれでいいんだよ。
質問主からの結果報告がないようだけど。
>>464 の回答で解決でしょ。
472:名無しさん＠お腹いっぱい。
08/08/13 16:08:43
「苦しいんです。いっそ殺して楽にしてください」って患者に言われて、 言われるままに青酸カリを処方する医者は薮なんだぜ。
473:名無しさん＠お腹いっぱい。
08/08/13 16:15:24
たとえになってない。
ハイ次。
474:名無しさん＠お腹いっぱい。
08/08/13 16:19:56
>>472
Linuxの -o nolock オプション付でmountした場合、
rpc.lockd経由の異ホスト間のロックがかからなくなるだけで、
同一ホスト上だと、(たとえロック対象ファイルがNFS上でも)ちゃんとlockがかかるよ。
なので、-o nolock が質問者に対する適切な回答と思われる。
475:名無しさん＠お腹いっぱい。
08/08/13 17:08:08
「まず壊れているものを直す」これが問題解決の原則。
この場合、壊れているのはロック要求に応えないNFSサーバであり、
ロックの必要がないのに獲得しようとしているスクリプトだ。
-o nolockは逆に、壊れていないNFSクライアントを壊してしまう。
(ネットワークワイドでのlockを無効にし、アプリケーションにエラーも返さない)。
そのサイトで動作するアプリケーション全体に影響が及ぶことを考えれば、
他で対処できないときの次善の策と考えた方がよい。
476:名無しさん＠お腹いっぱい。
08/08/13 17:29:56
「まず質問者が質問していることに答える」これが問題解決の原則。
477:名無しさん＠お腹いっぱい。
08/08/13 17:39:09
自分のやり方を押しつけちゃいかんよ。
どっちも。
478:名無しさん＠お腹いっぱい。
08/08/13 17:54:02
「自分のやり方を押しつけちゃいかん」という考えも押しつけちゃいかんよ。
3人とも。
479:名無しさん＠お腹いっぱい。
08/08/13 21:31:45
ありがとう -o nolock で無視できた
でもしっくりいかないなあ
statdやlockd走しらせてmountしたファイルシステムにflockかけただけで半ストール状態になっちゃうものなの?
サーバー側がおかしいのかな
480:名無しさん＠お腹いっぱい。
08/08/13 23:43:29
質問者はその問題に関する知識がない(これは質問者なんだから当たり前)。
だから、質問者が発した質問が適切に組み立てられるとは期待出来ない。
質問の裏にある、質問者が抱えている真の問題を見抜いて解決法を回答するのが、
知識のある回答者の側の責務。
>>479
サーバ側、もしくはサーバとの通信がおかしい。
たとえばdaemonは動いていてもどこかのレイヤでパケットがフィルタリングされている、等。
481:名無しさん＠お腹いっぱい。
08/08/14 07:01:31
>>480
質問者はその問題に関する知識がないからこそ、
直接の回答なしに質問以外のことに対する余分な指図と思われる返答があっても
それを受け入れない、または理解できない。
まずは質問に対する直接の回答をするべき。
一旦その回答を質問者が試した上でさらに質問や疑問点があれば
再度質問すればいいことだから。
482:名無しさん＠お腹いっぱい。
08/08/14 11:07:21
>>479
パケットフィルタのせい？
フィルタが原因で、そういう現象が結果として出てくるのかは知らないけど。
483:名無しさん＠お腹いっぱい。
08/08/14 11:16:29
エスパーすると、lockd/statdは、クライアント、サーバー、双方で起動必要。
そのどちらかを忘れてるとか。NFS鯖がFreeBSDの場合はlockはうまく動かないのが普通。
484:名無しさん＠お腹いっぱい。
08/08/14 11:54:33
理解できるように説明してやればいいんじゃね
485:名無しさん＠お腹いっぱい。
08/08/14 22:41:52
フィルタリングはiptablesくらいしかしてないので
サーバー、クライアント両方切ってmountしてみたけど、、、同じだった。
statd走らせたうえで-o nolockで問題ないようなので
これで様子みてみます。
きっとたぶん忘れた頃にぽっと原因がわかったりするとおもう
ありがとー
486:名無しさん＠お腹いっぱい。
08/08/14 23:01:57
あ、あとexportfs -aしてもそのクライアントだけハングしちゃう
やっぱりちょっと気味悪いイ
487:名無しさん＠お腹いっぱい。
08/08/15 01:15:45
>>481
そんな劣悪な質問者だと直接の回答なのかどうかすら
判断できないんじゃねーの。
488:名無しさん＠お腹いっぱい。
08/08/15 12:22:31
>>479
斜めにしか過去レス読んでないのではずしてるかもしれんが、
NFSってパケットが普通にフラグメントして飛ぶので、
フィルタリングしてる機械がアホだと刺さるよ。
FreeBSDのpfでもscrub入れてないと刺さる。
489:名無しさん＠お腹いっぱい。
08/08/15 20:16:19
TCPでマウントしても？
490:名無しさん＠お腹いっぱい。
08/08/18 23:53:43
>>483
そういえば、FreeBSD+ZFSのNFSサーバでもlockできないのかな？
491:名無しさん＠お腹いっぱい。
08/08/19 09:00:54
>>490
ZFS、一体何の関係があるんだ？
492:490
08/08/20 20:56:11
>>491
ZFSはexportfsを使わないexportを行うから、lockも自前で行うのかなと思って。
493:名無しさん＠お腹いっぱい。
08/09/04 02:17:41
板違い覚悟で質問します。ご迷惑をおかけしますが、なにとぞご協力をお願いします。
物理ファイアウォール経由でNFSマウントをする構成なんですが、その物理FWがIPとポート番号をガチンコ指定なため、
NFSクライアント側の浮動するポート番号をなんとか固定しないといけないです。
すごくアホな話ですが、S側、D側のIPとポートを全制御できるパケットしか許可しないなんて言われてます。
環境：RHEL5 NFSv3
なんとか、NFSクライアントのポート番号を固定化する方法を教えてください。
せめてmount.nfs(サーバ側892ポートと通信するモジュール)のポート番号が特権ポートを使わないようにする
設定を教えてください。
494:名無しさん＠お腹いっぱい。
08/09/04 02:23:09
ちなみに、サーバ側の/etc/exportsにinsecureオプションを付与したりもしました。
portmapの使用するポート番号の指定もしました。(/proc/sys/net/ipv4/ip_local_range)
mount.nfsは、NFSマウントをかけに行ったときにnetstatを打つと892と通信していたモジュールです。
111とか2049はお行儀よくエフェメナルポートを使用しているのに、こいつだけウェルノウンポートを使用します。
本当は固定できれば最高なんですが、1024:65535のポート全開放しないとどの道sshやらできないよ
なんて方向で切り込めば押し込めるかなと思ってます。若干デスマーチ気味な構築になってますが、
なかなかデカいプロジェクトなので、重ねてご教示お願いします。
495:名無しさん＠お腹いっぱい。
08/09/04 03:36:48
ググレカス
496:名無しさん＠お腹いっぱい。
08/09/04 03:50:36
,．-─ ─-､─-､
, イ)ィ -─ ─- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ /
| ｀､ ⌒ ,/
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」
ググレカス [ gugurecus ]
（西暦一世紀前半～没年不明）
よく読めカス!
URLﾘﾝｸ(www.redhat.com)
497:名無しさん＠お腹いっぱい。
08/09/04 04:19:49
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼
／ ⌒（__人__）⌒ ＼ ＜若干デスマーチ気味な構築になってますが、
| |r┬-| | なかなかデカいプロジェクトなので、重ねてご教示お願いします。
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
＿＿＿_
／_ノ ヽ､_＼
ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo ﾐ ﾐ ﾐ ＜だっておｗｗｗ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼ /⌒)⌒)⌒)
| / / / |r┬-| | (⌒)/ / / /／
| :::::::::::(⌒) | | | ／ ゝ :::::::::::/
| ノ | | | ＼ / ） /
ヽ / `ー'´ ヽ / ／
| | l||l 从人 l||l l||l 从人 l||l
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
498:名無しさん＠お腹いっぱい。
08/09/04 04:21:59
【お前の頭はくるくるパーだおｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ】
∩ _rﾍ / ヽ∩
. ／＿ノυ＿＿＿ιヽ＿ ＼
／ ／ ／⌒ ⌒＼ ヽ ＼
( く ／（ ●） （●）＼ > ） お前の頭は
＼ ｀／::::::⌒（__人__）⌒:::::＼' ／
ヽ| |r┬-| |/
＼ `ー'´ ／
(( (ヽ三/) (ヽ三/) ））
. (((i ) ＿＿＿ ( i)))
／ ／ ／_ノ ヽ_＼ ヽ ＼
( く ／（ ●） （●）＼ > ） くるくる
＼ ｀／::::::⌒（__人__）⌒:::::＼' ／
ヽ| ￣ |/
＼ ／
∩∩∩ . ∩∩∩
.∩_:||_:|_:| |_:||_:|_:∩
│ ___ つ ⊂ ___ │
ヽ ノ ＿＿＿ ヽ ノ
／ ／ ／_ノ ヽ､_＼ ヽ ＼
( く oﾟ(（●）) (（●）)ﾟo > ） パーだおｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
＼ ｀／::::::⌒（__人__）⌒:::::＼' ／
ヽ| |r┬-| |/
＼ | | | ／
| | |
`ー'´
499:名無しさん＠お腹いっぱい。
08/09/04 04:27:03
,, -─- ､._
．-"´ ＼．
：/ _ノ ヽ､_ ヽ.：
：/ oﾟ(（●）) (（●）)ﾟoヽ：
：| （__人__） |： プギャー！！！
：l ) ( l：
：` ､ `ー' /：
：, -‐ (_). ／
：ｌ_ｊ_ｊ_ｊ と)丶─‐┬．''´
：ヽ ：i |：
：/ ：⊂ノ|：
500:名無しさん＠お腹いっぱい。
08/09/04 04:47:54
┐(´д｀)┌ やしやし
501:名無しさん＠お腹いっぱい。
08/09/04 09:23:04
>>496
早速のレスあざす。ただし、私の説明が良くなくて申し訳無いです。
/etc/sysconfig/nfsを編集してサーバ側のポートを固定することは成功しています。
説明が悪くすみません。マウントしにいく側のポートを固定したいと考えています
502:名無しさん＠お腹いっぱい。
08/09/04 09:31:26
デカいプロジェクトやデスマーチプロジェクトのサポート役を2chに
求めるって時点でその会社は終わってるな。
503:名無しさん＠お腹いっぱい。
08/09/04 10:23:52
>>502
だってメーカーサポートがないんだもーん
504:名無しさん＠お腹いっぱい。
08/09/04 10:43:26
フェドラなんかのフォーラムでも質問をなげたのですが、
良い答えはない感じでした。皆ファイアウォールの構成を変えろといいます。
それが正しいと思いますが。
クライアント側のポート番号のみブラックボックス化しているように見えます。
portmapが制御しているのは間違いないと思っていますが。
それこそ新たにモジュールを自作して噛ませる必要があるのでしょうか。
505:名無しさん＠お腹いっぱい。
08/09/04 10:45:55
自力で調べられる人とか、構築経験のある人とかがいないから終わってるって
ことだと思うのだが……そりゃデスマーチ状態になるわな的な意味で。
506:名無しさん＠お腹いっぱい。
08/09/04 11:10:47
Linux板行けよ。
507:名無しさん＠お腹いっぱい。
08/09/04 11:13:57
>>504
> portmapが制御しているのは間違いないと思っていますが。
違います。
ポートの範囲を狭められたとしても、固定は無理です。
lockdやstatdにも言及してないし、あなたには無理な仕事なんじゃないでしょうか?
508:名無しさん＠お腹いっぱい。
08/09/04 11:35:06
あ、確かにportmapではありませんでした。rpcbindですね。
509:名無しさん＠お腹いっぱい。
08/09/04 12:02:05
NFSクライアントの送信元ポート番号は実装による。普通は固定しない。
1024以下の番号を利用する事が多い。(UNIXの世界では1024以下はrootというお決まりなので)
ファイヤーウォールの設定を SrcPort 1-1024 DstPort 111,2049 と
status lockmgr mountd が使うポートを開放してもらえばよろしい。
ネットワーク管理者からすると、暗号化もされてない通信路でファイヤーウォール越しに
NFSなんてふざけてる奴だ、こう言っておけば諦めるだろうという意図だろう。
どうしてもやりたいなら VPN してやれや。
510:名無しさん＠お腹いっぱい。
08/09/04 12:06:15
色々なご意見、ご回答ありがとうございます。
実力不足はいまさらながら痛感しています。
熟達した技術をお持ちの皆様に不快感を与えてしまい申し訳ない気持です。
今後は今以上の精進を持って学習いたしますので、なにとぞご協力お願いしたい所存です。
/etc/sysconfig/nfsの設定ファイルで、lockdやstatdのポートを固定するよう設定しています。
確かにログなどを確認してもそれらのポートが使用されていないので
設定が足りないのかもしれません。rpcinfoでは固定されていることは確認できます。
クライアント側は、使用ポートを固定できなくとも、狭める事ができれば
それでもクローズは可能です。なにとぞ御教示お願いします。
公式ドキュメントなどでportmapが制御しているものと判断しておりました。
それが違うとのこと、了解致しました。ありがとうございます。別のアプローチをトライしてみます。
511:名無しさん＠お腹いっぱい。
08/09/04 12:09:26
>>510
このスレの人間は誰もやったことがないから答えられないんだよ。
実際のところはそんなとこｗ
512:名無しさん＠お腹いっぱい。
08/09/04 12:12:27
>>509
貴重なアドバイスありがとうございます。FWの構成もNFSマウントもすべて客先による指示であるため、ベストエフォートである必要があります。
そのため、VPNの検討もしてみます。ありがとうございます
513:名無しさん＠お腹いっぱい。
08/09/04 12:33:24
>物理ファイアウォール経由でNFSマウントをする構成なんですが、
どうでもいいけど、物理ファイアウォールといったら
ビルとかに設置してある防火壁のことなんじゃないだろうか。
iptables じゃなくてアプライアンス箱を使っているという意味は
わかるからいいけど。
514:名無しさん＠お腹いっぱい。
08/09/04 12:37:07
Linuxカーネルのソース書き換えろ。> 範囲固定
515:名無しさん＠お腹いっぱい。
08/09/04 12:48:42
送信元のポート番号を固定したら、NAPTできないじゃん。
516:名無しさん＠お腹いっぱい。
08/09/04 12:54:04
2chなんかで質問してしまうなんて、よっぽど気が狂ってるんだろうな。
全て客先による指示なら、客に聞けばいいだろ。
できる事と、できない事の区別もつかないなら、仕事向いてないよ。
517:名無しさん＠お腹いっぱい。
08/09/04 12:55:43
うるせーなクソカス
518:名無しさん＠お腹いっぱい。
08/09/04 14:10:48
>FWの構成もNFSマウントもすべて客先による指示であるため、
・・・・・客の指示だったら物理的に保証がないとか誰もやったこと無いような事まで
「できますって言っちゃったらやる」って言うの？
さすが出来る技術者は違いますね～（棒
519:名無しさん＠お腹いっぱい。
08/09/04 15:35:06
客が死ねと言ったらお前も死ぬんだな!
520:名無しさん＠お腹いっぱい。
08/09/04 16:19:09
だまれボンクラニート
521:名無しさん＠お腹いっぱい。
08/09/04 16:49:43
皆様の痛烈なご指摘通り、客先指示には原則従う事が前提です。
そのため、今回のようなケースでも可能性を地獄の果てまで追いかける必要があります。
もし不可能と言うことであれば、不可能である根拠や証跡が必要になります。
現段階ではまだ不可能と断定可能な材料がないため、調査及び有識者各位にお問い合わせしている次第です。
当然皆様に対して不可能な根拠や証跡まで要求する気はございませんが、
それでも図々しいお問い合わせをしていると認識しております。
皆様に置かれましては、私の見苦しい発言の数々でご迷惑の事と存じますが、
今一度のお力添えをお願いしたい所存です。
522:名無しさん＠お腹いっぱい。
08/09/04 16:51:38
>>521
>>514 が方法を回答してるじゃん。
523:名無しさん＠お腹いっぱい。
08/09/04 17:06:08
>>514
>>522
ご回答が遅くなり申し訳ありません。
その手段はOS自体や他APへの影響範囲が評価不可能なため、先ほど客先より却下されました。
申し訳ありません。
524:名無しさん＠お腹いっぱい。
08/09/04 17:24:14
技術力がないから「出来ない」といっても客に信用してもらえないんだな。
「うちは技術がないのでそんなこと出来ません」と正直に言っちゃえば
客も流石に飲むしかないと思うがな。
525:名無しさん＠お腹いっぱい。
08/09/04 17:32:06
できない仕事とるなよ。
526:名無しさん＠お腹いっぱい。
08/09/04 18:04:16
技術がないからできるとかできないとかで仕事選べないんじゃね
527:名無しさん＠お腹いっぱい。
08/09/04 18:12:35
既に取っちまったもんを、エンジニアだけでどうこう出来ないだろうて。
自分が同じ立場だったとして「出来ない」と突っぱねられるか？
528:名無しさん＠お腹いっぱい。
08/09/04 18:14:13
「2chで聞いたけどできないといわれました。」と答えればいい。
529:名無しさん＠お腹いっぱい。
08/09/04 18:14:48
そんなこと言われてもできるようにはならん。
530:名無しさん＠お腹いっぱい。
08/09/04 18:16:20
NFSプロキシ建てれば? プロキシ側でソースポート固定と。
531:名無しさん＠お腹いっぱい。
08/09/04 18:25:23
自分が同じ立場なら? なぜNFSが必要なのか、なぜソースポートまで固定した
厳格なファイアウォールが必要なのか、そういったところからヒアリングして、
できるだけ客の「やりたい事」に沿った解法を探るだろうな。
客はファイル共有やネットワークの保護がやりたいんであって、
客自身がNFSそのものがやりたい、ソースポート固定そのものがやりたい、ということは稀だ。
当たり前だが。
532:名無しさん＠お腹いっぱい。
08/09/04 18:29:38
なんだ、>>512 で「VPN検討する」って言ってるじゃん。それでFAだろ。
ハイ次の質問どうぞ。
↓
533:名無しさん＠お腹いっぱい。
08/09/04 18:44:00
>>531 客がｷﾁｶﾞｲだったってことは漏れ経験したｗ
534:名無しさん＠お腹いっぱい。
08/09/04 18:50:20
板違いだから。その話題は。
535:名無しさん＠お腹いっぱい。
08/09/04 22:02:21
現状 nfsd---|FW|---nfs client
解決 WiFi---nfsd---|FW|---nfs client---WiFi
これで桶w
536:名無しさん＠お腹いっぱい。
08/09/04 22:44:20
iptablesでそのサーバ宛のNFS関係パケットのソースポートを書き換える、とか？
537:名無しさん＠お腹いっぱい。
08/09/05 13:10:02
あんまりこねくり回すと、意味不明でメンテ不能になるぜ。
VPNして終了でいいじゃん。
538:名無しさん＠お腹いっぱい。
08/09/05 15:27:01
あっさりVPNで穴あける前に、なんでVPNなんてものが必要になるのか、
ファイアウォールの意味をもう一度考えようぜ。
539:名無しさん＠お腹いっぱい。
08/09/05 16:51:46
単なる釣だろ。
540:名無しさん＠お腹いっぱい。
08/09/05 17:21:54
A「お前さん、一杯喰わされたな。ありゃ単なる釣りだぜ」
B「そうか、なら良かった」
A「なに?」
B「ファイアウォールにNFS通そうとする馬鹿な客と馬鹿なSEは、いないんだ」
♪ダンダンドゥヴィ、ドゥヴィダダン……
541:名無しさん＠お腹いっぱい。
08/09/05 18:40:32
VPNが最強なんだぜ？
542:名無しさん＠お腹いっぱい。
08/09/05 19:56:56
VPNは、先ほど客先より却下されました。
申し訳ありません。
引続き解決策の議論をお願いします。
543:名無しさん＠お腹いっぱい。
08/09/05 20:09:13
>>542
SSHで繋がせてもらう
で SSH over PPP でトンネリング。
URLﾘﾝｸ(nakagami.blog.so-net.ne.jp)
客には、「VPNなんて使ってませんよ。telnetみたいなのしか使ってませんよ」とか言う
544:名無しさん＠お腹いっぱい。
08/09/05 20:21:57
客に却下されたからダメ、じゃなくて、
そうするよりマシな実現方法はないからこれでやらせろ、
それじゃなきゃやらない、ぐらいのアピールしろよ。
構築だけじゃなくて後の運用もどうせ請け負ってるんだろうから、
客の奴隷になるのは不幸になるだけだ。
そういう客の言いなりで作ると、けっきょく gdgd なものしかできなくて
後々まで泣くことになるぞ。
545:名無しさん＠お腹いっぱい。
08/09/05 21:49:11
送信元ポートを固定するようなアプリケーションの設計は
あまりよくない、むしろバカな設計なのだよ。
議論(藁)なんてする必要すらない。
だいたいNFSは信用できるネットワーク内で使う事を前提とされているし
ましてやWANを経由する事も考えられていない。
スレ違いのプロトコルと言ってもいいな。
546:名無しさん＠お腹いっぱい。
08/09/05 23:14:27
>客に却下されたからダメ、じゃなくて、
>そうするよりマシな実現方法はないからこれでやらせろ、
>それじゃなきゃやらない、ぐらいのアピールしろよ。
そーだ、その通りだー。
ファイアウオールにNFSを通すなんて（客がどっから実例拾ってきて提示してるか知らないけど）
元々の仕様を超えた使い方に対してはもう議論（苦笑）の余地さえも残っていないと思うけどね。
どうせ却下されるだろうけど試しにｗ
つ【業務用のネットワークとは別にNFS専用のネットワークを用意する】
547:名無しさん＠お腹いっぱい。
08/09/05 23:34:14
>>531 客がｷﾁｶﾞｲだったってことは漏れ経験したｗ
548:ななし
08/09/06 01:42:37
少なからずFireWall-1やNetScreenを使っているならNFSでも簡単かつセキュアに
通せるわけだが、その辺りのファイアウォールは使っていないって事？
だったら、そこそこでかいプロジェクトとは思えないんだけど。
ファイアウォールの管理者に地味に嫌がらせされてるだけ？？