2012-04-30

Home server via plala's network

外から自宅サーバーの Bazaar リポジトリに push しようとすると、

Run command: bzr push
Connected (version 2.0, client OpenSSH_5.3p1)
Using saved push location: sftp://piyolian@example.com:10022/~/repo
Authentication (password) successful!
Secsh channel 1 opened.
[chan 1] Opened sftp connection (server version 3)
Traceback (most recent call last):
  File "logging\__init__.pyo", line 799, in emit
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8a in position 18: ordinal not in range(128)
bzr: ERROR (ignored): 
bzr: ERROR: paramiko.SSHException: Server connection dropped: 

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 927, in exception_to_return_code
<...snip...>
  File "bzrlib\btree_index.pyo", line 1547, in _read_nodes
  File "bzrlib\transport\__init__.pyo", line 659, in readv
  File "bzrlib\transport\sftp.pyo", line 466, in _readv
  File "bzrlib\transport\sftp.pyo", line 728, in _translate_io_exception
SSHException: Server connection dropped: 

bzr 2.3.4 on python 2.6.6 (Windows-XP-5.1.2600-SP3)
arguments: ['C:\\Program Files\\Bazaar\\bzr.exe', 'qsubprocess', '--bencode',
    'l4:pushe']
plugins: bzrtools[2.3.1], colo[0.2.1], explorer[1.1.4], fastimport[0.10.0],
    launchpad[2.3.4], loom[2.2.1dev], netrc_credential_store[2.3.4],
    news_merge[2.3.4], pipeline[1.1.0], qbzr[0.20.1], rewrite[0.6.2dev],
    svn[1.0.5dev], upload[1.0.0], xmloutput[0.8.7.dev]
encoding: 'cp932', fsenc: 'mbcs', lang: None

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

何か変なエラー出た。何度やっても結果は同じ。pull の方は動く。更に変なことに、調査のために SSH で自宅サーバーに繋ぐと、1 分そこらで接続が切れてしまう。何度やっても結果は同じ。

暫く悩んでいると、思い出した。

少し前に、プロバイダーを切り替えた。今まで「玄人っぽい」という理由だけで *****.com だったが、最近になってやたらネットがブチブチ切れるようになった(気がする)ので頭に来た。プロバイダーなのか ADSL 回線なのか切り分けるため、まずはプロバイダーを plala に変えてみた。効果がなかったとしても、今より安くなるので問題ない。NTT 料金と合算できるのも良い。

試しに(検証用に残しておいた) *****.com に戻してみると、push できるようになった。SSH も、少なくとも数分で切れるということはない。もう plala 何してくれちゃってんの? それとも最近の大手プロバイダーってみんなこうなの? とか思いながら速攻 plala を解約しようと思ったら、ちょっと待った。

plala はデフォルトでフィルターが掛かっていて、会員サイトでその設定を変更できる、と。

早速「パケットフィルタレベル」を「0 (OFF)」にしたら、全ての問題が解決した。

結論: plala で自宅サーバーを立てるなら、「ネットバリア」の「パケットフィルタ」を切れ。

ちなみにネットが切れる件は、・・・あんまり変わらんかも。

2012-04-24

RHEL6: Disable screen saver on console

コンソールのスクリーンセーバーを切りたい。つまり画面がブラックアウトしないようにしたい。RHEL5 では、/etc/rc.d/rc.local に次の 1 行を入れていた。

setterm -blank 0 -powerdown 0

しかし RHEL6 では動かない。恐らく Upstart になったことで、rc.local を実行する端末が tty1 ではなくなったのだろう。方法は幾つかあるだろうが、次を参考に、

SystemV 形式の init script を登録することにする。端末を明示的に指定しているので、どの端末から実行しようと確実にコンソールに作用する。

/etc/rc.d/init.d/mytty:

#!/bin/bash
# mytty  This is the init script for tty configuration
#
# chkconfig: 2345 99 01
# description: Configures tty

# Source function library.
. /etc/rc.d/init.d/functions

# Find the name of the script
NAME=$(basename $0)
if [ ${NAME:0:1} = "S" -o ${NAME:0:1} = "K" ] ; then
    NAME=${NAME:3}
fi

