Entries : Category [ server ]
server のトラブル
[PC]  [server]  [network]  [info]  [tips]  [command]  [security] 

09 December
2009

zope の version up で Products "COREBlog" "EPos" でエラー

zope version up: ImageFile error

■背景
□旧 version
  Python-2.4.4
  Zope-2.10.4-final
□新 version
  Python-2.4.6.tgz [official site]
  Zope-2.11.4-final.tgz [official site]
□zope Products の version
  COREBlog125 [official site]
  Epoz-0.7.4 [official site]
  ejSplitter-0.5.1 [official site]
  jaMailHost-0.4.4 [official site]

■問題
新 version に update したところ、COREBlog が動作
しなくなりました。

■エラー: event.log の内容
□COREBlog
------
2009-12-04T09:52:50 ERROR Application Could not import Products.COREBlog
Traceback (most recent call last):
File "/opt/Zope-2.11/lib/python/OFS/Application.py", line 709, in import_product
File "/home/www/Products/COREBlog/__init__.py", line 23, in ?
from ImageFile import ImageFile
ImportError: No module named ImageFile
------

□Epoz
------
2009-12-04T09:52:50 ERROR Application Could not import Products.Epoz
Traceback (most recent call last):
File "/opt/Zope-2.11/lib/python/OFS/Application.py", line 709, in import_product
File "/home/www/Products/Epoz/__init__.py", line 17, in ?
from ImageFile import ImageFile
ImportError: No module named ImageFile
------

■原因
zope を以前の version "2.10.4" に戻すと、上記の
error は発生しないため、Python が原因ではなく、
zope の version up が原因となっている可能性が高
いところまでは確認しました。

event.log では、両 Product 共に "ImportError: No
module named ImageFile" なる error message があ
るので、調べてみました。

google: zope ImageFile error

確かに、HISTORY.txt の末尾に、"App.ImageFile" を
替わりに使え、という記載を確認。

unchor@rescue:/usr/local/src/zope/Zope-2.11.4-final/doc$ grep ImageFile *.txt
HISTORY.txt: - The ImageFile module has finally been deprecated for good and
HISTORY.txt: will be removed in Zope 2.11. Use App.ImageFile instead.

■対処
zope の instance root 以下で、

cd COREBlog
vi __init__.py
cd ..
cd Epoz
vi __init__.py
cd ..

で、それぞれの "__init__.py" を修正。
  from ImageFile import ImageFile
と ImageFile を呼んでいた部分を
  from App.ImageFile import ImageFile
と修正。

後、zope 起動時 event.log の error message は解
消され、COREBlog / EPos の正常動作を確認できまし
た。


Posted by unchor at 09:29 | Comments (0)
11 December
2009

zope の version up で "Some of your Scripts have stale code" なるメッセージが

zope version up: Python Scripts stale code recompile

■背景
先日の zope の version up 作業 (Zope-2.10.4-final
--> Zope-2.11.4-final) で、COREBlog などに Image
File module の load error が生じ、問題解決の手
かがりとして zope の吐く event.log を tail -f し
ていたところ見慣れない message に気がつきました。

■event.log の INFO message
------
2009-12-04T10:29:54 INFO PythonScripts Some of your Scripts have stale code cached. Since Zope cannot use this code, startup will be slightly slower until these Scripts are edited. You can automatically recompile all Scripts that have this problem by visiting /manage_addProduct/PythonScripts/recompile of your server in a browser.
------

■対処
event.log INFO message の指示に従って、(manage
に log in 後)ブラウザから
  http://rescue.unchor.com/manage_addProduct/PythonScripts/recompile
と URL を指定しました。

■結果
いくつかの scripts が無事 update されたようでした
(capture していなかったので、詳細は既に不明)。

zope は弊社設立後自社 web site の platform とし
て、2002 に運用を開始しましたので、使い始めて既
に 7年以上になりますが、このような機能があるのに
初めて気づきました。よい仕様ですよね(自動 recom-
pile でもいいんでない? という気もしなくはないの
ですが....事前の検証とかもあるでしょうからそう勝
手に自動 recompile ともゆかないのでしょうね)。


