目次
アップグレード
2.6r4から3.0へのアップグレード中に止まる
アップグレードインストールがうまくいかない場合があります。2.6r4に対して、3.0のCD-ROMから、アップグレード・インストールを指示すると、途中までは順調に進みますが、emacs-20.7あるいはw3m.elのインストールで刺さる場合があります。
どうやら、パッケージの導入後の作業で、(どちらの場合も)w3m.el関連のファイルをバイトコンパイルしようとして、失敗を続けているようです。1)
とりあえず、ctrl+alt+[F2]で、シェルが起動している仮想コンソールを呼び出して、make が走っているプロセスを kill すれば先に進みます。このとき、インストール言語を日本語にしている場合には、何かコマンドを実行する前に、
-bash-2.05# export LANG=C
としておきましょう。こうしておくことでメッセージが英語になります。konをするという手もありますが、konをやると、後で、Xの画面に戻ってからもう一度、シェルに戻ったときに、画面制御がおかしくなって困ることがありますので、しないほうがいいでしょう。
なお、シェルでの作業から、インストーラ画面への復帰は alt+[F7]になります。
開発環境がない
3.0になってからは、およそ開発環境に当たるものは、ばっさりと切り捨てられて導入されません。(さすがに gccくらいは入っていますが)
ので、何かをビルドする場合には、apt-get install xxx-develなどとして、開発環境を導入しまくるのが最初の仕事になると思います。
サーバとしての強固さを考えた場合には、一切の開発環境を排除するというのもありですが2)、ビルド用のマシンを別途用意できるような場合以外はそうもいってはいられませんね。
apt-get update ができない。
pubring.gpg3)が空なので、インデックスが取得できません……というようなエラーをだして、apt-get updateがうまくいかないかもしれません。インデックスを取得できなければ、アップグレード作業はできませんので、これでは困ります。
通常、正常にインストールできていれば、この情報は、きちんと存在してます。このファイルを管理するのは、vine-keyringというモジュールで、これがインストールされると、自動的にこのファイルを正しい状態にしてくれるのです。
ところが、インストール中に、時計が何かの弾みで狂うなどしていると、この作業が中断してしまうことがあります。具体的には、時計が、初期化(?)されるなどして、古い時間を指している場合などです。このとき、vine-keyringモジュールのインストール作業において、pubring.gpgの作成が、「キーが未来に作成されています」というようなエラーで失敗してしまうのです。時計を直してから、
-bash-2.05# rpm -Uvh --force vine-keyring-1.0-0vl10.noarc.rpm
などとして、強制上書きしましょう。これで正しく問題のファイルが生成されます。
Postfix + Cyrus-SASLによる SMTP Authがうまく有効にならない
SMTP Authは、セキュアなSMTPサーバを構築するひとつの有効な手段です。ローカルか認証されているサイトからのメールの発信、中継以外は認めないというわけです。pop before smtpなどに比べて、クライアント側の手間が少ないですが、MUAが対応している必要があります。京ポンでも対応しているので、大体対応していると思っていいのでしょうが。
2.6時代には、VinePlusに入っていた Cyrus-SASLは、3.0ではbaseパッケージに加わっています。ところが、このCyrus-SASLが、Postfixがアテにしているpwcheck機能をなしでビルドされているので、このままcyrus-sasl-develをインストールしてもダメなのです。(2.6ではちゃんと有効だった。)4)
そこで、postfixをリビルドする前に、Cyrus-SASLをリビルドします。
-bash-2.05# apt-get source postfix cyrus-sasl
として、ソースパッケージを取得します。展開されたパッケージのうち、/usr/src/vine/SPECSに展開されている、specファイルを修正します。
cyrus-sasl.specは、–without-pwcheck と書かれている部分を –with-pwcheckに直します。
156: --with-saslauthd=/var/run/saslauthd --without-pwcheck \
156: --with-saslauthd=/var/run/saslauthd --with-pwcheck \
なお
%define release 6vl1
となっている部分を
%define release 6vl1.1
などとしておくと、純正パッケージとの区別が付くし、rpm -Uで、アップデートするのが容易になります。 なお同時に、cyrus-saslのこのソースパッケージ(2.1.15-6vl1)は、3.0のシステムではビルドできません。automake-1.7に依存しているからです。 幸い、automake17というパッケージがありますので、これをもってきます。
-bash-2.05# apt-get install automake17
そして、cyrus-sasl.spec の中にある、aclocal と automake の呼び出し、三箇所ずつ5)をそれぞれ、aclocal-1.7 と automake-1.7 とで置き換えます。
ここまでやったら、
-bash-2.05# rpm -ba cyrus-sasl.spec
として、パッケージを作成します。もしかしたら、途中で、何かのパッケージが必要というエラーが出るかもしれません。そしたらその都度、そのパッケージを追加してください。
さて、SASLの用意ができたら、いよいよ postfix です。詳しい情報はあちこちにあると思いますので、ポイントだけ。
postfix.spec の116-117行目を次のように修正します。
116: -DHAS_PGSQL -I/usr/include/pgsql \ new: -DUSE_SASL_AUTH" \ 117: AUXLIBS="-lsasl"
なお、SASL2を利用したいなら、
116: -DHAS_PGSQL -I/usr/include/pgsql \ new: -DUSE_SASL_AUTH -I/usr/include/sasl" \ 117: AUXLIBS="-lsasl2"
とします。ただしこちらの挙動は検証していませんので使えるかどうかわかりません。6)
ビルドとインストールがすんだら、main.cf に次の設定をします。
smtpd_sasl_auth_enable = yes
smtpd_sasl_auth_domain = $mydomain # パスワード登録がホストでなら $myhostname
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated
reject_unauth_destination,
pcre:/etc/postfix/access_regexp, #特定のパターンがあるなら
permit_auth_destination,
reject
そして、/usr/lib/sasl/smtpd.conf に
pwcheck_method: sasldb
と書いて、postfix を再起動します。なお、利用許可するユーザは、
-bash-2.05# /usr/local/sbin/saslpasswd -c -u `postconf -h myhostname` ユーザー名 (多分、sasl2ならsaslpasswd2を使う)
でデータベース(/etc/sasldb)にパスワードを追加しておきます。
カウンタが働かなくなった(mod_ruby + cgi + ruby-dbi + postgresql-ruby)
当サイトのカウンタは、XOOPS上にあるものも含めて、Ruby+PostgreSQLで構築されています。
今回、PostgreSQLが7.4.3に、また、Rubyが1.8.1にそれぞれアップグレードした関係でだと思われますが、カウンタが機能しなくなっていました。
一応表示はかかるのですが、あらゆるアクセスが同一サイトからのアクセスとみなして、カウンターの更新が機能しなくなってしまったのです。
調べてみると、原因は、nullカラムの、dbiを通しての返り値が、nilから“”(空文字列)に変わっていたためと判りました。このようにRubyや、Perlといったものの大きなバージョンアップは思わぬトラブルを起こすことがあります。
grub-installにバグあり? → 0.95-0vl1.2で修正済み
0.95-0vl1のgrub-installにはバグがあります、多分。新しいgrubは、古いのと異なり、devfsをサポートしているのですが、実際に devfsで管理されているマシンで実行しようとするとエラーが出ます。
0.95-0vl1.2がリリースされこの問題は修正されています。0vl1で同様の問題が生じている方は是非アップグレードして、トライしてみてください。7)
469行目付近の
-e 's%.*d[0-9]*p*%%' \
は
-e 's%.*d[0-9].*p*%%' \ (もしかしたら -e 's%.*d[0-9].*p.*%%' \かも)
じゃないと、ダメなのです。オリジナルのままでは、devfs的HDDの表記
/dev/ide/host0/bus0/target0/lun0/disc
が、(上記のルールの後ろにこれを処理するルールは書かれています)ここにマッチして、
isc
という形に変形させられてしまうので問題を起こすのです。 まぁdevfsなんて使っていなければ問題ないんですけれど :cry:
grub-installがなんだか変
おまけですが、grub-installしたのに、だんまりになってしまうということがあるかもしれません。よくわかりませんが猛烈に時間がかかります。だんまりは時間がかかっているだけです。気長に待ちましょう 
//–no-flopp// オプションをつけると少し早くなるかもしれません。
3.1から3.2へアップグレードする。
このアップグレードはaptで行なうことができます。
/etc/apt/sources.list
を開いて、3.1をすべて3.2に置き換えてから
# apt-get update # apt-get dist-upgrade
するだけです。なおカーネルも更新対象ですが、例によってカーネルは自分で明示的にインストールしなければなりません。なお、2005年9月19日現在、aptで取得できるカーネルソースが何故か2.4.27-0vl7.6と、リリースにある2.4.31ベースではありません。各ftpサイトにミラーされているソースパッケージは2.4.31-0vl1.17と2.4.31-0vl1.18とがあります。多分、新しい方(0vl1.18)を取得すればよいと思います。
注意すべき事項(パッケージに関して)
標準のパッケージは特に問題ありませんでしたが、amavis-newが動かなくなりました。理由はパッケージの欠損です。IO::Wrap(とIO::Stringy)がないために、起動しなくなっていました。
インストールはCPANモジュールを使えばいいでしょう。かつてはperl-IO-stringyなどのモジュールもあったようですが、現在はないようです。(perl 5.8.0用のモジュールがインストールされているのですが、aptでも更新されないので、廃止されたのでしょう。)
# perl -MCPAN -e shell cpan> install IO::Wrap ... /usr/bin/make install -- OK cpan>
この過程でIO::Stringyも自動的に導入されます。なお、amavis-newを2.2.1から2.3.1にアップグレードしたのですが、その過程で Convert::UUlibのアップグレードも要求されました。これも同様に CPANモジュールでアップグレードすればいいでしょう。
# perl -MCPAN -e shell cpan> install Convert::UUlib ... /usr/bin/make install -- OK cpan>
3.0から3.1へアップグレードする。
このアップグレードはaptで行なうことができます。
/etc/apt/sources.list
を開いて、3.0をすべて3.1に置き換えてから
# apt-get update # apt-get dist-upgrade
するだけです。なおカーネルも更新対象ですが、例によってカーネルは自分で明示的にインストールしなければなりません。
注意すべき事項(パッケージに関して)
Postfixがアップデートされますので、SMTP-Authを利用している場合は上記のリビルドが必要となります。
bindの更新のタイミングがおかしいため、DNSの再起動に失敗しています。主導で、再スタートして完了。
aspellのパッケージングが変わり、旧aspell → aspell + aspell_el になりました。emacsで利用している場合には、aspell_elも導入しないと emacsの初期化に失敗します。
自分用: カーネルのアップグレード
うちのサーバのカーネルは、バイナリパッケージではなく、ソースパッケージからビルドする必要があります。理由は、devfsを使っているからとCPUが Cyrix C3だからの二点です。普通のユーザはこんなことを気にする必要はありません。
ソースパッケージの入手
カーネルのソースパッケージは、ftpで直接、RINGなどからとってきてもいいのですが、たまに更新が遅かったりするので、apt経由で取り込むのがいいでしょう。
# apt-get source kernel
これで /usr/src/vine の下にカーネルパッケージが導入されます。が、展開されたそれらには取り合えず、用はなくて、必要なのはこのときカレントディレクトリに残る、src.rpmの拡張子のパッケージそのものの方です。
ソースのリビルド
ソースのリビルドは単純に rpm –rebuild でやるのではなく、/usr/sbin/mkkpkg を使います。
# mkkpkg kernel-2.4.26-0vl16.src.rpm
の様にしてやるだけです。なお、我が家の場合は、SPECファイルの編集の必要はないですが、menuconfigの必要はあります。なお、区別のために、パッケージのバージョンを 0vl16 だったら 0vl16.1のようにしておきます。
menuconfigで修正すべき点
二点あります。
- CPU → VIA CyrixIII/C3
- File System → /dev filesystem の追加と devfs の自動マウント
これをしないと我が家では破綻を来たします。要注意 > 自分
SpamAssassin:http://www.spamassassin.org
SpamAssassinは、メールのスパムらしさを判定し、その結果をヘッダやサブジェクトに付与してくれるツールです。付与されたヘッダ情報を元に、メイラやprocmailなどで、ふるい落とすことで、かなりのスパムメールを葬り去ることができます。
比較的、非スパムメールをスパムと判定することが少ない点が特徴だと思います。(その代わり、漏れもあるので、このあたりはPOPFileとは好対照といえるかもしれません。)
2.xから3.xへのアップグレード上の注意。
/etc/mail/spamassassin/local.cfや~/.spamassassin/user_prefs といった設定ファイルは、2.xようのものをそのまま流用すると、機能しません。雛形を、configuration toolで作成してから、旧来の設定ファイルの内容を一つ一つ確かめながら移入するのがいいでしょう。RAZOR周りの設定は新しい形式でないと致命的なようですので、特に注意してください。
また、旧版でせっせと集めた、ベイジアン・フィルタの学習結果は、新しい版にはそのままでは引き継げません。sa-learnコマンドを使って、移入してやる必要があります。
$ sa-learn --import
これで、古いファイルは old_bayse_seen, old_bayse_toks のように old_というprefixがつけられて保存され、新しいファイルに内容が移行されます。新しいファイルは、DB形式のファイルになっているようで、この形式変換が必要なわけです。
VineLinuxに関してに戻る。