security-literacy

mt-search.cgi vs Namazu mknmz cron ジョブ

[追記 2006/12/31] namazu.cgi をFTPで転送するとき、Binary バイナリーモードです（通常のcgiファイルで用いる ASII アスキーモードでは内部サーバ・エラーとなります）。

Movable Type デフォルトのサイト内検索 Search は、とても簡便なのでよく利用されているようです。しかし、search_templates ディレクトリにある検索テンプレート comments.tmpl, default.tmpl を独自に変更した私の場合、Movable Type の(マイナー)バージョンアップの作業が増えるにつれて、MT の "夾雑物" 的存在となりました ( しかも、もともと高機能ではありませんし）。
よって、高速な全文検索システム 「Namazu」 のパワーを借りることにしました。以下は、MTで利用する際の tips です。
なお、必ずエントリーの最下段 [更新情報] をご一読下さい。また、ダイナミックページ, html 以外のページ形式 はアクセスできないようです。

(1) ホームディレクトリのトップ内にディレクトリ namazu, namazu内にファイル namazu.cgi および make_index.sh が存在することを確認します。ファイルを誤って削除した場合、ディレクトリのみ作成します。

(2) Movable Type 用のオリジナル(独自)ドメイン内に namazu.cgi のコピーを設置するディレクトリを作成します。

(3) 上記(2)のディレクトリ内に自動生成される設定ファイル .namazurc がブラウザでアクセスされないように .htaccess ファイルをアップロードします。
    http://www.namazu.org/FAQ.html.ja#dot-namazurc

(4) 日本語全文検索システム Namazu は、Xrea.com さんのサーバ内 /usr/local/libexec/ にデフォルトでインストールされていますので、導入法
    http://sb.xrea.com/showthread.php?t=4267&goto=nextnewest
を実行します (インデックス用ディレクトリ namazu は、ブラウザではアクセスできないホームディレクトリのトップに作成されますので、比較的安全です)。

(4) インデックス作成 mknmz を cron ジョブで実行し、インデックスファイルを定時的に更新できるように、スクリプトを作成し、管理ページで設定します ( cron ジョブの設定法については、当ブログ内の関連エントリーをご覧下さい)。

(例: cron ジョブ用スクリプト名 cron123.sh )
ユーザーID: user-id
オリジナルドメイン名: example.com
Namazu インデックスの対象:
    アーカイブ archives ディレクトリ内のファイルで、文書形式 text/html に限る。
ブログページからリンクする namazu.cgi の設置ディレクトリ:
    http://www.example.com/archives/search/ (注: ホームディレクトリのトップにあるディレクトリ namazu ではありません)。

#!/bin/sh

cd /virtual/user-id/public_html/www.example.com/archives/search/
cp -uf /usr/local/libexec/namazu.cgi ./;chmod 700 *.cgi;
cd /virtual/user-id/namazu/
/usr/local/bin/mknmz -V --media-type='text/html' --indexing-lang=ja /virtual/user-id/public_html/www.example.com/archives/ > /virtual/user-id/namazu/make_index.log
rm -f /virtual/user-id/namazu/namazu.cgi;cp -uf /usr/local/libexec/namazu.cgi /virtual/user-id/namazu/;chmod 700 *.cgi;
echo update!
exit

(注:)２つのディレクトリに namazu.cgi をコピー cp -オプションuf するコマンドは、Namazu のバージョンアップに対応したものです。もし、アーカイブページが多く、インデックス生成のタスクに時間がかかるようであれば、コマンド cp を含む行をコメントアウトする (ないし、mknmzによるファイル更新をサーバ負荷のできるだけ少ない時刻に設定する) などの変更をおすすめします。

(5) namazu.cgi のコピーが自動生成されたディレクトリ (2) 内の make_index.cgi を削除します。cgi 属性の変更は無効ですので、リネーム.cgi では危険です。

(6) [MT]/mt-search.cgi の属性を 600 に変更し、使用停止とします。

(7) MT テンプレート メインページの「サイト内の検索」フォームを namazu.cgiのコピー(2) へのリンクに変更します。
    (例) http://www.example.com/archives/search/namazu.cgi

(8) ホームディレクトリのトップディレクトリ namazu 内の NMZ.head.ja NMZ.foot.ja などを適宜編集します。
　　　　[例: cron 時に自動更新されるようにスクリプトを追加します]

[更新情報 Date: Wed Mar 14 16:43:01 2007]
バージョン ⇒ Namazu: 2.0.17
cronジョブによりpdf,doc,xls,pptなどのファイルをindexingするとき、文書フィルタの$PATHをshellscript内で指定しなければなりません。
エントリー「namazu-cron-pdf,doc,xls,ppt-$PATHと文書フィルタ」
　http://www.osbsd.net/2007/05/namazumknmzrc_654b.html
をご覧下さい。

[旧バージョンについて] 2005/1/30現在, Xrea.com さんのサーバで稼働中の Namazu は Version 2.0.13 であり、
   cross-site scripting 脆弱性
の問題があります。よって、Xrea.com さんのサポート宛て、バージョンアップ (2.0.14) を依頼するとともに、一時的に従来の検索システムにて運用します。
  [回答 1 Feb 2005 01:44:31 +0900] 「バージョンアップを行いますと、古いバージョンのバイナリ: namazu.cgi がライブラリの関係で動作しなくなることが確認できているため」、アナウンス後、更新を検討中とのことです。

Hijacked comments.cgi Vulnerable CGI Movable Type

投稿タイトル名は "Hijacked comments.cgi, My comments script was hijacked to email" であった。
日本語版 Version 3.122, 英語版 Version 3.15 以外のすべての Movable Type に CGI 脆弱性があり、mt-comments.cgi, mt-send-entry, mt-comments.cgiによって利用される Mail.pm and Util.pm などのバグを早急に解決できないとき、パッチ用 plugin をインストールする必要があります。

ハイジャック事例の第一報
ハンドル名 shirgall氏 Jan 22 2005, 10:53 PM
   http://www.jayallen.org/comment_spam/forums/index.php?showtopic=461&st=0&p=2279&#entry2279
Movable Type の CGI "comments.cgi" を何らかの方法で乗っ取り、
use MT::Util qw(is_valid_email);
行を追記・機能を悪用し、my($addr) 行に spammer のアドレスも列記すればメールヘッダー の from が spammer 自身となる。

脆弱性対策の発表
Six Apart社が Movable Type 3.15 released を公開すると共に パッチ plugin をリリース Jan 24 2005 06:51 PM
パッチ名: patch-20050124-mail-spam.pl  1KB

つまり、２日以内。Jay Allen氏主催の掲示板に投稿したのがよかったのであろう。

[追記 2005/5/29]
最近、Movable Type の脆弱性の問題が相次いでいるが、Movable Type 本家のホームページでは、情報公開や対応がスピーディに行われている。また、plugins ダウンロードサイトもわかりやすくなっており、免責事項も明確である。
# http://www.sixapart.com/pronet/plugins/
# Disclaimer: Six Apart does not test these plugins and is not responsible for any damage they may cause to your hosting environment.

Restricted Shell SSH2 WinSCP puTTYgen

Xrea.com さんの制限シェル の使用について (追加情報)
2005年１月、(すべてSSH サーバである) Xrea.com さんのサーバのホームディレクトリ /virtual/user-ID/ のトップディレクトリ内にある /.ssh に対して、FTPによる移動、コピー、属性変更などが可能となったようです。
また、.htaccess などのドットファイルは、FTP (WS_FTP Proなど) によるサーバアクセス時に(たぶん、全)サーバで明示されるようになりましたので、誤ったファイル名でのアップロードは減少するでしょう。
SSH 接続に際して、ユーザーパスワードを使用しないで、SSH2、キーペアー生成による Port forwarding　も可能ですので、お知らせします。
なお、以下の環境でのみ動作が正常であることを確認しました。また、この情報の利用・実行に際しては、必ずファイルのバックアップを作成後、すべて自己責任で行って下さい。ディレクトリ /.ssh がなければ、下記具体例のように簡単に作成できます。

(1) クライアントPC (ローカルホスト): OS Windows 側の準備
  WinSCP  Freeware SFTP and SCP client for Windows
をインストールします。
Key tools 「puTTYgen」 が必要ですので、最新安定版 (05/1/25 現在)

WinSCP 3.7.1　Released: 2004-10-31
Installation package 1,476,339 bytes

などを ダウンロード して下さい (フリーウエアですが、Donate が設けられています)。

(2) Xrea.com さんのサーバの管理ページにアクセス後、ホスト情報登録 「SSH 登録」をクリックして、数分待ちます。
https://ss1.xrea.com/www.s(サーバ番号 数字1-3桁).xrea.com/jp/admin.cgi

(3) WinSCP による通常 SSH 接続を確認します。
Xrea.com さんのサーバは、SCP (Secure Copy Protocol) service を利用できますが、SFTP (SSH File Transfer Protocol) によるアクセスはできません。
SSH Protocol version は SSH2 only を使用します。
エントリー「WinSCP rbash」
  http://shellscript.biz/archives/000064.html

(4) キーペアを作成
「PuTTY によるSSH接続 (SSH2 による Port forwarding)」
  http://medqa.net/hint/default4.php#1
などを参照して下さい。
  Key tools 「puTTYgen」をクリックして、キーペアーを作成します。
パラメーターは、SSH2 DSA (1024bits) でよいと思います。

  公開鍵 authorized_keys2 をリモートホストの ディレクトリ ./ssh 内にFTPでアップロードします。authorized_keys2 の属性 (パーミッション) は 400 が最も安全です。
  秘密鍵 **.ppk は WinSCP の設定「Private key file」で使用します。

    因みに、FTPで使用するパスワードは、ユーザー登録時に取得したパスワードの文字長８文字 (左側) のみ有効です。SSH 通常接続では、パスワードの全文字長が必要です。PuTTYgen.exe で使用する Key passphrase は任意に設定できますが、リモートホストへのログインの際にダイアログが表示されますので、入力します。
 Enter key passphrase
   Passphrase for key ’dsa-key-*****’:
キーペアー作成時、Key passphrase "空白" にすると、このダイアログは表示されませんが、暗号強度は明らかに低下しますので推奨いたしません。

(具体例)
公開鍵 (SSH2でのファイル名は必ず) authorized_keys2 を ASCII アップロードできるように、 テキスト形式 (かつ、エンコード EUC, 改行コード LFのみ) で作成、保存し、
  authorized_keys2.txt
ホームディレクトリのルート(トップ)デイレクトリ内にアップロード後、

ディレクトリ .ssh があるとき
すでに作成された公開鍵があれば、リネームしておきます。

$ ls -F .ssh
$ mv ./.ssh/authorized_keys2 ./.ssh/authorized_keys2_default.txt
$ mv authorized_keys2.txt authorized_keys2
$ cp -i authorized_keys2 ./.ssh
$ chmod 0400 ./.ssh/authorized_keys2
$ chmod 0700 ./.ssh
$ rm authorized_keys2

ディレクトリ .ssh がないとき

$ mkdir .ssh
$ mv authorized_keys2.txt authorized_keys2
$ cp -i authorized_keys2 ./.ssh
$ chmod 0400 ./.ssh/authorized_keys2
$ chmod 0700 ./.ssh
$ rm authorized_keys2

のように、コマンドを実行します (FTPであれば、操作はさらに簡単です)。

nofollow plugin rel attribute Movable Type

rel 属性と新しい属性値 "nofollow" rel="nofollow" を自動付加する plugin [ Release 1.0 公開日: January 18, 2005]
  ⇒ http://www.movabletype.org/news/2005/01/movable_type_nofollow_p.shtml

[追記 2005/1/19 21:00 下記の不具合は調査中ですが、Six Apart社, Movable Type本家では、未だ報告がないようです。
Ogawa::Memoranda さんの最新エントリー「No Follow, No Life」
  http://as-is.net/blog/archives/000959.html
にて相談しましたので、ご覧下さい。]

本スクリプト Release 1.0 をインストールすると、インライン要素 A のタグ中で、href 属性は問題ないかもしれませんが、下記のような name 属性ではバグ?が発生する 「MTPingID が消去され、空白となってしまう」
name 属性
<a name="<$MTPingID$>"><⁄a>
nofollow (-) ⇒ <a name="1"></a>
nofollow (+) ⇒ <a></a> name 属性が完全消去される.

Movable Type へのインストール
[MT]⁄plugins⁄nofollowfy.pl
[MT]⁄php⁄plugins⁄init.nofollowfy.php

インストール後のタグ内の変化
<a href="http:⁄⁄example.com⁄" rel="nofollow">
<a href="http:⁄⁄www.example.com⁄" rel="nofollow software">
<MTReferers nofollowfy="1">
など。
コメントのソースをみると、
<p class="posted">投稿者 <a href="http:⁄⁄www.example.com⁄" rel="nofollow">comment spammer<⁄a> : January 18, 2005 01:02 PM<⁄p>
のように、コメント内容だけでなく、投稿者の URL のタグ内も変化しています。

新しい属性値 "nofollow" を href 属性と一緒に アンカータグなどで使用する (rel="nofollow" が href 属性に加わる) と、コメントやTrackBack内のハイパーリンクが Google, MSN, Yahoo などのサーチエンジンの分析対象外となります。comment spam, trackback spam の減少を目的とする spam 対策です。
他に、Six Apart社(TypePad, MovableType, LiveJournal), WordPress もサポートしています。
というより、
   http://www.sixapart.com/log/2005/01/support_for_nof.shtml
「Support for nofollow (01.18.2005) 」の一部を引用すると、

The rel="nofollow" specification is not the end-all mechanism of stopping comment spam, but it’s a significant step, and a good partnership between weblogging vendors and search companies.

weblog ベンダーと検索(エンジン)会社はこれから仲良くやりましょうということに意義があるのかもしれません。
[追記 2005/1/24]
http://weblogs.mozillazine.org/ben/archives/007366.html
ウェブブラウザ「Firefox 1.0」開発者の Ben Goodger は、Google 社に採用された(本人のブログの一部引用)。

As of January 10, 2005, my source of income changed from The Mozilla Foundation to Google, Inc. of Mountain View, California. · · ·

なお、ロボット型検索エンジン、スパイダーに対するホームページ対策として、META タグの content属性の属性値"nofollow" が以前から知られています。参照ページ
    http://www.mediaweb.biz/database/others/meta_tag.html

[追記 2005/1/20] 世界の spam 対策にできるだけ協力したいので、いろいろ問題がある plugin "nofollow Release1.0 " で自動化するのではなく、各 Templates をみて、TrackBack, Comments などの Ping に関連するタグは、現時点では 手作業で、(例)
  <a href="<$MTPingURL$>" rel="nofollow">
  <MTPings nofollowfy="1">
と属性を追加することに決めました。

[追記 2005/1/30] 早速バージョンアップとなっています。
Nofollow Release 1.1
ファイル内表示: nofollow.pl,v 1.1.2.2 2005/01/24 19:01:02

SpamAssassin threshold X-Spam-Flag: YES

 SpamAssassin の「X-Spam-Flag: YES」の意義などについて

(例) threshold 設定 (7.0) :
spam メール検出の 特異性(特異度) 99.99%, 感度 88.50% の設定です (テスト用サンプル 合計84637通, Version 3.0.2 )。

メールヘッダー表示「X-Spam-Flag: YES」のとき、99.996%の期待陽性率で spam メールと判断できます [計算式(注1)]。しかし、感度は 88.50% で、「X-Spam-Flag: YES」と表示されないメールの中に、spam メールが 18.30% (=100% - 期待陰性率) [計算式(注2)]  混在する可能性があります。

 @ nifty辞書 http://www.nifty.com/dictionary/
[threshold]
【物】しきい値 ((反応などを起こさせるのに必要な物理量の最小値))
【生理・心】閾(いき) ((刺激に対して生体が反応するかどうかの限界))
「閾値 (いきち)」がよく使用されます。

SpamAssassin スパムアサシン のデフォルトの閾値 default threshold (ないし、default threshold value) は 7.0 であると記載されているページがありました。
     http://www.dam.brown.edu/computing/SpamAssassin/default.htm

X-Spam-Flag: - The "X-Spam-Flag:" identifier will ONLY appear when an email message has reached the spam threshold limit (default is 7.0).
- When an email message reaches and/or exceeds the spam threshold limit, the identifier "X-Spam-Flag: YES" will appear.
- This SpamAssassin identifier easily enables the individual to configure his/her client to look for the "X-Spam-Flag: YES" header to filter the spam messages.

ところが、
CPAN
     http://search.cpan.org/src/FELICITY/Mail-SpamAssassin-3.0.2/rules/STATISTICS.txt
では、Version 3.0.2 の default threshold:
# SUMMARY for threshold 5.0:
と記載されています。インストール後、ユーザー自身で確認された方がよいようです。また、threshold による感度、特異性をよくご確認後、設定して下さい。

ページ内のデータより、テスト用サンプルの合計は 84637 通(単位?)で、

Correctly spam +　False negatives =    55933
Correctly non-spam + False positives = 28704

ですので、spam メールの検出については、

特異性(度)= 100%* Correctly non-spam ⁄ {Correctly non-spam + False positives(偽陽性)}
感  度  = 100%* Correctly spam ⁄ {Correctly spam + False negatives(偽陰性)}
 (注1) 期待陽性率 =
 100%* Correctly spam ⁄ (Correctly spam + False positives)
 (注2) non-spam メールとの判定の中に spam メールが混在する頻度　=
 100% - 期待陰性率  = 
 100% - 100%* Correctly non-spam ⁄ (Correctly non-spam + False negatives)

と同義です。よって、
(1) threshold を高い値に設定すると、特異性はよくなりますが、spam メールの検出感度は低下します。
   · non-spam メールは正しく判定されるようになります (non-spam メールを spam メール と誤って判断する偽陽性率の低下 )。
   · spam メールの「すり抜け」が増えます (spam メールの検出感度は低下します)。

(2) threshold を低い値に設定すると、spam メールの検出感度はよくなりますが、特異性は低下します。
   · spam メールの「すり抜け」が減少します（ spam メールの検出感度は、よくなります) 。
   · non-spam メールを正しく判定する率は低下します (non-spam メールを spam メールと誤って判断する偽陽性率が増えます )。

