TidBITS: Apple News for the Rest of Us  TidBITS#939/04-Aug-08

Apple も、ついに自社のための過剰な秘密主義に陥るようになってしまったのか? この会社は、DNS のセキュリティホールを会社として通知を受けてから何ヶ月も開いたままにしたあげく、ようやくこれに対処した。けれどもこの問題に対し沈黙を保ってきたことで会社の評判に傷が付いたことは間違いない。その上、修正が施された後も、Mac ユーザーには攻撃に対する脆弱性が依然として残っている可能性がある、と Glenn Fleishman が説明する。秘密主義の実例は他にもある。なかなか直らなかった MobileMe 電子メールの問題は解決したということになっているらしいが、一方 iTunes 7.7.1 のリリースに際しては本当に最低限のリリースノートしか出なかった。(Adam が、修正点のいくつかを探り出すことに何とか成功する。)今週のその他のニュースとしては、Matt Neuburg が Panorama Enterprise を使って普通のやり方ではない、けれども非常に便利な方法でインターネット上でのデータベースの共有を実現する。また Adam は VMware Fusion 2 Beta 2 と The Missing Sync for Symbian のリリースを報告し、歩くための道案内を Google Maps に表示させる機能を紹介する。TidBITS 監視リストでは、Adobe Photoshop Lightroom 2、Aperture 2.1.1、それに Lexmark Printer Driver 1.1 が出たことをお知らせする。

記事:

----------------- 本号の TidBITS のスポンサーは: ------------------

---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----


iTunes 7.7.1 5つの不具合の修正の詳細について

  文: Adam C. Engst <ace@tidbits.com>
  訳: 湯本 敬<ymo@big.or.jp>

Apple が iTunes 7.7.1 をリリースした。そのひどくそっけないリリースノートの中には、「安定性とパフォーマンスを改善する修復」をしたとある。その結果、何が変化したかを理解するのはほとんど不可能だが、Apple のディスカッション・フォーラムの中を探すことで、追加の情報を得ることができた。以下のうち2つの不具合の修正は、Apple 社の匿名従業員によって書かれているので、ある程度信用できる内容だろう。その他については、我々の出来るベストは、ユーザーが報告した体験談を提供することでしかない。

iTunes 7.7.1 は Software Update または iTunes ダウンロードページからダウンロードする。ファイルサイズは 48MB だ。 


Apple、MobileMe メールの復旧が完了と発表

  文: Glenn Fleishman <glenn@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Apple の謎めいた David G. なる人物は、どうやら MobileMe 製品チームの一員らしい。(ひょっとしたらサキソフォン奏者 Kenny G の親戚かもしれないが。)彼が先週ポストした記事によれば、2008 年 7 月 18 日以来アーカイブされたメールにもアクセスできず立ち往生させられていた MobileMe ユーザーの 1 パーセントの人たちは、2008 年 7 月 25 日以後は新規のメールの送受信ができるようになっていたのだが、現在ではすべて元通り使えるようになっているはずだとのことだ。

この G 氏によれば、 現時点で何か電子メールの問題が残っているとしても、これとは別問題のはずだという。Apple はメールに問題が残っている人たちのために専用のチャット回線を開設しているが、これはこの問題に関してのみ、使えるものだという。彼らの通常のチャット回線は、私が先週使ってみたところ、待ち時間 30 分という状態だった。

私はここ数週間、MobileMe のスタートをめぐる失態について、何度となく Apple を批判してきた。私ならこれをどう処理したであろうか? 私はこれまでずっと少ない人数の顧客やクライアントではあるがいくつかの状況で機能停止が起こったのを経験したことがあるし、そのような機能停止を経験した会社とともに(顧客として、あるいはクライアントとして)働いたことがある。

  1. MobileMe のスタートは遅らせるべきだった。Steve Jobs はチームに対して 2008 年 7 月 11 日のスタートに間に合うように準備を済ませる必要があるとはっきりと述べた。けれども準備は間に合わなかった。彼らはきっとそのことが分かっていたのだろう。それなのに「我々は MobileMe を延期すべきだ」と口に出して言った者は誰もいなかった。
  2. MobileMe のスタートは段階分けされるべきだった。まず、iPhone 3G オーナーが新しいアカウントにサインアップする際には、すぐアクセスできるべきだ。次には、iPhone 3G や初代の iPhone オーナーで既存の .Mac を持っている人や、新しいアカウントを希望した人がアクセスを与えられるべきだ。その後で、同期方法の変更に興味を惹かれないユーザーたちが、何週間もかけてゆっくりと移行すればよかった。
  3. その 1 パーセントのユーザーたちが巻き込まれた機能停止が発見された時、Apple は問題が数時間程度では解決できそうにないということを察知するべきだったし、電子メールが人々のビジネスや個人的生活に決定的に重要な性質を持っていることをきちんと認識するべきだった。
  4. Apple は即座に、影響を受けたユーザーたちのためのページを掲載するべきだった。(合わせていろいろな Mac ニュースソースを通じても情報を伝えるべきだった。)そのページで、ユーザーたちが転送先のアドレスを入力すれば機能停止の最中はそちらで電子メールが受け取れるようにするのだ。さらには、機能停止の最中に電子メールの処理ができるようにクリーンで新しいアカウントを MobileMe に用意するか、あるいは必要ならば競合相手の会社のサービスさえも利用して提供すべきだった。
  5. いったん機能停止が解消された後は、Apple は顧客たちと協力して彼らが電子メールメッセージを保存することとなった二つの別々のアーカイブを一つに統合したり、人々が古いメールアーカイブを読み込めるようにしたり、その他必要に応じた作業をすることができた。決して見栄えの良い作業ではなかっただろうが、それでも新しい電子メールや送信したい電子メールにアクセスできないまま一週間を過ごすよりは良いことだったであろう。

