何をしたいかというと、アクセスが有った際に管理者に通知が届くようにしたい。
不正アクセスの把握にも役立つので、設定は必須。

どの様に設定を行えばよいかというと、通常の設定ではhosts.allowに

sshd :xxx.xxx.xxx.xxx ←　実際にはアクセスさせるIPアドレスを記述

こんな感じでアクセスを許可させるが、設定した内容でアクセスが有った場合、管理者へメール通知することが出来る。

具体的にはこんな感じ

sshd :xxx.xxx.xxx.xxx　:spawn (/usr/sbin/safe_finger -l @%h | /usr/bin/Mail account@hogehoge.jp -s "[tcpd] Access from %h to %s") &

こんな感じで記述すると、アクセスが有るたびに、access元のIPが記載されたメールが飛んでくる・・・

意外と、便利！！

Unable to open pty: No such file or directory

ファイルまたは、ディレクトリが無いだと！！

この「Unable to open pty: No such file or directory」でGoogle先生に聞いてみると、以外に多くのページがHITした。

説明によると、udevとの相性がわるいらしい・・・
では、何故今までログインできて、突然ログインできなくなったのか？
サーバの設定も変えた覚えもないし・・・　意味が分からない。

とにかく、ログイン出来るように対処方法が出ていたので、実行してみた。

エラーの内容では「Unable to open pty」となっていたので

/usr/sbin/vzctl exec CTID(CTの番号) /sbin/MAKEDEV pty　
とだけ実行したがだめ。

念のため、

/usr/sbin/vzctl exec CTID(CTの番号) /sbin/MAKEDEV tty
も実行してみた。

この2つを実行することで、ログイン出来るようになった。

しかし、サーバを再起動すると、同じ現象になってしまう。
では、継続して利用出来るようにするためには、どの様にすれば良いのか、再度Google先生に聞いてみた。

サーバ起動時に、udevを利かないように設定すればいいらしい。
って事で、早速やってみた。

先ず、
/usr/sbin/vzctl exec CTID(CTの番号) /sbin/MAKEDEV pty　
/usr/sbin/vzctl exec CTID(CTの番号) /sbin/MAKEDEV tty

を打って、

vzctl enter CTID(CTの番号)
で、対象CTにログインする。

そして
/etc/rc.sysinit　の
#/sbin/start_udev　　←　コメントアウトする

そして
/sbin/start_udev　を実行

念のため
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty
も実行して〜　再起動！！

起動後に
vzctl enter CTID(CTの番号)
でログインできることを確認。

そして
ssh root@CTのIPアドレス
にて、SSH接続を確認。

これで、何度再起動してもOKになったが、何故udevとの相性問題が出たのか、意味が分からない・・・・

■参考サイト
http://www.eukhost.com/forums/f29/vps-unable-open-pty-no-such-file-directory-2666/

今までも、起動スクリプトは作成していたが、都度作成していたので、応用の利きそうなものを作成してみた。

++++++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
#
# デーモン名
#
# chkconfig: 345 99 01　　←　用途や依存関係に気をつけて値を決める
# processname: デーモンName
# description: 適当に・・・ｗ

PROG=/usr/local/bin/XXXXXXXX
PROGNAME=XXXXXXXX
LOCKFILE=/var/lock/subsys/$PROGNAME

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

RETVAL=0

# Get config.
. /etc/sysconfig/network

# Check that networking is up.
if [ ${NETWORKING} = "no" ]
then
exit 0
fi

start() {
echo -n "Starting $PROGNAME services: "
daemon $PROG -p 1022 &
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch $LOCKFILE
return $RETVAL
}

stop() {
echo -n "Stopping $PROGNAME services: "
killproc $PROGNAME
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f $LOCKFILE
return $RETVAL
}

# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $PROGNAME
;;
restart|reload)
stop
start
;;
*)
echo "Usage: $PROGNAME {start|stop|status|restart}"
exit 1

esac

exit $RETVAL
++++++++++++++++++++++++++++++++++++++++++++++++

