カテゴリー: ITめいたこと (26ページ目 (31ページ中))

ムームードメインで管理している.netドメインがあって、そろそろ更新の季節だというメールが届いた。そうですかということで、素直に更新しようとしたら、コントロールパネルの画面にこんな文章が出てきて、手が止まった。

ドメインの更新に伴い、更新時に『お名前.com』へのトランスファー（移管）処理が行われます。トランスファー申請中は、ドメインの操作が行えません ので、予めご了承下さい。

* レジストラが変更になりましても、お客様側での設定やドメイン料金は変更されませんのでご安心ください。

* 入金確認後、トランスファーが完了するまで10日程度 かかる場合がございます。

* トランスファー更新にともなって、承認のため、「トランスファー承認手続きのお願い○○」及び 「Domain Transfer Request for ○○」という件名のメールが送信される場合がございますが、 こちらに対する手続きは一切必要ございません。

* トランスファー更新の後、60日間は他のレジストラへの移管を行うことが出来ない場合がございます。

* 移管状況の詳しい内容はドメイン詳細でご確認できます。

いきなり、お名前.comにトランスファーしますと言われても、意味がわからないんですけど…と思い、ヘルプページやサポートフォーラムを覗いてもさっぱりその辺への言及がなかった。こういうのって、なんか気持ち悪い気がする。で、ちょっと調べてみて、なんとなくわかったのでメモ。

ICANNのサイトを見ると、ムームードメインはICANN認定のレジストラではないから、ムームードメインがgTLDドメインを扱うためには、上位レジストラとしてICANN認定のレジストラが必要になる…と。

で、確か、ムームードメインは、eNomが上位レジストラだったんだけど、しばらく前にpaperboy&co.がGMOの連結子会社になった関係で、ムームードメインの上位レジストラをeNomからお名前.comに変えるというのがGMOグループ内の決定となったといったところだろうか。まぁ、上位レジストラがどうなっていようが、ドメインを使う分には問題ない…はず(レジストラのサービスの質を担保するためのICANN認定なんだろうし)だから、とりあえず、同意することにした。

初心者向けサービスを標榜する割には、しれっと「お名前.comにトランスファーします」なんて意味不明なことを言い始めるもんなぁ…って、どうなんでしょう。

さくらインターネットのレンタルサーバでは、fmlによるメーリングリスト機能を利用できる。サーバのコントロールパネルから送信先のアドレスを編集できたり、設定を変更できたりする…が、使っていて、ちょっと不便なことがあった。それは、メールヘッダの「reply-to」に関する設定をコントロールパネルから変更できないことだ。

ちなみに、デフォルト設定では、メーリングリストを介して配信されるメールの「reply-to」は、メーリングリストのアドレスになっている。つまり、メーリングリストを介したメールに対して返信すると、メーラーが「to」に指定するのはメーリングリストのアドレスになる。

そもそもメーリングリストとは何かを考えれば、そういう仕様でしかたないのかもしれないなぁとは思うが、ただ、単に「1個のメールアドレスで受けたメールを複数のアドレスにコピーして送るもの」としてメーリングリストを使いたいこともある。

そんな用途の場合は、fmlに任せるようなことではないのかもしれない…が、さくらインターネットのレンタルサーバ(少なくともビジネス向けのサービスの方は)のコントロールパネルでは、転送メールを利用するときに、転送先アドレスの指定がCSVでアドレス指定なので複数のアドレスを設定するときにかなり使いづらいという事情がある。…なので、仕方なくfmlにただメールを転送させることにした。

実際に会社の代表アドレスに、メーリングリストを使ってみると、さくらのレンタルサーバ上のfmlを介して届く関係で、reply-toがメーリングリストのアドレスになっている。なので、お問い合わせメールが届いて、それに普通に返信すると、問い合わせてきた人には届かなくて、社内だけに届いてしまう羽目になる。

そんなわけで、もし可能なら、メーリングリストでreply-toの付与を抑止できたらいいなぁと思ったけれど、その辺の設定項目がコントロールパネルになくて困った。さくらのレンタルサーバでは、SSHでログインすることが出来るので、fmlの設定をいじくってみることにした。

fmlのドキュメントなどを読んでみたら、「reply-to」の付与を抑止するには、設定ファイルに

&DEFINE_FIELD_FORCED

って書いてあるのを消せって書いてあったけど、そんなこと書いてなくて…どうしたものかと。なんとなく見てる設定ファイルを間違えているような気がしないでもないけど、なんとなく面倒な気がしたので、とりあえず、fmlが自動的にMLのアドレスを入れたreply-toを付与する前に、reply-toを書いてしまえばいいんじゃないかという…ちょっと邪道っぽい解決策を思いついた。

…というわけで、こんなのを設定ファイルに書き込んでみた。要するに、START_HOOKを利用して、reply-toにアドレスを指定してあるメールがMLに送られたら、改めて、そのメールアドレスをreply-toに入れてメールを配信するし、reply-toを指定していないメールに関しては、メールヘッダーのfromに書いてあるアドレスをreply-toに強引に(汗)入れて配信する…と。

