2009/11/18(水)体内時計は遺伝子が絡む?

2017/10/11 07:16 注目の情報
昨夜、テレビ朝日系が全国放送している「最終警告!たけしの本当は怖い家庭の医学」というのを観ました。
普段の我が家は、NHK以外は低俗なものが多く、殆ど観ないのですが、この番組は参考になるのでいつも観ています。

で、今回は「体内時計」の話。
http://asahi.co.jp/hospital/machiai/091117.html

番組で紹介されていた商社マンほど極端ではないですが、
・朝の起床が非常に辛い。起きれないこともあった。
・体調は常に悪いが、若さでフォローしていた。
・それ故、サラリーマンの頃、会社を休んだこともかなり多かった
・夜はなかなか寝付けない

という思い当たる事ばかり出てきて、
セルフチェックはやはり「超夜型」。

今まで、精神的なものも大きい(実際、会社勤めそのものに大きなストレス感じていたので・・・)と思っていたが、体内時計には個人差があって、24時間から25時間の間でばらつきがあり、それは脳の中の「時計遺伝子」というものが司るということらしい。
この「時計遺伝子」のサイクルが 24時間 に近い方々は、いわゆる「朝型人間」で日常生活に支障は無いが、25時間に近い方々(自分も含めて)は、起床すべき時間が本来は1時間ずつ遅くなるべきところ、物理的な時間は24時間なので、どうしても遅寝・遅起きになる「夜型人間」ということだ。
 遺伝子なので、寝溜めしようが何しようが、これを変えることはなかなか出来ないということになる。
 自分の時計遺伝子のタイプを知り、それに合わせる生活を営むのが一番だそうだ。治せないから。
 朝の起床が駄目で、精神的なもの・体力的なものに限界を感じて、サラリーマンを辞めたのが12年前。その後も午前中の仕事は殆ど断っていて、非難を受けることもよくあるのですが、自分の健康を考えれ>ば、サラリーマン辞めて正解だった、無理して常に先方に合わせることせずに正解だった、とちょっとだけ自信を取り戻した出来事でした。

 やはり、自分の場合「客先常駐」はやってはいけない仕事なんだな・・・

2009/11/09(月)仮想化サーバ

2017/10/11 07:18 サーバ運営・管理
この業界の悪い部分というか、当方では大嫌いな部分でもあるが、流行だとか、新しいものが最善の解決策だと思い込む中途半端な技術者がなんとも多いことか・・・

最近のトレンドは複数の方々にも言われたのだが「仮想化」らしい。
「仮想化」というのは、主に1台の物理的サーバを数台以上が稼動しているように仮想的に見せるもので、運用コスト・管理コスト低減に大きく役立つとされている模様。

まぁ、ひとつの技術ではあるのですが、既存のサーバを何でもかんでも仮想化するという現在の流れは、非常に幼稚且つ安易過ぎる。
ここが区別できない管理者や技術者が多すぎます。

先ず、「運用コスト削減」というのは、主に経費削減で得をする方々だけのメリット。利用者や運用担当の技術者に全くメリットは無いです。

次に、「管理コスト削減」というのは、主に経理管理する方々だけのメリット。同じく、利用者や運用担当の技術者に全くメリットは無いです。

仮想化によるしわ寄せは、ほぼ全て「運用担当の技術者」に行くのです。これだけならまだしも、しわ寄せがいくからと行って、「運用担当技術者の報酬」が上がるわけでもありません。

むしろ「コスト削減できたのだから、楽になるのでしょ?」と、極めて勝手な理由つけて、更なるコストダウンしようとするのが関の山。金の勘定だけで物事を進め、現場の技術者の言うことを聞かないので、幼稚で安易な「仮想化」は却って不安定なシステムを作り上げます。

仮想化が生きるのは、1日を通して殆ど使用状況が変わらず、且つCPU使用率が 1% にも満たないようなサーバに限定されると思います。

それと、Windows 等よりも FreeBSD が最も仮想化技術が安定しています。当方顧客には需要そのものが無く、今のところ使う気にはならないですが・・・ ^^;

2009/08/04(火)Apache 2.2.12

