RHEL6 になって、今まで使っていた smbpasswd のラッパースクリプトが動かなくなった。スクリプト中では smbpasswd ファイルを直接ごにょごにょしているのだが、そのファイルの場所が変わったらしい。
[rhel5]# testparm -sv | grep 'smb passwd file'
Load smb config files from /etc/samba/smb.conf
<...snip...>
Loaded services file OK.
Server role: ROLE_STANDALONE
smb passwd file = /etc/samba/smbpasswd
[rhel6]# testparm -sv | grep 'smb passwd file'
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
<...snip...>
Loaded services file OK.
Server role: ROLE_STANDALONE
smb passwd file = /var/lib/samba/private/smbpasswd
他にも幾つかデフォルト値が変わっている。特に lanman auth や wide links などはハマる人が居るかも知れない。まあ smbpasswd の場所が変わってハマるのは私くらいだろうけどな。
ところで、上では気になるメッセージも出ている。
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
これはファイルオープン数の上限を上げれば出なくなるらしい。
Samba の起動ユーザーだけ上限を上げたいところだが、あいにく Samba の起動ユーザーは root なので、root の上限を上げることになる。/etc/init.d/smb を編集(ulimit -n)すれば影響を Samba プロセスだけに限定できるが、システムがインストールするファイルを変更するのは気持ちが良くない。なのでひとまず root の上限を上げることにする。
[rhel6]# echo 'root - nofile 16384' >/etc/security/limits.d/50-samba.conf
[rhel6]# reboot
でもこれ、確かに厳密には 16384 必要なのかも知れないが、実際には絶対に必要ないだろ。多分この 16384 は smb.conf 設定でいう max open files の値だが、クライアントが同時に 16384 個もファイルを開くってどんな状況だよ。
なので取りあえずは問題が出るまで、無視することにした :-p。いやだって、RHEL5 Samba は今までデフォルト値(1024)で問題なく動いてるんだもん。
2017-05-03 追記
今まで放置していて申し訳ないが、このエントリには 重大な嘘 が 2 つある。
まず 1 つ目。
daemon系プロセスのファイルディスクリプタ数上限を設定する際、/etc/security/limits.conf は使えません。
うん、ほんとこれ。当時は Samba を再起動して確認しただけで、サーバー再起動後に改めて確認してなかった。当時の自分を叱ってやりたい。
そして 2 つ目。ソースコードをご覧あれ。
if (rlimit_max < MIN_OPEN_FILES_WINDOWS) {
DEBUG(2,("rlimit_max: increasing rlimit_max (%d) to "
"minimum Windows limit (%d)\n",
rlimit_max,
MIN_OPEN_FILES_WINDOWS));
rlimit_max = MIN_OPEN_FILES_WINDOWS;
}
つまりこのメッセージは rlimit_max を「上げろ」ではなく、「上げるよ」と教えてくれていた訳だ。なのでこのメッセージを受けて、私たちがやるべきことは何もない。
まあ確かに、increase (命令形)ではなく increasing となっているけれども、誤解されやすいメッセージだと思うんだよなあ。せめて increased だったら気付けたのかも。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。