Posted by unchor at 08:31 | Comments (0)
22 December
2009

openssl installation procedure

keywords: redhat linux openssl make install

■環境
下記、基本的には redhat linux 環境を想定しており
ます。

■背景
bind / apache / openssh などを src から compile
するために必須ですので、これら作業の事前準備とし
て、openssl をいれておきます。

redhat 系 linux では、default rpm によって導入さ
れている古い openssl がありますが、それには影響
がないように install します。prefix(導入先)は
default の
  /usr/local/ssl
としました。

この手法ですと、openssl version up の際には、上
記 directory に上書き version up となります。

■procedure
cd /usr/local/src/openssl/
# wget http://www.openssl.org/source/openssl-0.9.8h.tar.gz
wget http://openssl.linux-mirror.org/source/openssl-0.9.8l.tar.gz
md5sum openssl-0.9.8l.tar.gz
sha1sum openssl-0.9.8l.tar.gz
tarx openssl-0.9.8l.tar.gz
cd openssl-0.9.8l
./config -fPIC shared no-sse2
# for duron
# ./config 386 shared
make
make test
make install

□note
wget で download した後、念のため md5 / sha1 で
検証しておきます。

□config option
.no-sse2
当該 server の CPU は(古い)PentiumIII だったり
するので、sse2 なし、とします。

sse2: hatena::keyword

.duron の場合
上記の option "386 shared" にしないと、make が通
りません。

■after work
src から導入する場合、初回のみ、
  /usr/local/ssl/lib
に path を登録する必要があります。具体的には、
vi /etc/ld.so.conf
  /usr/local/ssl/lib
を追加し、編集後
ldconfig
を実行します。

この "after work" は openssl version up 時には不
要です。何故ならば、既に上記 path
  /usr/local/ssl/lib
は system に登録済みだからです。

なお、必要があれば、
  /usr/local/ssl/bin/
に path を通すか、
  cd /usr/bin
  ln -s /usr/local/ssl/bin/openssl openssl
などして、簡便に実行できるようにておくのもよいか
と。

□動作確認
/usr/local/ssl/bin/openssl version

■tarx
tar の option は面倒なので、sh script にしており
ます。下記参照。他に、tarc / tart とかも....。

#!/bin/sh
#
# tarx.sh
#
tarx ()
{
echo "tar xzvf $1"
tar xzvf $1
}

tarx $*
#
# end of file


Posted by unchor at 12:21 | Comments (0)
25 December
2009

isc bind installation procedure

keywords: redhat linux bind make install

■前提
src から install した openssl が
  /usr/local/ssl
にあること、を前提とします。

下記は、
  /usr/local
を導入先 (prefix) としております。従って、version
up の際には、「上書き install」となります。

■環境
下記、基本的には redhat linux 環境を想定しており
ます。

■src bind installation
□procedure
cd /usr/local/src/bind/
# wget http://ftp.isc.org/isc/bind9/9.5.0-P2/bind-9.5.0-P2.tar.gz
# wget http://ftp.isc.org/isc/bind9/9.6.0-P1/bind-9.6.0-P1.tar.gz
wget http://ftp.isc.org/isc/bind9/9.6.1-P2/bind-9.6.1-P2.tar.gz
wget ftp://ftp.isc.org/isc/bind9/9.6.1-P2/bind-9.6.1-P2.tar.gz.asc
gpg --verify bind-9.6.1-P2.tar.gz.asc bind-9.6.1-P2.tar.gz
tarx bind-9.6.1-P2.tar.gz
cd bind-9.6.1-P2
LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure --prefix=/usr/local --with-openssl=/usr/local/ssl --disable-ipv6
make
# /etc/init.d/named stop
make install
# /etc/init.d/named start

□note
wget で download した後、念のため gpg で検証して
おきます。

□補遺
init script の stop / start は念のため comment
にしてあります。