2017/10/11 07:21 サーバ運営・管理
Webサーバソフトウェアとしては、5割強から6割程度のシェアを有する Apache ですが、今般、2.2.12 からhttps のネームベースバーチャルホストをサポートするようになったということで。。
この仕組みは特に SNI (Server Name Indication と言われているようです。
RFC4366(最新は RFC5246) で提案されています。RFC提案仕様変更の可能性があるため、正式サポートになるかどうかは不透明な部分もあります。

どの程度使えるものなのか、確認してみました。
今まで、https:// にてネームベースバーチャルホスティングは、SSL通信プロトコルの規則上、不可能でした。
そのため、バーチャルホスティングであっても https:// なサイト収容のためには、同じ物理装置にIPアドレスを複数割り当てるか、別々の物理装置に収容するなどして、IPアドレスが別々になるようにする必要がありました。同じ物理装置に収容する場合、IPアドレスベースのバーチャルホスティングと言われます。

2009/07/30(木)そろそろ限界か

2017/10/11 07:23 サーバ運営・管理
Valustar VU45/T 本体 6年以上、DNSとして使っています。本来はデスクトップPCですが、24時間運転のサーバとして使っています。
CPU K6-2 450MHz,メモリ 256MByte SDRAM2枚,HDD ATA66 20GByte。

この時代の製品は、現代と異なり丈夫なものが多く、永く使えます。
台湾製のものは概ね4年くらいで逝きます。

FreeBSD 7.2 を cvsup でソースコードを取得し、

make buildworld すると 18時間弱
make buildkernel すると 約6時間

かかります。
FreeBSD 4 の時代は長くても8時間くらいで済んだものですが、、、

その他もろもろの構築作業行うと、足掛け3日かかります。
普通は、作業効率悪すぎるので、他の構築方法を選ぶか、大抵はこのスペックのマシンは捨てて、より高性能なものに入れ替えるのですけどね。

いろいろ代替方策はありますが、システムの都合上、どれも使えないのです。
どれだけコストダウンの努力をしているのかのごく一端でも垣間見ることがお分かりいただけたらと希望しています。

2009/07/29(水)OpenLDAP 2.4.17 の構築オプションはまともに機能しない?

2017/10/11 07:26 サーバ運営・管理
先日、アカウント管理に使用している OpenLDAP を、2,4,16 から 2.4.17 に更新しました。
構築時、最初に configure コマンドにてオプション設定するわけですが、オプションが有効にならなかったり、テストでエラーになったりします。2.4.16 では出なかったんだけれど、、

以下は気づいた点:
--disable-monitor と --enable-monitor=no は同じ意味になるはずだが、どういうわけか --enable-monitor=no は効かない場合がある。
--disable-monitor オプション付きでコンパイルしても、テストは実行されてしまう。だから、この場合 test056-monitor はエラーになる。
--disable-dynlist は、デフォルトでそういう設定だが、中途半端に有効になり、明示的に無効にする指定をしないと test044-dynlist はエラーになる。
--without-cyrus-sasl または --with-cyrus-sasl=no は指定しても機能しない。無効にするには、Cyrus-SASL そのものをライブラリとヘッダごと削除しないと駄目っぽい。
Cyrus-SASL は最近はまともにメンテナンスされておらず、特に FreeBSD 7.0以後、構築すると、Warning が沢山出てくる。使えるのだろうが、一抹の強い不安がある。
hdb バックエンドにおいて、test058-syncrepl-asymmetric がエラーになる。hdb はとりあえず使わないので、気にせずインストールしているが、、

2009/07/26(日)便利そうだが使えない― milter-manager/dovecot-sieve

2017/10/11 07:28 サーバ運営・管理
弊社では、営業運用として電子メールサーバを稼動させています。
今の事業形態になる前を含め、本格稼動から9年経過し、2003年8月に大幅なシステム改良を顧客のご協力を得て行ったのが現行のシステムな訳ですが、一部ソフトウェアにサポート継続が出来るかどうかの問題が出てきたため、将来的な費用対効果もあって、一部を変更する検討をしていたのですが、、

現在は、
SMTP: Postfix
IMAP/POP: Courier-IMAP
LDA:Courier-maildrop
Virus/Spamscan: ClamAV/SpamAssassin/Amavisd-new
Auth:Cyrus-SASL/Courier Authlib/OpenLDAP
という布陣です。

メールサーバというのは、サービス特性上、1つのソフトウェアのみで構成不能なのが通常で、弊社の場合は9つのソフトウェアを組み合わせて構築しています。更に稼動させるために基本OS含め5つの主なソフトウェア(うち3つが自社開発)を使う必要があり、合計14のソフトウェアで構成していることになります。
Web サーバより、はるかに複雑なのです。

そのうち、稼動負荷の高い Amavisd-new と、将来的なメンテナンスに不安材料を抱える Courier-IMAP,Cyrus-SASL と、メンテナンスコストを大幅低減を狙うため、加えて Courier-maildrop, Courier-Authlib,Cyrus-SASL の代替を探していたところ、候補にしたのは、
・dovecot (Courier-IMAP と Cyrus-SASL を置き換える)
・dovecot-sieve (Courier-maildrop を置き換える)
・既存 ClamAV の milter 対応 (Amavisd-new を取り除く)
・既存 SpamAssassin の milter 対応 (Amavisd-new を取り除く)
・milter-manager (Amavisd-new の代替)

そしてこの5つが実現できることで、 Courier Authlib も不要になり、Courier シリーズ全廃&管理コスト削減という算段だったのですが、、

dovecot-sieve は、Courier-maidrop のように、外部プログラムを呼び出して、フィルタする、ということが、現状ではできません。
これはかなり致命的。
milter-manager で消化することを試みることにしました。milter-manager は ruby 1.8とC の混在環境で稼動するよ うです。

が、設定までは何とか出来るのですが、SMTP コネクションを接続し、milter-manager を呼び出したところで、どういう訳かサーバそのものが I/O デッドロック状態のようになります 。
リセット・再起動しないと、キーボード入力すら受け付けないのです。

ruby のバージョンを 1.8.7 の最新にしてみたり、依存ライブラリ等を最新にしてみたり、上書きインストールをしてみたり、と色々試したのですが、どうもマルチスレッド絡みで根深そうなので、今回は、milter-manager の採用は見送りざるを得ませんでした。

結局置き換え出来たのは、
Courier-IMAP → dovecot
Cyrus-SASL → dovecot
Amavisd-new → ClamAV-milter (ClamAV 標準配布)

の3つで、運用管理するべきソフトが3つ減り、新たに dovecot が加わった形。
dovecot-sieve で外部コマンドが実行可能だと、Courier-maildrop と Courier-Authlib も廃止できて、更に2つ減らせたのだけれど、、
さもなければ、dovecot-deliver で maildrop と同様の機能を提供して頂くとか。現状は外部コマンド実行不可なので、この時点で当環境では dovecot-deliver の採用はできないことが判明。

dovecot-sieve は機能不足で、当環境では採用時期が早過ぎたようです。振り分けだけなら出来るのですけどね。。

2009/06/11(木)最近、変な審判多い

2017/10/11 07:31 はんかくさい
年に1~2回、何かしらの試合見ていると出くわすが・・・

1つめ:2009/05/25 プロ野球 セ・パ交流戦 日ハムvs中日
http://www.youtube.com/watch?v=rt6Nvlml4BE 〔打撃妨害?〕(Youtube です)

打者(中日・谷繁)は内角高めに来た球を避けようとして、バットを持ったまま後ろに後ずさり。
捕手(日ハム・大野)は単純に球を受けようとして、左手を高く上げた。

そのとき、捕手のグローブと打者のバットが当たった。球は避けたつもりのバットに当たった。
通常はファールを取ると思うが、何故か「打撃妨害」とされ、捕手のエラー、打者は1塁へ。

9割「あれは、ファールだろ」という意見だが、このときの審判はそれを受け入れず、監督(日ハム・梨田)が抗議するも覆ることは無かった。
#野球中継やっているアナウンサーも解説者も「あれで打撃妨害はおかしい」と力説していた。

結局、流れが崩れて日ハムはこの日の試合は逆転負け
今年の交流戦は、これ以外にもセ・リーグ側チーム主催試合の時の変な判定がちょっと目立ちます。

2つめ:ワールドカップサッカー アジア地区最終予選 日本vsウズベキスタン

後半は終始押され気味で、日本代表を応援している方は「負けるかもしれんな」と脳裏の片隅で思っていたことと考えるが、

長谷部選手が後半44分くらいに「悪質なファール」で退場(どうみても軽く相手チームの選手と不可抗力で接触しただけのように思える)、そしてなぜか岡田監督も退場処分。本人はもとより、何故退場処分なのか全く判らん。。

結局この試合は4分のロスタイムも凌ぎ勝って、ワールドカップ出場は確定したが、、、

憶測だが、サッカーのレフリー陣を買収したのではないか、という話が飛び交っているようです。
この試合のレフリー(審判)はシリア国籍。裏で北朝鮮か中国が核問題の腹いせに日本に不利な審判をするように頼んだのではないか、なんて有り得ないようで有り得る話です。

まぁ、共産主義国のインテリ官僚や役人どもは民度がすこぶる低い。よく知られた事実になりつつあります。

2009/06/05(金)松前城

matsumaetower.jpg
2009/ 5/ 5 撮影。
北海道では、唯一の城です。北海道最南端の松前町にあります。
一度、火災で全面焼失しているため、これは復元された建築物です。
桜の名所としてもよく知られており、非常に多くの種類の桜の木が植樹されています。

桜というのは「ソメイヨシノ」や「エゾヤマサクラ」「チシマサクラ」だけではなく、
数百種類あるようです。
松前町では、毎年4月末から5月中旬まで「さくらまつり」が開催されており、種類によって開花時期が異なる桜を楽しむことが出来ます。

2009/05/18(月)PDFJ が Perl 5.10 で動作しない状況を打破

PDFJ というのは、perl 上で動作する日本語対応の PDF 生成モジュールです。
作者のサイトは こちら 〔中嶋 靖 さん〕

某所サイトで PDF 出力機能をつけていたりするのだが、何故か「ファイルが壊れています」的なエラーになって、Acrovat Reader で表示できなくなった。。

最近、環境上で手を入れたこととして、
・FreeBSD を 7.2R にした
・Apache を 2.2 系にした
・PostgreSQL を 8.3.7 にした
・PHP を 5.2.9 にした
・Perl を 5.10.0 にし、mod_perl も 2.0.4 にした

という感じだが、最初の4つはどうみても関係無いなと。。
最初は何がなんだか判らなかった訳ですが、Perl 5.10 での PDFJ はどうなのか調査すると。。。

「動かない」

そうだ。。orz
ここ → 〔PDFJ を perl5.10 で動かす〕 でパッチを入手し、どうにかパッ チ当ててみると、目出度く元のように表示されました。
利用者がそれなりに広がりがあるはずなのに、情報が少ないことは同感。

2009/05/15(金)IEが一番人気だと考える時代遅れなサイトオーナ達

2017/10/11 07:35 はんかくさい
今どき、Firefox がシェア的には1番なのは常識の範疇かと思っていたのだが。。

シェア率調査はここが一番客観的だと思う → Browser Statistics

IE は、IE7,IE6,IE8 と集計を分けているが、全部合わせても Firefox には及ばない状態が現状。
IE8 を投入するも、全体的な減少に歯止めかかっていないようで。。
#上記サイトで Fx は Firefox, Sは Safari O は Opera の略。

しかし、ここ(http://www.geocities.jp/fghi6789/) なんか見てると、「自分がたまたま与えられた環境が一番標準的な環境」と思い込みが激しいらしく、「IE のユーザは多い」と知ったかぶり。

Firefox で見ると、えらく表示が崩れるので、またか、という思いで IE7 で見てみると、きちんと表示はなされるので、こういうサイトは、例外なく 「IE だけできちんと見える」ように制作されているんだ な、というのを再確認。
こういうサイトは、評価を下げる(リピータが来なくなる)んだけどね。

どうしてこうなるのか、という話ですが、IE はスタイルシートの解釈がどこまでも標準規格の挙動ではありません。
Firefox が標準規格の挙動になってます。なので、今どきの Web サイト制作者は、Firefox で先ず制作し、その後、仕方なく IE でまともに表示できるように修正するのです。

複数種ブラウザ対応のサイト制作やってみると、IE のおかしな挙動にかなり困ることを例外なく経験するはずです。

Firefox で正しく表示するサイトは、概ね Opera などでも正しく表示されます。slepinir は、ブラウザエンジンが IE のものと同じなので、このブラウザだけは例外。

とはいえ、IE8 は スタイルシートの解釈が Firefox に近いという話なので、その話を信じる限り、IE8 が来年か再来年あたりIE系の標準ブラウザになった状況では、シェア率はどうなるか想像できませんね。
IE7 で正しく表示されるサイトは IE8 対応で再び大規模な修正を余儀なくされるのでしょうかね。