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.
となっているが、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 にいろいろついてるのがまずいような。外してビルドしてみたら、きちんと動作するようになった。
2005-01-11 (Tue)
_ [debian] mozilla-firefox 1.0+dfsg.1-2vd1
vd_bugzilla-jp_bug-1476_attachment-1656_for-mozfx-0.9.3.patch、vd_mozfx-0.10.1_without-gnome-and-gconf.patch、mozilla-1.8a5-gtk2-composition-fix.diff を当てて作成。
_ [debian] heimdal-kdc 0.6.3-6 変
MIT krb5 は Kerberos5 の MIT リファレンス実装で、Kerberos5 の free 実装版の Heimdal のほうを使ったほうが Debian 的にはいいようだ。というか MIT krb5 ってアメリカの輸出規制にひっかかってるんだっけ？ ということで Heimdal のほうを試しに入れてみようかとしたら、heimdal-kdc 0.6.3-6 の install で
Section realms::REALM.ORG doesn't exist
Cannot parse command line
と失敗してしまった。探してみると #289295 にひっかかってしまったようだ。示されている patch を /usr/share/doc/heimdal-kdc/examples/kdc.conf に当てて突破。
_ [comp] Heimdal テスト
Krb5Debian と Krb5Plamo を見つつ、やってみる。 いろいろ設定して試したけど、kinit で Kerberos V5 のチケットしか取ってないのだが、ktelnet は Kerberos V4 でしかつなぎに行かない。どうなってんだろ、これ。–without-krb4 でパッケージを作ってみたけど、やはり Kerberos V5 で認証している気配がない。設定ミスか？ と思ったら、kftp のほうはきちんと行けた。よくわからん。NFSv4 もできたので、手順をメモ。 構成などは Kerberos5 テスト に準じる。 まず Heimdal を install。
# apt-get install heimdal-kdc heimdal-servers heimdal-clients
realm 名と KDC の password を聞かれるので設定。 /etc/krb5.conf は MIT krb5 のそれと同じ。/var/lib/heimdal-kdc/kdc.conf は MIT krb5 の /etc/krb5kdc/kdc.conf とほぼ同じ。 KDB は install 時に、kstash 及び kadmin -l init REALM の実行によって作成されているのでパス。 管理 principal を登録。
# kadmin -l
> add foo/admin
password を聞かれるので設定する。/var/lib/heimdal-kdc/kadmind.acl で ACL を設定。
foo/admin@EXAMPLE.JP all *
foo の user principal を追加。
# kadmin -l
> add foo
password を聞かれるので設定する。 server で server, client 両方の nfs principal を追加。
# kadmin -l
> add -r nfs/server.example.jp
> ext_keytab nfs/server.example.jp@EXAMPLE.JP
> add -r nfs/client.example.jp
> ext_keytab nfs/client.example.jp@EXAMPLE.JP
/etc/krb5.keytab が生成されたことを確認。 server で client 用の keytab を生成。
# kadmin -l
> ext_keytab -k /tmp/keytab nfs/server.example.jp@EXAMPLE.JP
> ext_keytab -k /tmp/keytab nfs/client.example.jp@EXAMPLE.JP
server:/tmp/keytab を client:/etc/krb5.keytab としてコピー。 この後の作業は MIT krb5 の場合 と同様。 なお、MIT krb5 でも Heimdal でも、
client# mount -t nfs4 -o sec=krb5 server:/ /mnt
はきちんと動作しなかった。何かが足りない？
_ [comp] dnsmasq
お手軽 DNS キャッシュ用に dnsmasq を入れてみる。