なんとなく実験 with SIProp開発記

SELinuxについて、つらつらと。。。

●各デーモンの設定具合
では、本題のSELinuxが、どのくらい設定されているか確認。
（Zオプションで、SELinuxのドメインが表示されます。
　unconfined_tというドメインは、全てOKというSELinux無効モードです。）

# ps -eZ

・unconfined_t以外のドメインが設定されている物
named,ntpd,postgres,mysql,apache,syslogd,snmpd,squid

と、基本的な物は、SELinuxで設定されているようです。

が、sendmailなどのメール系は、設定されていない模様。
それに、あまり使用しないような物も、設定されていません。

この手のセキュリティー系は、全てに対して設定しなければ、意味がない
ため、このままでは、無意味としか言いようがないでしょう。
（セキュリティーは、一カ所でも破れれば、OKですからね。
　侵入時に、全てのドアや窓の鍵を破る泥棒はいないのと同じです。）


●各アプリの設定具合
続いて、どのくらい強固な設定となっているか、設定ファイルをのぞいて
みようと思います。
今回の題材は、ネットにいっぱい情報が転がっているapacheちゃんです。

・各ディレクトリに割り振られたドメイン
/etc/selinux/targeted/src/policy/file_contexts/program/apache.fc

・各ドメインの権限
/etc/selinux/targeted/src/policy/domains/program/apache.te

二つのファイルが、連携して、各ディレクトリやファイルに対し、権限操作を行って
います。

「apache.fc」に、どのディレクトリやファイルにどのドメインを割り振るかを記述し、
「apache.te」に、どのドメインが、どんな権限(書き込み権や実行権など)を持って
いるかを記述します。

これをのぞいてみると、、、

読み込み用、スクリプト実行用、ログ用、コンフィグ用

など、いろいろロールに分かれており、良さそうに見えなくもないのですが、
実際には、「httpd_tドメイン」には、書き込み権など強力な権限が割り当て
られていますので、実環境にあわせて、もう少し権限を絞る必要があると
思います。


●まとめ
といったように、全体的に利便性重視の甘い設定がされているようです。

実は、それもそのはずでして、現在のポリシーは、「targeted」というものに
なっています。
このポリシー自体が、利便性重視なのです。

そのため、セキュリティー重視の「strictポリシー」という物があり、こちらを
利用すると、とてもがちがちな設定をしてくれるようですが、動かなくなる
アプリが続出すると思われますので、すべて、正常動作させるようにするには
かなり、根気のいる作業となります。
しかし、そうした場合、かなりのセキュリティー(TCSEC(米国のセキュリティ
評価基準。通称オレンジブック)でB1レベル相当)を、実現できるはずです。


●感想
個人的な感想としましては、「strictポリシー」で動作させる気がないのだったら
素直に、Offにしておいた方がよいように思います。

通常、サーバをたてるときには、開発したアプリをインストールしたり、メール
サーバなどを動かしたりすると思いますので、デフォルトの設定のまま使用する
可能性はほとんど無いと思われるためです。


●おまけ

ちなみに、設定法の基本は、下記のパターンで、設定していくことになります。
もう、気が遠くなりそうですよね。。。

1，「setenforce 0 」で、「permissiveモード」というSELinuxのアクセス制御を
　無効にするモードで、動作確認をする。

2，「setenforce 1 」で、SELinuxのアクセス制御を有効にして、再度、動作確認を
　する。

3，動かない場合には、SELinuxのアクセス制御(*.fc,*.te)を再度設定する。
　「ドメインがどんなファイル・リソースにアクセスできるか」ですので、
　考え方はより詳細に制御できるパーミッション管理と変わりません。
　一つずつ、潰していけば、必ず、設定できるはずですので。

まっ、入れねばならぬでしょう、ということで。(^-^;A

●変更点
変更点としましては、、、という、細かい話は、

http://www.redhat.com/software/rhel/

を、見て頂くとして、今回の変更点で、
「プログラマ」としては、

・Kernel2.6
・I/Oまわりの変更

が、気になるところでしょうか？
パフォーマンスやスケーラビリティー、さらに、プログラムの組み方（ﾉД｀）
が、パワーアップしているらしいです。

組み方については、もちろん、いままでのやり方でも動くのですが、より
パフォーマンスを出せる組み方が出来るようになっています。


つづいて、「管理者」としては、

・SELinux（Security-Enhanced Linux）
　これについては、この辺の連載がよいかも？？？まだ更新されるようですし。

でしょう。なんといっても。
しかも、これ、デフォルトでONになっているとのこと。

パーミッションの扱いなどが、大きく変わりますので、移行やバージョン
アップ組は、苦労するんじゃないでしょうか？
それに、新規システムだとしても、SELinux流の設計・設定をマスター
しなくては、構築もままなりません。
（まぁ、使わなければよいという話もありますが。）

この点から、SELinuxについては、少々、つっこんでみたいと思います。
（ただし、細かい話はやりません。ほかで、いっぱい出てますので。)


