2009-10-08

cmdagent.exe の CPU使用率が99%に

緊急(?)公開メモ。

それは突然やってきた。何をやるにしても重い。ほぼ操作不可能。
タスクマネージャを開くことも、ソフトウェアリセットもままならない。
幾度かのハードウェアリセットの直後に原因を探っていくことに･･･

イベントマネージャで履歴を確認したりした後に、タスクマネージャを開いて診てみると、「cmdagent.exe」がCPUをほぼ100％占有している。
しかしこやつは「プロセスの終了」も受け付けない。

貴様は何者だぁ〜？

調べてみると、"COMODO Internet Security"のプロセスのようだ。

どうやら自動アップデートのアンチウィルスデータベースになんらかの不具合があったようです。

対策としては、
１．COMODO Internet Securityをいったんアンインストール
２．再起動
３．最新のCOMODO Internet Securityをダウンロードして再インストール
Comodo Firewall | Get Best Free Personal Firewall Software

以上。

対策参考：What the Tech | Your Place for Tech Questions

本家バグレポート：Loginには他の対策方法も紹介されています。

2009-05-20

CentOS 5.x の logrotate で postrotate を無視するバグが直ってるっぽい

インターネットサーバ構築

CentOS 5.2 の logrotate (logrotate-3.7.4-8) で postrotate 内のスクリプトを実行しないバグが、CentOS 5.3 の logrotate-3.7.4-9 で直ってるっぽいです。logrotate の挙動には悩まされたので、公開メモ。

Apache の access_log や error_log などを日次で rotate して日付を付けて gzip で圧縮している (したい) 方は多いと思います。下記のように postrotate 内のスクリプトで個別にもろもろ処理をしたいが、先のバグのため dateext 等の指定や自作スクリプトなどで対処していらっしゃる方もまた多いのではないでしょうか?

$ cat /etc/logrotate.d/httpd
/home/*/logs/*log {
    daily
    rotate 180
    create
    ifempty
    missingok
    <略>
    sharedscripts
    postrotate
        EXT=`date -d '1 day ago' +%Y%m%d`
        for F in $1; do
        mv $F.1 $F.$EXT
        <その他もろもろ略>
        done
    endscript
}

古いバージョンや他系列のバージョンなら機能するという logrotateのバグや CentOS 5.2 の Logrotate などの貴重な情報もあります。それが CentOS 5.3 の logrotate-3.7.4-9 (09-Mar-2009 10:46) では修正されたようです。なんか postrotate 内が動いてないんじゃ ?? とお悩みの方は、以下の検査方法で切り分けできるかと。

【検査方法】
1. テスト用ディレクトリ作成:

$ mkdir -p /tmp/test_log/1 /tmp/test_log/2

2. テスト用設定ファイル (/tmp/test_log/config) 作成:

$ vi /tmp/test_log/config
/tmp/test_log/*/*_log {
    rotate 3
    compress
    missingok
    create
    sharedscripts
        postrotate
        echo $1
    endscript
}

3. テスト用ログ作成:

$ echo "hi" | tee /tmp/test_log/1/access_log > /tmp/test_log/2/error_log

4. テスト実行

$ logrotate -f /tmp/test_log/config

5. テスト結果確認
空行だけしか出力されなければ postrotate は機能してません。

$ /tmp/test_log/1/access_log /tmp/test_log/2/error_log

と表示されれば機能しています。

上記検査方法(再現方法)は、Bug 241766 – Logrotate ignores pre/postrotating scripts arguments （調査依頼書としてお手本にしたい簡潔明瞭さです。）を参考にワイルドカードもきちんと処理されるかを確認できるようにちょっとだけ変更。

【アップデート】

$ cd /usr/local/src
$ wget http://ftp.riken.jp/Linux/centos/5.3/os/i386/CentOS/logrotate-3.7.4-9.i386.rpm
$ rpm -Uvh logrotate-3.7.4-9.i386.rpm

上記 3.4.5.で再検査。

6. (後片付けするなら)

$ rm -fR /tmp/test_log

【※注意※】
ただし、かの logrotate には他にもいろいろバグがあるようで (参考1,2,3) それらが全て logrotate-3.7.4-9 で直っているかは確認していません。さらに Bug 445554 – Logrotate ignores pre/postrotating scripts arguments には、"Regression (退行)" している部分があるとの指摘もありますので、お約束で恐縮ですがくれぐれも各自の用途に沿った選択と自己責任でお願いいたします。