基本的に、Apple は丸一週間待ってから、やおら新品の、以前と全く同じ名前のアカウントを電子メール無しで過ごした人たちに提供して、その空白の一週間分の電子メールメッセージを後からそこに復旧しただけだった。先週一週間をかけて、彼らはアーカイブされていたメッセージを新しいアカウントに統合させたわけだ。もしも彼らがもっと早い時点でその決断を下してさえいれば、彼らが非常に反応の良い会社だという印象を多くの人たちが持っただろうし、何千人もの人たちがフラストレーションに満ちた数日間を過ごさずに済んだことだろう。

けれども実際に Apple がとった行動は、問題を公に認めるのをあんなに長い間拒んだことで、数え切れない人数の顧客たちを苛立たせて (これでも控え目に言っているつもりだが)、その結果、何と傲慢で無能な会社かという印象を与えてしまった。


Apple、ようやく DNS 欠陥と ARDAgent 脆弱性を修正

  文: Glenn Fleishman <glenn@tidbits.com>, Adam C. Engst <ace@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

インターネットが機能する上で中核となるドメイン名システム (DNS) プロトコルにおける深刻な欠陥にパッチをあてるために業界の他の者たちが皆揃って動いてから二十四日も後になって、Apple はやっとのことで Security Update 2008-005 をリリースした。このアップデートの中には Mac OS X 10.4 Tiger および 10.5 Leopard の、通常版およびサーバ版に対する修正が含まれている。24 日というのがそれほど長い期間でないと思われる方には、Apple が非公式に 2008 年 5 月 5 日(ほぼ三ヶ月前)にこの問題について知らされていたことを指摘しておこう。それに、これは公開の場で広く議論された脆弱性であって、Apple の企業関係ならびにホスティング関係の顧客に対して破滅的な影響を持つ可能性があったのだから。この点に関しては、Mac システム管理者の John Welch が Macworld の意見記事で存分に説明している。

このアップデートではまた 2008 年 6 月 18 日に初めて報告された ARDAgent の欠陥も修正されている。この欠陥のため、コンピュータに通常ユーザとしてアクセスできる者、あるいはトロイの木馬を含むソフトウェアを誰かにダウンロードさせて走らせるよう誘導することができた者が、そのシステムの root 権限を獲得できてしまう可能性があった。

(この DNS 欠陥と、Apple の反応の遅さについては、2008-07-24 の記事“Apple、DNS が攻撃される危機的な欠陥をパッチせず”に詳しい解説がある。ARDAgent 脆弱性がどのように攻撃を受ける可能性があったかの詳細については 2008-06-25 の記事“新しい Mac OS X のトロイの木馬から身を守る方法”参照。)

Security Update 2008-005 はソフトウェア・アップデート経由(これが最も手軽な方法だ)か、あるいは独立ダウンロードで Mac OS X 10.5 Leopard のすべてのバージョン用 (65 MB)、デスクトップ版の Mac OS X 10.4.11 Tiger の PowerPC 用 (88 MB) Intel 用 (143 MB)、それから Mac OS X 10.4.11 Tiger Server の PowerPC 用 (135 MB)Intel 用 (180 MB) が入手できる。Leopard 用のアップデートにはこれが Leopard Server で使えるとは明記されていないが、私たちは 10.5.4 Leopard Server の走る TidBITS の Xserve で Software Update をチェックして、これが Leopard の 10.5.4 デスクトップリリースの走る MacBook 上でと全く同じサイズと名前のアップデートをインストールしたことを確認している。

DNS 欠陥の修正 -- Tiger あるいは Leopard のどのバージョンの下でも、DNS サーバを運営している人はすべて、直ちにあなたの現在のシステムのバックアップをとって、万一アップデートに失敗した場合に備えて戻って来れる確かな場所が出来ていることを確認してから、このセキュリティアップデートをインストールすべきだ。それ以外のすべての Tiger と Leopard のユーザーたちについても(影響ある可能性はより少ないものの)やはり同じことが言える。

私たちはこのアップデートを稼動状況において、つまりインターネットのいたるところにあるサーバからの DNS クエリーに答えている状況下でテストした訳ではないが、このアップデートは私たちがアップデートしたすべてのシステムで、Leopard Server も、通常の Leopard インストールも含めて、問題なく働いているようだ。Apple のセキュリティアップデートはこれまで、期待通りに動いて新たな厄介事を持ち込んだりしないという全般的な実績がある。

Tiger ユーザーには、Internet Security Consortium BIND (Apple の依存している DNS ソフトウェア) がバージョン 9.3.5-P1 にアップデートされる。一方 Leopard システムではバージョン 9.4.2-P1 になる。BIND ソフトウェアの最新版は 9.5.0-P1 だが、Apple はこのアップデートを Leopard に組み込んではいない。

Mac OS X 10.3 Panther またはそれ以前のリリースで動いているシステムのオーナーたちは、そのシステムが再帰的な DNS サーバとして同じコンピュータまたは他のコンピュータからのクエリーによる検索を処理しているにしろ、あるいは単にクライアントとして挙動しているにしろ、いずれも依然として脆弱性を抱えている。今回の欠陥はサーバに対する攻撃に使われるものと考えられるが、クライアントも脆弱性を持っていることに変わりはない。少なくとも、サーバにおいては再帰性をオフにして、リクエストはパッチ済みの DNS サーバに転送するようにするだけで、現時点でのリスクの度合いを劇的に減らすことができる。Panther あるいはそれ以前のシステムの通常ユーザーにとって実際の懸念の度合いがどの程度のものなのかは、私たちも今後もっと理解を深めてからその結果をお伝えして行きたいと思う。そのような人たちの数は多くないかもしれない(Omni Group によるオペレーティングシステム統計によれば、彼らのユーザーのうち 57% が Tiger を、42% が Leopard を使い、ほとんどないくらいに少ない 0.3% がそれ以前のバージョンの Mac OS X を使っているという)が、古いシステムを使っている少数の人たちのグループが新しいタイプのマルウェアのための跳躍板として利用されるようなことは、私たち Mac コミュニティーとしては絶対に見たくないところだ。