●インストール
さて、では、早速インストールをしようかと思います。
インストールマシンは、例のごとく、VMWareちゃんです。

VMWareで、インストールOSとしてLinuxを選択すると、ディスクのインター
フェースにSCSIが選ばれますが、RHEL4.0では、自動認識されないようです。

使用可能なSCSIドライバは、下記の物なのですが、デフォルトの選択肢には
ないのです。
もちろん、ドライバを別途作って読み込ませれば、OKなのですが、ここは
めんどくさいので、あきらめてIDEに接続し直すことにします。

・Buslogic BT-958 Compatible

・LSI Logic LSI53C10xx Ultra160

このあとは、いつものanacondaちゃんが起動します。
いままでのインストーラそのままですので、迷う人もいないでしょう。

ただ、一点、ファイアーウォールの設定のところで、SELinuxを使うかどうかの
設定が増えています。
使いたくない人は、ここで、使用しない設定にしましょう。
今回は、これがメインイベントなので、「アクティブ(デフォルト値)」です。


そして、インストールが無事に終了したら、起動画面が現れます。
ここからが、今までと少々違うようです。

最初に、Windowsの様にRedHatNetworkアクティべーションを要求されます。

ここで、登録しないと30日のトライアル版扱いとなるようです。

以上でインストールは終了です。


そして、無事にgnomeGUIが起動するわけですが、こちらも大きく変わって
いるようです。
あえて、キャプ画面は載せないので、どう変わったかは、皆さんの目で
お確かめを。

さて、いままで、意図的に極力避けてきたのですが、そろそろ、ぽつぽつと
思考系の話でも書いてみようかと思います。

