interfacesでバッククオート使えるんだ…
先日、IPv6の設定の実験をしていたけど、自宅サーバはDynamic DNSであるため、 アドレスが変化する可能性がある。 そうなると、/etc/network/interfaces で設定するIPv6アドレスも変化する。 このため、"iface tun6to4 inet6 manual"で設定していた。 しかし、アドレス部分でコマンドが使えないかとバッククオートを試したら、 使えるじゃん…
auto tun6to4 iface tun6to4 inet6 v4tunnel endpoint any address `/bin/cat /var/run/DDNS.ipv6`::1 # 我が家のDDNSのipv6アドレス(2002:XXXX:XXXX) netmask 16 gateway ::192.88.99.1 #公衆6to4リレールータ local 192.168.XX.XX #ルータの中なのでprivate
ただし、まだ radvd の設定がまずく、ルータ以外のPCがグローバルなIPV6に接続できない…
/etc/login.defsのMAIL_DIR修正
随分前から気になっていたけど、原因調べる気もなかったんだけど、 ターミナルソフトでサーバに入ると、未読も無いのに "You have new mail…" 日曜の昼寝後にふと直す気が起こったので調べると、 /etc/login.defs の MAIL_DIR に、"MAIL_DIR /var/mail" と書いてあるのが原因とな。 いまどき、login.defs 触るとは…
(( /etc/login.defs )) MAIL_DIR Maildir ←修正 #MAIL_DIR /var/mail ←コメントアウト #MAIL_FILE .mail
DebianでソフトウェアRAID構築
職場に新しく導入するサーバなんだけど、セットアップを自宅でするために持ち帰り中。 でも、RAIDのために搭載されているボードが、 "Intel Embedded Server RAID Technology II"なる製品で、導入予定のDebian/squeezeでは サポートが不完全みたい。 RAIDボードのBIOS画面で、2台のHDDをRAID1で構築するために、 設定を行い、Debian インストーラを立ち上げるけど、md126(read-only)と書かれて、 書き込みができずインストールに失敗。
色々調べても、よく解らないし、基本はSoftware RAIDっぽいので、いっそのこと RAIDボードは使わずに、素のSoftware RAIDでインストールすることにした。 性能の低下といっても、HDDアクセスが頻繁でなければわずかだし、 Software RAIDなら不整合トラブル時に、メールを出すとかの設定もできる。
ということで、sda , sdb のドライブに、/boot 用の領域100MBほど作り、 残りの領域をRAID構成にしたうえで、その中に LVM のボリュームグループを作り、 その中に、論理ボリュームで、swap , / (root) , /home を分けることにした。 実際に、設定はうまくいってインストールも終えたんだけど、 手作業でのパーティショニングで肝心の /boot に、bootマーカを付け忘れたため、 起動に失敗。…ということで、再チャレンジとなった。
sudoトラブルの確認
恒例のパッケージ更新ということで、"aptitude update ; aptitude safe-upgrade"を実行したら、 延々とパッケージのチェックをして、未確認の欄に表示されるパッケージ件数が55000を越えても 止まらない。もともとインストールされているパッケージ数も2500程度だし、異常動作。
保留の欄にも100件近いパッケージが表示されるので、ひとまず以前から更新を 止めていた"sudo"を更新する。 次に、apticronが報告してきていた更新候補をひとまずインストール。 すると、正しく更新作業も完了したし、再び"safe-upgrade"を実行しても、 普通に更新チェックが終わるようになった。
そもそも、sudo の更新ができなかったのは、MovableTypeへの記事の投稿scriptで、 ゾンビプロセスが残るのが理由だった。 ということで、記事の投稿を試すが、特に問題も発生しなかった。
# qmailからpostfixに変更したおかげかな…
職場の新しいサーバ名はiris
職場に新しく導入した、Xeon Quad Core ×2 で、ちょいとうるさいサーバだけど、 職場のホスト名の命名のルール(その時点の子どもの好きなキャラクタで女性名)ということで、 iris を採用。 キャラの名前、iris だったんだ…
HDDのUUID認識とはいえ
LinuxのKernelの機能で、HDDの認識がUUIDを使う方式に変わり、 HDD増設の度にシステム起動するかな…という不安に駆られる ことはなくなっている。
しかし、先日サーバの再起動をかけたんだけど、 HDDの増設もなにもしていないんだけど、 見事に /dev/sda , /dev/sdb , /dev/sdc が入れ替わっている。
さすがにmunin等の画面にUUIDな超長いデバイス名が書かれても困るし、 かといってデバイスの認識順序がブート時にちょっと変わっただけで、 デバイス名総入れ替えは勘弁してほしいなぁ… /dev/disk/by-id/* を覗いてみたけど、この辺を経由するシンボリックリンク貼れってことなんだろうなぁ…

Debian/Wheezy(testing)を入れる
先日、Debian6.0(squeeze/stable)が出たので、ひとまず様子見として見送っていた、 新しいtesting(wheezy)への移行作業を行った。
といっても、testing用のsources.listに修正して、aptitude safe-upgrade かけても、 更新が激しい怪しそうなパッケージも出てこなかったので、そのまま"yes"を入力。 (とはいっても、400件近いパッケージ更新だけど)
さほど、『読むからに動かなくなりそう…』という警告も出ず、入れ終わった。 ただ、ボチボチ触っていて、実は動かなくなってる…というのが常なので、 当面は気を付けよう。
Debian 6.0リリース
自分で管理しているサーバ群は、ほぼ Debian この中で、Debian 6.0(squeeze)が stable としてリリースされた。 これに伴い、testing は wheezy となったみたい。 管理しているサーバ群だけど、oldstable を使うように設定を変更しておかないと、 気軽にupdateしたら、急に動かなくなるパッケージが続出してくる可能性がある。
ためしに、いままで testing(squeeze) で運用していたサーバを、testing(wheezy) に 変更すると、更新:344個、新規:7個、削除:0個、保留:1個 となった。 6割がライブラリで、さほど影響もなさそうだなぁ…勇気いっぱつ "Yes"…といきたいけど、 ひとまず躊躇。
debianでDropboxをインストール
Debian/squeezeな自宅サーバにDropboxをインストールしてみた。 当初、DropboxのDownloadでubuntuなパッケージを入れようとしたけど、 動かなかった。しかたがないのでソースインストール。
(( コンパイルに必要なパッケージをインストール )) # aptitude install libnautilus-extension1 \ libnautilus-extension-dev \ docutils-writer-manpage (( コンパイル )) # tar jxvf nautilus-dropbox-0.6.7.tar.bz2 # cd nautilus-dropbox-0.6.7/ # ./configure # make # make install (( 使ってみる )) $ dropbox start -i : $ dropbox stop
IDEディスクをlvmでまとめる
自宅のサーバの更新を終え、古いサーバも様子見で動かしていたけど、 今朝変な音をたてていて、ネットワーク接続を受け付けてくれない。 細かいチェックはしていないけど、ついに絶命か… ということで、内臓HDDで新しめで容量の大きいものを取り出す。
# この作業でわかったんだけど、どうも壊れかけていたのは電源のFANみたい。
160GBのIDEディスクが2個取り出せたけど、 試用期間から考えて2次バックアップ用途あたりが無難。 かといって、160GBというのは小さく、マウントしても容量を気にして使わないといけない。 ということで、LVM機能で見かけ上1つのドライブとして使えるようにすることにした。
以下は、参考記事をみながら作業したときのメモ。 IDE2個を追加で接続したら、当初SATA=/dev/sda だったのが、 IDE1=/dev/sda,IDE2=/dev/sdb,SATA=/dev/sdc になって割り当てられた。 以前なら、ルートパーティションのデバイス名が変わって、地獄をみるんだけど、 最近は/etc/fstabには、ドライブのIDでマウント先が記載されているので、 まるっきり問題なくブートできる。さすが…
IDE1=/dev/sda IDE2=/dev/sdb SATA=/dev/sdc (( lvm2のインストール )) # aptitude install lvm2 (( PV物理ボリュームの割り当て )) # fdisk /dev/sda | dコマンドでパーティションをすべて消しておく # fdisk /dev/sdb | 同じくパーティションを消す # pvcreate /dev/sda # pvcreate /dev/sdb (( VGボリュームグループに割り当てる )) # # ボリュームグループにlvmという名前をつける # vgcreate lvm /dev/sda /dev/sdb (( 論理ボリュームの作成 )) # # ボリュームグループの中に論理ボリュームを作る。 # # lvmの中にlvm0を作る。 # lvcreate -n lvm0 --size 290G lvm (( マウントできるようにする )) # mkfs.ext3 /dev/lvm/lvm0 # mount -t ext3 /dev/lvm/lvm0 /mnt
さて、これでバックアップ用容量はひとまず確保。 1次バックアップ=外付けUSB(1TB)、2次バックアップ=LVM(290GB) がそろったけど、まだバックアップ処理を動かしていない。 さて、元サーバのバックアップスクリプトをどう動かそうか….