参考1：logrotateのバグ修正および機能拡張アップデート
参考2：https://bugzilla.redhat.com/buglist.cgi?component=logrotate&product=Red%20Hat%20Enterprise%20Linux%204
参考3：https://bugzilla.redhat.com/buglist.cgi?component=logrotate&product=Red%20Hat%20Enterprise%20Linux%205

2009-05-19

CentOS で日本語man jman を使う

インターネットサーバ構築

CentOS 5.2 で日本語の man が既に使えるようになっていたので、使い方のメモ。

(CentOS でというより、筆者の契約サーバには既に入っていたというべき話なのかもしれない??)

/usr/share/man/ 配下を見ると各国語用ディレクトリがすでに用意されていた。
西欧諸国などに混じって、sk (スロバキア) はあるのに si (スロベニア) はないみたいなナゾナゾっぽい基準が筆者には良くわからないが、さておいて ja にはかなりの man ファイルが入っている。

$ ls /usr/share/man/ja/
man1  man2  man3  man4  man5  man6  man7  man8  man9 ← 全てのセクションが揃っているようだ
$ find /usr/share/man/ -type f | wc -l
9397 ← 全ての man ドキュメント数
$ find /usr/share/man/ja/ | wc -l
2642 ← 日本語 man ドキュメント数

これらの日本語 man ページの出所は、http://www.linux.or.jp/JM/ さん、Japanese Manual Project for FreeBSD さん、NetBSD jman さん等々からの恩恵なのかな??。経緯詳細は不明ですが多くのボランティアの方々のご尽力に感謝しつつ、せっかくあるので使ってみる。

FreeBSD 等々には jman というコマンドがあるらしいが、筆者の環境 CentOS では環境変数 LANG に応じて man が判断して表示するらしいので早速試用。

$ env LANG=ja_JP.UTF-8 man ls

おおおぅ♪
これまでの異邦人のような落ち着かない気分が、田舎のオラが村に帰ってきたような"ほのぼの"気分に･･･

なかなか良いので .bashrc で alias に登録。

alias jman='env LANG=ja_JP.UTF-8 man'

ログインしなおして、その後は jman [xx] で都度"ほのぼの"。

2009-05-17

DenyHosts の働きで SSHでログインできなくなってしまった

インターネットサーバ構築

不正侵入防止のために DenyHosts を設置している。

DenyHosts は、セキュリティログを監視して (筆者の環境 CentOS 5.2では/var/log/secure) 不正ログインを試みた痕跡があった場合に、/etc/hosts.deny (TCP wrapper によるアクセス規制リスト) に規制する IP を自動で追加してくれる。

設定ファイル (/etc/denyhosts/denyhosts.cfg) はデフォルトのもの (/usr/share/doc/denyhosts-2.6/denyhosts.cfg-dist相当) で必要十分に機能するようになっているが、筆者はさらに以下などのようにして少しばかり厳しくしている。

PURGE_DENY =                 ←2度とログインを受け付けない…
BLOCK_SERVICE = ALL          ←全てのサービスで…
DENY_THRESHOLD_INVALID = 1   ←1度でも…
DENY_THRESHOLD_VALID = 1     ←1度でも…
DENY_THRESHOLD_ROOT = 1      ←1度でも…しくじったら。

正しい意味は、本サイト http://denyhosts.sourceforge.net/faq.html 等々でご確認くださいね(^^;)

それがきちんと機能した…

FTP をスーパーデーモン (xinetd) 経由の起動に変更したので、念のため nmap などを使ってセキュリティ監査をしていたら、DenyHosts から報告メールが届いた。見覚えのあるIP。なんと自IPが蹴られるようになってるじゃないか…。(DenyHosts はきちんと働いてくれている。アンポンタン筆者の予見力がきちんと働いていない。)

筆者の設定では、1度でも不正アクセスを試みた IP からは hosts.deny を参照する全てのサービスへのログインができないようにしているので、FTP でログインして /etc/hosts.deny を一旦削除するなどの方法もとれない。コンパネがあれば、それ経由で作業するなどしかないかと思うが、筆者はたまたまログイン中のコンソールがあったのでそこから作業した。

