Confirmed users
394
edits
Windows Service Silent Update: Difference between revisions
Updated with latest information, mostly changes about x64.
(→Limited user accounts: Bug 711475 is fixed.) |
(Updated with latest information, mostly changes about x64.) |
||
| Line 46: | Line 46: | ||
The service security is modified with a special [http://msdn.microsoft.com/en-us/library/aa379298.aspx ACE] which allows non elevated processes to start and stop it. Setting these permissions on the service is needed because by default services can only be started and stopped by elevated processes. This is possible via the Win32 API [http://msdn.microsoft.com/en-us/library/windows/desktop/aa379589%28v=vs.85%29.aspx SetServiceObjectSecurity]. | The service security is modified with a special [http://msdn.microsoft.com/en-us/library/aa379298.aspx ACE] which allows non elevated processes to start and stop it. Setting these permissions on the service is needed because by default services can only be started and stopped by elevated processes. This is possible via the Win32 API [http://msdn.microsoft.com/en-us/library/windows/desktop/aa379589%28v=vs.85%29.aspx SetServiceObjectSecurity]. | ||
The service logs all operations of the last update, as well as taking a backup of the last 10 update | The service logs all operations of the last update, as well as taking a backup of the last 10 update operation logs | ||
before it. The install process and update processes are logged separately. The logs live in %programdata%\Mozilla\logs. | before it. The install process and update processes are logged separately. The logs live in %programdata%\Mozilla\logs. | ||
Since the service executes an update via updater.exe in session 0, no UI is displayed. | Since the service executes an update via updater.exe in session 0, no UI is displayed. An alternate implementation could have been to have the UI display by running updater.exe with a user token from the service instead, but to avoid permission problems on files, and inconsistencies in different OS versions and user types, the update is always run as session 0 with the SYSTEM account. | ||
== A single service and service versioning == | == A single service and service versioning == | ||
| Line 57: | Line 57: | ||
If a service is already installed, the service will be replaced on updates and installs only if it is newer than what is installed. This means that if a user has Nightly installed, the Nightly service will be used to update all channels. | If a service is already installed, the service will be replaced on updates and installs only if it is newer than what is installed. This means that if a user has Nightly installed, the Nightly service will be used to update all channels. | ||
As of Firefox 35, the service is also installed and used with x64 native builds. | |||
If both x86 and x64 builds are used, then the service will be installed and updated into the first location it was installed to. | |||
The x86 service can update both x86 and x64 builds. The x64 service can also update both x86 and x64 builds. | |||
Work was done for native x64 builds in [https://bugzilla.mozilla.org/show_bug.cgi?id=715876 Bug 715876]. | |||
The service decides whether or not it is newer by looking at the updater file's version number in comparison to a new one being updated by application update or the installer. | The service decides whether or not it is newer by looking at the updater file's version number in comparison to a new one being updated by application update or the installer. | ||
| Line 98: | Line 101: | ||
* The service gets started | * The service gets started | ||
* The service determines which action should be performed from its command line parameters. | * The service determines which action should be performed from its command line parameters. | ||
* If the command is an action other than a software update, the action is performed. | * If the command is an action other than a software update, the action is performed. | ||
* If the command is a software update then continue on... | * If the command is a software update then continue on... | ||
* The service verifies the updater.exe file (See section Signing builds below) | * The service verifies the updater.exe file (See section Signing builds below) | ||
| Line 108: | Line 111: | ||
== When the service fails == | == When the service fails == | ||
* If there is an error creating the process, or during update, or a | * If there is an error creating the process, or during update, or a binary windows authenticode certificate check error, an error is written to update.status and info is reported via telemetry on the next restart of the callback application. The next restart of the callback application will also set the status back to pending so that the update will be applied next time without the service. | ||
* If there are more than 10 consecutive service specific errors, the service will automatically disable itself and reset this count to 0. A user can re-enable the service via preferences. | * If there are more than 10 consecutive service specific errors (tracked with the app.update.service.errors pref), the service will automatically disable itself and reset this count to 0. A user can re-enable the service via preferences (app.update.service.enabled). | ||
== Service as an optional component == | == Service as an optional component == | ||
* If the service is not installed, or disabled, we will fall back to the old way of updating: using updater.exe | * If the service is not installed, or disabled, we will fall back to the old way of updating: using updater.exe only. | ||
* A user can | * A user can choose to not install the service at install time of Firefox. | ||
== Limited user accounts == | == Limited user accounts == | ||
| Line 123: | Line 126: | ||
The service will be installed for users automatically via application update. There are reasons why the service will not be installed via application update though: | The service will be installed for users automatically via application update. There are reasons why the service will not be installed via application update though: | ||
* An OS lower than XP is being used (this also applies to the installer). | * An OS lower than XP is being used (this also applies to the installer). | ||
* The update is being performed as a limited user account (this also applies to the installer). | * The update is being performed as a limited user account (this also applies to the installer). | ||
| Line 136: | Line 138: | ||
You can also control whether the installer installs the service using a [[Installer:Command_Line_Arguments|configuration ini]] method provided by the installer. | You can also control whether the installer installs the service using a [[Installer:Command_Line_Arguments|configuration ini]] method provided by the installer. | ||
== | == Verifying the updater is our own binary == | ||
To ensure we execute our own binary, we verify the signature of updater.exe to make sure it is signed by us. | To ensure we execute our own binary, we verify the signature of updater.exe to make sure it is signed by us. | ||