ネットニュース記事案内 (2007年12月11日〜)

Expireのことを忘れているような雰囲気が…(笑)。この手の記事は、送られたそのときにいたユーザが読めばそれで事足れりというわけじゃなくて、新規ユーザがいつ来ても目的の記事を読める状態にないといけないので、送るほうで勝手に判断して送らないってのはまずいような気がします。

NNTP的思想を考慮すると、

• 記事送出側は過去記事のMessage-ID(群)を指定して、その記事がある場合は蓄積しなくてよい旨を意思表明する
• 記事蓄積側はそのままスプールに入れてしまってもいいし、過去記事がある場合は過去記事だけ残して新規記事は除去するか、過去記事を新規記事で置き換えるか、それ以外のなにかの方式を取るかは自由(サイトポリシによる)

という感じかな。どっちにしろ、RFC 3977を更新しないといけないような気がする。

問題は、どこまでの過去記事Message-IDをリスティングすれば目的が達成できるかがわからないので、とりあえず過去に送った同内容メッセージの全Message-IDをつけないと普遍的な解決にはならないってところですか。

う〜ん、これは

• ネットワーク設定を変えるけど、その設定の反映を遅らせたい
• ネットワーク設定を変え、反映させるけど今の接続は前のまま

のどっちを希望してるんだろ?

後者ができると非常に便利ですけど、できる環境をちょっと思いつかない。

前者はやりようによってはできると思うけど、じゃあ反映するその瞬間はどうするんだって気がする。ちなみに、Linux(RedHat)でよくやるのは/etc/sysconfig/network-scripts配下のファイル(例えばifcfg-eth0)を直接手で変更して、そのディレクトリで

% ( sleep 3 ; ./ifdown eth0 ; sleep 1 ; ./ifup eth0 ) & exit

とかやったりしますが、設定内容を間違えてると当然二度と接続できなくなりますね(笑)。MacOSXでこういうことをしようとしてるって思っていいのかな?

コンソールリダイレクションとかIPMIとかが根本的な解決方法なんだろうけど、MacOSXということだからハードウェアがMacintoshなんですよね。XserveならIPMI対応とかしてる可能性もありそうなのだが、クライアント機だとたぶん無理か。

でも、リモートで制御したいってんだから、クライアント機ってことはないと思っていいのかな?