/etc/hosts.deny から自IPの行を削除。
ログイン → OK♪
ところが、しばらくすると再び DenyHosts からメールが来る。
(ホラー映画みたいだ･･)
/etc/hosts.deny を確認すると "きちんと" 再登録されている。
(真面目だ･･)

再び、「なんで〜??」

もしや nmap の使い方を間違えて再三ポートスキャンでもさせちゃってるのかと当初見当外れな調べからはじめたが、一息ついて DenyHosts の動き方を考え始めてやっとこさ理解。

DenyHosts は、冒頭に書いたように、定期的にセキュリティログを監視して、その結果不正アクセスを試みたIPを hosts.deny に追記している。そのため履歴が残っている限り登録し続けるようだ。
(あなたが正しい、私が正しくない)

で、「どうすれば…?」

当該ログから自IPでの不正アクセスの痕跡(?)と判断される行を探して削除するとか、
DenyHosts のワークファイル (/usr/share/denyhosts/data 以下) を触るなどしても可能なのかも(?)しれませんが、
筆者はなるべく簡単確実そうな (←これ重要)、以下のアプローチを試しました。

1. /etc/denyhosts/denyhosts.cfg の以下を変更。

 > #RESET_ON_SUCCESS = yes
 < RESET_ON_SUCCESS = yes

2. /etc/hosts.deny から自IP を削除。

3. DenyHosts を再起動

$ service denyhosts restart

4. なんらかのサービス (SSH, FTPなど) で "即" ログイン

↑ "即" がキモです。

DenyHosts をデーモンとしてデフォルト設定で起動している場合には、

DAEMON_SLEEP = 30s

となっているかと思いますので、その30秒のインターバルの間に正しいログインをすればそれまでの悪行(?)、もとい愚行をチャラにしてくれます。

2009-05-09

アクセス解析 Analog の URLデコード logkf

インターネットサーバ構築 Webサイト管理

サーバにWebのアクセス解析を設置したときのメモ。

フリーでポピュラーなところではAnalog, AWStats, Webalizerなどがあり、AWStatsはアウトプットが綺麗とのことで少し心惹かれ、AWStats Documentation - Log File analyzer comparison なども一応参考にしたが、あえて先ずは老舗の一角Analogを設置して評価してみた。

Analog 良いです。

確かにアウトプットは今風とはいえないかもしれないけれど、速いし、カスタマイズや外部連携なども柔軟にできるので、まずは満足です。

ReportmagicというHelper Applicationと連動すればプレゼンも変えられるが、質実剛健な職人といった風情も悪くないので筆者はそのまま使っている。

設置したのは最新バージョン6.0 (といっても熟しているので2004-11-19が最新)

一応日本語にも対応している国際化版だが、混沌とした日本語環境に完全対応とはいかないようだ。
（そりゃそうだろう。日本人開発者ですら幾度か苦労するほど多くの文字セットが混在するんだから）

日本語環境で使用するには、例えば文字セットをUTF-8で統一する場合、設定ファイル (analog.cfg) などで、

LANGUAGE JAPANESE-UTF → 出力の文字セット
LANGFILE /usr/local/bin/analog/lang/jpu.lng → 基本文言の和訳ファイル
DOMAINSFILE /usr/local/bin/analog/lang/jpudom.tab → ドメイン(TLD)の和訳ファイル
DESCFILE /usr/local/bin/analog/lang/jpudesc.txt → レポート説明文の和訳ファイル

･･･などの言語環境の指定をして、

さらに"検索語レポート"、"検索語句レポート"で文字化けしないように

SEARCHCHARCONVERT ON

を指定すると、一応それなりに検索語は変換してくれる。

一応と言ったのは一部文字化けするからで、これについては後日analog全般のインストール・設定についてまとめて記述する機会があればと思っているが (予定は未定)、今回はURLデコードについて、良い発見をしたので先んじてご紹介。

"参照元レポート"などには、検索エンジンから飛んできた場合など、
http://search.yahoo.co.jp/search?p=%83X%83i%83t%83L%83%93%8dD%82%ab...
http://www.google.co.jp/search?q=%83X%83i%83t%83L%83%93%8dD%82%ab...
と "スナフキン好き" が "%83X%83i%83t%83L%83%93%8dD%82%ab" とURLエンコードされてapacheによってロギングされた文字列がそのまま出力されるので、これをデコードしてやらないと(、超人以外には、少なくとも筆者や筆者の顧客の皆様には) 読めない。