ARDAgent やその他の欠陥の修正 -- Security Update 2008-005 はそれ以外にも、Tiger や Leopard における深刻そうに見える欠陥でいずれもまだ実際には攻撃されていないと思われるものを多数修正している。さきほども触れたように、このアップデートでは Apple Remote Desktop (ARD) デーモンソフトウェアがスクリプトを走らせるコンジットとして(たとえ動作していない時であっても)利用されて、そのスクリプトがローカルユーザーに、あるいはローカルユーザーがインストールした悪意あるソフトウェアに、システムへの root アクセス権限を与えてしまうことができるというセキュリティホールを塞いでいる。

ARDAgent(あるいはそれと同種のプログラム)に対する修正には、Open Scripting Architecture における変更を施して、システムレベルのアクセス権を持つプログラムがスクリプティング機能追加をロードするのを防止することが関係してくる。そうすることで、アタッカーがシステムへのコントロールを得るためのくさびとしてそのようなソフトウェアを利用するのを防ぐのだ。

今回のアップデートではまた、Disk Utility が 10.4.11 の下で Repair Permissions を使った時に起こるエラーも修正された。アクセス権の修正後に、ターミナルベースのテキストエディタ emacs に root 権限が与えられてしまっていたからだ。この修正によって Disk Utility 内部では正しいコントロールが復活したが、Apple はあなたがもう一度アクセス権の修正を走らせるべきかどうかについて何も発表していない。私たちの推測では、もしもあなたが 10.4.11 を走らせている同じシステム上に他のローカルユーザーがいるのならば、再度アクセス権の修正を走らせるべきだろうと思う。

もう一つ、注目に値することは、この Security Update 2008-005 が PHP のバージョン 5.2.6 をインストールして、従来 Leopard に含まれていた 5.2.5 リリースにおけるセキュリティ上の欠陥に対処したことだ。PHP はウェブサイトを駆動するために広く使われている。その他にも、あまりよく知られていないけれども懸念の対象となる可能性のあるような問題点がいくつも修正された。

世評には深刻な打撃 -- いつもと同様、私たちは決して Apple がセキュリティアップデートをリリースすることについてあら探しをしたりする意図は持っていない。ことに今回のようにこれほど深刻な脆弱性を修正するものならばなおさらだ。けれどもはっきりと言ってしまえば、今回は Apple の大失敗だった。このアップデートは、業界の他の会社が各社一斉にパッチをリリースした 2008 年 7 月 8 日にリリースしておくべきだった。もちろん、当時 Apple が iPhone 3G、iPhone ソフトウェア 2.0、それに App Store の打ち上げ、それに加えて .Mac から MobileMe への移行(こちらもそれ自体大失敗に見舞われた)といったことに忙しかったことは承知している。でもそんなことは関係ない - Apple には十分の時間があったし、彼らがしなければならなかったのは、新バージョンの BIND をパッケージに組み込んで、通常のストレステストを施すことだけだった。この BIND インストールを見ると、その作成日は 2008 年 7 月 25 日となっている。つまり、Apple はほんの一週間前になるまで、このアップデートの最終版をテストにかける段階に至っていなかったということだ。

信用を得るには時間がかかるが、信用を失うのはあっという間だ。Apple は Mac OS X のセキュリティを重要視してきたし、Mac OS X の最も初期の数バージョンにおいては多少のスタート時のゴタゴタがあったものの、その後は全般によい仕事をして、セキュリティ上の脅威に対してもまあまあタイムリーなやり方で対応してきた。それなのに、今回のようにこれほど重要な脆弱性に対して修正のリリースを遅らせるとは、怠慢の一言以外の何物でもない。そしてこれは、Macintosh のシステム管理者たちを激怒させたばかりでなく、企業向け市場における Apple の評判にも傷を付けてしまったのだ。


DNS クライアントにパッチ後も小さなリスク要素が残る

  文: Glenn Fleishman <glenn@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

SANS Institute は、ドメイン名システム (DNS) プロトコルに内在する欠陥に対する Apple の修正をインストールしてテストし、その結果 Mac OS X 10.5 Leopard(デスクトップ版であって、Leopard Server では _ない_)にパッチをあてたものが 依然としてリスクを伴うテクニックを示しており、DNS がまだ攻撃に対し脆弱であることが判明したと発表した。

現在のところ、この種の攻撃が実際に行なわれる可能性は _極めて僅か_ であると思われるが、実際にどの程度僅かであるのかは、この欠陥の発見者であるセキュリティ研究者 Dan Kaminsky が 2008 年 8 月 6 日に Black Hat カンファレンスにおける講演で全面的開示を提供するまで私たちには分からない。彼の講演タイトルは“Black Ops 2008: Its (sic) the End of the Cache as We Know It”(Its の綴りは発表のまま) だ。

Rich Mogull と私が記事“Apple、DNS が攻撃される危機的な欠陥をパッチせず”(2008-07-24) で述べたように、サーバはこの DNS 脆弱性による大きなリスクを持っている。この欠陥は、アタッカーがサーバに対して何万という偽の DNS クエリーを送りつけることによってサーバ内にある DNS 項目を _汚染_ してしまうというものだが、その攻撃が成立するためには、クエリーの対象となるドメインを扱う DNS サーバからの本物の返答が到着するよりも前に、アタッカーがその偽物の情報を、本物と正確にマッチしたパターンを含むものとして送りつけなければならない。