configure option の
  --disable-ipv6
は、当該環境が ipv6 環境でないため、disable にし
ました。

■動作確認
上記 init script が okay であれば問題ないですが、
念のため
  /var/log/message
をざっとみておくとよいと思います。

■summary
bind は、基本的には、
  configure; make; make install
でゆけます。configure option もそんなに凝るもの
ではないので、平易に install できるのではないで
しょうか。


Posted by unchor at 09:02 | Comments (0) | Trackbacks (0)
29 December
2009

rpm 既存版 bind の 削除

keywords: redhat linux rpm bind uninstallation / deletion procedure

■背景
redhat linux では当初 os installation 時に選択す
れば、rpm 版の bind が同時に install されます。

但し、(el: enterprise linux ではない、古い)red
hat linux 自体は既に support 対象外ですので、以
降の bind の version up に対する follow up につ
いては、(official な .rpm が提供されない以上)
src から compile (make) する必要があります。

しかし、src から導入すると、既存の rpm 版と併存
することになり、何某かの理由で混乱を来しかねない
ので、できれば、既存の rpm version を削除してお
きたいところです。

ということで、今回は、既存の rpm version bind の
削除手続きについて書いてみました。

■前提
src から install した bind が
  /usr/local/sbin/named
で動作すること、を前提とします。

bind の installation については、以前の項を参照。

■環境
下記、基本的には redhat linux 環境を想定しており
ます。下記は、redhat linux 7.3 とか 7.0J とか、
かなり古い linux での例です。

■方針
src 版 bind の install についてもそうなのですが、
なるべく、使い慣れた rpm 版 bind の使い勝手を残
したいと思います。例えば、
  設定 file は /etc/named.conf
  zone file は /var/named/
  pid file は /var/run/named/named.pid
  init script は /etc/init.d/named
などなど。ということで、symlink を活用します。

■削除対象 binary の(念のための)確認
□procedure
システムに導入されている bind 関連 package につ
いて、
  rpm -qa| grep bind
で検索します。上記で判明した bind の binary など
の具体的な files については、下記の commnd で確
認しました。
rpm -ql bind-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"
rpm -ql bind-utils-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"
rpm -ql bind-devel-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"
rpm -ql bind-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"| grep bin
rpm -ql bind-utils-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"| grep bin
rpm -ql bind-devel-9.2.1-10.73| grep -v -e "\/doc\/" -e "\/man\/"| grep bin

□rpm package を削除しない場合
下記の binary を実行不能にしておけば、少なくとも
間違って古い version の bind 関連の binary が動
作することは回避できます。下記は command は、念
のため comment にしてあります。

# /etc/init.d/named stop

# chmod 000 /usr/sbin/dns-keygen
# chmod 000 /usr/sbin/dnssec*
# chmod 000 /usr/sbin/named*
# chmod 000 /usr/sbin/rndc*
# chmod 000 /usr/sbin/lwresd

# chmod 000 /usr/bin/dig
# chmod 000 /usr/bin/host
# chmod 000 /usr/bin/nslookup
# chmod 000 /usr/bin/nsupdate
# chmod 000 /usr/bin/isc-config.sh
# chmod 000 /etc/rndc.*


■init script の待避と修正
rpm -e で bind を削除すると、/etc/init.d/ に格納
されている起動 script も削除されてしまいますので、
事後に書き戻せるよう、取り敢えず待避しておきます。

下記 "procedure" では、rpm 版 init script の内容
を src 版 bind が起動できるよう、path などを編集
しています。

□procedure
cd /etc/init.d/
cp named /tmp/
cd /tmp/
vi named
  :%s;/usr/;/usr/local/;g
  /usr/local/sbin/named -u named ${OPTIONS}
diff /etc/init.d/named /tmp/named
cd /usr/local/bin/
ln -s /usr/bin/killall killall

□init script 修正
上記 "procedure" では、binary の path を
  /usr/
から
  /usr/local/
