当サーバではfml4を使ったメーリングリスト（ml）を提供しています。
しかし、docomoのspモードメールアプリのバージョンが・・・

2014/05/20 までは「docomo mail ver.11030」
2014/05/21 以降は「docomo mail ver.11050」

・・・とアップデートされ、アップデート後のdocomo発信メールは
なんと文字コードが一般的な「iso-2022-jp」から「utf-8」へと変更されてました。
（docomoからは利用者へ公式案内は流れていないようです）

「utf-8」コードで作成されたメールは例えばauの@ezweb.ne.jpでは
酷い文字化けを起こし、配信されても判別不能になってしまいます。

そこで・・・

http://yamagata.int21h.jp/tool/gmail-filter/

・・・にてご紹介戴いている漢字変換フィルタをサーバ側の
postfix aliasに仕掛ける事にしました。
これでutf-8だろうが何だろうが、全てiso2022-jpでml配信されます(^^)

但し、フィルタの処理時間として従来より若干（数秒程度）配信遅延が発生する模様です。
まぁハード（M/B、CPU）に金をかけて高速化すれば対処可能かとは思いますが(^^;)

自宅鯖のVine5.2もi845なCeleronだったし、HDDエラーとかでて老朽化してきたので、この際UpgradeしようとASUSのQ87M-EとLGA1150(Haswell)なCore i5のプラットホームへマイグレーションすることにしました。DDR3-1600のメモリが何故か4枚余ってたのでCPUとマザーさえあれば安価にマイグレーションできるかも・・・と考えたのがハマりの始まりです。

実験君をしていた時にはとても調子が良く、1日で終わるはずだったのですが、結果的には3日仕事になりました。。ハードデュプリケータで1TBのHDDをクローンコピーしてBackUpを常に残しながら何度も何度もDVDインストールからやり直し(T_T)

原因は恐らくM/BのDRAMソケットの公差不良と「余ってた」SDRAM(16GB DDR3-1600 ADATA製)のタイミング不良の合わせ技（爆）

当初は割と機嫌良く動いていたのに、時間の経過と共に16GBを4枚実装するとほぼNG、1枚だけ実装してもダメな物がある（怒）

仕方が無いのでM/BのBIOSでDDR3-800にクロックを落として、一番安定している1枚のみを使う事に。その後もInstall->apt-getでハマりまくり。
apt-get update、apt-get upgradeで
「これらを解決するためには ‘apt-get –fix-broken install’ を実行する必要があるかもしれません。」
と表示されてもそれを無視して、apt-get -f install、apt-get dist-upgradeとすすまねばならないらしい。

http://vinelinux.org/vlmagazine/20120730.html

やっとこさApache2(http/Web)とpostfix(SMTP)、Courier-IMAP(POP3)、Proftp(ftp)、flm(ml)サーバが稼働し、rootでの作業が出来るまで数時間×3日ぐらい・・・・疲れました～orz

フレッツ光ネクストハイスピードタイプ(200Mbps)から光ネクスト「隼」に変更しました。
入線していた光ファイバは「Bフレッツ」初期時代のモノだったのでファイバ張り替え工事とルータ（PR-S300SE -> PR-S300HI）のリプレイスも実施。

さて、例によって今回のトラブル（爆）

プロバイダの契約変更などを含め、工事日時はすべてシンクロさせるのが当たり前で、そのような手配も完了していたのですが、

・ＮＴＴさんが前日PM16:30にONUリンクをブチ切る（入れ替え後のルータ情報に書き換えてた）という暴挙が発生、この為、約半日ダウンの予定が、１日ダウン。
前日帰宅後にインターネット系作業がすべて利用不能という酷い目に（泣）

・新しいルータと古いルータはconfigの互換が無い為、手打ちで設定変更が必要でした。その為、旧ルータの設定をプリントアウトして、新ルータに手打ちしたのですが、外部（WAN）側から全くアクセス出来ないという事態に・・・。
よくよくルータのヘルプを読んでみると「宛先IPアドレス」という語の定義が変更されていました。

旧ルータ（PR-S300SE）：グローバルIP（WAN側の固定IP）
新ルータ（PR-S300HI）：グローバルIP経由のLAN側のターゲット機器IP（ローカルIP）

