2004/12/16(木)FreeBSD 4.11R
2017/10/12 2:02
今のところ、2005/01/24 を予定しているらしい。（いつものように、また遅れる可能性は大）
2004/12/07(火)今更ながら、32GByte の壁
2017/10/12 2:09
しかし、マザーボードが、1997年くらいの製造で、ハードウェア的に 32GB より大きな容量のＨＤＤは認識しません。
ＢＩＯＳは、アップデートしたのですが。。
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 を削除し、上記のようにすることで、構築できました。
填まりまくって２時間以上かかりました。
現在のバージョンの FreeBSD では、自動的に必要なモジュールを動的に結合して動作するので、必ずしもカーネル再構築は必要ないです。
また、FreeBSD 5.2 以降では、options PFIL_HOOKS が必要という記述も見受けられますが、実際にはこのオプションをしていなくても FreeBSD 5.2.1 では動作していました。
また、FreeBSD 5.3 でこのオプションを指定すると、config エラーになります。
デフォルトで有効とのことです。
2004/11/09(火)bind8 から bind 9 に移行
2017/10/12 2:32
ちょっと情報足りないので、後日また購入に..（涙）
2004/10/02(土)マニュアル斜め読みの罠
2017/10/12 2:53
ひととおりきちんと作成したマニュアルを２週間前に渡したのですが、
勝手な思い込みでエンドユーザに伝えていない設定内容が数点あったようです。
そのため、担当者が全社内通知を３回くらいやったようです。
（填まりそうだったので、支援の為にこちらでメールサーバのログを常時モニタしていました。通常はやりません〔爆〕）
AM 8:00 過ぎに「送受信できない」の電話一本から始まったのですが、
結局は設定内容や手順をきちんと周知していなかったような状態でした。
マニュアルの記述内容が判らないという感じではなかったです。まぁ、２ヵ月後には笑い話になることでしょう :-)
2004/07/24(土)sqwebmail の authデーモン
2017/10/12 3:20
ただ、Courier-IMAP をインストールしているところへ、sqwebmail を更にインストールすると、
libexec/authlib 配下が上書きされるので、注意が必要です。
こちらでは、 authdaemond スクリプトが書き変わった為に 認証デーモンが起動しなくなり、復旧に難儀しました。
2004/07/20(火)PHP 5
2017/10/12 3:23
これも今日初めてしりました（爆）
裏を返せばそれだけ変に忙しい＝作業効率悪い という訳です（爆）
2004/07/12(月)電子メール不正中継
2017/10/12 3:25
踏み台を試みているはんかくさい奴がいるので、様子を見るために、その穴を一部（半分程度）塞ぎました。
電子メールハブサーバまでは中継されますが、そこで結局は止めるので、RBL などの不正中継サイトにはなりませんが、
電子メールハブサーバの負荷が無用に大きくなるので、対処することにしたのです。
2004/06/11(金)PostgreSQL の二重化
2017/10/12 3:34
先に 7.4.2 を入れてしまった環境では、待ちの姿勢の方が良い（7.4.2 ベースは開発中ですが、苦労されているようです）
だろうということで、標準でバンドルされている DBMirror というものを採用しました。
情報がすくなく、かろうじて これ が唯一非常に参考になる情報でしたが、実際に動作させると、
ミラーリング処理で「Permission denied」的なエラーがでまくりでした。
権限の問題ということは判ったのですが、ひとつだけ serial 型のスキーマがどうしても「Permission denied」
になり、どうしようもない状態になりましたが、マニュアル漁っていると、serial 型は内部でテーブルを作って
動作させている、ということがヒントになり、通常のテーブルと同じように考えることで、権限の問題を解消しました。
おそらく、Postgresスーパーユーザではまず起きない問題でしょう。
解決するのに３～４時間填まってました +_+)。
一旦稼働できると、札幌のマシンで更新したデータが、30秒程度後には、東京のマシンに即座に反映するので、
本当に即時性が必要な用途以外では実用になります。
DBMirror はスレーブサーバ側には、特に仕掛けは必要ないですが、DBMirror 稼働させる直前のデータを
スレーブ側に用意しておくことと、生データが流れるので、PostgreSQLを SSL 対応にしておくことが重要だとおもいます。