で、Analogが出力してくれたxhtmlなどの出力ファイルを、デコード処理に渡して変換してやる必要があるのだが、先達によりいくつかのツールが公開されている。

analogurldecode(旧urldecode.pl) -
anadeco.pl Analogの解析結果に現れるURLエンコードを変換 - 徒書
logkf-1.0beta2.tar.gz analog.cx - このウェブサイトは販売用です！ -&nbspanalog リソースおよび情報

筆者は適材適所使用しているのだが、今回はその中でlogkfについて。

logkfは、Analogの出力形式をASCII形式に指定した出力ファイルもうまく変換してくれた。
例えばcronから起動して日次レポートをASCII形式で生成してadminにmailしたい場合など有用。

logkfは上記の日本Analogユーザ会でHelper Applicationとして紹介されているが、現在は (作者さんのHPが閉じていて) 落とせないので転載してくれているAnalog によるアクセスログ解析さんから取得。
ただし最終バージョンにもまだ少し不具合が残ったままのようだ。

筆者の場合、cronから呼び出したSHスクリプトから、

logkf -8 [入力ファイルパス] > [出力ファイルパス]

とするとうまく動いたが、

/usr/local/bin/logkf -8 [入力ファイルパス] > [出力ファイルパス]

とすると

logkf: Cannot open file "/usr/local/bin/[入力ファイルパス]"

みたいな入力ファイルのオープンエラーが発生した。
（どうやらパラメータをチェック、補完したりしている辺りのコードが悪戯をしているようだ。）

筆者はSHスクリプトからのコマンド呼び出しは明示的にフルパスで指定する流儀にしているので、logkfのソースを修正しようかと思っていたところすでにパッチを作ってくれている先達がいたので感謝と紹介。

turutani diary(2006-09-14)

上記パッチを当てるとうまく動きました。ありがとう！

2009-01-22

Plesk環境が嫌になってきた…

インターネットサーバ構築

半年前からテスト用に借りている某VPSサーバのコンパネがPleskという商用コントロールパネル。

これが、なかなかの曲者。

”えぇ〜?”というような（サービスの稼働状況表示みたいな）基本的なところにでさえバグはあるし、
(2008-09バグレポート提出, 現時点アナウンスなし、)
公開情報が少ない独自仕様で解説書のような一般書籍も（もちろん?）出ていない。
Administrator's Guideには基本設定手順くらいしか記載されていない。
Webのサポート情報も(本国含め)十分とはいえない。

その上、サーバ事業者のサポートも同様に素敵だ。
自社で採択したコンパネの特有の癖くらいは情報提供してこそサーバサービス事業者たると私は思うのだが、事業者はそうは思わないらしいので見解の不一致(*1)。
端から "root権限付きは全て自身で解決していただくのが基本です" と紋切り型スタンス。
おっしゃるとおりです。オープンソースの世界で一般公知情報の類であれば、私もそう思います。

しかたなく･･･(?)苦労した先達の奉仕的情報公開や、他(!)事業者さんのサポートフォーラムの情報（「使えるネット」さんなど）などを参考にしたりしながらなんとかしてきたけど、知るほどにその独自仕様に嫌気が･･･

Webサービスを組み上げるためにはいろいろと手を施してやらなければならないのに、これまでの（WebサーバやDBサーバの設定といった）基本的なところまででの制約を鑑みると先が思いやられるというか…

