こんなの作ってみた。

#!/bin/sh

wnum=`date +'%u'`
bnum=`expr $wnum % 2 + 1`

rsync -az --delete /etc/ backupserver:/tmp/backup.${bnum}/etc/

これで日、月、水、金はbackupserver:/tmp/backup.1/etcに、火、木、土はbackupserver:/tmp/backup.2/etcに/etc配下のコピーが保持される。
日曜と月曜分が被ってしまうが、まぁいいか。

Tomcat起動時のJava引数でJMXエージェントを有効化するオプションを追加してやればサーバ側はOK。
たとえばbin/setenv.shでCATALINA_OPTSに追加してやる。

CATALINA_OPTS="$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8686 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
"

あとはJConsoleを実行する側でサーバ名とポート番号(上の例では8686)を指定して接続すればよい。
ちなみに上の指定はSSLも認証もなしの状態なので、クローズドなN/W経由で利用しないと危険。

またJMXエージェントとのやりとりはRMIでおこなわれるので、jmxremote.portで指定した番号以外のポートも使われる。
Firewallを経由する場合は注意が必要。

JMX を使用するプラットフォームの監視と管理

CORESERVER.JPでCGI版PHPを動かす場合に「PHPをCGIとして動かす方法について」の方法に従うと
CORESERVER.JPでPHPをCGIで動かすとContent-Typeが上書きされる
なことになります。
CMS Made Simpleはそれでは悲しいことになってしまうので、サーバ提供設定に頼らずにCGI化した際の覚え書きです。

簡単に言えば、

• *.phpファイル編集
  *.phpの先頭に

  #!/usr/local/bin/php5 -q
  

  を加えて実行権限を付与します。数多くて手作業では大変なのでsedで一気に変更しました。

  $ for f in `find . -name "*.php"`; do
  > sed -i '1i#!/usr/local/bin/php5 -q' $f
  > chmod +x $f
  > done
  

• .htaccess設定
  .htaccessで

  AddHandler cgi-script .php
  

  を記述した.htaccessファイルを用意して/直下に配置します。

• php.ini設定
  php.iniでセッション情報保存パスを設定します。

  session.save_path = "/virtual/account/tmp"
  

  もちろんディレクトリを用意して、書き込み権限を設定しておきます。
  php.ini配置場所は、/直下と/admin直下の2箇所。
  ちなみにこれはCORESERVER.JP提供の方法でCGI化する場合も必要。

サーバ提供のCGI実行方法が-qオプション付きでPHPを実行してくれてれば、こんな面倒なことしなくていいんですけどね。

早速CMS Made SimpleをCORESERVER.JPで試そうとしたところ、不思議な現象にあたりました。

XREAやCORESERVERはPHPをSafe Modeで動かすようになってます。
そうするとCMS Made Simpleのウェブ管理インターフェースを使ったModule導入などがおこなえません。
こういった場合のために、PHPをCGIで動かす方法が提供されているのですが、そうするとFirefoxではStylesheetが適用されなくなってしまいます(Internet ExplorerはOK)。

LiveHTTPHeadersで追いかけてみると

GET /cms/stylesheet.php?templateid=17&mediatype=handheld HTTP/1.1

リクエストに対する結果がContent-Type: text/htmlになってしまっています。

ApacheモジュールだときちんとContent-Type: text/css; charset=utf-8になるのに。

Firefoxは厳密にContent-Typeで判定し、Internet Explorerは中身も見て判定するのでこうなっちゃうんですね。

サポートフォーラム検索してみるとこんな記事が。
php: header()が正しく機能しない
がぁーん。実行環境側で対応する方法はないんでしょうか?

でも、そもそもSafe Modeはセキュリティ的にそんな役立つものでもないし、PHP 6.0.0では削除されるんだから撤廃しちゃえばいいのに。

2007 Open Source CMS Award Finalists
を見ていて、CMS Made Simpleに興味が沸きました。ちなみにDrupalもFinalistに残ってますが

Drupalのようなブログっぽいツールではなく、ページを構造的に配置してサイトを構築していくツールです。
説明難しいんですが、スクリーンショットのコンテンツ一覧を見ていただくとイメージしやすいかもしれません。

惹かれているのは以下の点。

• コンテンツを構造的に配置して管理できる。
• コンテンツ階層単位に適用テーマを変更できる。
• モジュールやテーマのインストールやアップグレードをウェブインターフェースでおこなえる。
• モジュールが豊富(ブログやフォーラムもあります)。モジュールやテーマのRatingが公開されていて何が人気が高いのか比較的わかりやすいです(Drupalもやったらいいのに)。
• ネーミングがGNU is Not Unixのようなセンスを感じさせて、いかしてる

標準で多言語対応されているようで、管理画面では日本語メニューを使うこともできます。
メール送信とか細かいところで多言語対応バッチリかは未確認ですが。

私は一時TYPo3の管理構造がいいなと思いチャレンジしたことがあったのですが、あまりの難しさにあきらめた経験があります。同じような思いをされた方、いかがでしょうか?

ちなみにライセンスはGPLですが、商用利用の場合は有償になるようです。
http://cmsmadesimple.org/main/commercial