CPAN参照ページ(同上):
テスト用サンプルを threshold 5.0 で検出すると、
特異性(度)99.95% 感度94.01% 期待陽性率99.97% 期待陰性率89.54%

# SUMMARY for threshold 5.0:
# Correctly non-spam:  28690  99.95%
# Correctly spam:      52582  94.01%
# False positives:        14  0.05%
# False negatives:      3351  5.99%

threshold 7.0 で検出すると、
特異性(度)99.99% 感度88.50% 期待陽性率99.996% 期待陰性率81.70%

# SUMMARY for threshold 7.0:
# Correctly non-spam:  28702  99.99%
# Correctly spam:      49503  88.50%
# False positives:         2  0.01%
# False negatives:      6430  11.50%

たとえば、threshold 5.0 (下限） から 7.0 (上限) の間で設定すればよいのではないでしょうか。
なお、「スパムメールと闘う」
     http://linuxmag.sourceforge.jp/Japanese/January2003/article279.shtml
のページに SpamAssassin のわかりやすい解説があります。
ただし、CPAN
     http://www.cpan.org/modules/by-category/19_Mail_and_Usenet_News/Mail/Mail-SpamAssassin-3.0.2.readme

--
SpamAssassin also includes support for reporting spam messages automatically, and/or manually, to collaborative filtering databases such as Vipul's Razor [1].
--
--
SpamAssassin includes a Bayesian learning filter,
--

ですので、Bayesian, Razor 双方のスパムフイルターは SpamAssassin にすでに組み込まれています。

Outbound Port 25 Blocking, Rate base spam control

私が最初に取得したインターネットメールのアドレスは、「ぷらら」さんのものでした。常に最先端のセキュリティ対策を目指す大手ISP 「ぷらら」さんの <スパムメール撲滅に向けた取組み> をお知らせします。
  http://www.plala.or.jp/access/living/releases/nr04_dec/0041207_01.html
  http://www.plala.or.jp/access/living/releases/nr04_dec/0041207_02.html
(1) Outbound　Port 25 Blocking [2005/1/31 実施予定]
(2) Rate base spam control
などが2005年１月から導入されます。
また、新規登録に際して、必ず以下の同意が必要となっています (オンライン登録時のユーザー向け表示ページの一部を原文のとおり引用します)。

スパムメールを送信した場合には、スパムメール1通あたり100円をご登録の請求方法に上乗せして、ご請求させて頂きます。

「例」　スパムメールを1万通送信した場合

１００円×１万通＝（請求額）１００万円

また、弊社サービスに影響の生じた場合は上記とは別に「威力業務妨害」等により、刑事告発及び損害賠償請求をさせていただく場合があります。

[追記 2005/1/17]
J.D. パワーアジア・パシフィック社による
2004年日本ブロードバンド・インターネット・プロバイダー顧客満足度調査（PDF）
  http://www.jdpower.co.jp/press/pdf2005/2004JapanISP_J.pdf
もご覧下さい。PDFファイルです。
報道用資料 タイトル
「ISP の顧客満足度、加入後半年未満では @niftyとSo-net、半年以上ではぷららがトップ」

Technorati, Claim a Weblog 後のブログタイトル表示エラー

Ping サーバ Technorati http://www.technorati.com/
にメンバ登録し、ブログページを Claim a Weblog すると、サンプルページ
   http://www.osbsd.net/technorati.html
のように、自動検索可能となります。Cosmos Search とよばれているようです。
2004年12月、Technorati さんのサーバ・ページがリニューアルした後、自動登録ツールのバグ?なのか、Cosmos Search Results:の次行のURL(ないし、ブログ・タイトル) に他人のブログページが表示されるようになりました。
Claim a Weblog を繰り返したり、登録を一旦削除しても同じだったので、support宛てメールにてリビルド等を依頼し、解決しました。
Cosmos Search の内容については、すべて正しかったので、ブログページのURLのみ、他人のものが表示されたようです。

個人用電子証明書 デジタルID セキュア S/MIME メール

セキュアメール　無料キャンペーン(主催: 日本ベリサイン株式会社 協賛: 株式会社ジャストシステム) 期間中のため、spam 対策の１つとしてお知らせいたします。
現在、私は
   · 日本認証サービス株式会社 http://www.jcsinc.co.jp/
   · 日本ベリサイン株式会社 http://www.verisign.co.jp/class1/services.html
発行の個人用電子証明書 (PKI によるデジタル Digital ID)を使用しています。
その用途として、一般的には
   · セキュアメール
   · アクセスコントロール
   · 電子署名
などが可能ですが、主に、セキュアメール (特に、S/MIME メールの電子署名) のために利用しています。

個人メールをセキュアとするだけであれば、ベリサイン社個人用電子証明書は (経験上)取得手続が簡単で、安価と思います。本証明書は、単品「ベリサイン 個人用電子証明書ライセンスシート」として、Just MyShop オンライン購入も可能です(店頭での購入はできません)。

また、セキュアメール　キャンペーン主催者の日本ベリサイン株式会社
    http://www.verisign.co.jp/class1/index.html
にアクセスすると、３ヶ月間無料でトライアル版の体験できます。
株式会社ジャストシステムさん協賛で、「企業内個人様向け」 「2005年2月28日まで」です。
ページ内には [証明書を利用するための環境]：
   · OS＝WindowsXP/ME/98/2000
   · ブラウザ＝Internet Explore5.01(SP2)-6.0
と指定されていますが、主に、メールソフト「Shuriken Pro3 /R.2」
     http://www.justsystem.co.jp/shuriken/product/pro3r2set.html
の動作環境と思います。たとえば、鶴亀メール Ver4.03 [2005年8月9日,「鶴亀メール」から「秀丸メール」となりました]においても本証明書は問題なく利用できますが、Windows XP以上のOSでないと、メールソフト上で証明書の表示はできません（ CryptUIDgViewContext 関数が使えないため、とのことです)