そもそも、コンパネの存在意義って、設定操作を簡便にするためだと(私は)思うのだが、Pleskで設定できることはごく基本的なことに限られている上に、それ以外の本来各サーバソフトウェア群でできるはずの設定をしたいと思うと、途端に情報が少ない独自仕様の世界に付き合わされることになる。
各サーバソフトウェア群もPleskと協調させるためにカスタマイズしているようなので、例えばMySQLやPHPを最新バージョンに上げたいとか、Apacheのオプションを追加/変更してビルドしなおしたいなどというようなことが難しい。
その上、事業者はPleskのアップデータの適用さえ推奨していない(動作保障できないと）及び腰だ。

せっかくオープンソースの世界にいるのに、これでは某ソフトウェア帝国を想起させられる窮屈さだ。

･･･ということで、これ以上１ベンダーの１製品に足を縛られるのがあほらしくなってきたので、見切りをつけてサーバ移転を検討開始だ。

(*1)
[追記：2009-01-24]
後日発見。「くららオンライン」さんには十分な注意書きが掲載されているのを発見。コンパネを選択する際には参考にさせていただくと宜しいかと思います。

Pleskご利用マニュアル｜サーバ管理｜クララオンライン｜カスタマーサポート

http://support.clara.jp/clarafaq/index.php?action=artikel&cat=11&id=104&artlang=ja

<以下、抜粋引用>

- - - - -

Pleskご利用上のご注意

Pleskはあらゆる操作をWebブラウザを通して行うことを想定しており、SSHなどを用いて直接コマンドを操作しサーバの設定を変更することを許可していません。そのため、Pleskの動作に関係するソフトウェアの設定をサーバ内で手動で書き換えた場合、Pleskだけではなく、サーバ自体が正しく動作しなくなる可能性がありますのでご注意ください。

手動でhttpd.confの設定を変更する場合、Pleskが許可している外部ファイルの読み込み手順に従って作業していただく必要があります。詳しくは弊社のFAQをご覧ください。 PleskはMySQLやPHPを用いて動作しています。PleskはOS標準のバージョンにより動作確認を行っており、お客様にてソフトウェアの入れ替えを行われる場合などにはParallels 社 ( 旧 SWsoft 社 )及び弊社からの動作保証がございません。お客様にてMySQLやPHPについて、OS標準バージョン以外のソフトウェアの導入をご希望の場合には、PleskではなくWebminを用いた構成をお選びいただくことを推奨いたします。

サーバに含まれる設定ファイルをお客様にて書き換えられた場合の動作保証はございません。お客様の責の範囲でご利用いただきますよう予めご了承ください。

- - - - -

<引用終わり>

[追記：2009-02-10]
Pleskはごく初歩的なサーバ運用で十分というニーズにはユーザーフレンドリで適しているのかもしれませんね。
筆者のニーズにはマッチしなかったので専用サーバに移転しました。

2009-01-09

Plesk環境でのMySQLデータベース管理

インターネットサーバ構築

PleskはMySQLのDBとDBユーザを独自に管理している。

そのため、Plesk環境下では、DBやDBユーザを新規作成するとき、コントールパネル上から行わないと不整合が生じる。

PleskからphpMyAdminを起動できるようになっているにもかかわらず、phpMyAdminでDBやDBユーザの追加（たぶん変更・削除も）をしたものは解釈しません（できません?）ということらしい。(-。-;)

そんな素敵仕様とは知らずに既に多くのDBを作って運用し始めてしまったアンポンタンな筆者の選択肢は？

1.DBをmysqldumpして、Plesk経由でDBとDBユーザを作り直して、restoreしなおす。
2.Pleskには理解していただかなくても結構です(管理外)と、コンパネと決別する。
3.Pleskになんとか理解していただけないかと説得を試みる。

"Plesk、なぜあなたはこんな制約を？"というPleskを理解しようという心持ち(努力は大切だ)と作業量予測から先ずは3.からアプローチ。PleskがMySQLのDBとDBユーザをどう把握しているのかを軽く探ってみることに…

どうやらPleskは、MySQLに"psa"というDBを持って、そこに自身の管理用データを集約している（ようだ?)。
MySQLに関しては、その中の"data_bases"と"db_users"というtableを使っている(ような)ので、その2つのtableに反映させてやればよい(ようだ? ようだ?ばかりで恐縮です)。せめて推測しやすい名前であったことを軽く神に感謝しつつ覗いてみると…

table → data_bases
field → id, name, type, dom_id, db_server_id, default_user_id

table → db_users
field → id, login, account_id, db_id

と解りやすいご関係。(あくまで現状内部仕様の話)

テーブルを直接触る前にもうひとつ理解しておいたほうが良い(?)Pleskの独自素敵仕様がある。

Pleskのコンパネ上からはDBとDBユーザを1:1でしか定義できない（させない?させたくない?）。
例えば全権ユーザrootなどを作って、複数のDBを横断的に使いたいとしても普通にはできない。かといって同じDBユーザ名、例えば全てadminとかを許すのかというと当然のごとくAlreadyなんちゃらみたいに怒られる(-。-;)

これらの制約も上記の2つのテーブルを整合性をもって調節してやれば可能です。

リレーション関連図でも描いて貼ろうかと思ったけど、実データで見れば解る程度なので省略します。

参考：http://forum.tsukaeru.net/viewtopic.php?t=2189