今頃気がついたのですが、Tomcat 5.5以降はJSPコンパイラにEclipse JDTを使うようになったそうです。つまりjavacが不要になったのでJDKではなくJREでも動かすことができると。
ただJREに含まれるのはHotSpot Client VMだけなので、HotSpot Server VM使いたければJDKが必要になります。

Tomcat 5.0まではコンパイラの変更もweb.xml設定でOKだったのですが、それが少しややこしくなったようです。
以下のスレッドでコンパイラをjikesに変更する方法が話題になってます。

• Does Tomcat 5.5 support jikes?

JSPが出回り始めた頃は「なぜ本番サーバに開発キット(JDK=Java Development Kit)を入れなきゃいけないの?」と思ってたのですが、やっとRuntimeだけでもいけるようになったということですね。

mod_rewriteのRewriteCondディレクティブ。内部的にはRewriteRuleのあとに判定されます。
たとえばhttp接続してきたものをhttpsにリダイレクトするようなルールを書いたとします。

RewriteEngine on
RewriteLog logs/rewrite_log
RewriteLogLevel 4
RewriteCond %{HTTPS} off
RewriteRule . https://%{HTTP_HOST}/%{REQUEST_URI} [L]

サイトがwww.example.jpだったとして、http://www.example.jp/index.htmlにアクセスしてみると、RewriteLogには以下のようなログが出力されます。

(2) init rewrite engine with requested uri /index.html
(3) applying pattern '.' to uri '/index.html'
(4) RewriteCond: input='off' pattern='off' => matched
(2) rewrite /index.html -> https://www.example.jp/index.html
(2) explicitly forcing redirect with https://www.example.jp/index.html

2行目でRewriteRuleが判定され、3行目でRewriteCondが判定されていることになります。
先頭の()数字はRewriteLogLevelを表しているのでRewriteLogLevel 4にしたのですね。

で、こちらの処理順序ですが、こちらのメーリングリストで知りました。
RE: [users@httpd] RE: case insensitive rewrite rules and nested mapping
こちらのスレッドの最後のメールで

The order of processing is
rule-pattern --> condition(s) --> rule-substitution

と説明されていました。
ま、こんな内部的な順番知っててもしょうがないかもしれませんけど

アプリケーションの実装としてではなく、Tomcatレベルで変更する方法です。
@ITのフォーラムには以下のQAがあります。
JSESSIONIDを保持したCookieをsecure属性にする方法 - Java Solution
こちらによれば、Tomcatは「セキュアな通信の場合CookieにSecureを付与してくれる」ことになります。

ところがApacheやTomcatでSSLしてる場合はよいのですが、SSLアクセラレータやロードバランサ、stunnelなどでSSLを解除しているとsecureと認識されなくなってしまい、Secure属性が付与されなくなってしまいます。

で、TomcatのAJP13コネクタ定義にはsecureという属性があり、こちらをtrueに設定するとresponse.isSecure()にtrueを返してくれるようになります。

ですのでserver.xmlのコネクタ定義で以下の設定をおこなえば、毎回cookie.setSecure(true)が実行されて、CookieにSecureが付与されるようになります。

<Connector port="8009" secure="true"
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

Debian etchにアップグレード後、aptitudeを実行するとlocale関係でエラーで出るようになりました。

locale:Cannot set LC_CTYPE to default locale: No such file or directory
locale:Cannot set LC_MESSAGES to default locale: No such file or directory
locale:Cannot set LC_ALL to default locale: No such file or directory

Debian usersのMLに投稿されていた下記の事象とまさに同じ。

• [debian-users:48130] Re: xfonts-baseについて

解決方法もそちらのスレッドに返信されています。
うちの場合、localeコマンド実行結果は以下。

# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US
LANGUAGE=en_JP:en_US:en_GB:en
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

エラーになるLC_CTYPEとLC_MESSAGES、それにLC_ALLに指定されているlocaleをdpkg-reconfigure localesで有効にしてあげれば解消できるということになります。
実際にはen_USというlocaleは存在しませんので、「Locales to be generated」と「default locale」にen_US.UTF-8を選択して解決しています。日本語にしたい場合はja_JP.UTF-8やja_JP.EUC-JPを指定すればよいのでしょう。

厳密な方法ではありません。禁止ではなく防止できるかも、というレベルです。
rcスクリプト等でtomcatの起動ユーザをroot以外にしていたとします。

case "$1" in
  start)
    su - tomcat -c "$CATALINA_HOME/bin/startup.sh"
    ;;
  stop)
    su - tomcat -c "$CATALINA_HOME/bin/shutdown.sh"
    ;;

ですが、$CATALINA_HOME/bin/startup.shを直接実行されるとtomcat以外のユーザで起動されてしまう可能性があります。そこでsetenv.shを使い、tomcatユーザ以外で実行した場合にメッセージを出して終了するようにしてみました。

if [ "`/usr/bin/whoami`" != "tomcat" ]; then
  echo
  echo "tomcatユーザ以外では起動しないでください。"
  echo "/etc/rc.d/init.d/tomcat {start|stop}を使ってね。"
  echo
  exit
fi
:

こうしておけば、startup.shレベルであれば起動ユーザをチェックできると思います。