FreeBSD 日誌

こちらでお知らせした通り、本ドメインは約１ヶ月間落ちていた。編集ミスでhomev6.jpドメインのデータがnamedが読めなくなり、その状態が１週間以上続いたためTTLを過ぎてしまったため、slave serverでもデータが消えてしまった。
気がついた時点でファイルを修復し手元の(master) namedおよびslaveのデータは復帰したのだが、問題はISP等のnamed上のキャッシュである。大規模なお客を抱えているnamedでは、処理が破綻しないようにキャッシュの有効期限を延ばしている。問題なのは「落ちた」という情報もキャッシュされるので、立ち上げ直してもISPのnamed上では落ちたままとなる。この期間が大抵１ヶ月なので、１ヶ月後に大半のnamed上でhomev6.jpドメインがやっと復帰した。

しかしこんなミスをするとはまだまだroot修行が足りないようである。

投稿者: FTNS 日時: 22:36 | パーマリンク | コメント (0) | トラックバック (0)

amd64 7.0-RELEASEはプロダクションリリースではあるが、運用を重視するならamd64 6-STABLEのまま運用すべきである。
ところがそう言っていられない事情が起きてしまった。

事の発端は先週職場のHP ML115でamd 6-STABLEをcvsupを使ってアップデートした所、それ以降必ずcvsupがSegmentation Faultを起こすようになってしまった。前回の調査で一度クラッシュさせてしまっていたので、その影響かもしれないという結論に達したのが金曜日。
念のため自宅の試験用FreeBSDを最新のamd 6-STABLEにアップデートしてみたところ、問題が再現されてしまった。　

その後友人に教えてもらったcsupは最新の6-STABLEでも正常に動作することがわかった。しかし7-STABLEではcvsup も正常動作するので、なんだかよくわからない不具合である。

困ったのが運用中のamd64 6-STABLEの鯖である。うっかり/usr/src/以下をcvsupにて最新にしてしまっており、これをインストールすると同じ問題に直面することになる。問題が解決されるのを待ってそれまで放置する手もあまり望ましい手ではない。実はこの時CPUをAthlon64X2と勘違いしていたため、SMPカーネルにしようとしていたのである。

前回の調査に出ているAMD64付のHP ML115は自宅用に購入したものである。NTT-X Store にて約1.5万円にて売られていたので、消費電力を減らすために導入した。(という理屈で衝動買いしたのだろうというご指摘は正しい:-)
6-STABLEのままにしようとすると、ソースはすでに問題のある最新版にしてしまっていたのでFreeBSD全体をバージョンアップする必要があるが、これは避けたい。だからといって6.3-RELEASEのCD-ROMからソースをコピーして、6.3-RELEASEに戻すのも面倒である。そこで、「プロダクションリリース」との言葉を信じて、7-STABLEへの以降を決断した。

続きを読む "6-STABLEから7-STABLEへ" »

投稿者: FTNS 日時: 20:11 | パーマリンク | コメント (0) | トラックバック (0)

最低なオペレーションミスをやってしまった...orz
4月末にnamedの設定を変更した際に、ケアレスミスをやってしまった。 そこで気がつけば何ともなかったのだが、事後確認を怠った為にnamedが 10日間以上も止まってしまった。友人にお願いしているセカンダリも当然expireしており、 １週間近くhomev6.jp domainが存在していなかった事になる。
このためメールが届かない、web serverのお客も激減するなど、皆様に大変なご迷惑をおかけしてしまった。 復旧した現在でも大手ISPなどのDNSサーバではhomev6.jpドメインがひけないようである。 これはnamedの負荷を下げる為に、DNS情報の更新の間隔を延ばしているためである。 最悪今月いっぱいはトラブルが収まらないと予測している。

【教訓】
なにかやったら事後確認を必ずすること。

5/16/08追記：
なぜかnospambbs.netドメインが生き残っていたので、掲示板をそちらに移す事にした。
あとは主催者のH氏が私のメールに気づいてくれれば、メルマガで移動を周知出来るのだが....

投稿者: FTNS 日時: 07:16 | パーマリンク | コメント (0) | トラックバック (0)

3年間頑張ってくれたDell PowerEdge 400SCだが、ハードウェアの故障のため引退させる事になった。
夏をエアコン無しで３回も越したので、こんなものだろう。

最初の症状は、数ヶ月前からnetatalk でファイル共有(afpd)が出来なくなった。 それまでは何ともなかったのに、Macから共有しようとした途端にafpdが落ちてしまう。 デバッガで追ってみた所、select()で通信待ちをしているが、ファイル共有接続要求が 来た時点でいきなりSIGTRAP(本来はデバッガ用のシグナルなので、システムから 送られる物ではない)を食らって落ちている。最初はEthernet I/F(em)の故障かと思ったので、Gigabit Ethernet I/Fを2種類(vge, re)買ってきて試したが、何も変わらない。 原因不明の為、予備PC(sc430)にFreeBSD 6-STABLE(i386)をインストールし、各I/Fでafpdをチェックした所、オンボードのI/F(bge)や購入したEther I/F(vge, re)でも何も問題ない。
ソフトウェアは全く同じ物なので、これはハードウェアの故障の可能性が高いと判断した。

その後sambaも同じ症状になり、仕舞いにはsshdまで起動しなくなってしまった。
いったいどこが壊れたらこんな挙動になるのやら。ソフトウェアのバグならまだ理解できなくはない。 しかし6-STABLEを使うという事は、バージョンアップのたびにシステムが新しくなっているので、 他のPCでは正常に動いている以上ソフトウェアの可能性はまず無いはずなのだが。