・・・これって真逆じゃん（T_T）

何でこんな罠を仕掛けるかなぁ（号泣）　＞ＮＴＴ

・・とりあえず酷い目に遭いましたが、サイト復旧は出来ました。
さて、ブロードバンドスピードテストで計測してみると・・・・

「以前とほとんど変わらない」（体感できず）

フレッツ金額は変更無し、工事費も無料なのですが、プロバイダ料金は上がりました。
ベストエフォートだから仕方が無いのかもしれませんが、いずれ速くなることを期待しよう(T_T)

とにかく調子が悪い。

しょっちゅうフリーズする困った子になってしまったVine5.2マシンを「よゐこ」にする為、

TELリセッタの設計を大阪の裏物ハード屋大先生に依頼中なのですが、併行して

新兵器を導入しました。その名は・・・

WATCH BOOT nino　RPC-2LC

http://www.meikyo.co.jp/products/2lc.html

既にEOLなんですが、ヤフオクで「リブータ」ウォッチで見張ってたら突然引っかかった。

恐らく何処かの企業でリースバックになったか、経年で上位機種に入れ替えとかで、

SIerが搬出して二次転売って感じかもしれませぬが、結果的に15K程度の投資で入手。

で使ってみたら結構良い仕事をしてくれるので大感激(T_T)

今までの苦労が何処へ行ったのやら～って状態に緩化されました。

新兵器君、アーキテクチャ・フロー的には単純なんですが・・・

ターゲットマシンのIPを設定→ターゲットマシンの電源をリブータ君のアウトレットから取得

→ターゲットマシンとリブータ君をRJ45線でつなぐ

→リブータ君はターゲットに一定間隔でPING→無反応をかんちした場合、設定秒数後に

アウトレットを切断、再投入→最初に戻る

・・・といった感じ。簡単に言うとターゲットマシンの電源ブッコ抜いて再度ブッ挿すって事。

（死活監視＆電源アウトレットリセット）

ターゲットマシンのBIOSで「Auto Power On After AC Power Loss」みたいな設定が出来るタイプなら十二分に使えます♪

もちろんリブータ君が逝去された場合はどうしようもないですが、そこまで冗長設計するほどクリティカルなデータセンタでも無いのでまぁしばらくはこれで様子見とします。

2Wほど運用しましたが、

数回稼働したログが残っている＝数回叩き起こされる事が無くなった

すごいカイゼン効果です(笑)

しかし、ほぼ時を同じくして例の震災が発生した関係にて、遠隔死活監視を無料で行ってくれていたシーマン社（http://www.cman.jp/network/）が無料の死活監視を無期停止するとの告知が(–;;)

今まではこの仕組みでターゲットマシンが死んだ際、携帯にアラートが吹っ飛んできてたのですが、監視してるだけで実際にリセット・リブートするのは「人間」の作業が必要だった訳です。

しかし現在はこれも無用になった次第で静けさが戻って大助かり。

あとはリブート時にext3のファイルシステムがジャーナルでちゃんと復帰する事のみ祈っておきませう_(_ _;;)_

最近になってとっても不安定度が増しました。。。

なんといいましょうか目を離した隙きにこけている状態(泣)

先日はメモリ(DDR266)を疑ってDDR400へ交換してみたが収まらず、

ということで、再度M/B交換(同一型番のRevision Ver2.1x→Ver3.x系へ)しました。

これで少しは安定してくれれば良いのですが。。。

あとはCPU(P4)との相性かなぁ。。。以前のCeleron時代にはこんな事はなかったのですが、

EOL(EOS)となったVine4.xから仕方なくVine5.2へ乗り換えてから不調続きで困っていますorz.

昨日M/Bのコンデンサをバッチグにしたのに、起動すると何故か

「PS/2キーボードが全く効かない」という状況に。。。(-_-;;)

VNCとか生きてたのでリモートでいろいろメンテしたけど、

ローカルキーボードが全く効かないのは困る。

という事で原因究明の為に、再度鯖を開く事に(泣)

昨日まで正常に動いてたんだし接触不良かなぁ・・・と思いきや、原因はPS/2コネクタ裏の

チップ抵抗の消滅（有るはずの場所のチップがどっかにもげて落下？）でした。