cron ジョブ と デーモン

· cron ジョブについて
2005/1/3 現在, Xrea.com さんの サーバ s102, s104 は、cron ジョブが停止しているようです。
自宅サーバ機であれば、サーバ上で cron ジョブ ( 各ユーザが crontab を使う ) などのプロセスがデーモンとしてバックグラウンドで実行されているか ?

コマンド ps  
ps aux | grep "ジョブ名" 
[PATH]/crontab -l (例 /usr/bin/crontab -l)

などで確認できます。しかし、一般的なレンタルサーバでは、確認用のコマンドを利用できないことが多いので、何らかの理由で サーバが一部のプロセスを停止しているか? 現在サポート様へ問合わせ中です。
[追記 2005/1/12] s106サーバ では、cron ジョブは正常作動しています。広告免除サービス (免除権) をサーバ間で移動した場合であっても、cron ジョブの反映まで数時間かかります。 因みに、ディスク容量表示の反映まで24時間程度かかります。
[追記 2005/1/17] s107サーバ: cron ジョブは正常作動しています。
[追記 2005/1/24] s111サーバ: cron ジョブは正常作動しています。
[追記 2005/2/1] s112サーバ: cron ジョブは正常作動しています。
なお、(s100 以降の) s101, s103, s105 サーバ の cron ジョブは、未確認です。
バイナリーファイルのインストール、データーベースなどの設定前に (特に、Movable Type 管理者の方で、予約投稿を予定されている場合)、ご契約サーバの crontab 作動状態の確認をおすすめいたします。
[追記] crontab (cron ジョブ) のみをローカルネットワーク上の別サーバで作動させることが可能のようです。( s102 サーバについては、ユーザー個別に) 別サーバで設定していただきました。
[追記 2005/2/23] s114サーバ: cron ジョブは正常作動しています。
[追記 2005/3/30] s139サーバ: cron ジョブは正常作動しています。