これをフォーマットにすれば、余計な時間を取られずに済むな・・・・

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead in /var/www /html/eccube/data/class/util/GC_Utils.php on line 221

こんな感じのエラーだったが、Google先生に確認すると、直ぐに対策が解った。

今回のサーバでは、CentOS5.7+PHP5.3.8の構成でエラーが出た。
php.iniに細工をすると直るらしい。

修正箇所は以下のとおり。

php.ini の [Date] セクションにtimezoneを設定するだけ。

[Date]
date.timezone = Asia/Tokyo

そしてApache再起動！

php5.1とかではこんな設定したことなかったけど、EC-CUBE側の仕様変更なのかな？？？

バーチャルドメインのログを見ても、それらしきものは残っていない〜

coreが吐かれていたので、内容を確認したが以前と同じ・・・
(gdb) where
#0 0xb7bca697 in memset () from /lib/libc.so.6
#1 0xb7e987ab in apr_password_validate () from /usr/lib/libaprutil-1.so.0
#2 0xb7843bda in __cxa_finalize () from /etc/httpd/modules/mod_authn_file.so
#3 0xb7f11c6e in __cxa_finalize () from /etc/httpd/modules/mod_auth_basic.so
#4 0xb7f52a0d in ap_run_check_user_id ()
#5 0xb7f53d17 in ap_process_request_internal ()
#6 0xb7f6763b in ap_process_request ()
#7 0xb7f643ef in ?? ()
#8 0xb7f5fa0d in ap_run_process_connection ()
#9 0xb7f5fb0c in ap_process_connection ()
#10 0xb7f6c694 in ?? ()
#11 0xb7f6c9a1 in ?? ()
#12 0xb7f6d3a3 in ap_mpm_run ()
#13 0xb7f43157 in main ()

怪しいのは
mod_auth_basic.so
mod_authn_file.so

ここのところ、phpMyAdminに対しもログが残っている。
ｐｈｐMyAdminのディレクトリにはベーシック認証を施している。
もしかすると、ベーシック認証を破る攻撃がなされば場合にApacheに不具合が出るのかもしれない。
しかし、ググッてもそれらしき情報が無いため、対策が打てない！
地道に攻撃元IPをブラック化（iptablesで破棄）するしか無いだろうな〜〜

[Tue Nov 08 02:08:31 2011] [notice] child pid 27500 exit signal Segmentation fault (11)

しかし、swatchで感知しないｗ
設定ファイルには　watchfor /signal Bus error (7)|signal Segmentation fault (11)/　のように記述しているが。。。。
何か、問題でも？？

って事で、watchfor /signal Bus error|signal Segmentation fault/　こんな感じにしてみた。

それと、昔NICが死んでしまう現象があり、その時にお対策を行った事が有ったが、logrotateする際に、古いLogDATAを読み続けてしまう現象が有った。
今回のLogはApacheのログなので、logrotateした後にswatchを再起動するようにして、logrotateした後の新しいLogを参照するように追記してみた。

