Serversman@VPS yum updateと対策

Serversman@VPSでyum updateを実施した

久しくと言っても、2011-9月にyum updateを実施しているが、その直前では、updateを行うと、BlueOnyxがことごとく文字化けして使いもにならなかったので、やむなく元に戻した苦い経験がある。
その直後にupdateされたパッケージを使うと比較的まともに使えたので、しばらく、これで行こうと思って運用していたのだが、どうも、サーバー負荷が 異様に上がってしまって、どうにも、原因不明なところが多いので、今回、思い切って、Serversman@VPSのyum updateを実施することにした。
Serversman@VPS+BlueOnyxな環境でアップデートをするか否かを迷っているユーザー向けに、yum updateを実施した場合の現象とその後の後始末に関して、書いておく。

yum updateを実施した日は、11月2日で、その後、新しいupdateは、なさそうなので、近い時期にアップデートされたいユーザーの環境とほぼ、同程度の内容になると思われる。

前提条件
Serversman@VPS Standard+エンジニアセット

【アップデートで起こる種々の動作不良に関して】

今回のアップデートでは、以下の問題が起こった

  1. iptable(FW)の自動リセット
  2. Serversman管理画面(WebDAV)への接続不良
  3. 自前で準備しているapache WebDAVへの接続不良
  4. sendmail clientの起動トラブル

全て、既出な内容で、対処は比較的簡単なので、以下の手順によって修復すると良い。
また、今回のアップデートを実施しても、重大なトラブルには、ならなかった点を明記しておきたいと思う。

【正常動作の範囲】

  1. BlueOnyxへの正常な接続
  2. httpdの正常起動
  3. sendmailの正常起動
  4. その他の重大な不具合なし

※何処が、どのようにFixされているかについては、BlueOnyxNewsを参照

【不具合対策と後始末】

1)iptablesのオートリセットへの対策

<原因>
/etc/cron.hourly/log_traffic が何らかの原因でリセットされてしまいiptable内容が、log_traffic内の再設定スクリプトへ反映されない。

<対策>
このプロセスは、本来、iptablesのカウンターリセットなどを実施しているのだが、特に必要なプロセスとは考えない場合、このlog_trafficを適当なディレクトリに移動させて動作をしないようにしておく。
# mkdir /root/cron.remove
# mv /etc/cron.hourly/log_traffic /root/cron.remove/
または、log_traffic内の再設定スクリプトへ自分のiptables内の設定内容を反映させる。
筆者の場合、プロセス自体を退避させたが、問題はない。むしろ、iptablesの内容を変更するにあたって、2ヶ所も直さなくてはならなくなるので、要らぬお世話でもある。

2)Serversman管理画面(クラウド)が起動しない

<原因>
/etc/httpd/conf/httpd.conf
が書き換えられてしまうため、cgiで動作しているserversman管理画面が起動しない。

<対策>
/etc/httpd/conf/httpd.conf内の以下の箇所のコメントを外す。
#
# ScriptAlias: This controls which directories contain serverscripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applicationsand
# run by the server when requested rather than as documents sent tothe client.
# The same rules about trailing “/” apply to ScriptAlias directivesas to
# Alias.
#
#ScriptAlias /cgi-bin/ “/var/www/cgi-bin/”  ←赤い#を 外し有効化する

変更
ScriptAlias /cgi-bin/ “/var/www/cgi-bin/”
#
# “/var/www/cgi-bin” should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
# <Directory “/var/www/cgi-bin”>
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

※この件は、既出だが、改めて記載した。

3)自前で立てたapache WebDAVが動作しない(書き込み不可)

<原因>
/var/lib/dav にあるロックディレクトリのオーナー・グループが、apacheへ変更されてしまうので、ファイルアクセス時に、ファイルロックが反映されず、書き込みができなくなってしまう。

<対策>
/var/lib/davのオーナー・グルーブをdaemonへと変更する。
# cd /var/lib
# chown daemon:daemon dav

4)sendmail clientが起動しない

<原因>
再起動のタイミングで、運が悪く、先の、log_trafficが実行された後であると、mail clientプロセスが起動しない。

<対策>
1)のiptablesの対策を実施すれば、起動するようになる。

概ねのところ、以上のとおり。

【参考】
今回のyum update対象