start() {
    local errors=0
    echo -n "Starting $NAME: "
    local term
    for term in /dev/tty[1-6] ; do
	[ -e "$term" ] || continue
	setterm -blank 0 -powerdown 0 >$term <$term || let errors+=1
    done
    if [ $errors -eq 0 ] ; then
	success
    else
	failure
    fi
    echo
    return $errors
}

# See how we were called.
case "$1" in
    start) $1 ;;
    *) ! echo "Usage: $0 {start}" ;;
esac

この理屈でいけば、rc.local に次を書くだけでも良いが、

setterm -blank 0 -powerdown 0 >/dev/tty1 </dev/tty1

ファイルを「編集」するよりもファイルを「追加」する方が、私の好み。その方が作業の自動化という面で都合が良い。

「編集」の場合、インストール(追加)は良くてもアンインストール(削除)が難しい。人が手で同種の設定を追加していた場合、それは削除せずにそのまま残すのが望ましい(でないと「勝手に消された」と言われる)が、それを確実に判断する方法がない。「追加」の場合は、追加したファイルを削除するだけで済む。

同様の処理を Upstart (/etc/init)に登録する方法もあるが、わざわざ SystemV (/etc/rc.d/init.d)に登録するのは、RHEL5 でも動くようにするため。


2017-05-09 追記

残念ながら、以上は RHEL7 では動かない。

May 09 16:17:23 rhel7 systemd[1]: Starting SYSV: Configures tty...
May 09 16:17:23 rhel7 mytty[1357]: Starting mytty: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: setterm: $TERM is not defined.
May 09 16:17:23 rhel7 mytty[1357]: [失敗]
May 09 16:17:23 rhel7 systemd[1]: mytty.service: control process exited, code=exited status=6
May 09 16:17:23 rhel7 systemd[1]: Failed to start SYSV: Configures tty.
May 09 16:17:23 rhel7 systemd[1]: Unit mytty.service entered failed state.
May 09 16:17:23 rhel7 systemd[1]: mytty.service failed.

TERM が未定義、と言われて setterm が失敗する。これはオプション -term linux で解決できるが、

May 09 16:25:19 rhel7 systemd[1]: Stopping SYSV: Configures tty...
May 09 16:25:19 rhel7 mytty[3513]: Usage: /etc/rc.d/init.d/mytty {start}
May 09 16:25:19 rhel7 systemd[1]: mytty.service: control process exited, code=exited status=1
May 09 16:25:19 rhel7 systemd[1]: Stopped SYSV: Configures tty.
May 09 16:25:19 rhel7 systemd[1]: Unit mytty.service entered failed state.
May 09 16:25:19 rhel7 systemd[1]: mytty.service failed.

今度はシャットダウン時に未実装の stop を呼ばれて失敗する。なので stop も実装する必要がある。

以下、RHEL7 対応版。

/etc/rc.d/init.d/mytty:

#!/bin/bash
# mytty  This is the init script for tty configuration
#
# chkconfig: 2345 99 01
# description: Configures tty

# Source function library.
. /etc/rc.d/init.d/functions

# Find the name of the script
NAME=$(basename $0)
if [ ${NAME:0:1} = "S" -o ${NAME:0:1} = "K" ] ; then
    NAME=${NAME:3}
fi

start() {
    local errors=0
    echo -n "Starting $NAME: "
    local term
    for term in /dev/tty[1-6] ; do
	[ -e "$term" ] || continue
	setterm -term linux -blank 0 -powerdown 0 >$term <$term \
	    || let errors+=1
    done
    if [ $errors -eq 0 ] ; then
	success
    else
	failure
    fi
    echo
    return $errors
}

# See how we were called.
case "$1" in
    start) $1 ;;
    stop) : ;;
    *) ! echo "Usage: $0 {start|stop}" ;;
esac

2012-04-18

Animes in the 1st quarter of 2012

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

3 年目突入の頃から見ている。アニメから入って原作も読むようになったが、テンポはアニメの方が良いと思う。取りあえず一旦ここで終了ということだが、変に延命してどっかの人気アニメみたくテンポが台無しになるよりはマシ。今まで散々笑わせてもらったので、大いに満足。またいつかの復活を期待したい。