ということで、急遽保守用に昨日同様にコンデンサ交換して備蓄しておいたM/Bに

交換する羽目に(滝汗)

しかし、M/B交換したら、最近のLinuxはKudzuとかいらっしゃらないのでオンボードNICを

誤認識（というか、改めて別NICとして追加認識）するんですなぁ。。。

こんなことしてたらeth0・eth1以外にeth2,3,4,5,6,7,・・・・みたくなってしまう(-_-;)

でこれ当初はこの原因解らなかったのですが、やはり同様にハマって探求されていた方が

いらっしゃったご様子、Gentooみたいですが、Vine5.2でも全く同一でした。

http://mylinux.blog42.fc2.com/blog-entry-370.html

引用ここから－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

１度使用した(?)MACアドレスは
/etc/udev/rules.d/70-persistent-net.rules
に記録されています。

私の場合は次のようになっていました。

PCI device 0x10ec:0x8168 (r8169) SUBSYSTEM==”net”, DRIVERS==”?*”, ATTR{address}==”00:e0:4d:28:3d:cf”, KERNEL==”eth*”, NAME=”eth0″

PCI device 0x10de:0x0760 (forcedeth)SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:24:1d:2d:10:07″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth1″

最初の r8169が、以前のマザーに載っていたネットワークのチップで
これが NAME=”eth0″ と、eth0 に当たっているのがわかります。

次の行が forcedethドライバで、新しいマザーに対応します。これが NAME=”eth1″ と
eth1 に当たっているんですね。
/etc/init.d/net.eth0 は、eth0 相手なので、eth1 が割り当てられてもそれを制御できない。
という状態になっていたのです。

対処としては、上記の２行を削除して、再起動。
udev が新たに 70-persistent-net.rules を生成し、それがeth0 に割当てられるので
無事に動作するようになりました。

引用ここまで－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

いやぁ助かりました。

ということで、今度こそ安定駆動、フリーズ無しを祈ってやみません(^^;;)

M/Bのほとんどが台湾製ということは仕方がないのですが、

主要部品として利用されている電解コンデンサまで台湾製というのは勘弁して欲しいっす(;_;)

まぁ、例によって例のごとく、経年劣化によって膨張してきて不安定化するといった始末。。

で、安定化の為、「疑わしき物は全て罰する」方針で怪しげな電解コンデンサを

全て交換してみました。

作業時間は保守用M/B3枚を含め、作業場所とのDoor to Doorで約5時間ぐらいでした。

結果的にハンダ除去とハンダ付けのスキルが若干上がりました(^_^;)

DNS伝播にえらく時間がかかっていたと思ってたら・・・

外注セカンダリDNSサーバ会社のシステムがコケてました(泣)

ということで、やっとDNS的に復旧。。

お外からちゃんと正引き逆引き共に引けるようになりました。

良かった良かった(^^;)

本日メイン回線を旧プロバイダである某「インター○ンク」より某「xxx」さんに乗り換えました。

理由は旧プロバイダの「あまりにも酷い帯域制限」にブチ切れたからです。

数年来利用してましたが、さすがにフレッツ光ネクストハイスピードタイプ200Mbpsのインフラで、

モデム並みの速度しか出なくなる事が頻発すると毎月の料金支払いがばかばかしくなります。

当サイトはそれなりに高帯域を利用しますので例えば「料金値上げ」提案などがあった場合、

それはそれで仕方ないかなぁと思いますが、値段は据え置きでも「安かろう悪かろう」に

なってしまっては本末転倒です。

「SLA」(Service Level Agreement)という概念をお持ちなのでしょうか。。。呆れてしまいます。

新プロバイダの某「xxx」さんは速度テストサイトとかで確認しても「際だって高速」という訳では

ありませんでしたが、必要十分な帯域を備えているようで本日現在の所満足しています。

あとはDNS伝播が早く完了するのを願う限りです(^_^;;)

設定を見直しておりましたら、Apache(WebServer)や各種掲示板、fml(メーリングリスト)等の

安定性・堅牢性に一部疑念が生じましたのでセキュリティ面から各種設定を変更しました。

これでほぼ大丈夫かなぁ(^^;;)