しかしながら、個人の使うコンピュータであって DNS サーバソフトウェアが動作していないものであっても、やはりこの DNS の欠陥に関して脆弱だ。ただ、私たちがまだそれがどの程度脆弱なのかを知らないだけだ。世界中でサーバのパッチは急速に進みつつあるので、低く垂れ下がった果実はもう消えてしまったということで、アタッカーたちの目はクライアントに向けられることだろう。もしも、クライアントもたやすく攻撃できるものであるならば。クライアントは _スタブ・リゾルバ_ を使う。これが、DNS 回答へのリクエストを会社や ISP、ネットワークプロバイダ、あるいはコロケーション施設などにある本格的な(つまり _再帰的_ な)DNS サーバに転送する。

そのようなクライアントはただリクエストをそのまま手渡すだけなので、攻撃を受けることはありそうにないように思える。ただしアタッカーがローカルネットワークの同じセグメント上にあってシステムが無防備になっている場合は別だが、その場合にはアタッカーはこれ以外にもさまざまな種類のネットワーク情報汚染の武器一式を備えているわけで、もっと効率的な方法で DNS を混乱させることも可能だろう。

この DNS 欠陥は、DNS クエリーにおけるドメイン名検索のための外向きリクエストに対して、ポートが割り当てられる方法が予測可能なことに依存している。アタッカーは、DNS サーバがそのアタッカー自身がコントロールする DNS サーバを使ってドメインを調べるよう強制し、そこから現在リクエストに使用されているポート番号を得る。もしも使われているポート番号が逐次的ならば、つまりそれぞれのクエリーが次のリクエストに使うポートに 1 ずつ増やした番号のものを使い続けるならば、アタッカーはたった今傍受したばかりのポート番号に 1 を足した番号を使って偽のリクエストを送り始めるだろう。

このことも、クライアントの脆弱性に関する疑問点の一部だ。そもそも、初めのてこ入れとして邪悪なドメインを調べるようにクライアントを強制することは非常に難しい。なぜなら、クライアントはもともと DNS クエリーに答えることはしないからだ。アタッカーが電子メールの返送先に邪悪なドメインを記入したものを送りつけても、それで餌食になってしまう電子メールサーバをクライアントが走らせていることは普通あり得ない。

エントロピーを増大させることによって、つまり個々のリクエストごとにランダムなポート番号を選ぶことによって、パッチ後の DNS サーバはアタッカーが十分素早くパケットを生成して正当な DNS サーバとの競争に勝つことができないように予防できる。つまり、ポート番号をランダムにすることで(統計的に言って)DNS キャッシュが汚染されるのを防ぐわけだ。(実際これはあくまでも _パッチ_ であって _修正_ ではない。根本的な弱点を除去するためには DNS 自体のオーバーホールが必要だ。)

私は自分のアッップデート済みの Leopard デスクトップシステムをチェックしてみた。すると、案の定、SANS が報告した通りの結果が出た。これが何をもたらすかはさておき、とにかく外向きのリクエストへの返答として逐次的な UDP ポート番号が返されていた。

あなたもこの SANS 実験をしてみたいと思われるなら、次の手順でできる:

  1. Applications > Utilities > Terminal(ターミナル)を起動する。
  2. 次のコマンドをタイプし、求められればあなたの管理者パスワードを入力する。
    sudo tcpdump | grep domain
  3. もう一つ別のターミナルウィンドウを開き、その中に次のようにタイプして、Return キーを押し、それから上矢印キーに続いて Return キーをあと数回押して同じコマンドを繰り返し入力する:
    dig tidbits.com
  4. tcpdump が走っている方のウィンドウに、以下のような感じの行が見えるはずだ。
    15:06:53.900835 IP 192.168.1.16.49229 > yourDNSserver.com.domain: 5228+ PTR? 16.1.168.192.in-addr.arpa. (43)
    15:06:53.947838 IP 192.168.1.16.49230 > yourDNSserver.com.domain: 48400+ PTR? 11.1.168.192.in-addr.arpa. (43)
    15:06:55.003628 IP 192.168.1.16.49231 > yourDNSserver.com.domain: 15730+ PTR? 7.34.232.205.in-addr.arpa. (43)
  5. 最後に Control-C (Command-C ではない) を押して tcpdump の出力を止める。
    (もしもステップ 4 のような結果が出力されなければ、もとの tcpdump コマンドでネットワークアダプタを指定してやる必要がある。以下のコマンドのようにして、en1, en2, en3 などを試してみればよい。)
    sudo tcpdump -i en1 | grep domain

上記の出力例で、"192.168.1.16" の後に 49229, 49230, 49231 などの数が見える。これらこそ、それぞれのリクエストで使用されたポート番号だ。そして、これらが逐次的になっている(次々に 1 ずつ増えている)という事実こそ、Leopard が DNS クライアントとしてまだ脆弱であることを示している。

けれども私たちは最初の時点に戻ってしまったわけではない。なぜなら、クライアントを攻撃するのはサーバを攻撃するのとは比較にならないほど困難だからだ。それでも、これがセキュリティホールであって、塞がなければならないものであることは間違いない。ただ、それがどの程度に深い穴であるのかは、来週になるまで私たちには分からない。


Google Maps 歩行道案内を追加

  文: Adam C. Engst <ace@tidbits.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

地図の戦いへの参入は比較的遅かったとは言え、Google Maps は、地図を見たり、運転経路案内等を得るトップサイトの一つになっている。そして今度、Google のおたく達は Google Maps に歩行道案内を加えた、これは、車を一方通行では正しい方向へ導くロジックを外し、そして可能な時には歩行者専用の通路を考慮する様にしたものである。