MySQL 4.1.7 (s101, s102 サーバ) と PublishCharset UTF-8

Xrea.com さんの 110台余りのサーバの中で、２つのサーバ s101, s102 は特別な仕様となっているようです。
     Athlon64 3500+ 1GB RAID1 (Perl5.8.3 / PHP5.0.3 / MySQL4.1.7 / PgSQL 7.4.5 )
   http://sb.xrea.com/showthread.php?&threadid=4443

Movable Type 新規インストールの際、
データベース MySQL 使用時、mt.cfg 設定: 文字コード (PublishCharset) utf-8 は使用できません。
UTF-8 として、mt-load.cgi を実行すると、

テンプレートを設定しています...
データの設定中に以下のエラーが発生しました:
Insertion test failed on SQL error Duplicate entry '1-' for key 2

となります。
文字コード (PublishCharset) EUC-JP とする必要があります ( 2005/1/3 確認済み) 。
MySQL4.1 新機能による影響のようです。データベースをみると、
  phpMyAdmin version 2.6.0-pl3 SQL Dump では、sql ファイルは、UTF-8 Unicode (utf8) で作成・エクスポートされます。
  MySQL dump version 10.8 をみると、dump ファイルは、ujis (EUC-JP) で作成・エクスポートされます。

「第48回 MySQL 4.0から4.1へのアップグレード 、トラブってませんか?」
鶴田展之氏 2004/12/21
   http://pcweb.mycom.co.jp/cgi-bin/print?id=25624