前作は私が「シャフト」を知ることになった名作。ノリはそのままなので、前作を楽しめるキャパがあるなら問題なし。しかしボリューム不足の感は否めない。話数(24 -> 12)以上に、何か足りない。前作キャラの濃さに比べると、シスターズはイマイチだった感がある。あと OP/ED も期待はずれ。尤も前作は ED が傑作過ぎたので、比べるのは酷か。

第 2 期以外は見てるが、だんだんつまらなくなってきた。初期は心温まる話が多かったが、最近は暗めのが多くないだろうか。そろそろ主人公のコンプレックスがウザい。そう何度も幼少の暗い話なんか聞きたくないっつーの。少なくとも最近のは子供に見せたいような作品じゃなくなった。まあシリーズが続く限りは見続けるとは思う。

「少女マンガ原作のアニメにハズレ無し」のジンクス通り、今期一番のアタリ。努力の正しい方向性を描いている(同種には「capeta」「モンキーターン」等がある)。子供が居るなら是非見せておきたい。ヒロインはその一生懸命さが眩しくて惚れる。中の人(瀬戸麻沙美)は初見だが、キャラに合った絶妙な配役だったと思う。OP も良で、総じて素晴らしい。

前シリーズから引き続いて熱い。なので内容に関しては特に言うことは無し。しかし今シリーズは ED が残念だった。前シリーズは ED が 2 つとも良かっただけに、今作も期待していたのだが。既に第 3 シリーズが決まっているようなので、次回に期待。

手間は掛かってそうだが、何かイマイチ。原因を考えるに、私の萌えポイントに欠けてたんだと思う。真っ先に萌えられそうなアナが男という設定が最大の敗因では。次点はエレナだが、出番が少なすぎて全然足りない。ノノハに萌えるのは、ゴメンちょっと無理だった。既に第 2 期が始まったようだが、たぶん同じ結果になりそうな予感。

何といっても京都アニメーション。OP を見るだけで只者でないセンスを感じる。しかし今回は分が悪かったか。もしくは原作(見たことないけど)のアレンジの方向性を間違えた気がする。正直、ノリがウザかった。個人的には博士・ナノ・坂本が居れば十分、他キャラの必要性を余り感じなかった。

こっちの「日常」はサンライズ。しかしこちらも役不足。わざわざ大御所が作らなくても、スクエニが自前で作った方がコスト的にも良かったんじゃないのか、と思う。有名声優は多数出ているが、キャラが声優に負けている気がするんだが。中身もおおよそつまらなかったが、文学少女とリンゴちゃんは良かった。

何かヒロインの声が好きなんだわ。えーと、石原夏織か。覚えた。前述の瀬戸麻沙美と出所が同じらしいが、演技は要練習か。話の内容は、特に盛り上がりもなく終わった。素材は良いのに、活かしきれていない感がする。あと、マルとかワンとかカシコマリーとか、推すんだったらもう少し押さないと。マルとワンは絶対に流行らんと思うけど。

不勉強ながら前作は未見。第一話で映像に魅せられた。これだけで見る価値はあった。残念ながら、話はその初回がピークで後は尻すぼみ。最後には、敵の大将は一体何がしたかったんだ、と。前作を見た輩は概ね酷評している様子だが、同意せざるを得ない。きっと前作の方がずっと面白かったに違いない。機会があれば前作を見てみたい。

集英社の圧倒的メディアミックス戦略により、漫画版は至る所で読んだ。原作は未読。何が集英社をそこまで駆り立てるのか謎。個人的に次女の中の人(喜多村英梨)に期待したが、不発。話も特に面白い訳でもない。が、これだけは認めねばなるまい。ヒナたんが可愛い・・・。ベタな狙いにまんまとハマりやがって、という侮蔑は甘んじて受けよう。

とある女子が妄想した、戦国時代を都合よく改変して自分好みのキャラと声優をいっぱい出してみました、的な。ノリも如何にも女子が好みそうで、書いた人はさぞかしハァハァしたかも知れないが、男子が見ても面白くない。個人的に、主役二人の掛け合いを受け付けない時点で終わった。