我々はたまたま英国を旅していたので、Old Mill Hotel (おおよそ 1500年に建てられ、我々も Salisbury で一夜を過ごしていた) から Salisbury Cathedral への歩行道案内を頼んでみた。その時、Google Maps は 1.4 マイルの歩行経路を提示してきたがちょっと遠回りの様に見えた、そして実際の所、ホテルの親切な人達は Town Path を行く様に教えてくれたのだが、これは市の反対側へと通じる湿地帯を横切る心地よい小道なのである。残念ながら、Google の新しい歩行道案内ですらこの Town Path のことは何も知らずに、通常の街の中の道路を使うずっと遠回りな経路を薦めてきた。下記のスクリーンショットで Google の薦めてきた経路と赤の実際の歩行ルートとを較べてみて欲しい。

Google-Maps-walking-directions

同様に、Portsmouth で泊まったホテルから、HMS Victory, HMS Warrior, そして Mary Rose が見られる Portsmouth Historic Dockyards までの経路を Google Maps に聞いた時も、Google は道路に固執し、海岸沿いに散歩を楽しめる Portsmouth の Millennium Promenade のことは無視したままであった。

Google も、彼らが未だ知らない歩行者専用道路が沢山あることは認識 しており、その様な新しいデータを収集しそして最適の経路に関して自ら歩いた人達のフィードバックを集める方法について検討している。勿論、'最適' の経路は必ずしも最も効率的ではないことを Google が認識していることを願うものである;Portsmouth で Millennium Promenade を歩くことは我々の目的地への最速の道ではないかもしれないが、その海辺の景色は 5 から 10 分余計にかけるだけの価値は十分にあるし、それに車の排気ガス、交差点を避け、そして道路を横切る時どっちの方向から車が来るのかに対して [訳注:英国では車は米国とは反対側の車線を走る] 我々の 9 才の子供が十分注意を払っているのか心配しなくてもいいのは何物にも代えがたい。


VMware Fusion 2 Beta 2 重要な機能を追加

  文: Adam C. Engst <ace@tidbits.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

進行中の Parallels との仮想化競争で先手を取るべく、VMware は tVMware Fusion 2 の二つ目の公開ベータをリリースした。このベータは無料のダウンロードが入手可能で、Mac-Windows 統合技術の Unity に対する機能、問題が発生した時の保護のための仮想化マシンスナップショット、ビデオの能力と性能の向上、等々が付け加えられている。VMware の Team Fusion ブログで、更なる詳細やデモビデオを見ることができる。

VMware Fusion 2 Beta 2 で最も目に付く変更は Unity 2.0 にあり、これによるとアプリケーションを今や Mac と Windows 間で共有することが可能で、どの Mac ファイルでも Windows アプリケーションから開くことが出来る様になる。Unity 2.0 は又単なるフォルダ共有を超えて、二つの環境の間で主要なフォルダをミラーリングする、例えば Windows は Mac OS X の Desktop, Documents, Music, そして Pictures フォルダをそれぞれに Desktop, My Documents, My Music, そして My Pictures として使用する。その他の Unity 2.0 改善点には、二つの環境間でのキーボードとマウスのカスタムマッピング、共有フォルダの信頼性の改善、そしてコピー&ペーストの改善もあり 4 MB までのデータを扱え、様式付きテキストも扱えるようになった。使い勝手に関する改善では、Leopard の Quick Look のサポート、動作を表す輝くアイコン、Quicken と Google Earth とのキーボード整合性の改善、そして Boot Camp の 64-bit Windows Vista の サポートとの統合改善がある。

多くの Windows 仮想マシンがテストを行なうために使われるので、VMware は複数のスナップショットを取り、保存し、そして管理する機能を加えた、お陰で損傷が与えられる以前の状態に戻すのが楽になった。更に、Fusion 2 は AutoProtect スナップショットを使って指定の時間間隔で自動的に仮想化マシンのバックアップを行なえる。

ビデオサポートも改善され、Windows XP と Vista で 1080p 高精細度ビデオをサポートし、3D サポートも良くなり、そしてゲームをしている最中に全画面ビューへ行ったり戻ったりの切替が可能となった。

Apple が Mac OS X Server のライセンス制約を緩めたので ("Apple、Leopard の仮想化を認める" 2007-10-31 参照)、今や Mac OS X Server 10.5 を含んだ仮想マシンを造ることも出来る。このベータは又 Ubuntu 8.04 Hardy Heron に対するサポートも含むので、Linux 内での Unity ビューも提供し、そして Linux Easy Install もサポートするので多くの人気のある Linux プログラムのための VMware Tools もインストールできる。仮想ディスクのリサイズも今や可能である。最後に、この公開ベータでは実験的に一つの仮想マシンの中で 4 個までの仮想 CPU をサポートし、VMware Fusion をスクリプトするためのコマンドラインインターフェースも提供している。

蛇足とは思うが、これはベータソフトウェアであるのでミッションクリティカルな仕事には使うべきではない。Fusion 2 が最終的にリリースされた暁には、全ての Fusion 1.x ユーザーに対して無償のダウンロードできるアップグレードとなる予定である。


Missing Sync for Symbian が近接同期を提供

  文: Adam C. Engst <ace@tidbits.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

Mark/Space は、Mac と広い範囲にわたるモバイル機器との間のデータ同期のためのツールを提供することでその名を上げてきた。その最新版が $39.95 の The Missing Sync for Symbian である。Symbian は Nokia により広範囲に使われてきたスマートフォンのオペレーティングシステムであるが Sony Ericsson, Motorola, そして Samsung にはそれ程多く使われていない。Symbian は最近 Nokia に買収された ("Symbian プラットフォームが無料に、一部はオープンソースに" 2008-06-24 参照)。