などが参考となりそうです。
つまり、s101 サーバでの報告
   http://sb2.xrea.com/showthread.php?p=64430
と同様の設定エラー が s102 サーバにおいても発生しますので、mt.cfg の文字コード (PublishCharset) は 必ず EUC-JP とする必要があります (PublishCharset Shift_JIS は未確認です)。

再構築後、atom.xml のエンコードをみると、"EUC-JP"なので、mt.cfg の文字コード設定が反映しています（当たり前ですが）。
   <?xml version="1.0" encoding="EUC-JP" ?>
これでは、MySQL 4.1系の高機能を利用できるようになっても、
   http://shellscript.biz/archives/000023.html
過去エントリー(2004年09月20日)のとおり、「文字コードEUC-JPでは、エントリーの記述内容次第で、再構築後にRSS、Atomに対応しなくなることがあります。」ので、ブログページの質は低下してしまう。

因みに、MySQL 4.0.23 の s104 サーバなどでは、従来どおり 文字コード utf-8 設定可能です。
[重要! 追記 2005/4/24] s101-s150 すべて4.1系 (MySQL4.1.7) のサーバ と表示変更されています (バージョンアップ完了)。
  http://sb.xrea.com/showthread.php?&threadid=4443
s104, s106, s107, s111, s112, s114, s139 では、MySQL Client API version 4.17, かつ 文字コード utf-8 設定可能となっています。ただし、s103、他サーバについては未確認です。