2004/12/07(火)今更ながら、32GByte の壁

2017/10/12 2:09 サーバ運営・管理
 当方のプライマリDNSは非常に多忙というほどではないので、K6-2 450MHz レベルの中古品を使用しています。
 しかし、マザーボードが、1997年くらいの製造で、ハードウェア的に 32GB より大きな容量のHDDは認識しません。
 BIOSは、アップデートしたのですが。。
 20GByte のものと 40GByte のものをあまり深く考えずに後払いで購入した(爆)ですが、
 40Gbyte のものは認識せず、20Gbyte のものが使えた状態でした。

2004/11/12(金)FreeBSD 5.3R における IPFIREWALL のconfig

2017/10/12 2:29 サーバ運営・管理
# PPPoE/FireWall
options         IPDIVERT
options         NETGRAPH
options         NETGRAPH_ETHER
options         NETGRAPH_PPPOE
options         NETGRAPH_SOCKET
options         IPFIREWALL
options         IPFIREWALL_VERBOSE

 これでは、どうやら、カーネル再構築途上でコンパイルエラーになるようです。
 FreeBSD 5.2.1 まではコンパイル通ります。
# PPPoE/FireWall
options         IPDIVERT
options         NETGRAPH
options         NETGRAPH_PPPOE
options         NETGRAPH_SOCKET
options         IPFIREWALL
options         IPFIREWALL_VERBOSE

 NETGRAPH_ETHER を削除し、上記のようにすることで、構築できました。
 填まりまくって2時間以上かかりました。
 現在のバージョンの FreeBSD では、自動的に必要なモジュールを動的に結合して動作するので、必ずしもカーネル再構築は必要ないです。
 また、FreeBSD 5.2 以降では、options PFIL_HOOKS が必要という記述も見受けられますが、実際にはこのオプションをしていなくても FreeBSD 5.2.1 では動作していました。
 また、FreeBSD 5.3 でこのオプションを指定すると、config エラーになります。
 デフォルトで有効とのことです。

2004/10/02(土)マニュアル斜め読みの罠

2017/10/12 2:53 サーバ運営・管理
 移転は順調ではありませんでした。
 ひととおりきちんと作成したマニュアルを2週間前に渡したのですが、
 勝手な思い込みでエンドユーザに伝えていない設定内容が数点あったようです。
 そのため、担当者が全社内通知を3回くらいやったようです。
(填まりそうだったので、支援の為にこちらでメールサーバのログを常時モニタしていました。通常はやりません〔爆〕)

 AM 8:00 過ぎに「送受信できない」の電話一本から始まったのですが、
 結局は設定内容や手順をきちんと周知していなかったような状態でした。
 マニュアルの記述内容が判らないという感じではなかったです。まぁ、2ヵ月後には笑い話になることでしょう :-)

2004/07/24(土)sqwebmail の authデーモン

2017/10/12 3:20 サーバ運営・管理
 Courier-IMAP のものが基本的に使用できます。prefix をインストール時にCourier-IMAP と揃えればよいです。
 ただ、Courier-IMAP をインストールしているところへ、sqwebmail を更にインストールすると、
 libexec/authlib 配下が上書きされるので、注意が必要です。
 こちらでは、 authdaemond スクリプトが書き変わった為に 認証デーモンが起動しなくなり、復旧に難儀しました。

2004/07/12(月)電子メール不正中継

2017/10/12 3:25 サーバ運営・管理
 Null クライアント(電子メール送信専用)にしているサーバに対して SMTP 接続をして、
 踏み台を試みているはんかくさい奴がいるので、様子を見るために、その穴を一部(半分程度)塞ぎました。
 電子メールハブサーバまでは中継されますが、そこで結局は止めるので、RBL などの不正中継サイトにはなりませんが、
 電子メールハブサーバの負荷が無用に大きくなるので、対処することにしたのです。

2004/06/11(金)PostgreSQL の二重化

2017/10/12 3:34 サーバ運営・管理
 PGClaster を使いたかったのですが、対応する PostgreSQL コアが7.3.4/7.3.6 ベースなので、
 先に 7.4.2 を入れてしまった環境では、待ちの姿勢の方が良い(7.4.2 ベースは開発中ですが、苦労されているようです)
 だろうということで、標準でバンドルされている DBMirror というものを採用しました。
 情報がすくなく、かろうじて これ が唯一非常に参考になる情報でしたが、実際に動作させると、
 ミラーリング処理で「Permission denied」的なエラーがでまくりでした。
 権限の問題ということは判ったのですが、ひとつだけ serial 型のスキーマがどうしても「Permission denied」
 になり、どうしようもない状態になりましたが、マニュアル漁っていると、serial 型は内部でテーブルを作って
 動作させている、ということがヒントになり、通常のテーブルと同じように考えることで、権限の問題を解消しました。
 おそらく、Postgresスーパーユーザではまず起きない問題でしょう。
 解決するのに3~4時間填まってました +_+)。
 一旦稼働できると、札幌のマシンで更新したデータが、30秒程度後には、東京のマシンに即座に反映するので、
 本当に即時性が必要な用途以外では実用になります。
 DBMirror はスレーブサーバ側には、特に仕掛けは必要ないですが、DBMirror 稼働させる直前のデータを
 スレーブ側に用意しておくことと、生データが流れるので、PostgreSQLを SSL 対応にしておくことが重要だとおもいます。