某MLに入っている人は、お解りかもしれませんが、個人的に、こういうのは、
大好きなのでして。(^-^;A
（下手の横好きってことで、大目に見てやってください。）


今回は、ぶっちゃけ、yusuke大先生の話に釣られました。(^-^;A

これをベースに、ちょろちょろと書いてみようかと思います。


●儲ける構図
個人的に、Skypeが、2ndPhone以上にはなれないと感覚的に考えていたのですが、
その答えの一つを見つけた感じです。

SIPとSkypeも似た構造にあります。
SIPは、RFCであり、仕様は一般に公開され、実装は各々が行うことになります。
Skypeは、ソフトが提供されており、APIを使用する場合、ライセンスが発生すると
いう構図になっています。

これは、yusuke大先生のblogにある、JavaとZopeの構図の類似といってよい
と思います。


●現在の構図
現在、SIPもSkypeも「電話の延長」としてしか実装されていないような状態です。
そのため、電話をやろうなどと言うところは、限られるわけです。

よって、儲けの構図は、

「電話屋さんが自社の製品のリプレースくらいしかない」

という状況です。
そのため、一社が握っている技術を主製品の基盤として開発しては、リスクが
高すぎるため、Skypeが選択肢に入ることはありえないわけです。

そのため、Skypeががんばっても、2nd製品以上には成り得ないわけです。


●未来の構図
現在、「電話」としてしか使われていませんが、本来的にこれらの物は、

「コミュニケーションツールとした場合」

その真価を発揮できると考えています。
(正確には、SIPはただのセッション管理でしかないですが、これでは、あまりに
抽象的すぎるので。)

このように発展してくると、現在「電話屋」しかない市場が広がっていき、
いろいろなベンダーが参入してくることが予想されます。

この状態となると、まさに、JavaとZopeの構図と同一になるといえるのでは
ないでしょうか？


※※※以上。yusukeさんの説を元とし導き出せる仮説としての考察です※※※

いままで、Pen3-1GHz Dual のマシンにWindows2000 Serverを入れて、外部からネットワーク経由(VPNやSSHトンネル)にて、リモートデスクトップを叩いておりました。

これにより、ネットワークにつながっていれば、どこからでも全く同じ環境が使えるという構成にしておりました。

しかし、最近、個人的な理由によりネットワークから隔離された場所を往復する必要性が出てきたのとさすがにそろそろスペックが苦しくなってきたため、リプレースすることにしました。






基本的なコンセプトは、

・どこでも同一環境・同一データを扱える
・データ保全(確実なバックアップ環境)
・ネットワークを使用しない環境でも使用可能

そこで、今回考えた構成は、、、

・超弩級スペックのノートPCをメインマシンにする
・ノートPCだけにデータを入れておくのは、故障が怖いためデータバックアップ用のマシンを用意する

チョイスしたマシンは、、、

・超弩級母艦　IBM ThinkPadT42pの後継機(ただいま、待ち状態。(^-^;A)
　堅牢性とスペックの高さからチョイス。やはり、個人的にThinkPad以外のノートPCは、信じられないので。
・データバックアップマシンとして、ARAID99 にて、RAID1構成を作り、冗長なバックアップ領域とする

　

いまは、母艦マシンとして、IBM ThinkPad X21 を使用中。
先週は、ずっと、この環境を整えてました。(^-^;A

バックアップ先としては、バッファローの「TeraStation」も捨てがたかったのですが、音楽・ムービー再生環境と兼用にしたかったので、上記のチョイスと
なりました。




ちなみに、ネットワークに接続できるのなら、やはり、リモートデスクトップ環境がベストかと思います。
ネットワークの速度としては、128kのAirH"では、少々荷が重いというところ。使えなくはないですが、ストレスがたまります。
最近発表された、256kのAirH"が160k〜200kくらい出るということですので、このくらいあれば、あまりストレス無く使えるかもしれません。
ちなみに、RDP（リモートデスクトップが使用するプロトコル）自体に圧縮機能があるので、AirH"のトルネードWebなどは役に立ちません。(128kが、90k〜110kくらい。)

接続先のOSとしては、XP Proがリモートデスクトップをデフォルト装備ですので、それを、メインとして使うのがよさそうです。
ただ、今までの経験からXP Proは一週間に一回くらいフリーズすることがあるので、この辺、対処策が必要かもしれません。

2003 Serverを使うという手もありますが、ライセンスが高いという欠点があります。また、Serverを使うときは、Admin権限で利用することをお奨めします。
普通のUser権限ですと、運用するといろいろとトラブリますので、対処するための知識が必要となり、けっこうハードルが高いです。

やはり、個人的に気になるのが、メッセージプロトコルがHTTP+XMLという点
ですね。
まさに、SIP+というか、SIPの別プロトコルを考えたら、こうなるよねという
典型的なモデルの一つです。

個人的には、非常にアリだと思っています。

ただ、組み込み系を考慮すると、HTTPサーバ+XMLパーサ+teleoStackを積む
のは、現時点では、スペック的に非常に厳しいと思われます。
現在の流れを考えると組み込み系ははずせないため、ここをどうするのか？が
ポイントになるかなと思います。
(もしかすると、SIP互換という機能は、このためにある可能性アリです。
組み込みは、SIPで通信すると割り切っているのかも。)

でも、これだけじゃ、SIPの問題点は、解消されないという罠。
けっきょく、互換性が一番の問題点ですので。。。




そして、致命的なのが、パスワードの扱いなどのセキュリティーまわり。
暗号化なし、平文でパスワードを流すというのは、もう、致命的とかそういうのを
通り越して、リカイフノウ。

さらに、プロトコル的にセッションハイジャックが比較的簡単にできそうな
印象もあります。

これで、「プリペイド式で金払ってね」と言われても無理がありすぎです。




とてもじゃないが、Skype対抗にはならないというのが、印象です。

どうやら、メッセージは、HTTP+XMLで制御メッセージは通信しています。
ということは、TCPなんですね。
やはり、UDPで制御メッセージのやりとりってアレゲなのかなぁ。
UDPで、やりとりすると、どうしても分割の問題が発生してしまって
他網と接続することを考えたりすると非常に厳しいんですよね。
ほかにも、暗号化しようとしたときに問題もありますし。。。

ちなみに、音声は、RTPをそのまま使用しています。UDPです。




下記に代表的なメッセージのサンプルをピックアップ。
(こんなの書いて、開発元からつっこまれたらやばいなぁ。
つっこまれたら、速攻、削除するので、その辺ご了承ください。)

●ログインメッセージ。
＿|￣|○　ガックシ・・・ また、パスワードは平文かよ。。。
と、いきなりへこみ気味ですが、気を取り直して。

さて、メッセージとしては、単純ですね。
SIPのREGISTERをかなり単純にした物という感じで、あまり、つっこむ
ようなところはないですね。
ただ、バージョン番号が、下記の2種類あるのが気になります。
う〜ん、これだけ内容が違う物が入っているというのは、いやな感じで
すね。

<version id="1.0">
<version id="clientManager-client XML v0.9">

・サーバへの送信メッセージ

<?xml version='1.0' encoding="UTF-8"?>
<clientMsg>
  <version id="1.0">
    <date>02/16/2005</date>
    <ip>192.168.100.191</ip>
    <mid>073106872</mid>
  </version>
  <sipRegister>
    <uName>teleo2@noritsuna.jp</uName>
    <Password>password</Password>
  </sipRegister>
</clientMsg>

・サーバからの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:01 GMT</date>

    <mid>073106872</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

●プレゼンス情報
ユーザリストに登録されている人の生存情報がサーバから送れてきます。
そのときのメッセージです。

<sipAccountStatus>

が、肝の部分。

<accountBalance>

が、謎ですが、それ以外は、見たまんまと言うところ。
これが、そのうち拡張されるのかが、個人的には興味アリです。


・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:01 GMT</date>

    <mid>236411472</mid>

  </version>

  <sipAccountStatus>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <accountBalance>0.5</accountBalance>

    <DID>15109041126</DID>

  </sipAccountStatus>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>236411472</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

ちなみに、

<sipAccountStatus>

だけではなく

<sipOk>

という、ものもあるみたい。
どう違うのかは、現在不明。




●コール(発信)
通話した時のメッセージ内容。
これは、SIPとは違う動きをするようなので、詳細に追ってみたいと思います。


1，最初に、どこと通話をしたいのかネゴシエーションをとる。

これは、接続先が、teleoやGW、SIPなどいろいろなプロトコルとの相互接続を
考えているために、プロトコルのネゴシエーションをしているのではないかと
思います。

・サーバへの送信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>073131767</mid>

  </version>

  <sipOutboundCall>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <called>15109041126</called>

    <receivePort>30000</receivePort>

  </sipOutboundCall>

</clientMsg>

・サーバからの応答メッセージ1

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>073131767</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

・サーバからの応答メッセージ2(相手もOKという情報)

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>450446506</mid>

  </version>

  <sipOk>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <uName>teleo2@noritsuna.jp</uName>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipOk>

</serverMsg>

2，サーバから相手のメディアに関するネゴシエーションが送信されてくる。
SIPでは、発信するクライアントが「1」のパケットにSDPという形で載せるのが

一般的ですが、teleoは、全く逆な形を取っているようです。
（ちなみに、このように動くSIPもあります。ACKにアンサーSDPを載せます）

ちなみに、SDPに相当する部分は、かなり似通っていますね。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id='sipManager-stateMachine XML v0.9'>

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>086512035</mid>

  </version>

  <sipRTPConnect m='audio'>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <rtpAddress direction='IN' type='IP4'>216.143.130.43</rtpAddress>

    <rtpPort>9232</rtpPort>

    <availableMedia>

     <codec a='rtpmap:101' >

       <version>telephone-event</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:3' >

       <version>GSM</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:18' >

       <version>G729</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:8' >

       <version>PCMA</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:0' >

       <version>PCMU</version>

       <rate>8000</rate>

     </codec>

    </availableMedia>

  </sipRTPConnect>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>450446506</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

3，サーバから相手のメディアに関する最終応答が送信されてくる。
相手が、受話器を取った状態です。
内容的には、mid以外、同じ物のようです。

これは、SIPで言うところの200応答に相当する物のようです。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id='sipManager-stateMachine XML v0.9'>

    <date>Wed, 16 Feb 2005 03:25:34 GMT</date>

    <mid>387355624</mid>

  </version>

  <sipRTPConnect m='audio'>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <rtpAddress direction='IN' type='IP4'>216.143.130.43</rtpAddress>

    <rtpPort>9232</rtpPort>

    <availableMedia>

     <codec a='rtpmap:101' >

       <version>telephone-event</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:3' >

       <version>GSM</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:18' >

       <version>G729</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:8' >

       <version>PCMA</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:0' >

       <version>PCMU</version>

       <rate>8000</rate>

     </codec>

    </availableMedia>

  </sipRTPConnect>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>387355624</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

4，「3」のメッセージ直後、サーバからACK相当送信されてくる。

これは、SIPで言うところのACKに相当する物のようです。
これといった、特徴はありません。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:34 GMT</date>

    <mid>435870003</mid>

  </version>

  <sipOk>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <uName>teleo2@noritsuna.jp</uName>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipOk>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>435870003</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

●BYE(切断)
切断した時のメッセージ内容。
SIPと違い、両方で投げ合うような動きをしています。

課金を伴うサービスであるため、切断には、万全の体制を取るのが普通であり
当然の仕様と考えられます。
万が一、切断情報が相手に届かなければ、誤課金へつながるおそれがあるため
です。

・サーバへの送信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>073160559</mid>

  </version>

  <sipHangUp>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipHangUp>

</clientMsg>

・サーバからの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:54 GMT</date>

    <mid>073160559</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

サーバ側から、再度、同じ切断メッセージが送信されてきます。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:54 GMT</date>

    <mid>472351630</mid>

  </version>

  <sipHangUp>

     <uName>teleo2@noritsuna.jp</uName>

     <callID>77757717-3332-8208-4376-688581188635</callID>

     <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipHangUp>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>472351630</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

●セッションタイマ
サーバ主導型のようです。定期的に、送信されてきます。

まぁ、NAT越えしているので、その方が、よいのかもしれません。
ただのポーリングといえば、それまでですが。(^-^;A

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:31 GMT</date>

    <mid>708746305</mid>

  </version>

  <teleoHeartbeat />

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>708746305</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

以上。

SIPとも互換性があると謳っているSkype対抗のソフトウェア・teleo。

売りとしては、下記の点らしいです。

・普通の固定電話からの着信にも対応！
・IEなどにバーが追加される！（Googleバーみたいなの）
・SIPともお話しできる！

ということなので、いろいろと試してみました。




まず、アプリケーションとして、とても不安定ぽ。
アイコン化された後、何をやっても元に戻せないことが。（ﾉД｀）ｼｸｼｸ

さらに、そのあと、登録されているアカウント情報がめちゃくちゃになり
接続できない事態が発生。。。
ちゃんとした物に書き換えることにより、接続できましたが、その後、
何度起動し直しても、アカウント情報壊れちゃいます。orz

んで、アカウントを登録したのですが、その最終認証画面。
URLの部分をよ〜く見てください。(図、赤い囲みの中)
「http://www.teleo.com/activate.php?user=teleo@noritsuna.jp&pass=password」

IDとパスワードが、平文&パラメータとしてわたってる。しかも、SSLじゃない。orz

という感じで、ちょっと使っただけですが、α版レベルという印象です。




■機能

・メッセージング機能
電話しかできないんですね、これ。
メッセージくらい送れればよいのに。。。




・通話品質
は、、、（ﾉД｀）ｼｸｼｸ すみません。ヘッドセット持ってないんです。
試せませんでした。ぺこ <(＿ ＿)>




・IE統合機能
いらないかも。。。IE起動するたびに通信してくれるので重いIEがさらに重く
なる罠。。。




・NAT越え
Skypeと同じ形式の模様。
RTPの通信が始まると通信先のIPがプロバイダの物と思われるIPにかわりました。

ただ、これ以上は、下手に調査すると不正アクセスとか言われかねないので
調査していません。

次回は、通信プロトコル編の予定。

噂の企業向けメッセンジャーです。
http://itpro.nikkeibp.co.jp/members/NT/ITARTICLE/20050208/155850/

これは、自分とこに「Live Communications Server 2005」をたてるのが、
前提なので、一般の人には無関係なものなのですが、これ、プロトコルに
SIPを使用していますので、SIPヲタな私としては、反応しないわけには
いかないということで、一応、反応しておくことにしました。




技術的に見ると、ただ単に、SIP的に正常進化しただけです。
今までは、RFC2543という、古いSIPの仕様に準拠していたのですが、
それを、RFC3261という、新しいSIPの仕様に準拠し直したバージョン
という、ところです。

機能的にも、今までのメッセンジャーで出来ていたことだけですし、
他社のSIPソフトフォンでは、もっと、機能が豊富なくらいです。

ただ、さすがは、ゲイツ様謹製ソフトは、ひと味違っておりまして
微妙に、RFC3261からはずれたりして、独自な実装がされている
部分があります。
そのため、純粋なSIPとしてみると、結構、微妙なものがあり、実は
最近、泣かされた経験があります。(^-^;A




と、いった感じで、別に、どうでもよいようなものだったりします。

本文の最後に、普及に関してかかれていますが、まさに、その通りで
国内メーカーが対応してくれるわけがありません。
SIP的に見ても、独自な部分がありますし、機能的にも思いっきり
かぶるとなったら、だれが、対応するんでしょ？って感じです。

そんなことをやるんだったら、無償でAPIまで公開するとか、オープン
ソースするとかしてくれると、非常にうれしいのですが。。。
※Longhornで、SIP関連のAPIが載ってくるようですので、こちらを
　利用すれば、もどきを作ることは可能になるかと思います。




ただ、この辺は、いつものMSの必勝パターンで、最初は糞のような
リリースを出して、そのうち、追いつき、気がついたら、トップシェアと
いうパターンになるんですかね？

＠ITにて、仮想マシンの記事が、掲載されていたので反応してみます。

まずは、これ。
http://www.atmarkit.co.jp/fsys/kaisetsu/053virtual_machine/virtual_machine.html

う〜ん、ごくごく普通の仮想マシンの使い方ですね。
これといって、特筆するようなものはなし。

ただ、

シナリオ3：OSイメージのバックアップをとる

は、結構便利かもと思いました。
サーバのディスクイメージってとるの大変ですから、こんな感じで
さくっとイメージとれるのはすばらしいことだと思います。
ほんとに、これだけでも使う価値ありですね。




そして、最後に、書いてありました。
これです、これ。これが、仮想マシンの真髄です。

複数のサーバをまとめて、リソース・プールを作成し、そこから必要なリソースをアプリケーションが得るような仮想化技術が普及することになるだろう。

聞いたことあると思います、これと同じことを言っているシステムって。
そうです、「グリッド」です。

実は、この手の技術って、こういう使い方なんですよね。今の流れって。
私の求めているシステムは、これなんです。この辺の突っ込んだ話は
いずれまた。








続いて、こちら。
http://www.atmarkit.co.jp/flinux/special/vm/vm01.html

こちらは、もう少し、大きな概念の説明ですね。
非常にわかりやすく、よくまとまっています。




そして、どうやら目玉になっているようですが「仮想マシンモニタ Xen」。
これ、これがすごいんです。「専用モニタを用いる仮想マシン」の解説を
読んでみてください。
どうでしょ？これも、「グリッド」を彷彿とさせませんか？

これを踏まえて、こちら。
http://www.computerworld.com/hardwaretopics/hardware/server/story/0,10801,98814,00.html?source=NLT_LIN&nid=98814

Xenが、RedHatとSUSEに、載ってくるらしいのです。
もし、本当に載ってくるとすれば、これらのOSをインストールした時点で
グリッドのリソース候補マシンの完成です。

Xenに関しては、すでに動いているおもしろいネットワークもあるので、
そのへんを含めて、いずれ書こうかなと思います。
はっきり言って、この辺は、すごいです。




近いうちにXenの記事を出すそうなので、かなり、期待です。






おまけ
http://www.itmedia.co.jp/news/articles/0502/08/news023.html
Cellが、発表されてようです。
こちらは、言わずとしれたPS3＆グリッドコンピューティング用のプロセッサです。
記事中央付近に、「仮想化技術」の文字が。。。
IntelでいうところのVanderpool Technologyがデフォルト装備されていると
みてよさそうです。

これからみるに、グリッドを実現するアーキテクチャ的には、上で解説している
ようなXenなどのアーキテクチャを元にやるようですね。
やはり、グリッドは、仮想化からってことですね。

しかし、スペック見るほど、化け物プロセッサですね、これ。
PPC完全互換と言うことは、某MacXが走る可能性が。これは、すごいかも。
もちろん、YellowDogLinuxなんかも動く可能性もあるわけで。

どこか、PC汎用パーツが使えるようなマザーボード出してくれないかしらん。

Plan9な環境を作ってみようかとおもい、早速インストールしてみました。
（正確には、先週からやっていたのですが、風邪引いて倒れて他ので、止まってました。(^-^;A）

木田さんのHPを参考にして、軽くインストールしてみる。

今回のポイントは、VMWareを使ってみた点。
これにより、CPUサーバや認証サーバなどいっぱい増やすのがらくちんに
なるという利点があります。
（本家サイトには、それを見越して、VMWare用のイメージもある）

う〜ん、これといって全くはまるような点は、ございません。
OSをOtherに設定して、後は、ごくごく普通にインストールできちゃいました。

　

　

　

みよ！これが、VMWareに輝くGlendaちゃんだ！！！

　

　

　

ついしん なんとか、風邪、直ってきました。 でも、まだ、咳が止まらない。。。けっこう、くるしいです。