$START_HOOK =q#

if (&GET_HEADER_FIELD_VALUE(‘reply-to’)) {

&DEFINE_FIELD_FORCED(“reply-to”, &GET_HEADER_FIELD_VALUE(‘reply-to’));

}

else {

&DEFINE_FIELD_FORCED(“reply-to”, $From_address);

}

#;

とりあえず、かなり強引なやり方ではあるけれど、reply-toでややこしくなる事態は回避できたような気がする。まぁ、思いつき型の解決策にありがちな、なにかのレアケースでややこしいことになりそうな気もしないけど、、、しばらく様子を見てみようかと。

最近、KLabさんがオープンソースで公開している「makuosan」を使ってみようと、意気込んでセットアップしていたら、以下のようなエラーに直面して、どうにもならなくなっていた。

CentOSが動いている「とあるホスト」にインストールしてあるmakuosanが以下のようなエラーメッセージを/var/log/meassageに残して、接続先(まぁ、同期対象のホスト群)を見失ってしまうというエラーで、回復するためには放置しても無駄で(汗)makuosanを再起動するしかなささそうだけど、再起動してもしばらくするとエラーメッセージ(ちょっと加工してますが)を吐いて接続先を見失うという無限ループ(汗)

Sep 4 11:38:01 centos makuosan: root: mrecv_gc: pong timeout some.host.net

Sep 4 11:38:01 centos makuosan: root: [error] member_del_message: pong time out: XXX.XXX.XXX.XXX(some.host.net)

これが発生するのは、makuosanを起動、もしくは再起動してからだいたい5分後。起動直後の5分間はまともに接続先が見えているんだけどなぁ…と思いつつ、なんとなくiptablesの設定を疑って他のマシンの設定ファイルとdiffを取ってみたり、makuosanを再インストールしてみたり…と、とっても五里霧中な感じのトラブルシューティングが続いた。

で、うろうろしたあげくに、makuosanのソースの「makuosan.h」を見てみると、以下のような記載があった。

/*----- timeout -----*/
#define MAKUO_SEND_TIMEOUT  500    /* 再送間隔(ms)                                 */
#define MAKUO_SEND_RETRYCNT 120    /* 再送回数                                     */
#define MAKUO_PONG_TIMEOUT  300000 /* メンバから除外するまでの時間(ms)             */
#define MAKUO_PONG_INTERVAL 45000  /* PONG送信間隔(ms)                             */
#define MAKUO_RECV_GCWAIT   180000 /* 消し損ねたオブジェクトを開放する待ち時間(ms) */

エラーメッセージに「pong timeout」と書いてあったことと、MAKUO_PONG_TIMEOUTの時間から察するに、makuosan起動直後からPING/PONGによる接続先生存確認に失敗してる感じかなぁとぼんやり妄想してみたが、やっぱりよくわからない。しかも、調べてみると、「とあるホスト」からは、周囲にいる接続先が見えなくなるけれど、周囲にいる接続先から「とあるホスト」は見えたまま…とうアンシンメトリーな状態だったことがわかり、なんとも気持ち悪かった。

…で、もうなんとなくやることがなくなって、唐突ではあるけれど「NICが怪しい」と思い始めて調べてみた。この「とあるホスト」はコストをケチるために、オンボードのNICに加えて、玄人志向製の「GBE-PCI2」(…なんか安易な型番だな)を使っていて、使っているチップはVIAの「VT6122」とのこと。いわゆる、Velocityシリーズってやつ。

この「VIA Velocity」用のドライバは、私が知る限り、2種類あって、1つがCentOSに入ってる「via_velocity」で、もう1つがVIAのサイトからダウンロードできる「velocityget」。以前、とあるMLで「via_velocity」のデキがよろしくないようで、Sambaなどで性能劣化を起こすという投稿を見つけていたので、「とあるホスト」には、VIAのサイトから「velocityget」を落として組み込んであった。…はずだったが、先日、カーネルを更新した際に「velocityget」を再インストールするのを忘れてたらしく、lsmodしてみたら、いないはずの「via_velocity」がいらっしゃった！(modprobe.confでは「velocityget」を指定してあったけれど、肝心の「velocityget」が存在しないから、代わりに「via_velocity」が読み込まれて、何となく使えてたらしい)

目下、makuosanが接続先を見失う問題に対しては、特に打つ手もなかったので、期待を込めて「velocityget」をインストールしなおし、「via_velocity」を/etc/modprobe.d/blacklistに書き込んで、マシンを再起動してみた。

そして、makuosanが起動して5分後、やや緊張しながら/var/log/messageを覗くと…何にも出力されていない。「msync –member」をやってみても、makuosanは接続先を見失っていなかった！

…というわけで、起動して5分でmakuosanが接続先を見失うという問題は、makuosanとはまったく無関係な、安いNICと怪しげなドライバが原因だったという、なんともお粗末な結末…orz。

今度、マシンにNIC足すときは、なんとなくbroadcomとかIntelのNICにしようと決めた次第である。