The Missing Sync for Symbian は、他の The Missing Sync バージョンと同様に、ユーザーがコンタクト、カレンダー、そしてタスクを Apple の Address Book と iCal に同期出来るようにし、更に Microsoft Entourage や Market Circle の Daylite の様な Sync Services を理解するアプリケーションとも働く。また、音楽、写真、そしてビデオもどちらの方向にも同期出来るので、電話から新しい写真やビデオを iPhoto にアップロードしたり、逆に iPhoto から電話に写真をダウンロードしたりも出来る。ドキュメントの同期すらも出来るので、それらに対応可能なハンドヘルドアプリケーションから見たり編集したりも可能である。The Missing Sync for Symbian はまた、検索や課金のためにテキストメッセージや通話ログ (Nokia スマートフォンのみ) も Mac にアーカイブ出来る。

しかしながら、The Missing Sync for Symbian が他のバージョンの The Missing Sync や、そして Apple の iPhone からも際立つのは、 その新しい Proximity Sync 技術のお陰である。あなたの電話をあなたの Mac に USB 経由で接続する代わりに、Proximity Sync は Bluetooth を使って、電話がほぼ 30 フィートの範囲内に近づくと自動的にデータを同期出来るようにする。これは証明書に値するほど頭が良い、そしてもし電話にも 電線無しの誘導充電が適用できれば、我々のモバイル機器から電力と通信のための全ての邪魔くさいケーブルを失くすことが出来る。

では iPhone もこの近接同期機能を持つべきだろうか?純粋に技術の観点から言えば、答はイエスである - 格好いいしそれに他の電話も Bluetooth 経由の同期はかなり前から採用している。Joe Kissell が私に語ったことによれば、彼はこの近接性を Salling Clicker 遠隔操作ソフトウェア用に ProximitySync アクションスイートで引金として使っていると言う。しかし Bluetooth は、iPhone 同期用には他の電話用ほどには意味を成さない。一番の問題は同期するデータの量である、iPhone では同期する度に自分をバックアップするし、それに重たいポッドキャストやビデオファイルを同期することも多い。良くても Bluetooth 2.0+EDR でのスループットは 3 Mbps であり、USB 2.0 の 480 Mbps とは比べものにならない程で、同期に要する時間も分単位ではなく時間単位になってしまう可能性がある。それに現実問題として、iPhone の電池寿命はそれ程長くないので毎日の充電作業が必要で、Apple が選択した充電と同期を一緒にすると言うのは理に適っている。


Panorama Enterprise、データベースのインターネット同期を提供

  文: Matt Neuburg <matt@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

ProVUE Panorama は卓越したデータベースアプリケーションで、TidBITS でも過去 15 年にわたって追跡し続けてきた。私の書いた分析記事(2001-11-19 の“Panorama で光明を見出す”)をお読みの方はご存知だろうが、Panorama はそのデータすべてをメモリにロードするので、検索やその他のデータ処理が高速(RAM アクセスは高速)かつ安全(あなたが保存を指示しない限りディスクには何も書き込まれない)に行なわれる。また、Panorama ではデータへのアクセスのために手の込んだウィンドウを作ることができる。テキストフィールドやボタン、スクローリングリスト、メニューその他を自分で組み合わせることができるのだ。実際、ここには壮大なプログラミング言語が内蔵されているので、Panorama はむしろデータベースソフトウェアの構築キットとも言え、HyperCard や REALbasic を思い起こさせるものとなっている。それでいて同時に、Panorama は使いやすい。なぜなら、あなたのデータを単純に Excel 風のグリッドに並べて見ることはいつでもできるからだ。

他の過去記事で、TidBITS 出版責任者の Adam Engst は Take Control 関係の会計処理のために Panorama が最適のデータベースだと判断した経緯を記している(2005-03-14 の記事“Panorama の眺めを必要とする時”)し、Panorama を臨機応変の目的のために使った興味深い方法についても(2005-04-11 の記事“Panorama の意外な使い方”)説明している。実際、この「臨機応変」というのが、Adam が Panorama を指して言う際のお気に入りの表現だ。あらかじめデータベースの仕組みを立案しておく必要はない。そこにあるグリッドにはいつでもあなたのデータがあるので、あなたはいつでもそのデータを拡張してそのグリッドを使いこなしたり、別のデータベースで別のグリッドを持つものをそこに追加して互いに連携させたりもでき、ウィンドウやプログラミング言語を用いてそのデータにアクセスしたり処理を加えたりする特別の方法を考えることも後で自由にできる。実際ちょうど今朝のこと、私が Twitterrific を始動させると、そこには Adam のメッセージがあって「ふぅ、やっと(Take Control の)印税の計算が終わった! 再販業者や協力編集者の取り分を計算するのにデータベースをあちこち調整しなければならなかった。どんどん複雑になる... でも、この種の作業で Panorama を使いこなすのは大好きだ。だって、必要なことが増えるに従って、それに応じて新しいデータベースを作って少しずつ拡張して行くのがとても簡単なのだから。」一言で言えば、Panorama は私たちとともに成長し、それは一つの意味にとどまらない。私たちはそれに依存し、同時にそれが私たちに新しい使い方を促してくる。

この記事では、最新バージョンの 5.5.1 をもって Panorama が全く新しい世界に、その名も Panorama Enterprise というものに踏み込んだことを報告したい。何年もの開発期間を費し、ユーザーによる多くのベータテストに支えられて、Panorama は今や、ネットワーク上で動作するようになった。私自身はまだ実際にこれを使ってみたことがないが、説明書類をじっくりと調べ、開発者の Jim Rea とも話した結果、私が理解した範囲のことを以下に記したい。あなたが持っているのは、一個の Panorama データベースと、Panorama のコピーが数個だ。Panorama のコピーの一つはネットワーク上にある。それはローカルネットワーク上で Bonjour 経由のアクセスができるものでもよいし、あるいは静的なな IP アドレスで遠隔アクセスできるようなものでもよい。そしてそれが、サーバとして指名される。つまり、その Panorama が、データベースのマスターコピーを管理するのだ。それ以外の Panorama のコピーは他のいくつかのマシン上にあり、それぞれがそのデータベースのコピーを持っている。そして、それらが何か変更された場合にはその旨がマスターコピーに知らされることとなる。