に全置換し、named への path を
  /usr/local/sbin/named -u named ${OPTIONS}
と修正しました。

□ld.so.conf の確認
vi /etc/ld.so.conf
  /usr/local/ssl/lib
ldconfig

ld.so.conf に
  /usr/local/ssl/lib
への path が登録されているかを再確認します。登録
させていない場合は、先頭行に追加。

■conf file path などの微調整
□procedure
cd /usr/local/etc/
ln -s /etc/named.conf named.conf
/usr/local/sbin/rndc-confgen -a -b 512 -k rndckey
chown named.named named.conf rndc.key
chmod 775 /var/named
rmdir /usr/local/var/run/
rmdir /usr/local/var/
vi /etc/named.conf
  pid-file "/var/run/named/named.pid";
  listen-on-v6 { none; };

  logging {
  # channel "default_syslog" {
  # syslog local5;
  # };
     category lame-servers {
     null;
   };
  # category default {
  # default_syslog;
  # };
  };

□概要
前提として、これまで使い続けてきた rpm 版の bind
の設定 file を引き続き用いたいです。しかし、諸々
の pathが異なるので、この辺りの調整をする必要が
あります。

また、ipv6 環境ではないので、ipv6 関連を無効にし
ます。

上記
  logging
section では、 log に "category lame-servers" 系
の情報が追記されることを抑止する設定を追加しまし
た。

zone file の格納場所はこれまで通り
  /var/named/
とし、pid file も redhat の作法通り、
  /var/run/named/
とします。

■rpm bind deletion
rpm -e で bind package を削除しますが、この際の
ポイントは、
  ・init script が削除されようとする
  ・/var/named/ の named.ca が削除されようとする
  ・/etc/passwd から user "named" が削除される
  ・/etc/group から group "named" が削除される
  ・/var/run/named/ が削除される
  ・named が os 起動時自動起動するよう設定されている場合は解除される
辺りでしょうか。

□procedure
# rpm -qa| grep bind
# rpm -e ypbind-1.10-7 yp-tools-2.6-4
# rpm -e caching-nameserver-7.2-1
# rpm -qa| grep bind
# rpm -qa| grep bind| xargs rpm -e
# cd /etc
# mv named.conf.rpmsave named.conf
# mv rndc.conf.rpmsave rndc.conf
# chmod 000 /etc/rndc.*
# ln -s /usr/local/etc/rndc.key rndc.key
# vipw
#  named:x:25:25:Named:/var/named:/bin/false
# vigr
#  named:x:25:
# mkdir /var/run/named
# chown named.named /var/run/named
# cd /var/named/
# mv named.ca.rpmsave named.ca
# cd /usr/local/etc/
# chown named.named named.conf rndc.key
# cd /etc/init.d/
# mv /tmp/named .
# chkconfig --add named
# chkconfig --level 3 named on
# chkconfig --list| awk '{print $1, $5}'| grep "3:on"| sort


Posted by unchor at 20:16 | Comments (0) | Trackbacks (0)
19 January
2010

bind の conf file と zone file の構文検証

tools: named-checkconf & named-checkzone command

■背景
bind には conf file である "named.conf" と domain
の zone file の構文を検証する tool が付属してい
ます。conf miss で dns server が予期せぬ動作をせ
ぬよう、念のため一通り確認をしておくことは有用で
はなかろうかと思います。

reference web site: http://www.atmarkit.co.jp/flinux/rensai/bind911/bind911b.html

conf file 確認のための command は
  named-checkconf
zone file 確認のための command は
  named-checkzone
となります。src から install した場合、default の prefix では、
  /usr/local/sbin/
以下に格納されていると思います。rpm 版の場合は、
  /usr/sbin/
以下かも知れません。binary の場所は
  whereis [reference web site]
command で確認することができるかも知れません。

■named-checkconf
□概要
command "named-checkconf" は named.conf を走査し
て、その整合性を検証します。

command option で named.conf の場所を指定
  named-checkconf /etc/named.conf
