二つ目のプロバイダ ( その2 )

新しいIPアドレスを使った、仮想WEBサーバー、仮想メールサーバー等の枠組みが動きだしたので、あちこちに散らばっているWEBサイト群をこちらに集約することにする。

あちこちに散らばっているのは、以前 無料のサービスだけでどこまでできるか、というのを試していた時期があって、そのなごり( つまり、フリーのドメイン名、フリーのネームサーバー、フリーのメールサーバー、フリーのWebホスト等々 ) なのだけれど、ちょっと手を広げすぎて管理能力の限界を超えてしまった気がする。
フリーのサーバー群を使っての結論としては、『特殊なことをしない限り、速度とかをあまり気にしないのであれば、(広告無しにこだわったとしても)フリーのサービスの組み合わせだけで殆どのことは足りる。だけれども、サービスが分散する分、管理の手間が余分にかかるので、実際上、管理可能なのはせいぜいドメイン一つか二つが限度。』といったところ。
突然のサービス停止などの影響で引越しを余儀なくされる手間を考えると、その辺が趣味というのでなければ他人にはあまり奨められない。

散らばっているもう一つの理由には、匿名化したいドメインがあったということ。会社のIPアドレスを使うとそれだけで身元が分かってしまうので、それは避けたかった。( 無料系のサービスで、メールの発信時に匿名を徹底できるサービスは結局見つからなかったけれど。)

とりあえず、ドメイン名だけ確保したまま、実質的に放置状態だったサイトから集約することに。

二つ目のプロバイダ

転送量制限があるものの、500円/月で IPアドレスがもう一つ使えるということで、プロバイダをもう一つ契約することにした。
今のルータは pppoe をパススルーにして、内側から直接 pppoe で接続することにする。
パケットフィルタリングは、今回は ipfw でなく pf を使うことにする。ipfw は、jailと同時に使うときに挙動が少し判りにくい点があったのと、pf だと nat の記述を同じレベルで書けるので。

まあ、とりあえず、一番シンプルな形でのルールを設定して様子をみることにして、調子がよさそうなら、今あるサーバー群を順次こちら側に移動する予定。

逆引きの設定ができないのが難点といえば難点なのだが、逆引きを ns.* なんて名前になるようにしてしまうと今度は 某巨大掲示板に撥ねられてしまうので、痛し痒しといったところ。

玄箱HG ( その7 )

動作そのものは安定しているのだけれど、再起動があまりに不安定なので( ... 新旧kernel のどちらで立ち上がるのかの条件がはっきりしないのね ... ) 結局、玄箱は廃止してもとの PC に戻すことにする。まあ、玄箱ではコンパイルが遅すぎるとか、メモリが足りないとかそんな理由もあるわけだが。
消費電力の方は、あまり有効に使われていない別のPCと機能統合して、台数的にはトータルでは一台減 ( つまり、PC×2 => PC + 玄箱 => PC×1 ) ということで、なんとか辻褄を合わせることに。

玩具としてはそれなりに面白い機械なので、もう少し安定稼働できるようになれば、また復活するかも。

玄箱HG ( その6 )

iptables用に kernelを再構築したら、また再起動しなくなった。
いや、ログを見る限りでは、新しい kernel での再起動そのものはされているようなのだが、アクセス不能になる。
再構築の手順自体は特に変ったところがあるわけでもないし、もしかして、iptables の初期設定って、すべて block だったりする？

玄箱HG ( その5 )

さっそく pop3 やら ssh でちょっかいを出してくる輩がでてきた。
今のところ 外部からアクセスする予定はないので、ブロックしておこう。
はやく iptables を導入しないといけないね。

玄箱HG ( その4 )

Rebootが変に見えたのは、多分起動にかかる時間が想定していたより相当に長かったせいだろうということで、とりあえず一件落着。何度も再起動していたので、fsckが動きだしてそれが終了していなかったのだろう。こういう時には やはりシリアルコンソールがないとちょっとつらい。

そんなわけで、pppoeで直接プロバイダから得たIPアドレスで公開する方向で その他の設定を変更中。
今までは、LAN内で ファイヤウォールからは (reverse) proxy の形でのアクセスだったので、セキュリティもそこそこ手抜きができたのだが、これをもう少しきつめの設定に変える必要がある。

ま、要は proxy server のメインテナンス中にも 独立して稼働できるように、ということなんだけどね。

玄箱HG ( その３ )

5月に稼働を開始して、それきりだったのだが、pppoe をしようと思ったところ PPP がkernelに組み込まれていない ということで、kernelの再構築。
再構築自体は x86 系の linux では何度もしているので、特に問題はないと思っていたのだけれど、なんだかうまくいかないね。
reboot も何だか変だし、kernel-2.4.17(つまり工場出荷時のkernel)で立ち上がったり。
まあ、最悪でも 2.4 で立ち上がることはわかったから、それほど神経質にならなくてすむのだけれど...

実用にしているので、そう長く中途半端な状態にしておくわけにもいかないので、とりあえず元の5月の状態に戻すことにする。4ヶ月も前のことだから、きっと何か手順を忘れているのだろう。

コンピュータルームが五月蝿くなってきた

某所のコンピュータ室が随分と五月蝿くなってきた。
自分で導入する場合だと、Pen4 2.8GHzの時にファンの音がかなり気になったので、TDP65W以上のものは特別な理由がなければ考慮外なのだけれど、他社は騒音にはまったく無頓着に爆音コンピュータを導入してくれる。
まあ、発注する側としては、高発熱・高性能のCPUを拒絶する理由はあまりないし、できあがったシステムの遅い理由がCPUが遅いせいだ なんて言い訳は聞きたくないから、提案されるものをそのまま受け入れてしまうのだろう。
たかが WEBサーバーなんて、いまやNetworkの速度が完全に律速になっているのだから、それに見合うCPUで充分なのにね。

そんなわけで、そこで作業する人間の環境はだんだんと酷くなる、というわけだ。sigh...

uucpssh がサービス停止

長いことメールサーバーのバックアップとしてお世話になったが、9月いっぱいでサービスを停止することになったという知らせがやってきた。
理由の第一は、手間がかかりすぎるということ。第二はたぶん有料会員が少なすぎたということらしい。( 多少なりとも寄付があったのは、合計でも20に満たなかったらしい。)

有料会員の会費が 50ユーロ/年間 と、サービスの内容に比べるとかなり高い設定になっていたので、それだけの価値を見出す人はすくないだろうな とは思っていたけれど...
[ 有料会員になると、メールの受信だけでなく送信もできるようになるのだけれど、それだけのためなら 10ユーロ/年くらいが 相場ではないかと思う。]

Gmail のサービスが始まって、メール機能のバックアップとしては Gmail でほぼ足りる ( もちろん、uucpssh でできたことが すべて Gmailでできるわけではないが ) ようになったのも、一つの要因なんだろう。