設定したことを忘れないように書いてあります。
PCの調子が悪くなり、マザーボードを交換。
設定変更が面倒なので、同じチップセットのもの選んだため、HDDをそのままつけて問題なく起動。
と、思ったら、/dev/hdc2がFAIL-DISKとなってしまった。/dev/hdcの他のパーテションは問題ないので、どうしてだろうと思い、 調査のために、/dev/hdc2をマウントしようとしたら、/dev/hdc2がない!
ls -al /dev/hdc*とすると、確かになかった。
と、いうことで、とりあえず mknod -m 660 /dev/hdc2 b 22 2と、nodeを作ってみる。 ついでに /dev/hdaもなかったので、こちらも作成。
rebootして、raidhotadd /dev/md0 /dev/hdc2 とすると、問題なくraidに追加されたので、良しとする。
会社で立てたApacheサーバにアクセスする際、ディレクトリ参照の/を忘れるとアクセスエラーとなる。 末尾のスラッシュが補完された後に返す名前が、FQDNで返らないため、名前解決ができなくなるという問題のようだ。
現象自体は以前からわかっていたのだが、googleで検索してもうまく事例を引っかけられず、解決できないでいた。
ま、そもそもどんなキーワードで引くべきかわからないからなんだが。そのためここでは、なるべくいろんな記述をとるようにしている。
で、やっと解法が見つかったので、ここに記しておく。http.confに、
UseCanonicalName ON ServerName my.server.name
と記述すると、ディレクトリをスラッシュ無しで参照した場合に返すサーバー名を設定できる。 ServerNameディレクティブに記述すれば、そのサーバーにリダイレクトされる。 UseCanonicalNameの意味は、サーバが自分自身のURIをつくる必要が発生した場合(ま、この現象のように、再度ディレクトリ名でアクセスさせたいとき等)に、 ServerNameを参照するか、クライアントから送られてきた値を返すかを設定するディレクティブ。 ONならばServerNameに記述したものを返す。ま、バーチャルホストで使うことが多いんじゃないかな。
このディレクティブに関しては、既にに設定していたのだが、当然のことながら、 バーチャルホストを使っている場合は、coreの記述とは別に、<virtualhost></virtualhost>の範囲にも、 ServerNameを記述しておく必要がある。 考えればわかりそうなものだったね。
postgresqlをインストール。Vine Linuxにはあらかじめ入っていたような気もするが、MySQL使いだったので、MySQLを入れ直した覚えがある。 今回、家では違ったSQLサーバを試してみたいと思い、Postgresqlを入れてみた。
やりたいことは、phpおよびperlからのDB操作なので、
apt-get install php-postgress apt-get install postgresql apt-get install postgresql-server
をインストールした。その後、DBをイニシャライズし、postgresqlサーバが立ち上がるようにした。
|root #su - postgress |bash-2.04$>initdb | |The files belonging to this database system will be owned by user "postgres". |This user must also own the server process. | |Fixing permissions on existing directory /var/lib/pgsql/data... ok |creating directory /var/lib/pgsql/data/base... ok |creating directory /var/lib/pgsql/data/global... ok |creating directory /var/lib/pgsql/data/pg_xlog... ok |creating directory /var/lib/pgsql/data/pg_clog... ok |creating template1 database in /var/lib/pgsql/data/base/1... ok |creating configuration files... ok |initializing pg_shadow... ok |enabling unlimited row size for system tables... ok |creating system views... ok |loading pg_description... ok |vacuuming database template1... ok |copying template1 to template0... ok | |Success. You can now start the database server using: | | /usr/bin/postmaster -D /var/lib/pgsql/data |or | /usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start | |bash-2.04$ exit |root# chkconfig postgresql on #### 起動時にサーバが立ち上がるようにする。 |root# /etc/init.d/postgresql start #### postgressを起動 |Starting postgresql service: [ OK ] |root# su - postgres |bash-2.04$ createuser -d -A apache #### apache用のユーザを作成
その他ユーザは、必要に応じて作成。phpの方は/etc/php.iniを直しておく必要があるが、Vine Linuxはすでに設定済みのため特に変更はなし。
Shurikenを使うことに決めたので、IMAP4サーバを立ち上げる。 すでにimap-2001a-10vl3が入っていたため、/etc/inetd.confのimapの行のコメントを外して、
/etc/init.d/inet restart
を行うだけでok。だったのだが、デフォルトの設定のままでは、
このため、/etc/c-client.cfを以下のように作成する。
I accept the risk for IMAP toolkit 4.1. set new-folder-format mbx set mail-subdirectory Maildir
一行目は、この文字列をみてtoolkitが判定をするらしい。この文字列がないと以下の設定は無視されます。
二行目は、新しく作成されるフォルダはmbx形式とするという意味。この設定を記述する前のものは、 mboxのままだが新規に作ったものは、mbxになる(ようだ）。
三行目は、各ユーザのホームディレクトリ配下のMaildir以下がメールディレクトリになる。 あらかじめMaildirが作成されていない場合の動作は保証されていない。
という設定。これらは、(英語だけど)/usr/doc/imap-2001a/imaprc.txtに書いてあります。
これでとりあえずサーバ側の設定は完了。
使った感じは、サーバ側フォルダの操作をすると結構時間ががかるという感じ。
メーラ上はすでに移行が終わっているように見えるのだが、そのフォルダを参照するとファイルの移動が発生し待たされることが多い。 これは、shurikenの実装の問題なのか、サーバの問題なのかは不明。とにもかくにも、サーバ側でのメール管理が実現できた。
ちゃんとkernelがRAIDに対応している起動ディスクが必要だということで、KNOPPIXのディスクを作成し起動。 その状態で、kernelを再作成した。
/mntに、/dev/md0(root)と/dev/md1(/boot)をマウントして、chroot /mntとし、liloを更新。とやってみたが、うまくliloが反映されず。 なぜか、liloの起動中にL 99 99 99 99 となってしまう。どうやら正しくインストールされていない様だが、メッセージは特になし。
仕方ないので、再びKNOPPIXを起動して、/dev/hda2の/etc/lilo.conf.resqと最低限のものを作成し、 Vine Linuxのインストールディスクで途中まで起動させ、Alt-F2で画面を切り換え、/var/tmpに/dev/hda1と/dev/hda2をマウント、chroot /var/tmpした後、 lilo -v -C lilo.conf.hdaを行い、無事起動した。
復旧するために、Vine LinuxのCDを作って起動し、upgradeをかける。 liloをインストールしないと設定したので、kernelは更新されないだろうと思っていたが、kernelが更新されてlilo -vを実行された上、昔のカーネルが削除されていた。
当然、kernelはソフトウエアraidに対応していないため、起動に失敗する。
Vine Linuxのdistributionが2.6から3.0に上がったため、upgradeを実施した。 まず、/etc/apt/sources.listに3.0のディレクトリを設定して、dist-upgradeをかけてみたが、aptが更新された時点でそれ以上何もできなくなる。 ftpでダウンロードしてローカルからupdateするが、改善されない。
で、前述のようにやっていたのだが、raidにコピーしてbootしたときに、
cramfs: wrong magic kernel panic
となる。raid系のdriverをスタティックに組み込まなかったのかといろいろ試行錯誤、mkinitrdで ブートイメージを作ったりしたが、何のことはない、fsタイプを83からfdに変更していなくてオート でマウントできなかっただけだった。 fdiskで切ったときにfdにしていたつもりだったので、チェックが後回しになってしまった。
で、元のディスクをfdiskできりなおす。パーティションサイズは、raidで使用しているものと同サイズか それ以上でないとraidに組み込むことができない。こんどはちゃんとfdにfsタイプを設定して、raidhotadd /dev/md0と順に追加。 liloの設定をしてから再起動で完了。
ついでに現在ext2からext3に変更。kernelにスタティックに組み込んでいることを確認して、
tune2fs -j /dev/md0
と順にコンバート。本来はmountしたままではやらない方がよいとのことだが使用中なので仕方がない。 /etc/fstabをext3に変更して再起動。
最終的にディスクは以下のとおりとなった。
ディスク /dev/hda: ヘッド 255, セクタ 63, シリンダ 5005 ユニット = セクタ数 of 1 * 512 バイト デバイス ブート 始点 終点 ブロック ID システム /dev/hda1 63 530144 265041 fd Linux raid 自動検出 /dev/hda2 * 530145 8932139 4200997+ fd Linux raid 自動検出 /dev/hda3 8932140 9992429 530145 82 Linux スワップ /dev/hda4 9992430 80405324 35206447+ 5 拡張領域 /dev/hda5 9992493 45206909 17607208+ fd Linux raid 自動検出 /dev/hda6 45206973 62814149 8803588+ fd Linux raid 自動検出 /dev/hda7 62814213 80405324 8795556 fd Linux raid 自動検出 ディスク /dev/hdc: ヘッド 16, セクタ 63, シリンダ 77545 ユニット = セクタ数 of 1 * 512 バイト デバイス ブート 始点 終点 ブロック ID システム /dev/hdc1 63 514079 257008+ fd Linux raid 自動検出 /dev/hdc2 * 514080 8653679 4069800 fd Linux raid 自動検出 /dev/hdc3 8653680 9680831 513576 82 Linux スワップ /dev/hdc4 9680832 78165359 34242264 5 拡張領域 /dev/hdc5 9680895 43792559 17055832+ fd Linux raid 自動検出 /dev/hdc6 43792623 60848927 8528152+ fd Linux raid 自動検出 /dev/hdc7 60848991 78165359 8658184+ fd Linux raid 自動検出
]$ cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath]
read_ahead 1024 sectors
md1 : active raid1 hdc1[0] hda1[1]
256896 blocks [2/2] [UU]
md0 : active raid1 hdc2[0] hda2[1]
4069696 blocks [2/2] [UU]
md2 : active raid1 hdc5[0] hda5[1]
17055744 blocks [2/2] [UU]
md3 : active raid1 hdc6[0] hda6[1]
8528064 blocks [2/2] [UU]
md4 : active raid1 hdc7[0] hda7[1]
8658112 blocks [2/2] [UU]
unused devices: <none>