画質がいかにも J.C.STAFF。正直期待してなかったが、思ったよりは良かった。とはいえ、話から恋愛を取ったら宇宙人くらいしか残らないので、甘酸っぱい話にキュンキュンする年頃でもない私には大して効果が無い。ただ、ここでも石原夏織が登場。彼女の声にはキュンキュンする。ラグランジェよりもキャラと合っていて良い。あと、OP/ED がどちらも秀逸。

普段ホラーは見ないので、怖かったらどうしよう、と心配だったが大して怖くなくて安心。私に推理の才能は無いので、最後まで死人は分からなかった。すると困るのは、この手の話は途中に伏線が散りばめられているため、確認でもう一度見ないといけない。まあ女子キャラの絵が好みなので、もう一度見るのは問題ない。

またツンデレ主人公の話か、と思ったら存外に良かった。それぞれのキャラがいい味出してる。何といっても頻繁に出てくるデフォルメ絵が可愛い過ぎる。話の本筋をやる程つまらなくなるが、大体はバカやってるので楽しめた。OP も良。個人的に、題名にある狐キャラが一番要らなかった。

2012-04-08

SELinux: file redirection is denied

logwatch のデフォルト設定では、レポートをメールで送信する。しかし不要なサービスは起動しないのがセオリー、logwatch の為だけにメールサーバーを起動したくない。代わりにレポートを /var/log 下に保存するため、cron に下記のようなスクリプトを登録する。

#!/bin/bash
LOGWATCH=/usr/sbin/logwatch
if [ -x "$LOGWATCH" ] ; then
    mkdir -p /var/log/logwatch
    $LOGWATCH -save /var/log/logwatch/logwatch-$(date +%Y%m%d)
fi

RHEL6 でこれを実行すると、SELinux に引っ掛かる。/var/log/audit/audit.log には、

type=AVC msg=audit(1332785643.501:68869): avc:  denied  { write } for  pid=23193 comm="logwatch" name="logwatch" dev=sda5 ino=258088 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir
type=SYSCALL msg=audit(1332785643.501:68869): arch=c000003e syscall=2 success=no exit=-13 a0=3037430 a1=441 a2=1b6 a3=3f5311dba0 items=0 ppid=23178 pid=23193 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=7979 comm="logwatch" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)

logwatch_t は var_t に書き込む権限がない、と言っている。なのでやり方を変えてみる。

$LOGWATCH -print >>/var/log/logwatch/logwatch-$(date +%Y%m%d)

結果は、

type=AVC msg=audit(1332873421.565:77913): avc:  denied  { append } for  pid=4424 comm="logwatch" path="/var/local/pearl/log/logwatch/logwatch-20120328" dev=sda5 ino=258164 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1332873421.565:77913): arch=c000003e syscall=59 success=yes exit=0 a0=17cd9f0 a1=17caea0 a2=17cacf0 a3=18 items=0 ppid=4409 pid=4424 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9452 comm="logwatch" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)

じゃどうすりゃいいんだよ、と途方に暮れていると、

記事の内容は logwatch とは関係ないが、試してみる価値はある。

$LOGWATCH -print | cat >>/var/log/logwatch/logwatch-$(date +%Y%m%d)

ビンゴ。:-D

結論: ファイルにリダイレクトする際は、取りあえず cat を通しとけ。

そうすれば、SELinux に呪いの言葉を吐く回数が減る。

2012-04-05

RHEL6: JDK: /lib/ld-linux.so.2: bad ELF interpreter

RHEL6 に JDK をインストールしようとすると、エラーが発生。

[rhel6]# ./jdk-6u31-linux-i586.bin
Unpacking...
Checksumming...
Extracting...
./jdk-6u31-linux-i586.bin: ./install.sfx.10908: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Failed to extract the files.  Please refer to the Troubleshooting section of the Installation Instructions on the download page for more information.

Google 先生によると、ld-linux.so.2 は libstd++ パッケージに入っているらしい。

[rhel6]# rpm -q libstdc++
libstdc++-4.4.6-3.el6.x86_64

既に入ってますが。RHEL5 ではどうだったかというと、

[rhel5]# rpm -q libstdc++
libstdc++-4.1.2-46.el5
libstdc++-4.1.2-46.el5