------------------------------------------------------------------------------------------
/var/log/httpd/*log {
weekly
rotate 13
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
------------------------------------------------------------------------------------------
↓　↓　↓
------------------------------------------------------------------------------------------
/var/log/httpd/*log {
weekly
rotate 13
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
/etc/rc.d/init.d/swatch restart　　←　ここ
endscript
}
------------------------------------------------------------------------------------------

これで、再度様子みてみようか・・・

ちょっと時間が有ったので、ここ最近追加したドメインの配下を見てみたら、htdocsの下にcoreが吐かれてる。
findで検索すると、他のドメインでもcoreが吐かれてるドメインが有る。

今度、エラーが出てSwatchでApacheが再起動すればメールが飛んでくる。
そのタイミングで、各ドメイン配下にcoreが有るか確認すれば、追求出来るかも！！
※ドメイン配下に有ったcoreは調査する前に削除していたので、次回発生しないと調べられないｗ

って事で、
child pid XXXX exit signal Segmentation fault (11)
とか
child pid XXXX exit signal Bus error (7)
を吐いたら、Apacheを再起動するようにしてみた。

早速、swatchを導入。
通常 /root/.swatchrc に記述するようになっているが、これでは管理しにくいので、 /etc/swatch に設定ファイルを置いて動くようにしてみた。

# mkdir /etc/swatch
# cd /etc/swatch
# vi error_log.conf
----------------------------------------------------------------------------------------
#logfile: /var/log/httpd/error_log

watchfor /signal Bus error (7)|signal Segmentation fault (11)/
echo
mail admin@hogehoge.jp,subject=[Alert] Apache Restart!!
exec /etc/rc.d/init.d/httpd restart
----------------------------------------------------------------------------------------

こんな感じで設定。
swatchは標準で起動スクリプトが用意されていないので、色々調べてこんな感じで作ってみた。

----------------------------------------------------------------------------------------
#!/bin/sh
#
# Swatch
#
# chkconfig: 345 90 35
# description: swatch log monitoring
#

SWATCH=/usr/bin/swatch
LOCKFILE=/var/lock/subsys/swatch
CONFPATH=/etc/swatch
PROCFILE_PATH=/var/run
CONFFILE=*.conf
WORKPATH=/tmp
LOGFILE=/var/log/swatch/swatch.log

. /etc/rc.d/init.d/functions

start()
{
RESULT_CODE=0

if [ -f ${LOCKFILE} ]; then

echo "Swatch is already running."
exit 1

else

touch ${LOCKFILE}

fi

PROCCOUNT=0

for CONFIGFILE in ${CONFPATH}/${CONFFILE}
do
if [ -f ${CONFIGFILE} ]; then

PROCCOUNT=`expr ${PROCCOUNT} + 1`

TARGET_LOG=`head -1 ${CONFIGFILE} | awk 'BEGIN { FS = ":" }; { sub(/([ \t]+$|^[ \t]+)/, "", $2); print $2 }'`

echo -n "Starting swatch: ${TARGET_LOG}: "

daemon ${SWATCH} \
--config-file ${CONFIGFILE} \
--tail-file ${TARGET_LOG} \
--script-dir=${WORKPATH} \
--awk-field-syntax \
--daemon \
--pid-file ${PROCFILE_PATH}/swatch.${PROCCOUNT}.pid \
2>> ${LOGFILE}

RETVAL=$?
echo

if [ ${RETVAL} != 0 ]; then

RESULT_CODE=${RETVAL};

fi

else

RESULT_CODE=7

fi

done

return ${RESULT_CODE}
}

stop()
{
if [ -f ${LOCKFILE} ]; then

for PID in ${PROCFILE_PATH}/swatch.*.pid
do
if [ -f ${PID} ]; then

PID_NUMBER=`cat ${PID}`

echo -n "Shutting down swatch (pid ${PID_NUMBER}): "

killproc -p ${PID}
RETVAL=$?

rm -f ${PID}

echo

else

RETVAL=7

fi

done
fi

rm -f ${LOCKFILE}
rm -f ${WORKPATH}/.swatch_script.*

return ${RETVAL}
}

status()
{
if [ -f ${LOCKFILE} ]; then

echo -n "Swatch (pid :"

for PID in ${PROCFILE_PATH}/swatch.*.pid
do
if [ -f ${PID} ]; then

echo -n " `cat ${PID}`"

fi

done

echo ") is running."

else

echo "Swatch is stopped."

fi

return 0
}

case "$1" in

start)
start
RETVAL=$?
;;

stop)
stop
RETVAL=$?
;;

restart)
stop
start
RETVAL=$?
;;

status)
status
RETVAL=$?
;;

*)
echo "Usage: swatch {start|stop|restart|status}"
exit 1
esac

exit ${RETVAL}
----------------------------------------------------------------------------------------

これを
chkconfig --add swatch
して
service swatch start
して
chkconfig swatch on
こんな感じ！

これで、ちょっと様子見だな。

coreを吐いた時刻付近のログを調べたいが、150以上のドメインのログを見ていくのは辛い。
そこで、何か良い案は無いかと、知恵を絞ってみた。

　grepコマンドで絞れそうな気がしてきた

現在、バーチャルドメインのディレクトリは /home/virtualdomain/ドメイン名　としている。　その配下にlogsを作成し、ドメインごとのログを取っている。
ターゲットは/home/virtualdomain/ドメイン名/logs/error.log　だ！

多分こんな感じで行けるのかな？？　と、やってみたら簡単に抽出できた。

grep "Wed Nov 02 06:52" /home/virtualdomain/*/logs/error.log