続きを読む "4代目サーバへ移転" »

投稿者: FTNS 日時: 12:35 | パーマリンク | コメント (0) | トラックバック (0)

Slashdot.jpの記事によれば、以前このblogで取り上げたCrawler Agent: BaiduSpiderを運用している百度(Baidu)の日本向けサービスが始まるとの事。

プレスリリース： 日本語サイトのwebページの収集Spider（クローラ）問題についてによれば、嫌われた事自体は理解した模様。ただそれを「日本のインターネット業界におけるルール」と言ってしまうのが役人的だなぁ。
この問題は、「とんでもない頻度と規模でweb pageを片っ端からcrawlする事で、サーバと回線に脅威となる程の負荷をかけてしまった」という純粋に技術的問題なのだが。「日本のインターネット業界」という言葉をわざわざ使う所が、なんとも＊＊＊である。

baiduは余りにも遅く出てきたので将来性に大いに疑問があるが、アクセス許可して様子を見てみたとｒころ、普通のアクセス量なのでそのままにしてある。

投稿者: FTNS 日時: 21:51 | パーマリンク | コメント (0) | トラックバック (0)

最近続けてRAID1のHDDが故障し新しい物に交換したので、その際の手順を書いてみる。

本来RAID1は予備のディスクを壊れたHDDと交換すれば問題ないが、 壊れた頃には同じドライブは手に入らないし、古いHDDと同じ容量を買える値段＋αで もっと大きなHDDが買える事が多い。
しかもミラーリングに頼るならそのままでは昔の小さいHDDの容量のままであり、生き残った古いHDDもそれほど寿命があるとは思えない。
よってシビアな運用が必要な鯖ならともかく、普通の運用ならHDDを両方とも 変える方が良いだろう。

方法1. 予備の鯖を使う

予備の鯖に古い生きている方のHDDをnon RAIDで接続し、本鯖は新しいHDDで 新しい環境を作り直す方法。
利点

• 大幅に更新したい場合は、大抵1から作り直す方が楽である。

---

この鯖はこの方法でやりました。
HDDとRAID I/Fとの非互換性のせいもありますが、FreeBSD 5.5 -> FreeBSD 6.1、 PHP4->PHP5と変更したい物が沢山ありました。
ただし同時に複数の物を新しくするのはリスクが高いので、 安全性を重視するなら、次の「1台の鯖だけでHDDを1台づつ交換する方法」をお勧めします。

---

• システムに使われていない物が残っていれば、この際になくす事が容易である。

欠点

• その鯖で何を提供しているのか、その為に必要なファイルや設定は何かといった 情報を確実に漏れなく事前に知る必要がある。大抵漏れがあり、「あれ？これが動かない」 といった事になりがちである。

---

FTNSもこれやってしまいました。サービス毎のメモを用意したのですが、抜けがあって 結構ドタバタするはめになりました。

---

• 予備の鯖PCが必要になる。高負荷な鯖の場合、高くついてしまう。

---

この鯖は大した負荷はないのですが、時々バースト的にアクセスが集中する 事があります。本鯖は1.5Gbyteもメモリを積んでいるのでなんともありません でしたが、予備の鯖は512Mbyteしかないため高負荷時に仮想記憶まで一杯 になって、一部のプロセスが異常終了するなどのトラブルが起きました。

---

方法2. 1台の鯖だけでHDDを1台づつ交換する

RAID1を一度解除し、壊れたHDDを新しい物と交換し、古い生きているHDDの内容を そのまま新しいHDDに移行する方法。
利点

• 全てのバイナリ、設定ファイル、ライブラリがそのままコピーされるので、 サービスが停止する、ファイルが失われるなどのリスクが少ない。

欠点

• 以前と同じままなので、大幅に更新したい場合には不向き。
• Hardware RAIDでRAID I/FとHDDの間に非互換性があると、どうにもならなくなる。

今回は、「1.予備の鯖を使う方法」を解説する。

続きを読む "鯖のHDD交換(1) 予備の鯖を使う方法" »

投稿者: FTNS 日時: 23:45 | パーマリンク | コメント (0) | トラックバック (0)

ポリシーなどと書くと大げさだが、管理作業での自分の指針というか、習慣である。

管理作業にGUI(webminなど)は使わない。

• 例外1. X11(X Window)は大画面マルチスクリーンとして使っている。大抵ktermを複数と、emacsを１つ開いている。狭い画面ではソースや設定ファイルの見通しが悪くて使いづらい上に、歳のせいか画面を切り替えた際に前の情報を良く忘れるので。


• 例外2：MacOSXではGUIの出来が良いのと、現状サーバとして使っていないのでGUIも積極的に使っている。もちろんX11.app(MacOSX用X11 server)も使っている。


• 例外3: WindowsはGUIしかないので、嫌でも使わざるを得ない。

暗号化しないパスワードは信用しない。

たとえ暗号化してあっても、その実装方法を間違えると脆弱性が生じる。

　opensshでは認証に公開鍵を使えば、パスフレーズを盗まれても秘密鍵さえ守れれば乗っ取られる事は無い。ただしopenssh自体にも度々脆弱性が見つかっているので、日頃からの情報収集が重要。

続きを読む "FTNSの管理ポリシー" »

投稿者: FTNS 日時: 23:00 | パーマリンク | コメント (0) | トラックバック (0)