できますが、省略する
  named-checkconf
こともできます。この場合、
  it defaults to /etc/named.conf
とのことで、上記 default の場所に存在する named.
conf が検証の対象となります。

□実行結果
command "named-checkconf" は結果が正常である場合、
即ち、構文上問題ない場合は、標準出力にはとくにな
にも返さず、
  exit status "0"
のみを返します。従って、通常の確認 flow は、

named-checkconf
echo $?
となります。下記
unchor@rescue:~$ /usr/local/sbin/named-checkconfunchor@rescue:~$ echo $?
0
が実行例です。

一方で、構文 error がある場合は、その内容が出力
され、
  exit status "1"
が返されます。下記
unchor@rescue:/tmp$ /usr/local/sbin/named-checkconf /tmp/named.conf
/tmp/named.conf:22: unknown option 'typo'
unchor@rescue:/tmp$ echo $?
1
が実行例です。

■named-checkzone
□概要
command "named-checkzone" は対象 domain の zone
file を走査して、その整合性を検証します。書式は、
  named-checkzone zonename filename
となります。

□実行結果
通常の確認 flow は、
cd /var/named/
named-checkzone unchor.com unchor.zone
echo $?
となります。下記
unchor@rescue:/var/named$ cd /var/named/
unchor@rescue:/var/named$ /usr/local/sbin/named-checkzone unchor.com unchor.zone
zone unchor.com/IN: loaded serial 2009120401
OK
unchor@rescue:/var/named$ echo $?
0
が実行例です。exit status は "0" です。

一方で、構文 error がある場合は、その内容が出力
され、
  exit status "1"
が返されます。下記
unchor@rescue:/var/named$ /usr/local/sbin/named-checkzone unchor.com /tmp/unchor.zone
/tmp/unchor.zone:36: unknown RR type 'Ctypo'
zone unchor.com/IN: loading from master file /tmp/unchor.zone failed: unknown class/type
unchor@rescue:/var/named$ echo $?
1
が実行例です。


Posted by unchor at 08:49 | Comments (0) | Trackbacks (0)
26 January
2010

HDD の read test と bad block の登録

HDD trouble shooting: badblocks command

■背景
HDD に bad sector ができはじめると、先ずは、seek
error / read error などが kernel messages として
  /var/log/message
に記録され始めます。

このような場合、可能であれば速攻 HDD を交換すべ
きでしょう。しかし、状況がそれを許さない場合もあ
るかと思います。

細やかながらの抵抗として、下記の延命策が有効であ
るかも知れない、ということで "badblocks" command
について書いてみたいと思います。

reference web site: badblocks

□環境
今回は、os は linux、且つ、file system が ext3
である環境を想定しております(きちんと確認してお
りませんが、freebsd とかですと、fsck の option
が異なるようです。)。

■事前準備
□既存の bad block の調査
既に bad block として何らかの登録が為されている
かについて、下記の "dumpe2fs" command によって調
べることができます。

cd /tmp/
df
dumpe2fs -b /dev/hda2
dumpe2fs -b /dev/hda2 >bad.txt

□block size の確認
今回の主たる command である "badblocks" の発行に
は、当該 file system の block size が必要ですの
で、事前に確認しておきます。block size は、下記
の "dumpe2fs" command によって調べることができま
す。
dumpe2fs /dev/hda2 |grep "Block size"

■disk の検査
当該 file system に対して disk の read 検査を行
い、seek / read error が発生した部分を bad block
として出力します。下記の例では、
  badblock.txt
として file に出力しています。
badblocks -i bad.txt -o badblock.txt -b 4096 -vs /dev/hda2

■bad block の登録
前項で、判明した bad block を当該 file system に登録します。登録は "fsck" command によって行います。
fsck -B 4096 -l badblock.txt /dev/hda2

■再確認
上記「事前準備」の項で挙げた "dumpe2fs" command
にて、前項で登録された bad blocks を確認すること
ができます。
dumpe2fs -b /dev/hda2