コンソールにはズラズラズラと出るが、分かり難い

そこで、抽出したデータを/tmp/error.dumpに書きだしてみる。

grep "Wed Nov 02 06:52" /home/virtualdomain/*/logs/error.log > /tmp/error.dump

すべてのドメインの　error.log から、"Wed Nov 02 06:52"にHITするものが一目で見られるが、それらしきエラーは無い！
時間を変更して抽出しても、怪しい書き込みが無い・・・・

あらら。。。　お手上げだ〜〜〜

複数のドメインを管理しているため、ログは各ドメイン配下に書き込まれる。
大元のログには、上記内容のみの記述しか書き込まれない・・・・

頻繁に発生するので、coreを吐かせるように設定してみた。

先ずは、ulimit設定確認

# ulimit -a
core file size (blocks, -c) 0　　←　ここ
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 143360
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 143360
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

これでは、ダメなので　/etc/profile　の値を書き換えて、無制限にしてみた。

# ulimit -a
core file size (blocks, -c) unlimited ←　ここ
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 143360
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 143360
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

apacheの設定に下記の記述を追加
CoreDumpDirectory /tmp

そして、Apache再起動
これで、準備OK！！

数日経ったある日、Apacheが死にやがった！
/tmpにはcore.XXXXが複数存在する。

このデータは生の状態では見られないので、gdbコマンドで見る必要が有る。

gdbコマンドはこんな感じで実行する。

gdb -c <(core)file>

それでは、実際に見てみよう
gdb /usr/sbin/httpd -c /tmp/core.28778

ずらずらずら〜〜〜っと出てきて、意味不明ｗ
そこで　where　と打ってみると、見やすくなるらしい

(gdb) where
#0 0xb7b8f697 in memset () from /lib/libc.so.6
#1 0xb7e5d7ab in apr_password_validate () from
/usr/lib/libaprutil-1.so.0
#2 0xb7808bda in __cxa_finalize () from
/etc/httpd/modules/mod_authn_file.so
#3 0xb7ed5c6e in __cxa_finalize () from
/etc/httpd/modules/mod_auth_basic.so
#4 0xb7f17a0d in ap_run_check_user_id ()
#5 0xb7f18d17 in ap_process_request_internal ()
#6 0xb7f2c63b in ap_process_request ()
#7 0xb7f293ef in ?? ()
#8 0xb7f24a0d in ap_run_process_connection ()
#9 0xb7f24b0c in ap_process_connection ()
#10 0xb7f31694 in ?? ()
#11 0xb7f319a1 in ?? ()
#12 0xb7f323a3 in ap_mpm_run ()

意味はわからないが、ベーシック認証系のエラーっぽい。
確かに、動的データが死んだ時は、ベーシンク認証でID&PASSが通らない。

何故、こんなエラーがでるんだ？？

そんな時にGoogle先生に聞いてみたら、
http://blog.daisukeyamashita.com/post/1714.html
に、よさそうな記事が！

何をするわけでは無いが、新たにネットワーク環境を作成するだけで、劇的に速くなると言う
早速試してみる。

[システム環境]→[ネットワーク]→[ネットワーク環境：ネットワーク環境を編集...]→[＋]→[適当な名前で作成]
元々「自動」となっていたので、今回は「手動」と言う名称で作ってみたした。

設定後、リンク速度を計測すると、９０M超え！

なんで、これだけで速くなるの？　　って言うくらいに早くなります。

初期設定では、何かがバグってるのかっもしれませんね