omaha‎ > ‎

overview

http://omaha.googlecode.com/svn/wiki/OmahaOverview.html
を適当に翻訳中

注意: TOEIC400点とかの人の訳なので、あまり信用しないように…

Objective

The Omaha project provides a shared autoupdate and install system for Windows client products at Google that works on multiple Windows platforms, including Windows Vista. Goals include the following:

  • One autoupdate mechanism which allows teams to roll out updates with no dependencies on other product teams, without having to write their own client or server logic
    • One autoupdate server that handles all autoupdate requests - each product team will not need to roll out and manage their own server
    • One desktop autoupdate client shared by all desktop client software - there will not be separate programs running for each installed application
  • A tiny meta-installer which includes the update client (and knows how to install it if necessary) and a reference to the desired application which the update client can then download and install
  • One-click web install of applications once the update client is installed
  • Support for rich update deploy logic allowing multiple tracks for public release, beta, development and "canary" experiments
  • Support for restricted user environments; for example, users without administrator privileges
  • Providing a shared runtime for other functionality common to all Google client applications:
    • Crash reporting


Non-goals include the following:

  • Support of platforms other than Windows 2000 (SP4+), Windows XP, Windows Vista, and Windows 7; in other words, we will not support OS X, Linux, non-NT versions of Windows, or any NT version of Windows preceding Windows 2000 SP4. (Although it should be possible for other platform teams to develop their own equivalent shared client and to use the same server that's being used for Windows)

目的

Omahaプロジェクトは、GoogleでのWindowsクライアント製品向けの、共有の自動アップデート/自動インストールの仕組みで、
WindowsVistaを含む複数のWindowsプラットフォームで動きます。

目標は以下の通りです

  • 他の製品チームに依存せずに、チーム独自のクライアントやサーバロジックを使用せず、アップデートを公開するための、自動更新の仕組み 
    • 全ての自動アップデートリクエストを扱う1つのアップデートサーバ - 各プロダクトチームは公開作業や独自サーバの管理をする必要がなくなる
    • 全てのクライアントソフトウェアに共有されるデスクトップ自動アップデートプログラム - 各インストール済みアプリケーションごとに別々にプログラムを走らせる必要がなくなる
  • 必要に応じてインストールを行うことができる更新クライアントや、ダウンロードやインストールを行うために予期されたアプリケーションへの参照を含む(訳怪しい)、1つの小さなメタインストーラ。
  • 一旦更新クライアントがインストールされると、ウェブでの1クリックインストールを行える。
  • 正式リリース、ベータ、開発、(Chrome) canaryのような最新機能の実験用など、複数のラインに対応した、リッチなアップデートデプロイの仕組みのサポート
  • 制限されたユーザ環境のサポート例えば、管理者権限なしのユーザなど。
  • 全てのGoogleクライアントアプリケーションの為の他の一般的な機能についての、共有ランタイムの提供。 
    • クラッシュレポート

目標ではないのは次の通りです
  • Windows2000(SP4+), WindowsXP, WindowsVista, Windows7以外のプラットフォームのサポート。
    言い換えると、OSXやLinux, NTバージョン以外のWindowsや、Windows2000SP4より前のWindowsはサポートしません。
    (とはいえ、できることなら、他のプラットフォームのチームのために、彼ら独自の同等の共有クライアントを作り、Windowsで使用しているのと同じサーバを使いたいのですが)

Background  

Google client products have the capability to update themselves to a newer version without end-user intervention. This capability is called "autoupdating."


Although our client products shared the autoupdate feature, they did not all share autoupdate code. Some had implemented their own autoupdate solutions, and others had taken advantage of the common autoupdater code and the common autoupdate server.


It was obviously desirable for products to avoid unnecessary duplication of code and for Google to avoid maintaining multiple servers that perform identical functionality. This reason alone was enough to consider unifying all client products under a single autoupdate solution. In addition, the evolution of Microsoft Windows made this unification almost mandatory. Windows Vista features a strict security model that limits the ability of most applications on a machine to perform system-changing activities, such as modifying the Windows registry, writing to the Program Files directory, or in some cases writing any persistent change to the system at all. Updating a program installation requires all these capabilities; thus, on Vista, most traditional autoupdating will fail.


Another problem caused by lack of shared code is that each autoupdate mechanism had its own subset of desired features. Most did not have a way to do canary experiments. Most did not have a way to have multiple update tracks. Most did not define a consistent versioning mechanism. Some of these features were not optional as user base size increased. By unifying the code we could deploy a rich set of autoupdate capabilities to all client applications.


Also, as the number of Google applications increased, it became more and more desirable to improve the overall install user experience. The browser typically prompted the user with a long series of techy, confusing and scary dialogs all trying to convince the user not to install. Then the user was prompted with a wizard filled with choices that they did not need to or know how to decide amongst. These factors combined to form a bad user experience and large drop-off during the app installation process.


To address the goals of Vista compatibility, reduction of duplicative effort at Google, improvement of deploy and autoupdate capabilities, and application install user experience improvement, we proposed to develop shared client infrastructure that handles all installation and autoupdating tasks for Google Windows client products. This client communicates with a single Google autoupdate server. Taken together, this server and client is named Google Update. The project code name is Omaha. 


背景

Googleクライアント製品は、エンドユーザの介入無しに、自身を新しいバージョンにアップデートできる機能を持っています。この機能は"自動アップデート"と呼ばれています。

我々のクライアント製品は自動アップデート機能を共有していましたが、それらは自動アップデートのコードを全て共有していたわけではありません。いくつかは、独自のアップデート方法を実装していましたし、他のものは共通の自動アップデータのコードや共通の自動アップデータサーバを利用していました。

必要のないコードの分離を避けることは、製品に明らかに望まれていましたし、Googleでは、複数の同等に振舞うサーバをメンテナンスするのは避けることが望まれていました。それだけに1つのアップデート方法の下で全てのクライアントを統一することが検討されました。加えて、Microsoft Windowsの進化は、この統一をほとんど強制的にさせました。WindowsVistaは、レジシトリを変更や、Program Filesディレクトリへの書き込みや、システムに対して権限の変更を行う場合、すべてにおいて、システムの変更を行うために、ほとんどのアプリケーションの機能を制限する厳格なセキュリティーモデルが特徴です。プログラムインストールの更新では、それらすべての機能を要求します。従って、Vistaでは、ほとんどの旧来の方式の自動アップデートは失敗します。

共通コードの欠如によって起こる他の問題としては、それぞれの自動アップデート方式が、予期された機能の独自のサブセットを持ってしまうことです。ほとんどの自動アップデータは、(Chorme)canaryの機能を実行する方法が無かったし、複数の更新トラックを扱うことができなかったし、一貫性のあるバージョン更新メカニズムを定義できていなかった。ユーザのベース数が増加するにつれて、これらの機能はオプションではなくなった。統一されたコードによって、我々は全てのクライアントアプリケーションに自動アップデート機能の高価なセットを展開することができた。


また、Googleアプリケーション数の増加により、インストール全般についてのユーザ体験の改善がより一層望まれてきた。

(従来のインストールプロセスはユーザ体験的に悪いという話。訳し難しいので略)


Vista互換、Googleの重複した試みの削減、デプロイや自動アップデート機能の改善、アプリケーションインストールのユーザ体験の向上

それらの目標に対処するため、我々はGoogleのWindowsクライアント製品のために、全てのインストールや自動アップデートを扱う、共有クライアント基盤の開発を提案した。このクライアントはGoogleの自動アップデートサーバに通信する。まとめると、このサーバとクライアントはGoogle Updateという名付けられた。そのプロジェクトコード名がOmahaである。



High Level Requirements

Feature
Solve pushing server content and binary changes at the same time
Allow our partners to add their own versions of their product to Omaha without our intervention or a server push on our end
Allow our partners to be able to test new versions integrated with Omaha without making the URL live to the rest of the world
Be able to offer different versions of the same product, including beta software at different URLs
Continue to support at least as good one-click install experience as we have now
Offer better non-admin/limited user account support, i.e. downloading and running the product over offering a link
Be able to install product updates without the product running
Optionally be able to automatically run the product after the installation completes
Be able to show no UI vs. a small progress bar - e.g. Earth install vs. Offline Gmail
Provide decent proxy support, i.e. reliable downloads outside the browser
Optionally don't require interactive installers/uninstallers for Omaha so product teams can rely on our translations for them.
Offer a small stub executable
Make the Omaha UI super fast to load
Omaha to support localization in the top X languages 
Be able to save the installer for later use

ハイレベルな要求


特徴
サーバコンテンツの挿入とバイナリ変更を同時に解決
我々のパートナーに、彼らプロダクトの独自のバージョンを、我々の介入やサーバへのプッシュなしに、Omahaへ追加することを許可
我々のパートナーに、URLを作成することなしに、Omahaを導入した新しいバージョンがテストできることを許可
別URLのベータ版ソフトウェアを含む、同じプロダクトの別バージョンの提供を可能とする
我々が今持っているようなワンクリックインストール機能を少なくともサポートしていく
非管理者、制限のあるユーザアカウントをよりよくサポートする。例えば、ダウンロードやオファーリンクを通じてのプロダクトの実行。
プロダクトの実行無しにインストール製品のアップデートを可能とする
オプションとして、インストール完了後のプロダクトの自動実行を可能とする
UI無しや小さなプログレスバーでの表示を可能とする。たとえばGoogleEarthに対してオフラインGmailのような。
行儀のよいプロキシサポートの提供。たとえばブラウザ外での確実なダウンロード。
オプションとして、製品チームは我々の翻訳に頼ることができるので、Omahaのためのインタラクティブなインストーラ/アンインストーラを要求しない
小さな実行可能なスタブの提供
OmahaのUIは読み込みが超速いように作成
Omahaは上位X言語のローカライズをサポートする
後で使うためにインストーラの保存を可能とする


Scenarios

Omaha consists of three principal parts: a client-side run time, a meta-installer (which simply wraps the client run time and either the application installer or a micro reference to the application), and a server. The client and server communicate with each other over HTTP or HTTPS. When a user wishes to install a new Google application, in actuality he or she merely downloads a meta-installer wrapping the selected application, which either installs the client or confirms that the currently-installed Omaha is up to date, and then exits after requesting that Omaha install the desired Google application. If that application is not already installed on the user's system, the Omaha installs it (using the wrapped installer or downloading the most recent version from the server). Omaha then periodically checks for updates to products installed on the system, and when appropriate, installs those updates. Omaha also provides elevated-privilege functionality to lower-privilege Google applications on the system.

New Install

User downloads a meta-installer from a Google website, going through standard browser file download steps. Once the user figures out how to launch the meta-installer, the meta-installer installs and runs the Omaha client. On Windows platforms, such as Windows Vista, with UAC, an elevation prompt is displayed when installing applications per-machine. The client then begins downloading and installing the app referenced by the micro reference.  

Secondary Install

Google website detects that Omaha client is installed, and instead of delivering a downloadable EXE or MSI, it vends an application micro-reference via an ActiveX (or equivalent) object. In this case, the user didn't have to go through any complicated download steps. They just clicked on a web link and the download starts. The rest of this scenario is the same as the initial install scenario.

Uninstall

Omaha uninstalls itself when there is no application registered with it for updates.

The overall sequence diagram is below:

  1. For organic installs, the user downloads an installer called AppNameSetup.exe, which is actually the Omaha meta installer plus a data tag containing the name and ID of the managed app (AppName, in this case)
  2. Execution of AppNameSetup.exe installs Omaha.  Omaha reads the data tag (to get the name of the app it's installing) and immediately contacts the Update Server to get the download location of the current version of AppName. The AppName installer is downloaded and executed on the user PC.  Omaha itself takes no part in the installation process; it merely executes the provided installer
  3. Omaha periodically (every 5 hours, as of this writing) checks for updates for all of its managed applications.  If an update is available, Omaha downloads the indicated binary and executes it


There is also support for offline installers (Omaha and the AppName installer bundled into the initial download) and partner distribution

シナリオ
Omahaは3つの主要な部分からなります。クライアントサイドランタイム、メタインストーラ(これは単にクライアントランタイムと、アプリケーションインストラーかアプリケーションへの小さな参照のどちらかを単にラップしたものです)と、サーバです。クライアントとサーバはHTTP/HTTPSを通じてお互い通信します。ユーザが新しいGoogleアプリケーションをインストールしたいとき、実際選択したアプリケーションをラップしたメタインストーラを僅かにダウンロードするだけです。メタインストーラは、クライアントをインストールするか、現在のインストールされたOmahaが最新であることを確認するかし、それからOmahaは予期されたGoogleアプリケーションをインストールするようにリクエストした後に終了します。もしアプリケーションが既にユーザのシステムにインストールされいなかったら、Omahaはインストールを行います(ラップされたインストーラを使うか、サーバから最新のバージョンをダウンロードすることで)。Omahaはそれから定期的にシステムにインストールされた製品のアップデートをチェックし、適宜、それらのアップデートをインストールします。Omahaはまた、システムの低い権限のGoogleアプリケーションに、高い権限
の昨日を提供します。

新規インストール

ユーザはGoogleウェブサイトから一般的なブラウザのファイルダウンロード方法を通じてメタインストーラをダウンロードします。いったんユーザがメタインストーラの起動法を見つけ出すと、メタインストーラはOmahaクライアントをインストールして走らせます。WindowsVistaのようなUACがあるWindowsのプラットフォームでは、1台のマシンごとにアプリケーションをインストールする際、権限の高いプロンプトが表示されます。クライアントはそれから小さな参照によって参照されたアプリケーションのダウンロードやインストールを開始します。

2回目のインストール

GoogleウェブサイトはOmahaクライアントがインストールされていることに気づき、ダウンロード可能なexe/msiの配信に代わって、ActiveXObjectのようなアプリケーションの小さな参照を提供します。この場合は、ユーザはどんな分かりにくいダウンロードステップも行う必要がありません。彼らはただダウンロード開始のウェブリンクをクリックするだけです。このシナリオの残りは最初のインストールのシナリオと同じです。

アンインストール

Omahaはアップデートのために登録されたアプリケーションがなくなると、自身をアンインストールします。

全体のシーケンスダイアグラムは次の通りです。
図 略
  1. 本格的なインストールでは、ユーザはAppNameSetup.exeと呼ばれるインストーラをダウンロードし、それは実際はOmahaメタインストーラに、管理されたアプリの名前(この場合はAppName)とIDを含むデータタグを足したものです。
  2. AppNameSetup.exeの実行はOmahaをインストールします。Omahaは(インストール中のアプリの名前を取得するため)データタグを読み取り、AppNameの現在のバージョンのダウンロード場所を取得するために、即座にアップデートサーバに通信します。AppNameインストーラはユーザのPCでダウンロードされ実行されたものです。Omaha自身はインストールプロセスの一部ではありません。提供されたインストーラを僅かに実行するだけです。
  3. Omahaは定期的に(この記述では5時間ごとに)、Omahaによって管理されている全てのアプリケーションのアップデートをチェックします。アップデートが有効であれば、Omahaは示されたバイナリをダウンロードし、それを実行します。
また、オフラインインストーラ(OmahaとAppNameインストーラは初回ダウンロードにバンドルされる)やパートナーディストリビューションのサポートもあります。

High Level Design

Client

The Omaha client is a Windows application, installed by a custom Windows installer. It performs several functions:

  • Installs and updates Google applications for the host machine
  • Periodically talks to the update server to determine whether an update is necessary
  • Provides a simple progress UI to notify users that the initial installation of the Omaha client is happening
  • The elevation functionality in the Omaha client allows applications to update themselves even if they are running in low-rights mode
  • Provides infrastructure for applications to report crashes (from the Breakpad project)


The client is able to handle multiple downloads in parallel, multiple sequential installs, and it is able to resume or restart partial downloads.


The client is not a separate application in the sense that it can be uninstalled independently of Google applications. Instead, it is considered a required feature of applications. It will uninstall itself when the last Google app using it is uninstalled by the user.


In addition to specific reporting related to installation and update, Omaha includes a generic crash-reporting facility for Google applications. The Breakpad project's network library is used, and the client will handle local minidump storage and queuing of reports.

 

The Omaha client consists of two major parts:

  1. Runtime, which handles all necessary update and install services
  2. Web browser control (ActiveX for Internet Explorer and NPAPI for other browsers), which allows Google web pages and Google applications to ask the run time to do tasks on their behalf

ハイレベルデザイン

クライアント

OmahaクライアントはWindowsアプリケーションで、カスタムのWindowsインストーラによってインストールされます。それはいくつかの機能を実行します:
  • ホストマシーンにGoogleアプリケーションのインストールとアップデート
  • アップデートが必要かどうか決定するために、定期的にアップデーサーバに通信
  • Omahaの初回インストールが始まったことをユーザに通知するための単純なプログレスUIを提供
  • 低い権限のモードで走るアプリケーションにアップデートを許可するためのOmahaにある高い権限の機能
  • (BreakPadプロジェクトからの)アプリケーションがクラッシュをレポートするための基盤
クライアントは、並列に複数のダウンロード、複数の連続したインストールを扱うことが可能で、そして部分的なダウンロードの復帰と再開が可能です。
クライアントは、Googleアプリケーションの独立したアンインストールが出来るという意味で、分割されたアプリケーションではない。代わりに、アプリケーションの要求された機能と考えられる。最後のGoogleアプリがユーザによってアンインストールされたとき、それ自身アンインストールされる。

インストールやアップデートに関する明確なレポートに加えて、OmahaはGoogleアプリケーションの便利で一般的なクラッシュレポートを含んでいます。BreakPadプロジェクトのネットワークライブラリが使用されていて、クライアントはローカルのミニダンプストレージやレポートのキューを扱えます。

Omahaクライアントは2つの主要な部分からなります:
  1. 実行時に、全ての必要なアップデートやインストールサービスを扱う
  2. ウェブブラウザコントロール(IE向けのActiveXや他のブラウザ向けのNPAPI)により、GoogleウェブページとGoogleアプリケーションは、実行時にそれらの振る舞いによるタスクを行うため、通信することができる。

Client Runtime

The runtime has the following functionality:

  • automatic startup so that it is always available to applocations
  • on-demand privilege elevation for install and autoupdate
  • autoupdate polling
  • downloading installers from Google download server
  • execution of Google installers
  • a persistent work queue for handling parallel restartable downloads and installs
  • progress and status notification hooks for UI 
  • self-uninstall when the last registered app is uninstalled
  • reporting of install success / failure pings
  • opt-in usage stat collection
  • crash reporting infrastructure for other Google applications
  • authentication and verification of installers

クライアントランタイム

ランタイムは次の機能を持っています:
  • いつでもアプリケーションを扱うための自動起動
  • インストールや自動アップデートのための要求に応じた高い権限
  • 自動アップデート ポーリング
  • Googleダウンロードサーバからのインストーラのダウンロード
  • Googleインストーラの実行
  • 並列したリスタート可能なダウンロードやインストールを扱うための永続的なワークキュー
  • UIのためのプログレスや状態通知フック
  • 最後の登録されたアプリがアンインストールされたときの自己アンインストール
  • インストール成功やpingの失敗の通知
  • 使用許諾集(?)
  • 他のGoogleアプリケーションのためのクラッシュレポーティング基盤
  • インストーラの認証と照合
Execution Model

The runtime functionality is divided between a couple of processes, most notable a core process and many worker process. There are a few reasons for the separation: robustness, running code with the least privilege, executing Google installers in the context of the logged in users as much as possible, and avoiding resource leaks and resource consumption in long-lived processes.


The execution model for the runtime code depends on how Omaha is actually installed. There are two main scenarios here:

  1. Omaha is installed for the machine. This requires the user has administrator privileges. In this case, a Windows service runs all the time as SYSTEM and, at the right time, it kicks off worker processes to do the bulk of the work. To update per-machine applications, the worker process runs as SYSTEM as well. The worker process terminates when there is no more work to do.
  2. Omaha is installed installs for the current user. Consequently, there is no service and no machine updates are possible. In this case, the execution model solely relies on a goopdate worker process that runs all the time in each interactive session as the user.

It is important the same binary works the same way on different operating systems: Windows 2000, XP, and Vista. The process execution model is almost identical, in both machine and user cases. For the most part, the machine and user instances of Omaha run in isolated security contexts and they share nothing.

The Omaha core runs in a local system process for the machine, and one process for each logged in user. Typically, there will be two core processes running. There is potential for an optimization here, as the local system process can create a process that runs as the logged in user when it needs to.


The machine Omaha core process is started at boot time by a system service that terminates soon after. There is a reason for not running the Omaha core in a service: a bug in XP prevents us from further updating the service if the service has crashed. More investigation will have to be done here, especially since having a service is quite nice and eliminates the need for another process. The user Omaha core process is started by the shell from the user's run key. To eliminate a single point of failure, there are fallbacks implemented using the Windows system scheduler to attempt to start the core process if for some reason it is not running. It should be desirable to measure the overall availability of the core process.  We strive to be as available as the Windows OS is in terms of uptime of the Omaha core.


The Omaha core is highly reliable and lightweight:

  • It does very few things well: scheduling of workers for silent updates, elevation, and support for breakpad crashes
  • Removes the core dependencies on several Windows modules: no msxml, no shell, no network, no UI, no crypto, no wintrust, etc
  • Reduces the working set and the resource consumption
  • By the virtue of less code and closer to the OS layer, the Omaha core can be made reliable, reliable, reliable
  • Everything else runs out of process


The Omaha worker processes do most of the actual work:

  • A unified IPC mechanism is desirable
  • The communication and synchronization between worker processes is kept to the minimum, according to the isolation and share-nothing concepts of the design
  • The workers use the new network stack and the new CUP - client update protocol, which uses HMACs over plain HTTP instead of HTTPS
  • To facilitate firewall traversals, a constant shell is used

実行モデル

ランタイム機能は、ほとんど主要なコアプロセスと多くのワーカープロセスからなる、複数のプロセス間で分かれている。分割にはいくつかの理由がある:頑丈性、最小の権限でのコードの実行、リソースリークや長期生存プロセスのリソース消費を避け、出来るだけ多くのログインユーザ下で、Googleインストーラを実行すること。

Omahaが実際どのようにインストールされるかによった実行時コードのための実行モデル。それは次の2つの主要なシナリオがある:
  • Omahaはマシーンにインストールされる。これはユーザに管理者権限を要求する。この場合、Windowsサービスは常にシステム権限で走っており、適当なときに、仕事の大部分を行うためのワーカープロセスをキックする。マシンごとのアプリケーションをアップデートするため、ワーカープロセスはシステムと同等の権限で走る。ワーカープロセスは他にやることがなくなったら終了する。
  • Omahaはカレントユーザ向けのインストールによってインストールされる。その結果、利用可能なマシンのアップデートやサービスのアップデートは無い。この場合、実行モデルは単に、そのユーザ権限で、それぞれのインタラクティブセッションで常駐する、Goopdateワーカープロセスに依存している。
    (注: omahaにはGoopdateというプロジェクトがある)
いくつかのバイナリはWindows2000/XP/Vistaといった違うOSで同様に動くことが重要である。そのプロセスの実行モデルは、マシンとユーザ両方のケースで、ほとんど等しい。ほとんどの部分で、Omahaのマシンとユーザインスタンスは、切り離されたセキュリティコンテキストで走り、共有されることはない。

Omahaコアはマシンのローカルシステムプロセスで走り、プロセスはログインユーザごとにある。典型的には、2つのコアプロセスが走るだろう。ローカルシステムプロセスは必要に応じて、ログインユーザ権限として走るプロセスを作ることが出来るので、ここを最適化できる見込みがある。

マシンのOmahaコアプロセスは、起動時にシステムサービスによって開始され、すぐに終了します。Omahaコアがサービスで走らない理由がります;XPのバグで、サービスがクラッシュしたら、次のサービスのアップデートから我々を妨げるというバグです。ここで多くの調査が行わないといけないでしょう、特にサービスを保持することは凄く良く、他のプロセスが不要になります。ユーザのOmahaコアプロセスは、ユーザが実行のキーを押すことでシェルによって実行されます。SPOFをなくすためには、コアプロセスが何かの理由で走らなくなったらWindowsシステムスケジューラを使用し、コアプロセスをスタートさせる試みの実装されました。コアプロセスの全体のアベイラビリティを測ることが望ましいです。我々はOmahaコアの動作可能時間に関して、出来るだけWindowsOSと同様に利用可能であるように骨を折ります。

Omahaコアは高い信頼性があり軽量です:
  • ほんの少しのことを上手く行います:サイレントアップデートのためのワーカーのスケジューリング、権限付与、breakpadクラッシュのサポート
  • いくつかのモジュールへのコア依存の除去:msxml/shell/network/UI/crypto/wintrustなど
  • リソース消費やワーキングセットの削減
  • OSレイヤーへの近さと、少ないコードの長所により、Omahaコアは信頼でき、信頼でき、信頼できる
  • 他の全てのことはプロセス外で実行する
Omahaワーカーは実際の仕事のほとんどを進める:
  • 統一されたIPCメカニズムには魅力がある
  • ワーカープロセス間の通信と同期は、分離と共有なしのデザイン方針により、最小限に保たれる
  • ワーカーは新しいネットワークスタックと、新しいCUP(クライアントアップデートプロトコル)を使う。それはHMACをHTTPSの代わりに簡素なHTTP越しに使用する。
  • ファイアウォールの走査を促進するため、固定のシェルが使用される(いまいち意味分からず...)
Application Registration

In order for an application to receive updates, the application must register with Omaha. The application registration mechanism is based on Windows registry. There are primarily two update policies supported by Omaha, which directly affect how an Omaha aware application registers with the Omaha runtime:

  1. per-machine updates
  2. per-user updates


In the case of per-machine updates, each application installed per-machine creates a key HKLM/Software/Google/Update/Clients/{GUID}. Under this key, the application creates the following values:

  • pv (current product version - e.g. 1.0.20.0)
  • name (ignored but useful for debugging)


In the case of per-user updates, the only difference is the location to where the key is created. In this case, the key is HKCU/Software/Google/Update/Clients/{GUID}.


When the update loop kicks in, Omaha runs the per-machine updates as SYSTEM and per-user updates as the logged in user. This assumes that the user has an active session, in other words, updates for per-user installed applications will not run if the user has not logged in. As long as there is anything under these keys, Omaha keeps pinging for updates and updating these applications. It is possible that the application is dead and its registration with Omaha still active, for example, in the case where the user just deleted the application files. Unfortunately, Omaha does not detect such conditions and it is going to download and apply updates for it until the application cleanly unregisters.


Exposing registry keys and low level implementation details to applications has disadvantages. It breaks the encapsulation of Omaha. An argument can be made that such implementation details would be better to be abstracted out in a code library that the application code links with. However, there is a great advantage for the current registration mechanism. Registry keys can be created easily directly from the installer script for applications that are using off the shelf installer technology thus making the integration with Omaha easier.


    アプリケーションの登録

    アプリケーションがアップデートを受け取るために、アプリケーションはOmahaに登録しなければならない。アプリケーション登録の仕組みはWindowsレジストリをベースにしている。Omahaによってサポートされる2つのアップデートポリシーが最初にあり、それはどのようにOmahaランタイムで良く知られたアプリケーション登録を行うかに直接作用する;
    1. マシンごとのアップデート
    2. ユーザごとのアップデート
    マシンごとのアップデートの場合、マシンごとにインストールされた各アプリケーションはレジストリキー HKLM/Software/Google/Update/Clients/{GUID} を生成する。このキーの元では、アプリケーションは次の値を生成する:
    • py (現在の製品バージョン - たとえば 1.0.20.0)
    • name (無視されるが、デバッグに便利)
    ユーザごとのアップデートの場合、唯一の違いはレジストリキーが生成される場所である。この場合、キーは HKCU/Software/Google/Update/Clients/{GUID} となる。

    アップデートループがキックしたとき、Omahaはシステム権限でマシンごとのアップデートを、ログインユーザ権限でユーザごとのアップデートを実行する。これはユーザはアクティブセッションを持っているとみなし、言い換えると、ユーザごとのアップデートでインストールされたアプリケーションはそのユーザがログインしない限り実行されない。これらのキーが何かある限り、Omahaはこれらのアプリケーションのアップデートと、アップデートのためのpingを保つ。アプリケーション死に、そのアプリのOmahaへの登録がまだ生きていることも可能性もある。たとえば、ユーザーが単にアプリケーションファイルを削除した場合など。不幸にもOmahaはこのような状況を検地できず、アプリケーションが綺麗に登録解除されるまで、ダウンロードやアップデートの適用を行う。

    レジストリキーや、低レベルアプリケーション実装の詳細の公開は、不利な点である。それはOmahaのカプセル化を壊す。議論により、このような実装の詳細をアプリケーションコードが互いにリンクしているコードライブラリから抽象的に出すほうが良いということになった。しかしながら、現在の登録の仕組みは素晴らしく有利な点がある。レジストリキーは、アプリケーション用のインストーラスクリプトから直接簡単に作れるので、install shelfテクノロジーのようなものを使用しなくとも、Omahaへのインテグレートが簡単である。

    Automatic Startup

    The service is set to auto run when Omaha is installed per-machine. The SCM failover mechanism is used to restart the service in case of a crash. When Omaha is installed per-user, the goopdate worker process is started by the Windows shell from HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.

    Scheduler

    The client runtime runs periodic tasks, such as the update check request to the server to discover updates. These tasks are kicked off by a scheduler. The scheduler code runs inside the Omaha core process. The main requirement for the scheduler is to execute a worker process once in a while.


    A lot of consideration was given to using the built in Windows scheduler instead of building our own. The windows task scheduler on Vista seems to be greatly improved. On XP and Windows 2003 there are some limitations to the windows task scheduler:

    1. Credentials are an issue with the pre-Vista scheduler. The issue is that the scheduler used to cache the credentials for the user that registered a scheduled event and if the user password changed, then the task was broken. It has been fixed in Vista.
    2. On Windows 2003 the use of the task scheduler service is restricted to Administrators only.
    3. If the machine is in a sleep state there are some hardware on which the task will not be scheduled. There are situations in which the scheduled tasks fail because of suspected ACPI interactions. One extreme case was a machine not able to schedule tasks when the LAN cable was disconnected.

    自動スタートアップ

    Omahaがマシンごとにインストールされたとき、サービスは自動起動するようにセットされる。SCMフェイルオーバーメカニズムは、クラッシュした場合のサービスの再起動に使用される。ユーザごとにOmahaがインストールされたとき、Goopdateワークプロセスは HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run からWindowsシェルによって開始される。

    スケジューラ

    クライアントランタイムは、アップデートを見つけ出すため、サーバにアップデートチェックの要求を行うような、定期的なタスクを実行する。これらのタスクはスケジューラによってキックされる。スケジューラコードはOmahaコアプロセス内で走る。スケジューラへの主な要求は、すぐにワーカプロセスを実行することである。

    我々の独自にビルドに代わって、はじめからビルトインされているWindowsスケジューラの使用については、かなり熟考された。VistaのWindowsタスクスケジューラは大変進化したように見える。XPやWindows2003はWindowsタスクスケジューラにいくつかの制限がある:
    1. Vista以前のスケジューラは権限に問題がある。問題はスケジューラが、スケジュールイベントを登録しパスワードを変更したとしても、ユーザの権限のキャッシュを使用することで、タスクが壊される。これはVistaで修正された。
    2. Windows2003ではタスクスケジューラサービスは管理者のみに制限される。
    3. もしマシンがスリープ状態になったら、タスクがスケジュールされなくなるハードウェアがいくつかある。スケジュールされたタスクがACPIイテレーションのような原因で落ちる状況がある。究極の場合では、LANケーブルが刺さってないときマシンはタスクをスケジュールできなかった。
    Resource and Timing Constrains

    The runtime follows a few constraints regarding resource usage and timing.

    Limiting resource use:

    • check to make sure we do not use all of the user's disk space
    • use little memory and delay load the modules that are not needed. This is very important for the resident core
    • try not to autoupdate unless the user has an internet connection (important for dial-up users so that we do not auto-dial their connection)
    • limit the bandwidth usage during background downloads
    • attempt to update application when the user's machine is idle


    Timing:

    • Check for updates at least once a day  
    • Serialize downloads and installs

    Web Browser Control  

    The web browser control exposes a high level interface to Google web pages and client applications, enabling features such as one-click web installs and rich update clients such as Pack. It needs to limit access so that only authorized Google web pages and applications have access to the services offered by the client run time. The interface is defined by very coarse-granularity functions. Rather than "download file X from server Y" it would instead offer "download application id X from Google". In the event that the client had a security hole, it's important that the interface limit the amount of damage that can be done.

    Crash Reporting

    There are two major parts to crash reporting on Windows: generating the minidump and reporting it to the server.  With Omaha, each application would still be responsible for catching exceptions and signaling Omaha to generate and transmit the minidump to Google servers. The minidump is created in a secure directory which Omaha can write to.  It has code to try to minimize possible accidental self-DDOS as a result of frequent crashes while still reporting important data, perhaps determining when a duplicate minidump was generated, or reporting the number of crashes that have been generated but not reported.


    リソースやタイミングの制限

    ランタイムは、リソースの使用やタイミングに関していくつかの制限に従う。
    リソースの使用の制限:
    • ユーザのディスクスペースの全てを使用してしまわないかチェックしてください。
    • 少ないメモリの使用や、必要の無いモジュールの遅延ロード。これらは常駐するコアにとってとても重要です。
    • ユーザがインターネット接続をしていない限り、自動アップデートを試みないでください。(ダイアルアップユーザにとっては彼らのコネクションを自動ダイアルにしないため重要)
    • バックグラウンドダウンロードを使用している間、バンド幅を制限してください
    • ユーザのマシンがアイドルのときアプリケーションのアップデートを試みてください
    タイミング:
    • 1日最低1回はアップデートをチェックしてください
    • ダウンロードとインストールのシリアライズ(連続でやれってことか?)

    Webブラウザコントロール

    Webブラウザコントロールは、ワンクリックウェブインストールや、Packのようなクライアントのリッチなアップデートなどを可能にすることで、Googleウェブページとクライアントアプリケーションへのハイレベルなインタフェースを体験させる。実行時にクライアントによって提供されるサービスにアクセスするアプリケーションや、Googleウェブページの認証の場合だけアクセスを制限する必要がある。インタフェースはとてもガサツな粒度の機能によって定義されている。"xというファイルをyというサーバからダウンロードする"というものではなく"xというアプリケーションIDをGoogleからダウンロードする"といったものだ。クライアントはセキュリティーホールがある場合は、インタフェースがこうむる損害の量を制限することが重要です。

    クラッシュレポーティング

    Windowsでは2つの主要なクラッシュレポート方法がある: minidumpの生成と、それをサーバへ送信することです。Omahaでは、minidumpを生成してGoogleサーバに送るために、各アプリケーションは例外をキャッチしOmahaへシグナルを送る責務がある。minidumpはOmahaが書き込むことのできるセキュアなディレクトリに生成される。それは重要なデータを送る一方、頻繁なクラッシュの結果によるselfDDOSによるアクシデントの可能性を最小にしようとするコードを持っています。たぶん、いつminidumpが生成されたかの定義か、生成されたけど報告されていないクラッシュ数のレポートなど。

    Meta-Installer

    The Omaha meta-installer is a simple wrapper that includes the client as well as information necessary to install one or more Google applications. It performs the following functions:

    • Installs the client if it is not installed
    • Upgrades the client if it contains a more recent version
    • Starts the client if it's installed but not running
    • Queues install requests to the client for the applications that it wraps


    Our goal is that the minimal installer will be less than 172KB (which takes less than one minute to download over a 28.8kbps link at 10 wire bits per 8 data bits, representing what's likely the slowest modem still in operation today). The current size of the matainstaller is larger than that. We are looking for ways to keep the download size down. 


    メタインストーラ

    Omahaのメタインストーラは、クライアントだけでなく1または複数のGoogleアプリケーションのインストールに必要な情報も含む、単純なラッパーです。
    次の機能を行います:
    • クライアントがインストールされていない場合、クライアントのインストール
    • より最近のバージョンを含んでいた場合、クライアントのアップデート
    • インストールされたが起動していない場合、クライアントの起動
    • メタインストーラがラップしているアプリケーションのクライアントへのインストールリクエストのキュー
    我々は172KBより小さい最小のインストーラを目標にしています。(今日まだ稼働している最も遅いモデムといえる、28.8kbpsの回線を通じても1分以内にダウンロードできます). 現在のメタインストーラのサイズはそれより大きいです。我々はダウンロードサイズを小さく保つ方法を探しています。

    Server

    The Google Update server is not part of the Omaha open source project. Providing updates for applications requires a server that implements the Omaha Server Protocol.

    Omaha has two server components: autoupdate and download. This separation of server responsibilities is desirable because the requirements are different: downloading large binaries takes high bandwidth and can tolerate relatively high latency, whereas small transactions such as update pings may be much more frequent but require extremely low bandwidth per transaction. These differences allow Google to provision the two servers appropriately.


    The autoupdate server provides the following functionality:

    • Responds to update pings that come from individual Omaha clients, telling them whether and how to update the set of client products on that machine.
    • Provides a rich enough configuration schema that individual product teams should not have to implement their own servers. Client products will be able to provide arbitrary flags to Omaha that will be passed through to the server during an update ping, and it will be possible to configure the server to behave differently according to the presence or absence of those flags.
    • Allows Google to run experiments on stable subsets of users. For example, a team might wish to deploy a new version of its product to 0.01% of its users for a week in order to confirm that it causes no unexpected problems before deploying more widely.


    The download server's primary job is to host binaries.  In order to support private betas and other restricted software updates, the download server can restrict access to certain downloads.


    サーバー

    GoogleアップデートサーバーはオープンソースプロジェクトであるOmahaの一部ではありません。
    アプリケーションへのアップデートの提供は、Omahaサーバープロトコルを実装したサーバが必要です。

    Omahaは2つのサーバーコンポネントがあります: 自動アップデートとダウンロードです。このサーバ分割の責務は、要求が異なるため望ましい: 凄く大きなバイナリのダウンロードは、アップデートピングのようなより頻繁で、しかし1トランザクションに非常に低いバンド幅しか要求しない、小さなトランザクションの一方で、高いバンド幅を取り、相対的に高い遅延に耐えることができる。これらの違いは、Googleに適切な2つのサーバを準備することを許可する。


    アップデートサーバは次の機能を提供する:

    • 独立したOmahaのクライアントからくるアップートピングへの返答として、そのマシンのクライアント製品のセットを更新するかどうか返す。
    • 十分に構成された高度なスキーマを提供により、独立した製品チームは、彼らの独自サーバを実装する必要はありません。クライアント製品は、アップデートピングの間で、サーバーへ受け渡す、任意のフラグを備えることが可能です。そしてそれは、それらのフラグが存在するかしないかということによって、サーバを異なった振る舞いに構成することが可能です。
    • ユーザの集合に安定した体験をもたらすことが、Googleに出来るようになります。例えば、あるチームは、広範囲にデプロイして予期しない問題が発生しないことを確認するために、毎週製品ユーザの0.01%に製品の新しいバージョンのデプロイしてもよいです。
    ダウンロードサーバの最初の仕事は、バイナリをホストすることです。プライベートベータや他の制限されたソフトウェアアップデートをサポートするために、ダウンロードサーバは確実なダウンロードのためにアクセスを制限ることができます。

    Rollout Process

    To the greatest extent possible, teams will be able to reconfigure their area of the update server without affecting other teams.


    ロールアウトプロセス

    できるかぎり、チームは、他のチームに影響を及ぼすことなしに、彼らのアップデートサーバの領域を再構成することができるようになります。
    Comments