ああ、分かった。64bit OS に 32bit JDK を入れようとしたからだ。つまり、

  • 64bit RHEL に 32bit JDK を入れる場合、32bit libstdc++ パッケージが必要。
  • 64bit RHEL5 には 32bit libstdc++ が入っているが、64bit RHEL6 には入っていない。

ならば RHEL6 DVD から入れれば解決・・・、

[rhel6]# rpm -ivh libstdc++-4.4.6-3.el6.i686.rpm
warning: libstdc++-4.4.6-3.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
        ld-linux.so.2 is needed by libstdc++-4.4.6-3.el6.i686
        ld-linux.so.2(GLIBC_2.3) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6 is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.0) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.1) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.1.3) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.2) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.3) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.3.2) is needed by libstdc++-4.4.6-3.el6.i686
        libc.so.6(GLIBC_2.4) is needed by libstdc++-4.4.6-3.el6.i686
        libgcc_s.so.1 is needed by libstdc++-4.4.6-3.el6.i686
        libgcc_s.so.1(GCC_3.0) is needed by libstdc++-4.4.6-3.el6.i686
        libgcc_s.so.1(GCC_3.3) is needed by libstdc++-4.4.6-3.el6.i686
        libgcc_s.so.1(GCC_4.2.0) is needed by libstdc++-4.4.6-3.el6.i686
        libgcc_s.so.1(GLIBC_2.0) is needed by libstdc++-4.4.6-3.el6.i686
        libm.so.6 is needed by libstdc++-4.4.6-3.el6.i686
        libm.so.6(GLIBC_2.0) is needed by libstdc++-4.4.6-3.el6.i686

依存関係が うぜえ。速攻で諦めて、素直に 64bit JDK を入れることにした。

JDK はサイズが大きいから自作インストールメディアに 32bit 版と 64 bit 版の両方を入れるのが嫌だったが、諦めた。現場 SE が自力で libstdc++ を入れられると期待するほど、私はお人好しじゃない。


2017-05-07 追記

今まで放ったらかしにしておいて申し訳ないが、このエントリは嘘です

Google 先生によると、ld-linux.so.2 は libstd++ パッケージに入っているらしい。

当時のことを思い出せるはずもないが、実際に JDK が動作するシステムで下記のように調べれば、

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.8 (Santiago)

# rpm -q --whatprovides /lib64/ld-linux-x86-64.so.2
glibc-2.12-1.192.el6.x86_64

ld-linux.so.2 は glibc パッケージに入っていることが分かる。glibc であれば、依存関係は(私の環境では) nss-softokn-freebl だけになる。それに OS メディアがあるなら、複雑な依存関係であったとしても、yum に解決してもらえる。

# yum -c /media/media.repo --setopt InstallMedia.baseurl=file:///media install glibc.i686
Setting up Install Process
InstallMedia                                             | 4.1 kB     00:00 ...
InstallMedia/primary_db                                  | 3.1 MB     00:03 ...
Resolving Dependencies
--> Running transaction check
---> Package glibc.i686 0:2.12-1.192.el6 will be installed
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.192.el6.i686
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.192.el6.i686
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.14.3-23.el6_7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                 Arch      Version              Repository         Size
================================================================================
Installing:
 glibc                   i686      2.12-1.192.el6       InstallMedia      4.4 M
Installing for dependencies:
 nss-softokn-freebl      i686      3.14.3-23.el6_7      InstallMedia      157 k

Transaction Summary
================================================================================
Install       2 Package(s)

Total download size: 4.5 M
Installed size: 14 M
Is this ok [y/N]: y
Downloading Packages:
--------------------------------------------------------------------------------
Total                                           4.7 MB/s | 4.5 MB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : glibc-2.12-1.192.el6.i686                                    1/2
  Installing : nss-softokn-freebl-3.14.3-23.el6_7.i686                      2/2
  Verifying  : nss-softokn-freebl-3.14.3-23.el6_7.i686                      1/2
  Verifying  : glibc-2.12-1.192.el6.i686                                    2/2

Installed:
  glibc.i686 0:2.12-1.192.el6

Dependency Installed:
  nss-softokn-freebl.i686 0:3.14.3-23.el6_7

Complete!

2012-04-02

diff RHEL5/samba RHEL6/samba

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 だったら気付けたのかも。