■用語
google: sector
google: cluster
google: block
google: track


Posted by unchor at 08:18 | Comments (0) | Trackbacks (0)
02 February
2010

php の version を 4.4.2 以降に上げたら header 関数 warning が

warning message "header()" after php version up to 4.4.2

■背景
今更 php 4.4.2 とかのお話し、というのも、随分と
時代遅れな感もございますが、
  php 4.4.1 以前
  php 4.4.2 以後
では、header 関数の挙動が変わる(仕様変更された)
ため、これまで動作していた script で http header
関連 error となる事例がありました。

■warning message
下記の warning

Warning: Header may not contain more than a single header, new line detected.
in /home/www/apache/html/php_warning/header.inc.php on line 29
が問題の warning message です。

■references
header 関数については下記
  reference web site: http://php.net/manual/ja/function.header.php
を参照。

上記の site からの引用ですが、
変更履歴
バージョン
4.4.2 および 5.1.2
説明
この関数は一度に複数のヘッダを送信できないようになりました。
これは、ヘッダインジェクション攻撃への対策です。

■原因
上記の php の仕様変更によって、header() 関数は、
複数の行を取り扱うことができず
  "not contain more than a single header"
なりました。header 関数で複数行を出力しようとす
ると、
  "new line detected"
と warning message が呈示されます。

■case study
□error script
基本的な構造は
  $headertext = "$hoge_01\n";
  $headertext .= "$hoge_02\n";
  $headertext .= "$hoge_03\n";
と header の内容を纏め、一括で、
  header($headertext);
と出力するような script が out となります。version
4.4.2 以降は、このような場合、
  header($hoge_01);
  header($hoge_02);
  header($hoge_03);
と逐次しなさい、という仕様になったと理解しました。

□simple test code
では、どうするかと考えますと、まあ下記のような素
人的な発想。
  $headertext
に格納されていた文字列を "\n" で分割して配列にい
れて、逐次出力しよう、と。
・script
unchor@rescue:/tmp$ cat test.php
<?php
$text="line1\n";
$text.="line2\n";
$do=split("\n", "$text");
foreach( $do as $value ){
echo $value."<br />\n";
}
?>
・実行結果
unchor@rescue:/tmp$ php test.php
line1<br />
line2<br />
<br />

余計な行があるらしいので確認。
・script
unchor@rescue:/tmp$ cat test.php
<?php
$text="line1\n";
$text.="line2\n";
$do=split("\n", "$text");
// foreach( $do as $value ){
// echo $value."<br />\n";
// }
print_r($do);
array_pop($do);
print_r($do);
?>
・実行結果
unchor@rescue:~/work/trash$ php test.php
Array
(
[0] => line1
[1] => line2
[2] =>
)
Array
(
[0] => line1
[1] => line2
)

□bug fix
-  header($headertext);
+# header($headertext);
+
+$header_do=split("\n", "$headertext");
+# array_pop($header_do);
+foreach( $header_do as $header_value ){
+ header($header_value);
+}


Posted by unchor at 11:47 | Comments (0) | Trackbacks (0)
04 February
2010

古い redhat linux で php configure error

keywords: expr error on php installation

■背景
上記で、「古い」と書きましたが、「古い」の定義は、
  expr –– hello
の結果が
  syntax error
となるか否か、で規定されるようです(と見做してよ
いようです)。しかし今回、その原因等々詳細な背景
については全く検証しておりません。従って、本項あ
くまでも対症です。

■error
php の configure 先頭近辺で下記の error message
が呈示されます。

unchor@rescue:/usr/local/src/apache/php-4.4.9# ./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-gd \
--with-zlib \
--with-pgsql
creating cache ./config.cache
checking for egrep... grep -E
checking for a sed that does not truncate output... /bin/sed
expr: syntax error

■reference web site
下記
  http://bugs.php.net/bug.php?id=39835
  http://www.mail-archive.com/php-bugs@lists.php.net/msg102431.html
に、同じような症状でお困りの先達の記録があり、末
尾に解法が書かれております。