これは、データベースのアーキテクチャとしてはちょっと風変わりなものだ。そして、そこにこそ、その輝きが潜んでいる。たいていのクライアント・サーバ型のデータベースでは、データベースはただ一個、マスターコピーのみだ。それがどこかのコンピュータに遠隔に存在していて、あなたが何かのデータを見たいとき、あるいは検索したいとき、あるいは変更したいときに、その遠隔コンピュータに通信するというのが普通だろう。現実問題として、あなたはローカルのコンピュータをその遠隔コンピュータのための単なる表示専用のターミナルとして使うだけだ。すべての作業が実際に行なわれるのは、その遠隔コンピュータにおいてのみだ。ところが Panorama ではそうはならない。Panorama はむしろ、言ってみればバージョンコントロールソフトウェアの Subversion と似た働きをする。Subversion は私たち TidBITS でも、記事の協同編集作業のために使っている。遠隔マシンにはデータベースのマスターコピーがあって、メモリに丸ごと保持されるので処理は高速だ。その一方で、あなたのローカルのコンピュータ上にもデータベースのローカルコピーがあって、こちらもメモリに保持されて高速だ。データベースを検索するには、あなたは単にローカルのコピーを検索する。これなら望み得る最大限に速い。それと同時に、あなたのローカルコピーは常時最新の情報を持っている。なぜなら、マスターコピーに施された変更について常に情報を得ているからだ。

では、どのようにして変更点がマスターコピーに連絡されるのだろうか? 例えば、もしもユーザー A が彼のローカルコピーのデータベースでデータの一部を編集し始めたとすると、マスターコピーはその事実を聞くやいなやその部分のデータを一時的に「ロック」して、もしもユーザー B がまったく同じ部分のデータを _彼の_ ローカルコピーのデータベースで編集しようとすれば警告を受けるようにする。それからユーザー A が編集を終えれば、変更内容がマスターコピーにコピーされてから、ロックが外される。(ここでもやはり、挙動は Subversion と同じだ。少なくとも、私たちが TidBITS で Subversion を使っている方法と同じだ。)ということはしかし、ユーザー A はネットワークに接続してからでないとデータベースの編集ができないのだろうか? 一般的には、その通りだ。けれども、彼が本当にそうしたいのならば、オフラインのままで彼のローカルコピーを編集することができる。すると、その次に彼がオンラインに戻った際に彼の施した変更がマスターコピーに同期される。(当然ながら、もしも一方でユーザー B がマスターコピーに何かのデータの変更を加えていたならば、衝突が生じている。この場合、Panorama はユーザー A に対してそのことを知らせ、彼が手で問題を調整するように促すことができる。何とまあ、これは Subversion そっくりじゃないか!)

けれども、Panorama データベースは単なるデータ以上のものも含んでいる。データ以外にも「フォーム」(ウィンドウの中でユーザーがデータをグラフィカルなユーザーインターフェイスを用いて一覧したり編集したりできるもの)やコード(例えば、ユーザーが特定のフォームウィンドウで特定のボタンを押した場合に何が起こるか)というものがある。そういうものがすべてあらかじめデザインが終わって固定されている必要がある、というのは決して私たちの望むことではない。それよりも、データベースが自由に進化できて、時間をかけて必要に応じて発展させられる、Adam の好きな臨機応変のものの方が望ましい。そして実際それが実現できるのだ。Panorama プログラマーは、データベースの自分のコピー上で新しい機能を開発したりテストしたりして、その結果すべての準備が整えば、そのコピーに対し自分自身をサーバにミラーするようにと指示する。その時以後、そのサーバに接続したデータベース共有ユーザーたちは、新しい機能をすべて備えたデータベースのコピーを受け取る。当然ながらその段階の作業は単に個々のデータ部分をやり取りするよりも時間がかかるが、おそらくそういうことが起こるのはずっと稀なことだろうし、時折のこの種の自動ダウンロードという程度ならば、データベースのおいしい新機能を受け継ぐことができるためにはほんの少しの犠牲と言ってもよいだろう。

というわけで、Panorama のサーバ対クライアントの設計概念のお陰で、一つのデータベースが複数の Panorama ユーザーたちの間で分配されることになる。そして、Panorama のマスターコピーはインターネット上でウェブサーバ (Mac OS X に含まれている Apache) の背後に位置することで働く。ここまで話が進めば、きっとあなたもお気づきに違いない。「おい、それなら、Panorama は単なるデータベース共有より以上のこと、ウェブページのサーバとなることもできるはずでは?」と。その通り、できるのだ! こうして、Panorama の別コピーを伴ってする代わりに、普通のウェブブラウザだけを伴って仕事をする人が出てくることもあり得るし、その方法でデータベースのマスターコピーを一覧したり編集したりすることも理論的には可能だ。もちろん、データベースがウェブブラウザのリクエストに対して反応するかどうか、する場合はどのように反応するかなどのルールはすべてあなたがデータベースの中でプログラムしなければならないことになる。言い替えれば、(さあ、ここでドラムの響きを盛り上げて...)今や Panorama は単なるソフトウェア構築キットであるだけでなく、ウェブアプリケーション構築キットでもあるのだ。

