lmtp2nntp の使い方がいまひとつよく判らないので、使い慣れた innd に戻すことにした。
ユーザー認証は、pam_pop3 を使って、間接的にcyrusのパスワードを参照することにする。
pam_sasldb というのが在るらしいのだけれど、サイトがリンク切れで辿り着けない。
2011年4月26日火曜日
2011年4月20日水曜日
cyrus nntp と replication
cyrus imapd に組み込みの nntpサーバーは、cyrus imapd の replication では複製できないのかな。
とりあえず、何も考えずに設定すると、エラーが延々とでる状態に陥ってしまう。レプリカの方ではnntpを動かさないとか、何かおまじない的なことが必要なのかもしれない。
とりあえず、何も考えずに設定すると、エラーが延々とでる状態に陥ってしまう。レプリカの方ではnntpを動かさないとか、何かおまじない的なことが必要なのかもしれない。
2011年4月18日月曜日
節電とLED電球
電力節約のために電球をLED型に替えた、なんて話が、ちらほら聞こえてくる。
長期的にみれば、それはごもっともな話なのだけれど、短期的に見て(つまり、電力不足が問題となる、ここ数年の観点で)本当に節電になるのかというと、話は少し変わってくる。
今の店頭在庫にあるLED電球は、発電所の事故以前に作られたものだろうから、それは別にして、これから製造されるLED電球を作るための電力コストはどのくらいになるのだろう。どちらもほぼ自動的に工場生産されるものだから人件費コストはたいした量ではない。違うのは製造に要する製作機械のコストと製作に関わるエネルギーコストが大部分。非常に大雑把な見積もりが許されるのなら、LED電球と従来の電球との販売価格の差は、それを製作するために要するエネルギーコストの差を反映していると思っていいのではないだろうか?
今の市場価格がどの位の開きがあるのかわからないけれど、仮に20倍の差があるとして、LED電球を一個つくるのに必要なエネルギー(製作機械を生産するためのエネルギーを含む)は、従来型電球の10倍くらいあるような気がするのだが、どうだろう。
時間をかけて LED電球に移行するのは確かに節電効果があるだろうが、一気にLED電球に走るのは、今年・来年の電力不足には却って逆効果な気がする。
年間に何%の電球を交換するのが一番節電になる、といったデータがあればよいのだが、それを計算するには上の見積もりでは荒すぎる。
長期的にみれば、それはごもっともな話なのだけれど、短期的に見て(つまり、電力不足が問題となる、ここ数年の観点で)本当に節電になるのかというと、話は少し変わってくる。
今の店頭在庫にあるLED電球は、発電所の事故以前に作られたものだろうから、それは別にして、これから製造されるLED電球を作るための電力コストはどのくらいになるのだろう。どちらもほぼ自動的に工場生産されるものだから人件費コストはたいした量ではない。違うのは製造に要する製作機械のコストと製作に関わるエネルギーコストが大部分。非常に大雑把な見積もりが許されるのなら、LED電球と従来の電球との販売価格の差は、それを製作するために要するエネルギーコストの差を反映していると思っていいのではないだろうか?
今の市場価格がどの位の開きがあるのかわからないけれど、仮に20倍の差があるとして、LED電球を一個つくるのに必要なエネルギー(製作機械を生産するためのエネルギーを含む)は、従来型電球の10倍くらいあるような気がするのだが、どうだろう。
時間をかけて LED電球に移行するのは確かに節電効果があるだろうが、一気にLED電球に走るのは、今年・来年の電力不足には却って逆効果な気がする。
年間に何%の電球を交換するのが一番節電になる、といったデータがあればよいのだが、それを計算するには上の見積もりでは荒すぎる。
2011年4月17日日曜日
gjournal と time stamp ( その2 )
cyrus-imap の reconstruct を実行すると、"timestamp mismatch" のエラーが大量にでる。
reconstruct を 繰り返しても、エラーがなくならない。
gjournal の問題なのだろうか? それとも、ハードディスクが壊れている?
この状態だと、ちょっと使えないので、近いうちにディスク検査 & 通常の UFS2 に変更だな。
reconstruct を 繰り返しても、エラーがなくならない。
gjournal の問題なのだろうか? それとも、ハードディスクが壊れている?
この状態だと、ちょっと使えないので、近いうちにディスク検査 & 通常の UFS2 に変更だな。
2011年4月16日土曜日
gjournal と time stamp
FreeBSD6.4のufs2 File System と、FreeBSD 8.2 のgjournal File System の間で、rsync すると、time stamplが正しく設定されない。
--modify-window=2 (1はまだ試していない)を指定すると、正しく転送されるようなので、たぶん両者のtime stampの精度に違いがあるのだろう。
FreeBSDのバージョン違いのせいなのか、ファイルシステムの問題なのかはよくわからない。
--modify-window=2 (1はまだ試していない)を指定すると、正しく転送されるようなので、たぶん両者のtime stampの精度に違いがあるのだろう。
FreeBSDのバージョン違いのせいなのか、ファイルシステムの問題なのかはよくわからない。
東電は経費節約、政府は金銭感覚マヒ
なんだか、政府のばら撒き政治がはじまったみたいね。
「安全だ」で通せばいいのに、そのうち風評被害まで補償の対象に含めてしまいそうだね。
一方で東電はといえば、どうしたら安上がりに解決できるか、そればかり考えているように見える。
何をするにも、政府の干渉が多くて即決できないのかな。船頭多くして... の典型なのかも。
「安全だ」で通せばいいのに、そのうち風評被害まで補償の対象に含めてしまいそうだね。
一方で東電はといえば、どうしたら安上がりに解決できるか、そればかり考えているように見える。
何をするにも、政府の干渉が多くて即決できないのかな。船頭多くして... の典型なのかも。
2011年4月10日日曜日
データの退避 (その2)
下り方向の速さを測ってみると、チャネル一つで約20Mb/s、チャネル二つだと約25Mb/s くらいの数字になった。もっともチャネル二つの場合は、こちら側のネットワーク機器が律速になっている可能性が高いので、きちんとした設備で測れば 35~40Mb/sは出るのだろうと思う。
これだけの速さが出ているのであれば、30GBでも2時間もあればダウンロードできる計算になるので、まあバックアップストーレッジとして使えるかもしれない。
転送量としては、プロバイダの方で、「快適に使えるのは 100GB/月程度まで」と制限を掛けているようなので、月に何度も丸ごとダウンロードを試すわけにはいかないが。
これだけの速さが出ているのであれば、30GBでも2時間もあればダウンロードできる計算になるので、まあバックアップストーレッジとして使えるかもしれない。
転送量としては、プロバイダの方で、「快適に使えるのは 100GB/月程度まで」と制限を掛けているようなので、月に何度も丸ごとダウンロードを試すわけにはいかないが。
2011年4月9日土曜日
「危険だ」と言ってもらいたい症候群
どうも、今の日本人は、「直ちには害を及ぼさない」とか、「乳児には危険」とか、そういう表現をすると、『じゃ、安全なのか、それとも危険なのかはっきりしろ』みたいな反応を返したくなる人が多いみたいね。
たぶん、「危険だ」と言って欲しいのだろうな。そうすれば、不安がなくなってすべてを東電や政府のせいにできて安心できる。
例えば、放射線のせいで、今まで一億人に一人の発病率だったものが、一億人に二人の発病率になったとして、じゃ安全でなくなったのか?といえば、「従来よりは安全ではない」としか言えないでしょう。じゃ危険なのか?といえば、「大抵の人にとっては、気にするほどの危険じゃない」。当たり前のこと。
たぶん、「危険だ」と言って欲しいのだろうな。そうすれば、不安がなくなってすべてを東電や政府のせいにできて安心できる。
例えば、放射線のせいで、今まで一億人に一人の発病率だったものが、一億人に二人の発病率になったとして、じゃ安全でなくなったのか?といえば、「従来よりは安全ではない」としか言えないでしょう。じゃ危険なのか?といえば、「大抵の人にとっては、気にするほどの危険じゃない」。当たり前のこと。
2011年4月5日火曜日
備忘録: phpのアップデート
php5.3.5 → 3.5.6 のアップデートをしたら、Segmentation fault を起こすようになった。
いろいろ検索してみると、どうも、phpの問題ではなくて、一緒にアップデートした libxml2 が問題らしい。
とりあえず、fixらしいのが、
http://forums.freebsd.org/archive/index.php/t-8965.html
こちらは、files//patch-configure から
phpの設定で、threadを有効にするのが正しい、というのが
http://forum.nginx.org/read.php?23,149976,151169,quote=1
いろいろ検索してみると、どうも、phpの問題ではなくて、一緒にアップデートした libxml2 が問題らしい。
とりあえず、fixらしいのが、
http://forums.freebsd.org/archive/index.php/t-8965.html
こちらは、files//patch-configure から
*freebsd*) THREAD_LIBS="";;の行を取り除けとのこと。
phpの設定で、threadを有効にするのが正しい、というのが
http://forum.nginx.org/read.php?23,149976,151169,quote=1
2011年4月3日日曜日
そろそろディスクの追加を
最後にサーバーのディスクを追加したのが2年前で、そろそろ窮屈になってきた。
もう PATAのディスクを追加するのはコスト的に見合わないし、SATAのディスクに移行するべきなのだろうけれど、そうするとマザーボードごと全取替だ。
いつもだと、比較的新しい機械を増強して、それのあまったパーツをサーバー用に転用するというパターンなのだけれど、今回は世代間の仕様のギャップが大きくて、うまくドミノ移植できるパターンが見つからない。
あまり消費電力の大きいCPUをサーバーに回したくない、というのが最大のネックかな。
もう PATAのディスクを追加するのはコスト的に見合わないし、SATAのディスクに移行するべきなのだろうけれど、そうするとマザーボードごと全取替だ。
いつもだと、比較的新しい機械を増強して、それのあまったパーツをサーバー用に転用するというパターンなのだけれど、今回は世代間の仕様のギャップが大きくて、うまくドミノ移植できるパターンが見つからない。
あまり消費電力の大きいCPUをサーバーに回したくない、というのが最大のネックかな。
登録:
投稿 (Atom)