□expr check
上記 web site では
# expr --version | head -1
expr (GNU sh-utils) 2.0

# expr -- hello
expr: syntax error

なので、expr が原因では、と書かれているのですが、
手許の redhat linux では、
  7.0J: expr: syntax error
  7.3: expr: syntax error
と、何れも expr syntax error となりました。

また、error message の量(行数)は異なるのですが、
何れの環境でも php configure 時に
checking for a sed that does not truncate output... /bin/sed
expr: syntax error
./configure: test: =: unary operator expected

の error message を確認することができます(多分
無視しても compile 通るような気もしますが....)。

■対処
原因は兎も角、対処可能ですので対処しました。問題
の file は、
acinclude.m4
aclocal.m4 (念のため)
configure
のようです。grep で
  "expr --"
が混入していないか、調べた結果です。

修正は下記の通り。これで、configure が通りました。
unchor@rescue:/usr/local/src/apache# diff -u ./php-4.4.9/acinclude.m4 acinclude.m4
--- ./php-4.4.9/acinclude.m4 Sun Mar 25 19:22:37 2007
+++ acinclude.m4 Tue Feb 2 09:35:55 2010
@@ -569,20 +569,20 @@
done

echo "'[$]0' \\" >> $1
- if test `expr -- [$]0 : "'.*"` = 0; then
+ if test `expr " [$]0" : " '.*"` = 0; then
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]0'"
else
CONFIGURE_COMMAND="$CONFIGURE_COMMAND [$]0"
fi
for arg in $ac_configure_args; do
- if test `expr -- $arg : "'.*"` = 0; then
- if test `expr -- $arg : "--.*"` = 0; then
+ if test `expr " $arg" : " '.*"` = 0; then
+ if test `expr " $arg" : " --.*"` = 0; then
break;
fi
echo "'[$]arg' \\" >> $1
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]arg'"
else
- if test `expr -- $arg : "'--.*"` = 0; then
+ if test `expr " $arg" : " '--.*"` = 0; then
break;
fi
echo "[$]arg \\" >> $1

unchor@rescue:/usr/local/src/apache# diff -u ./php-4.4.9/aclocal.m4 aclocal.m4
--- ./php-4.4.9/aclocal.m4 Wed Aug 6 17:36:39 2008
+++ aclocal.m4 Tue Feb 2 09:45:14 2010
@@ -569,20 +569,20 @@
done

echo "'[$]0' \\" >> $1
- if test `expr -- [$]0 : "'.*"` = 0; then
+ if test `expr " [$]0" : " '.*"` = 0; then
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]0'"
else
CONFIGURE_COMMAND="$CONFIGURE_COMMAND [$]0"
fi
for arg in $ac_configure_args; do
- if test `expr -- $arg : "'.*"` = 0; then
- if test `expr -- $arg : "--.*"` = 0; then
+ if test `expr " $arg" : " '.*"` = 0; then
+ if test `expr " $arg" : " --.*"` = 0; then
break;
fi
echo "'[$]arg' \\" >> $1
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '[$]arg'"
else
- if test `expr -- $arg : "'--.*"` = 0; then
+ if test `expr " $arg" : " '--.*"` = 0; then
break;
fi
echo "[$]arg \\" >> $1

unchor@rescue:/usr/local/src/apache# diff -u ./php-4.4.9/configure configure
--- ./php-4.4.9/configure Wed Aug 6 17:36:41 2008
+++ configure Tue Feb 2 09:49:18 2010
@@ -1725,20 +1725,20 @@
done