Packages Updated:
    base-sitestats-scripts-1.0-26BX23.centos5.noarch
    base-email-locale-de_DE-1.5.1-0BX10.centos5.noarch
    base-email-locale-da_DK-1.5.1-0BX10.centos5.noarch
    base-email-glue-1.5.1-0BX10.centos5.noarch
    base-network-glue-1.1.0-82BX34.centos5.noarch
    postgresql-libs-8.1.23-1.el5_7.2.i386
    1:mod_ssl-2.2.3-53.el5.centos.3.i386
    base-email-locale-en-1.5.1-0BX10.centos5.noarch
    httpd-2.2.3-53.el5.centos.3.i386
    base-email-ui-1.5.1-0BX10.centos5.noarch
    rpm-python-4.4.2.3-22.el5_7.2.i386
    python-2.4.3-44.el5_7.1.i386
    base-network-ui-1.1.0-82BX34.centos5.noarch
    base-snmp-locale-de_DE-1.0.2-1BX02.centos5.noarch
    base-network-locale-da_DK-1.1.0-82BX34.centos5.noarch
    rpm-4.4.2.3-22.el5_7.2.i386
    base-network-capstone-1.1.0-82BX34.centos5.noarch
    base-network-locale-ja-1.1.0-82BX34.centos5.noarch
    nss_ldap-253-42.el5_7.4.i386
    base-email-capstone-1.5.1-0BX10.centos5.noarch
    libxml2-2.6.26-2.1.12.el5_7.1.i386
    base-snmp-capstone-1.0.2-1BX02.centos5.noarch
    base-network-locale-de_DE-1.1.0-82BX34.centos5.noarch
    base-network-locale-en-1.1.0-82BX34.centos5.noarch
    tzdata-2011l-4.el5.i386
    popt-1.10.2.3-22.el5_7.2.i386
    pango-1.14.9-8.el5.centos.3.i386
    openldap-2.3.43-12.el5_7.9.i386
    base-email-locale-ja-1.5.1-0BX10.centos5.noarch
    base-snmp-ui-1.0.2-1BX02.centos5.noarch
    rpm-libs-4.4.2.3-22.el5_7.2.i386
    libxml2-python-2.6.26-2.1.12.el5_7.1.i386
    freetype-2.2.1-28.el5_7.1.i386
    base-snmp-locale-ja-1.0.2-1BX02.centos5.noarch
    httpd-manual-2.2.3-53.el5.centos.3.i386
    base-snmp-glue-1.0.2-1BX02.centos5.noarch
    base-snmp-locale-en-1.0.2-1BX02.centos5.noarch
    python-libs-2.4.3-44.el5_7.1.i386
    libX11-1.0.3-11.el5_7.1.i386
    base-snmp-locale-da_DK-1.0.2-1BX02.centos5.noarch
    base-disk-am-1.1.0-15BX24.centos5.i386

追記)
このようなアップデートを実施する場合、毎回、十分な監視を行わないとならず、大変なのだが、筆者の場合、内容によって、アップデートを手動で行なっている。
このような場合、Serversman@DISK (10GB 210円/月:2011-11月現在)を契約しておくと、システム全体のバックアップが可能になるので、そこにバックアップを実施した後に、yum updateを実行することにしている。
ただ、運悪く、リストアをしなくてはならなくなったときは、リストアせざるを得ないのだが、このリストア機能というのも曲者で、MyDTI管理画面から、 リストアを実行して、システム自体のリストアが完了しても、稀に(いつも?)sendmailが文句をいって起動しなくなる。原因は、sendmailに 関係する設定ファイルのパーミッションが規定ではないときに、

sm-client を停止中:                                        [失敗]
sendmail を停止中:                                         [失敗]
sendmail を起動中: 451 4.0.0 /etc/mail/sendmail.cf: line 105: fileclass: cannot open ‘/etc/mail/local-host-names’: World writable directory
451 4.0.0 /etc/mail/sendmail.cf: line 158: fileclass: cannot open ‘/etc/mail/virthosts’: World writable directory
451 4.0.0 /etc/mail/sendmail.cf: line 609: fileclass: cannot open ‘/etc/mail/trusted-users’: World writable directory
                                                           [失敗]
sm-client を起動中: /etc/mail/submit.cf: line 544: fileclass: cannot open ‘/etc/mail/trusted-users’: World writable directory
                                                           [失敗]

などのエラーを吐き出す。
ネットをぶらつくと、この件に対する様々なディスカッションがあるのだが、要は、上記にあるいずれかのファイルのパーミッションが、’何処からでも変更で きる状態になってますよ’と警告を発して、起動していないだけなのだが、いずれのパーミッションを見ても、そんなことはないよ、ちゃんと規定通りにしてい るよ。と思ってしまい、神経質な筆者のようなユーザーは、リストアできてないじゃんって、憤慨して、サーバーを再構築した経験すらある。

結論からすると、それらのファイルが、やはり、そのようなパーミッションになっていたのである。
種明かしをすると、なんと、/. つまり、自分が使っているサーバーのルートパーミッションが、777となっていて、そこを直さない限り、永遠とジレンマに陥るのである。
「えぇ~??マジ??」って、気がついたときには、なんか、ものすごい脱力感があったものである。
なんてことはない。
# cd /
# chmod 755 .
これを実行すれば、良いだけなのだ。
しかし、いい加減にしろと、言いたくなるようなVPSならではの不具合なのである。
これには、まいった。
本来、余談で記述するような内容ではないが、同様に困っているユーザーも多いはず。
なにをしても、ダメと思ったら、ls -la / あたりを実行してみて、もし、.(ドット)が777なんかになっていたら、呪文を唱えると良いだろう。