BLACK WIDOW

ベンダーのフルパーミッションの問題、ここんとこ騒がしいですね。

いろいろ取りざたされてますが、ざっと要約するとネットワークを利用したベンダー分散型サーバーなどの場合、ベンダー分散型サーバー同士からのリクエスト（リンデンのサーバー経由で送られてくるパケット）から、特定のＩＤつまりアカウント、この場合もリンデン側の処理はあくまでもアカウントさえ、プリムと同じ特定のＵＵＩＤで判断するそうですが、そのアカウント向けである処理であることを、２次外部サーバーでは判断します。この場合は恐らくメインランドとは切り離したＨＤＤでの切り出された仮想ドライブへのアクセス。つまり、自販機の置かれている場所は、ＲＬでのサーバーでは分散してネットワークで結ばれたサーバーの「中」にあるということ。

問題はこのときのベンダー（わかりにくくてごめんねー＾＾；これって自販機のことね）にあるＬＳＬでその処理が誰向けであるかを、どうリンデンのサーバーが処理するかですが、問題なのはベンダーがおかれてあるＳＩＭのバージョンと実際にリクエストを送信するサーバーのバージョンが一致しているか・・といったところのようです。

ややこしいですが、わかりやすくいうと、あなたが自販機（ベンダー）でモノを買ったとします。しかし商品は全く別のところから送られてくるんですが、送られてきた商品は元々はオーナーが違う、つまりあなたが買ったものであるにもかからわず、販売した人のものってことになっているんですが、持つ権利だけが与えられた状態で発送される。

これがリンデンの商品販売の仕組みです。

商品はデーターでしかないので、情報として「誰が改変できる権利をもつのか」ってことしか付与されません。

テキストデーターでも、ＰＤＦの場合、大抵もらってもそれを改変できることはないですよね？

コレに対価を支払って、自分のライセンスにするという仕組みがＳＬでのお買い物です。たとえ買ったとしても改変はオーナーでしか許可しない設定がしてあれば、それを引き継いでいきます。

ところが非常に厄介なのは、持ち物のライセンス、つまり権限としてパーミッションを保持するサーバーと、アカウント情報を保持するサーバーはリンデンでは全く別のサーバーです。この連携がスムースでないとバルクパーミッション機能を”ビュワーに”実装しても、リクエストはサーバーでは処理されません。

詳しくは公式Second Life WIKIに譲りますが、よくＴＰ不能になるとリクリエーション・アイランドというか、デフォルトアバターのよくいる場所へ強制的に降り立つことがありますよね？最近少なくなりましたが。

あれがリンデンの扱うアカウント情報を持っているセントラル・サーバーなんだそうです。つまり自分の持ち物を変更させる場合、とりあえずセントラルに送信させ、次にインベントリサーバーにアクセスさせる仕組みになっています。

あの状況では、というかあそこでは特定の場所以外ＲＥＺ不可となっています。ＴＰできない＝サーバー同士のネットワーク障害（サーバー間トラフィック障害。よくあるよねぇ・・）が起こっているので、持ち物を扱うサーバーにアクセスさせない処置がとられるってわけ。でないとみなさん、持ち物が見当たらないとかいってリログして同じことしちゃうでしょ？＾＾だから通信でログイン以外のサーバートラフィックを一旦切っちゃうわけ。

ＳＬではよくトラフィック障害とともに、ＲＥＺ不可能という状態に陥ることがありますが、そもそも頻繁にアクセスされそして削除と追加を余儀なくされる持ち物を扱うサーバーは常にＨＤＤ断片化が頻繁に発生します。

ここで話を元に戻すと、ＳＬ内で販売を行うということは、ベンダーのＬＳＬをつかってアカウント情報保持のセントラル・サーバーにパケットを送信し、持ち物サーバーからＵＵＩＤを見つけ出し、コピーを生成して再びセントラル・サーバーに送り返し、買った人のＵＵＩＤを探し、再びその人の持ち物サーバーに・・といったトラフィックを行わないと成立しません。

ところが全てのリージョンがリンデン管轄のリージョンであれば、間違いなく修正パッチは当てられていますが、プライベートＳＩＭの場合、リージョンを管理するサーバーのＨＤＤのWINDOWＳでいうところの仮想ドライブに割り当てられているので、サーバーのＯＳから見ると、ただのパーテーションが切られた一つの区画に過ぎません。

そうなると例えそこで断片化が起こっていても、サーバーを丸ごと処理する大規模な再起動をする以外、完全なＨＤＤの安定化は図れません。

リンデンは恐らくリナックスサーバーを扱う外部データーセンターを利用しているはずなので、ＯＳ再起動なしに、ＯＳの扱うパーティションだけを最初にバージョンを引き上げているはずです。

本当なら、皆さんがよくするデフラグも、実際にはメインランド、つまりＯＳの扱う区域だけ最初に行うのが効率がいいのです。サーバーの場合ログを初期化するとか。

ところがこのところのユーザー数の増加で、リージョンだけを扱うサーバーを最近は分離する必要に迫られ、プライベートアイランドだけを扱うサーバーを用意している匂い濃厚。これは想像ですが。

つまりアカウントを扱うサーバーのパッチは最新であり、信頼できるがそのほかのバージョンの違うサーバーからのリクエストは特定のパケットを不正として跳ねている可能性があります。

こうなるとリンデンというか、サーバーセンターの怠慢というか、管理の問題ですが、パーミッションとは結局セントラルサーバーのアカウント情報の扱いであり、持ち物サーバーとの連携で成り立つことなので、ベンダーの置かれてある位置が、リンデン管轄から離れるほど信頼性が低くなってるようです。

従って送られたパケット処理はパーミッション情報を保持せず、デフォルト、つまりＭＣＴ全てＯＫ状態で送信されてもおかしくないってことになります。

ちなみにウワサでは、リンデンはリナックスでも、経費を抑える必要性から開発バージョンであるＯＳを使用することを条件にサーバーセンターと契約しているのではないか？といったウワサが私の内輪のエンジニアからささやかれています。そもそも皆さんがよくやっているＲＥＺという機能は、ＭＡＣでも実現できるApacheを使ったWebＤＡＶの技術の応用でしかありません。

http://ja.wikipedia.org/wiki/WebDAV

理由はサーバー資源を不特定多数にアクセスさせるには、正規のベンダーを通して契約できないといったハードルのせいだとも・・。

私が扱ったことがあるNOKIAのサーバーが確かWIN2000サーバーでアクセス（資源使用アカウント）２００～３００程度が１台数千万ぐらいだったと思います。あと牛柄というかホルスタインのような柄の段ボールに入ったサーバー、ナンていったかなぁ・・思い出せない・・。

自社でサーバーを管理してる体制くらい小規模な企業なら、問題はすぐ解決するんでしょうけど、サーバー３０００台も扱ってる企業だしねぇ・・リンデン。