echo "'$0' \\" >> config.nice
- if test `expr -- $0 : "'.*"` = 0; then
+ if test `expr " $0" : " '.*"` = 0; then
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '$0'"
else
CONFIGURE_COMMAND="$CONFIGURE_COMMAND $0"
fi
for arg in $ac_configure_args; do
- if test `expr -- $arg : "'.*"` = 0; then
- if test `expr -- $arg : "--.*"` = 0; then
+ if test `expr "$arg" : " '.*"` = 0; then
+ if test `expr "$arg" : " --.*"` = 0; then
break;
fi
echo "'$arg' \\" >> config.nice
CONFIGURE_COMMAND="$CONFIGURE_COMMAND '$arg'"
else
- if test `expr -- $arg : "'--.*"` = 0; then
+ if test `expr "$arg" : " '--.*"` = 0; then
break;
fi
echo "$arg \\" >> config.nice


Posted by unchor at 20:24 | Comments (0) | Trackbacks (0)
23 February
2010

webalizer の DNS cache file 生成

keywords: webalizer & webazolver

■背景
前世紀は、apache の log 解析には専ら on demand
cgi の "analog" を使っておりました。出力はいかに
も無骨な unix style (?)。初めて webalizer の出力
をみたときは、随分と見栄えがよくて綺麗だなぁ、と
感心した記憶があるようなないような....

本項で採り挙げる "webalizer" ですが、redhat linux
のある程度の version からは、標準で os install
時に rpm 版が導入可能であったような気がします。
そしてあまり設定することもなく動かしてみると、下
記の error message が出力される、と。

■DNS cache
□error message
今回問題にする error message は

Error: Unable to open DNS cache file
/var/lib/webalizer/dns_cache.db
であり、即ち、(DNS cache file が生成されていないので)DNS cache file
  /var/lib/webalizer/dns_cache.db
を開けません、と。

□webazolver
では、DNS cache file を生成する為には、と申しま
すと、標題の
  webazolver
という command を用いよ、とのことです。引数なし
で実行すると、default の設定 file
  /etc/webalizer.conf
に従います。結果、DNS cache file が生成されるの
で、当初の error は出力されなくなる、と。

□要件
webazolver は berkeley DB を使うとのことですので、
db3 が必要のようです。依存関係の一部を調べてみま
した。
unchor@rescue:~$ rpm -qR webalizer-2.01_10-1
webserver
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
ld-linux.so.2
libc.so.6
libdb.so.2
libfreetype.so.6
libgd.so.1.8
libjpeg.so.62
libm.so.6
libnsl.so.1
libpng.so.2
libz.so.1
/bin/bash
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libdb.so.2(GLIBC_2.0)
libm.so.6(GLIBC_2.0)
unchor@rescue:~$ whereis libdb.so.2
libdb.so: /lib/libdb.so /usr/lib/libdb.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb.so
unchor@rescue:~$ rpm -qf /usr/lib/libdb.so.2
db1-1.85-8
unchor@rescue:~$ rpm -qi db1-1.85-8
Name : db1 Relocations: /usr
Version : 1.85 Vendor: Red Hat, Inc.
Release : 8 Build Date: Wed Apr 3 05:06:48 2002
Install date: Tue Oct 26 20:18:21 2004 Build Host: stripples.devel.redhat.com
Group : System Environment/Libraries Source RPM: db1-1.85-8.src.rpm
Size : 76904 License: BSD
Packager : Red Hat, Inc.
URL : http://www.sleepycat.com
Summary : The BSD database library for C (version 1).
Description :
The Berkeley Database (Berkeley DB) is a programmatic toolkit that
provides embedded database support for both traditional and
client/server applications. This package should be installed if
compatibility is needed with databases created with the Berkeley DB
version 1. This library used to be part of the glibc package.

□問題
そもそもの DNS cache の目的は、ip address の逆引
きですが、上記で一回生成しただけでは、基本的には
当初の目的は達成しません。何故ならば、全く更新さ
れないからです。上記は、あくまでも error 対策、と。

この辺りについて、下記
  http://webalizer.robata.org/dns_readme.html
の web site が詳しいようです。

しかし一方で、dns_cache が肥大化した [google] と
いう事例もあるようです。わたくしの環境では、dns
cache は用いていないので、検証しておりませんが。


Posted by unchor at 09:07 | Comments (0) | Trackbacks (0)
[1]   2   3   Next