2005-01-14 (Fri)

_ [debian] nfs-utils 1:1.0.7-1vd2

nfs-utils-1.0.7-CITI_NFS4_ALL-1.dif を当てて作成。

_ [vdr] 外部からの apache2 接続変

2004/12 末ごろからずっとおかしい。

  • 外部から apache2 接続をたまに受け付けなくなる。
  • 外部から apache2 以外の接続は OK。
  • 内部から apache2 接続は OK。

何だろう、これは。

2005-01-13 (Thu)

_ [debian] nfs-utils 1:1.0.7-1vd1

nfs-utils-1.0.7-pre2-CITI_NFS4_ALL-1.dif を当てて作成。

_ [debian] nfsidmap 0.9-0vd1, 0.10-0vd1

また debian/ 以下がからっぽだったので前回の 0.8 の debian/ 以下を流用して作成。 0.10 が出ていたが、やっぱり debian/ 以下はからっぽ。

_ [comp] ruby-postgres+PostgreSQL+pidentd おかしい

ruby-postgres から PostgreSQL に接続に行ったら、

PGError: FATAL:  IDENT authentication failed for user "XXXXXXXX"

とエラーが。syslog には

identd[XXXXX]: netlink_lookup: write failed: Connection refused

こんなログが。何事? 追跡しようかと思ったが、それより今は研究のほうを進めたいので s!ident sameuser!trust! /etc/postgresql/pg_hba.conf した。

_ [comp] ruby getopts

使い方を完璧に勘違いしていた。第一引数は1文字オプション、第二引数以降はロングオプションや引数を取るオプションという決まりが頭から抜けていた。

_ [comp] svn おかしい

コードを書いて、まず1回目の svn commit。ここまでは問題なし。さらにコードを書いて2回目の svn commit したら、

% svn commit
svn: XML パーサが '/XXXXXXXX/XXXXXXX' でパースに失敗しました
% LC_ALL=C svn commit
svn: XML parser failed in '/XXXXXXXX/XXXXXXX'

おいおい、勘弁してくれ。どうも .svn/ 内が腐ったらしい。svn co し直してみると、

% svn co file:///XXXXXXXX/XXXXXXX/SVN/repo
        :
zsh: segmentation fault (core dumped) svn co file:///XXXXXXXX/XXXXXXX/SVN/repo

おいおい、本気で勘弁してくれ。SVN/repo 内も腐ったか? まてよ。apache2 を Large File Support 有効でビルドしたせい? subversion は apache2 の libapr を使っているから、もしかしたら…。あった。#244897 に Large File Support の有無で libapr の ABI が変わってしまう、と書かれている。 というわけで、subversion を rebuild してみたところ、svn co は SEGV らずに行けた。新しく co した .svn/ と腐らせてしまった .svn/ を比べてみると、腐った .svn 内の text-time と prop-time が完全に狂っていた。例えば、

-   text-time="1906-06-04T13:04:54.-629184Z"
+   text-time="2005-01-13T10:16:54.000000Z"

-   prop-time="1928-11-26T21:16:11.-769776Z"/>
+   prop-time="2005-01-13T10:16:53.000000Z"/>

UNIX epoch 以前だったり、負になっていたり。この腐った .svn/ を破棄して新しい .svn/ と取り換えたところ、問題なく作業ができるようになった。ふー。

_ [debian] subversion 1.1.1-2vd1

Large File Support を有効にした libapr0 向けに作成。

_ [vdr] プロバイダ変更

7年間世話になったプロバイダの契約を更新しないことにした。新天地の準備ができたので、さくっと移転。

2005-01-12 (Wed)

_ [comp] apache2 2GB, 4GB の壁。

apache2 の扱えるファイルサイズには 2GB、4GB それぞれに壁があるという話を聞いたので、手元の apache2 2.0.52-3vd1 で確認してみる。2GB、4GB のファイルを作成。

% touch 2GB 4GB
% perl -e 'truncate shift, shift' 2GB 2349991936
% perl -e 'truncate shift, shift' 4GB 4699983872

telnet で接続して確認してみる。

% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /2GB HTTP/1.0

HTTP/1.1 403 Forbidden
Date: Tue, 11 Jan 2005 22:08:54 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

Connection closed by foreign host.

error_log には

[Wed Jan 12 07:08:54 2005] [error] [client 127.0.0.1]
 (75)Value too large for defined data type: access to /2GB failed

と記録された。4GB でも同様の結果。 まず、話の中で出てきた Large file support (> 4GB) for platforms w/ 32-bit size_t and 64-bit off_t で示されている ap_splitlfs.diff を当ててみる。が、結果は変わらず。 さらに調べてみると、#241223 にて

LARGEFILE_SOURCE
FILE_OFFSET_BITS=64

というコンパイルオプションが示されている。 また、/usr/share/doc/apache2-common/README.Debian を見てみると、

  • Despite large file support being enabled, you won’t actually be able to SERVE large files from apache2 unless you’re using a kernel that supports the sendfile64 syscall. For i386, this is any recent 2.4.x or 2.6.x kernel, for most other architectures, this means an upgrade to 2.6.x.
ref. /usr/share/doc/apache2-common/README.Debian

となっているが、2.6.x に上げてしまっているので問題ない。 結果、ap_splitlfs.diff を当て、_LARGEFILE_SOURCE 及び _FILE_OFFSET_BITS=64 のコンパイルオプションを渡して apache2 を build したところ、2GB、4GB のファイルどちらも問題なく扱えるようになった。

_ [debian] apache2 2.0.52-3vd2,3

ap_splitlfs.diff を当てた vd2 を作成。だが、うまく動作しなかった。 さらに、debian/rules でコメントアウトされている

AP2_CONFLAGS += -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

を有効にした vd3 を作成。こちらは問題なく動作した。

_ [debian] wget 1.9.1-10vd1,2,3

wget にも 2GB の壁があるようだ。2GB のファイルを転送しようとすると、取得サイズが負になっていて途中で切れてしまった。#240281 で示されている int64_t.patch を当てて vd1 作成。 って、http だけ対処か…。ftpd のチェックに wget を使ったら、最後の最後で core 吐いた。いろいろ探してみると、 Large file support for wget under Unix で patch を発見したのでこれを当てて vd2 作成。 ビルドはできたがミスってたので修正して vd3 作成。http/ftp どちらもきちんと動作した。

_ [debian] lukemftp 1.5-8vd1

lukemftp にも 2GB の壁。コンパイルオプションに -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 を追加して対処。

_ [debian] tdiary 2.0.0+2.1.0.20050112-0vd1

CVS から引っ張ってきて作成。

_ [debian] blackbox 0.70.0beta3-0vd1

いつの間にか出てたので作成。 0.65.0-3 の debian/rules をそのまま使うと、起動時にクラッシュする。CXXFLAGS にいろいろついてるのがまずいような。外してビルドしてみたら、きちんと動作するようになった。