もしもこれがエキサイティングなことだと思って頂けるなら(きっとそう思って頂けると思うが)その次にすべきなのは ProVUE の新装されたウェブサイトに行って、さらに詳しく学ぶことだ。まずは、このサーバ・クライアント版 ("Enterprise") Panorama のアーキテクチャ開発段階にベータテストに 参加した企業たちの述べた言葉を集めたページを読んでみよう。2007 年の映画“300”で視覚効果を管理するために どのように Panorama を使ったかという話も面白い。Panorama とは何かの感じを掴み、あなた自身がこれをどのように使うかを想像し始めるためのベストの方法は、スクリーンキャストを観ることだ。その後ですべてをダウンロード し、非常に詳しくて見事に書かれている説明書類を熟読してみるとよい。ちなみに、ダウンロードは 45 日間無料の試用版となっているが、クーポンコード TIDBITS8722 を使えば無料期間が 101 日間に延長される。試用は、Panorama と、2 ユーザー版の Panorama Enterprise(ウェブ出版機能付き)で働く。

Panorama は Mac OS X 10.4 Tiger かそれ以降を要する。価格設定はかなり複雑で、これはパワフルなマルチユーザー向けデータベースにありがちなことだが、分かりやすく要約できるかどうかやってみよう。

最低価格の製品は Panorama Direct と呼ばれている。これは Panorama データベースでデータの検索・処理・編集・追加ができるが、それ以外の機能は何もない。これを使って Panorama コードを書いたり、ウィンドウベースのフォームを作ってグラフィカルなユーザーインターフェイスでデータを一覧したりすることはできない。価格は $129.95 だ。オーサリング機能が欲しければフル機能版の Panorama 自体が必要になり、こちらの価格は $299 だ。だから、例えばどこかの小さな会社のようなところでは、フル機能版の Panorama を一つ入手してそれをデータベースプログラマーが使い、その他の人々はすべてそれぞれ Panorama Direct を使う、という風になるだろう。

分配形のデータベース共有のためには、Panorama のサーバコピーが必要となる。これについての価格は、一度にいくつの Panorama が _同時に_ サーバに接続できるかによって決まる。例えば、最大三つの Panorama が同時に接続可能なサーバは $399 だ。その次に六つまでのサーバがあり、それから二十までのサーバがあり、最後には同時に接続できる Panorama の数に制限のないサーバがあって、その価格は $1,999 だ。ここで強調しておくべき重要な事実は、Panorama Direct でもデータベース共有のクライアントになれるということだ。だから、もう一度さきほどの小さな会社を例に挙げると、最大三つまで接続可能のサーバが一つ、開発用にフル機能版の Panorama が一つ、それにたくさんの Panorama Direct という組み合わせでやって行くことになる。そこで起こり得る最悪のケースは、三人の Panorama Direct ユーザーたちが共有データベースを使用中に四人目のユーザーがサーバに接続を試みて、一時的に接続を断わられるという状況だろう。

Panorama サーバにウェブページを供給させたい場合はどうすればよいのか? その場合の価格は $899 で、これには同時に _一人_ のユーザーとのみデータベースの共有ができる機能が含まれている。(共有機能は絶対に必要だ。なぜなら、そうでないとデータとプログラミングがサーバ側で編集できなくなるからだ。)これと上記のデータベース共有を組み合わせた場合にはいろいろの割引が適用され、それに加えて Panorama の多数のコピーを購入する場合にはさまざまの数量割引もある。市場に出回っているデータベース共有ソフトウェアの価格に注意を払ってこなかった方々にはここに書いた価格がひどく高いものに聞こえるかもしれないが、実際に例えば FileMaker4D での同等機能版と比較してみれば、かなり安いものになっていることが分かるだろう。


TidBITS 監視リスト: 注目のソフトウェアアップデート、04-Aug-08

  文: TidBITS Staff <editors@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>


TidBITS Talk/04-Aug-08 のホットな話題

  文: Jeff Carlson <jeffc@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Finder の問題 -- Finder が、フォルダを(新規ウィンドウとして開くのでなく)一つのウィンドウで開くという環境設定を守らなくなってしまった。(メッセージ数 3)

MobileMe ステータスページは更新を約束、しかし口調は平板 -- この me.com は、Apple 以外の会社が運営しているのか? (メッセージ数 2)

AppleTV 対 Tivo? -- コスト削減のため、ある読者が料金の高いケーブルテレビとインターネットサービスを切ろうとしている。(メッセージ数 7)

PDF から画像を抽出 -- PDF ファイルから画像を取り出す方法はいくつかある。(メッセージ数 5)

あなたの DNS をセキュアに、Apple がしてくれないのなら -- 最新の DNS 汚染脆弱性に対し、たとえあなたの Mac が安全にアップデートされたとしても、他のプロバイダで問題にパッチを当てていないところがまだまだ多数ある。(メッセージ数 2)

iTunes 7.7.1 -- 最新の iTunes アップデートでも、依然として iPhone 同期や iPhone アプリケーションの扱いに関して問題が残っているようだ。(メッセージ数 2)

Apple が DNS 欠陥と ARDAgent 攻撃への修正をリリース -- 読者たちが、Security Update 2008-005 に含まれたさまざまのセキュリティ関係の修正について語る。(メッセージ数 3)

iPhone で Google マップの問題 -- iPhone の Maps アプリケーションは、ウェブ上の Google Maps とは違ったマップ情報を示しているように見える。(メッセージ数 4)

アップグレードの方法 -- Leopard へ直接アップグレードを実行すると問題が起こると思っている人たちがいるが、本当にそうなのだろうか? (メッセージ数 5)

Time Machine をネットワーク経由で -- ネットワーク経由で Mac をバックアップしようとすると、二台のマシンに複数のユーザアカウントがある場合に問題が起こる。(メッセージ数 3)


tb_badge_trans-jp2 _ Take Control Take Control 電子ブック日本語版好評発売中

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

©Copyright 2008 TidBITS: 再使用は Creative Commons ライセンスによります。

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2008年 8月 9日 土曜日, S. HOSOKAWA