Re: [munki-dev] Google Chrome and automatic updates

[Mike Pullen]

Hannes,

If one wanted to disable Chrome AutoUpdate systemwide, would one replace  registerChromeWithKeystone() with removeChromeFromKeystone() in main(), or is there another way?

Thanks,

Mike

On Mon, Nov 24, 2014 at 6:10 AM, Hannes Juutilainen <hjuuti...@mac.com> wrote:

The Keystone install tool changed in version 39. I've updated the script in GitHub:

https://github.com/hjuutilainen/adminscripts/blob/master/chrome-enable-autoupdates.py

--

Hannes

On 24.11.2014, at 13.37, Henning Kessler <he.ke...@googlemail.com> wrote:

Hi,

unfortunately this script stopped work for me with the new version (39.0.2171.65)

Munki gives me this error:

• Running postinstall_script for Chrome failed.

• ------------------------------------------------------------------------------

• Error: KeystoneRegistration.framework not found

• Error: Keystone install failed

• ------------------------------------------------------------------------------

Any idea?

Regards

Henning

Am Mittwoch, 30. Mai 2012 08:40:39 UTC+2 schrieb Hannes Juutilainen:

Yes, and there's two different approaches:

1. Remove Chrome registration from ticket store but leave Keystone installed. This might be desired if you have some other Google products installed.
2. Remove the whole Keystone and the ticket store (effectively removing Chrome registration too).

The Chrome ticket can be removed with the same ksadmin command that was used to register it. For example:
        cd "/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/"
        sudo ./ksadmin --delete --productid com.google.Chrome

The Keystone itself can be removed with the Keystone install script. For example:
        cd "/Applications/Google\ Chrome.app/Contents/Versions/19.0.1084.52/Google\ Chrome\ Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/"
        sudo ./install.py --nuke

The --nuke option removes Keystone files and the ticket store. Note that there's also the --uninstall option bat that leaves the ticket store on disk.

I created a script for this that can be used as a pre-uninstall script:
https://github.com/hjuutilainen/adminscripts/blob/master/chrome-disable-autoupdates.py


--
Hannes Juutilainen



On 30.5.2012, at 2.13, Greg Neagle wrote:

> Thanks for this, Hannes.
>
> As a companion and to aid in testing, have you documented the reverse procedure, that is, how to turn off/disable Keystone updates for Chrome?
>
> -Greg
>
> On May 25, 2012, at 2:33 AM, Hannes Juutilainen wrote:
>
>> First of all, thank you Nick McSpadden for the information on managing Google Chrome. I saw that it was posted to krypted.com too.
>>
>> The autoupdate issue still remains but I think I've found a solution to it. I read quite a lot of Chromium source code, looked through the logs and messed around within Google Chrome.app bundle trying to see what it does while registering for autoupdating. And fortunately I found some useful stuff...
>> The first thing that is needed is to install and register the Keystone itself. This is done with the KeystoneRegistration.framework/Resources/install.py script and works just like I thought when writing the initial message for this thread.
>>
>> cd "/Applications/Google Chrome.app/Contents/Versions/19.0.1084.46/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/"
>> sudo ./install.py --install=Keystone.tbz --root=/
>>
>> The second part (and the trickier one) is to register Chrome with Keystone. This is done with /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/ksadmin command line application which comes from the initial Keystone install. You can view the currently registered tickets with -p option and looking at the output reveals the options what Chrome should look like once registered:
>>
>> sudo ./ksadmin -p
>> <KSTicket:0x611480
>>         productID=com.google.Keystone
>>         version=1.0.9.2865
>>         xc=<KSPathExistenceChecker:0x611750 path=/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/ksadmin>
>>         url=https://tools.google.com/service/update2
>>         creationDate=2012-05-24 05:50:19 +0000
>>>
>> <KSTicket:0x611b50
>>         productID=com.google.Chrome
>>         version=19.0.1084.52
>>         xc=<KSPathExistenceChecker:0x611b10 path=/Applications/Google Chrome.app>
>>         url=https://tools.google.com/service/update2
>>         creationDate=2012-05-24 09:26:22 +0000
>>         tagPath=/Applications/Google Chrome.app/Contents/Info.plist
>>         tagKey=KSChannelID
>>         brandPath=/Library/Google/Google Chrome Brand.plist
>>         brandKey=KSBrandID
>>         versionPath=/Applications/Google Chrome.app/Contents/Info.plist
>>         versionKey=KSVersion
>>>
>>
>>
>>
>> ksadmin requires at least 4 arguments to register an application with Keystone but looking at the above it's clear that Chrome wants some more. This is also confirmed by looking at the Chromium source code at http://src.chromium.org/svn/trunk/src/chrome/browser/mac/keystone_glue.mm and its keystoneParameters method. So if you'd do this manually, you'd have this monster command:
>>
>> ./ksadmin --register --preserve-tttoken --productid com.google.Chrome --version 19.0.1084.52 --xcpath "/Applications/Google Chrome.app" --url https://tools.google.com/service/update2 --tag-path "/Applications/Google Chrome.app/Contents/Info.plist" --tag-key KSChannelID --brand-path "/Library/Google/Google Chrome Brand.plist" --brand-key KSBrandID --version-path "/Applications/Google Chrome.app/Contents/Info.plist" --version-key KSVersion
>>
>>
>> I've compiled all of this in to a python script that should work without customization on any recent version of Chrome. It checks what version is installed in "/Applications/Google Chrome.app" and then setups the autoupdates accordingly. I'm still testing this but it seems to do it's job: The "Setup automatic updates" button is gone from the About window and it successfully updates itself.
>>
>> You can get the script from:
>> https://github.com/hjuutilainen/adminscripts/blob/master/chrome-enable-autoupdates.py
>>
>> Just copy/paste as a postinstall_script in to your Chrome pkginfo.
>>
>>
>> --
>> Hannes Juutilainen
>>
>>
>>
>>
>>
>> On 18.5.2012, at 7.20, Mike Pullen wrote:
>>
>>> Sorry if I've missed an inferred answer to this question, but-- Is it possible to have Chrome autoupdate enabled for all users, even non-admin users?
>>>
>>> If so, is there anyone who does use autoupdate on the client end to keep Chrome updated? Then again if so, how do you set up the keystone autoupdater for all users? It isn't enabled as Chrome is installed-- and while there is documentation on how to disable the updater, I can find none detailing how to enable it as a post-flight script.
>>>
>>>
>>> Thanks!
>>> Mike
>>
>

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[zack.m...@bsd7.org]

I use this:

#!/bin/bash

if [ -e /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall ] ; then

/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall --uninstall

echo "Uninstalled KSFetch Update Service";

exit 0;

else

echo "KSInstall not found";

exit 0;

fi

It check for the file and if exists (should after version 38) runs uninstall.

[Mike Pullen]

Zach,

Awesome. Do you know, by chance, if that keeps Chrome from complaining to end-users that it can't keep itself updated?

Thanks,

Mike

[Gregory Neagle]

I always find these discussions surprising: since (at least for me) Munki installs Google Chrome as root, by copying the application bundle from a mounted disk image to the /Applications folder, the GoogleSoftwareUpdate thing is never installed and so Chrome does not attempt to update itself (or more accurately, the GoogleSoftwareUpdate thing doesn't).

Has Google Chrome itself become more aggressive about notifying users when it's out of date and the GoogleSoftwareUpdate thing isn't running/installed?

-Greg

[zack.m...@bsd7.org]

Zach,
Awesome. Do you know, by chance, if that keeps Chrome from complaining to end-users that it can't keep itself updated?

Thanks,
Mike

It does. It will ask once "Chrome is not setup for automatic updates" and clicking dismiss has so far dismissed it.

On Monday, November 24, 2014 8:32:45 AM UTC-7, gregn...@mac.com wrote:

I always find these discussions surprising: since (at least for me) Munki installs Google Chrome as root, by copying the application bundle from a mounted disk image to the /Applications folder, the GoogleSoftwareUpdate thing is never installed and so Chrome does not attempt to update itself (or more accurately, the GoogleSoftwareUpdate thing doesn't).

Has Google Chrome itself become more aggressive about notifying users when it's out of date and the GoogleSoftwareUpdate thing isn't running/installed?

-Greg

Chrome has indeed. I believe at first run it moves the GoogleUpdate app into place (or during first update after coping out of DMG). I thought munki would never have installed it either (for your reasons as well) however when I was testing on one of our labs, the Update app was installed shortly after the first run. Not sure as to what defines it to install it (might also have been Google Earth being installed at same time) but it does show up after time. I'll have to do more digging into it. 

For now, I added that as a post-install script for chrome, that way it uninstalls it. I wish Google would have an enterprise option that you could customize the options it ships with. *sigh* But that's asking too much ;) 

[Erik]

In my experience, upon first run of Google Chrome the Keystone is copied over from /Applications/Google Chrome.app to the users Library folder.

Once Chrome is out of date (and it fails to update) it will proceed to complain or make a secondary application bundle at ~/Applications/Google Chrome.app

[Erik]

Zach,

There most certainly is an enterprise option.

https://support.google.com/installer/answer/147176?hl=en&ctx=go

http://www.chromium.org/administrators/policy-list-3

[Gregory Neagle]

Oh, great. Now it's acting like malware.

-Greg

[Gregory Neagle]

On Nov 24, 2014, at 7:46 AM, zack.m...@bsd7.org wrote:

Zach,
Awesome. Do you know, by chance, if that keeps Chrome from complaining to end-users that it can't keep itself updated?

Thanks,
Mike

It does. It will ask once "Chrome is not setup for automatic updates" and clicking dismiss has so far dismissed it.

On Monday, November 24, 2014 8:32:45 AM UTC-7, gregn...@mac.com wrote:

I always find these discussions surprising: since (at least for me) Munki installs Google Chrome as root, by copying the application bundle from a mounted disk image to the /Applications folder, the GoogleSoftwareUpdate thing is never installed and so Chrome does not attempt to update itself (or more accurately, the GoogleSoftwareUpdate thing doesn't).

Has Google Chrome itself become more aggressive about notifying users when it's out of date and the GoogleSoftwareUpdate thing isn't running/installed?

-Greg

Chrome has indeed. I believe at first run it moves the GoogleUpdate app into place (or during first update after coping out of DMG).

If the user is not an admin, any update process will not be able to update /Applications/Chrome.app.

I thought munki would never have installed it either (for your reasons as well) however when I was testing on one of our labs, the Update app was installed shortly after the first run.

Where?

Not sure as to what defines it to install it (might also have been Google Earth being installed at same time)

Yes, since Google Earth is distributed as a _package_, when it installs it can install other components like the updater. An updater running as root could then update Chrome as root.

[zack.m...@bsd7.org]

On Monday, November 24, 2014 9:52:31 AM UTC-7, gregn...@mac.com wrote:

On Nov 24, 2014, at 7:46 AM, zack.m...@bsd7.org wrote:

Zach,
Awesome. Do you know, by chance, if that keeps Chrome from complaining to end-users that it can't keep itself updated?

Thanks,
Mike

It does. It will ask once "Chrome is not setup for automatic updates" and clicking dismiss has so far dismissed it.

On Monday, November 24, 2014 8:32:45 AM UTC-7, gregn...@mac.com wrote:

I always find these discussions surprising: since (at least for me) Munki installs Google Chrome as root, by copying the application bundle from a mounted disk image to the /Applications folder, the GoogleSoftwareUpdate thing is never installed and so Chrome does not attempt to update itself (or more accurately, the GoogleSoftwareUpdate thing doesn't).

Has Google Chrome itself become more aggressive about notifying users when it's out of date and the GoogleSoftwareUpdate thing isn't running/installed?

-Greg

Chrome has indeed. I believe at first run it moves the GoogleUpdate app into place (or during first update after coping out of DMG).

If the user is not an admin, any update process will not be able to update /Applications/Chrome.app.

And it can't. If you have Parental Controls on, it will continuously ask to be allowed until you either hit ok (and it returns later) or allow always. 

I thought munki would never have installed it either (for your reasons as well) however when I was testing on one of our labs, the Update app was installed shortly after the first run.

Where?

Installed to : /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle

On creation of one of our labs (No Google Earth) first run of chrome seemed to create this bundle, which contains the Autoupdating service. However that was only after hitting "Allow Always" on the KSADMIN / KSFETCH and GoogleUpdateService Prompts. If you hit OK, it will come back again and again.

Not sure as to what defines it to install it (might also have been Google Earth being installed at same time)

Yes, since Google Earth is distributed as a _package_, when it installs it can install other components like the updater. An updater running as root could then update Chrome as root.

I realized that after I posted that segment. 

[Hannes Juutilainen]

How are people deploying Google Chrome with munki? Are you just copying the app bundle to /Applications and be done with it? Or are you copying the app and using postinstall script to enable/disable/configure the automatic updates? My method has just been to copy the app bundle (with optional_installs and managed_updates) but I have been thinking about letting Chrome update itself since I'm not always up-to-date with the Chrome releases.

I see there's the KeystoneRegistration.framework inside the Chrome bundle which installs /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle or ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle respectively.

So would something like this in postinstall_script be enough to enable the updates:

#!/bin/sh

INSTALL_SCRIPT="/Applications/Google Chrome.app/Contents/Versions/19.0.1084.46/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/install.py"
KEYSTONE="/Applications/Google Chrome.app/Contents/Versions/19.0.1084.46/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/Keystone.tbz"

"$INSTALL_SCRIPT" --install="$KEYSTONE" --root=/

exit 0



There's also this information in Google Help titled "Managing updates in Google Software Update":
http://support.google.com/installer/bin/answer.py?hl=en&ctx=go&answer=147176
I haven't experimented with configuring the automatic updates (yet) but I'm assuming MCX would take care of these if needed.


--
Hannes Juutilainen

[Lee Ramsay]

Forgive me because I'm not at work and can't view/share what we currently push, but from memory we copy the app bundle with munki, have a master_preferences file, and manage several of the preference manifests google have made available via MCX. We also disable the keystone agent updates, and do them ourselves with munki

I run a student lab environment and it's important not to pester users with EULA's or browser popups, the academics really get narky about it. I've got the chrome deployment pretty "ready to go",  minus two things.

1) I'd love to set the default home screen to the "most visited" home screen, but it always seems to default to the apps one.

2) A yellow notification banner runs on first start warning the user that auto updates aren't enabled.

I hadn't actually considered allowing chrome to auto update itself, I dismissed it because I was concerned that I couldn't rely on it (internet access only available when a student is logged in). I suppose however that if auto updates are configured and it never gets around to it "automatically", I still release new chrome versions whenever I'm able to, and it will stop pestering users with #2.

I'll share my MCX settings and the rest I'm using tomorrow if possible, I'd really appreciate the assist if someone has tackled either of my two problems and can share! :D

Cheers,

Lee

[Greg Neagle]

I think others will be interested in the details. There was a question along these same lines on the MacEnterprise mailing list today as well.

-Greg

[Nick McSpadden]

I'm experimenting with this right now. There are a couple of
solutions but none of them are fantastic. For things that can't be
controlled through MCX, we can manually add things to the Master
Preferences List:
http://www.chromium.org/administrators/configuring-other-preferences.

> 1) I'd love to set the default home screen to the "most visited" home
> screen, but it always seems to default to the apps one.

There is unfortunately no interface for changing the new tab page.
There are extensions that do this, and I'm trying to replicate their
behavior, but simply adding their manifests to the Master Preferences
file isn't doing the trick. For example, chrome_url_overrides doesn't
seem to take effect, so I'm back to the drawing board.

> 2) A yellow notification banner runs on first start warning the user that
> auto updates aren't enabled.
>
> I hadn't actually considered allowing chrome to auto update itself, I
> dismissed it because I was concerned that I couldn't rely on it (internet
> access only available when a student is logged in). I suppose however that
> if auto updates are configured and it never gets around to it
> "automatically", I still release new chrome versions whenever I'm able to,
> and it will stop pestering users with #2.

Setting autoupdate to on might be a better solution, even if those
machines never have admin access. The other downside to turning
autoupdate on is that the program should still determine the latest
version and give you the little arrow to indicate that you're out of
date, even if it can't download new updates. I haven't tested this
thoroughly, though. I have not yet found any means to make the yellow
bars go away, though - I suspect that's a permanent feature.

--
--
Nick McSpadden
nmcsp...@gmail.com

[Nick McSpadden]

On Thu, May 17, 2012 at 11:33 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:

>> 1) I'd love to set the default home screen to the "most visited" home
>> screen, but it always seems to default to the apps one.
>
> There is unfortunately no interface for changing the new tab page.
> There are extensions that do this, and I'm trying to replicate their
> behavior, but simply adding their manifests to the Master Preferences
> file isn't doing the trick.  For example, chrome_url_overrides doesn't
> seem to take effect, so I'm back to the drawing board.

Got it. Add this to your MCX manifest for Google Chrome:
ExtensionInstallForcelist (array)
Item - dpjamkmjmigaoobjbekmfgabipmfilij;http://clients2.google.com/service/update2/crx

What it does is silently forces the install of an extension from the
Chrome web store called "Empty New Tab," which does exactly what it
sounds like. Note that this does pull it from the internet, so if you
want to avoid this, you'll need to locally host the crx file. There
is documentation on the Chromium for Admins site about doing this, but
I haven't looked at it beyond the cursory glance.

My attempts to recreate the extension's behavior without the extension
by adding it to the manifest and/or Master Prefs file was totally
unsuccessful, so this is a working and relatively straightforward
solution.

[Lee Ramsay]

As requested,

My chrome MCX enforced policies;

http://dl.dropbox.com/u/26749078/chrome.jpg

Keystone agent (disable updates);

http://dl.dropbox.com/u/26749078/keystone.jpg

master_preferences (which are the equivalent of 'once' preferences set on chrome profile creation);

http://dl.dropbox.com/u/26749078/masterprefs.jpg

I actually deployed my master prefs to  /Applications/Google Chrome.app/Contents/MacOS/master_preferences, as originally that's where documentation told me to do it. To the best of my knowledge that still works, despite documentation telling you to do elsewhere.

Nick Spadden on macenterprise (props by the way Nick, great article) however mentioned he's putting it in /Library/Google/Google Chrome Master Preferences, which is also where the chromium project suggests to put master_preferences.

I did my original config in december 2011, and it still seems to be working other than the 2 annoyances I have, which Nick has solved for me. I need to invest more time in it, but I have other fires to put out at present, and it seems to be doing what we need for now.

Hope this helps others get chrome out there, it really does it for me allowing people as much browser choice as possible, as long as the browser choices will honour the pretty basic organisational requirements we require.

Lee

[Lee Ramsay]

Nice work on the fix, I appreciate the assist. Doesn't work too well for my needs however, I actually like the new tab screen to display the most visited sites. I just want when someone clicks new tab for it to go to most visited, but it defaults to the 'apps' switcher down the bottom. If you select most visited and exit out of chrome, it will default to that screen from then on. I just can't seem to set that as the default via either master prefs or MCX.

Props again on the article, definitely a lot more helpful than googles disparate and incomplete mac documentation, IMO.

Lee

[Mike Pullen]

[Hannes Juutilainen]

[Nick McSpadden]

This is fantastic work, thanks!

[Mike Pullen]

Yes, huge...

Thank you!
Mike

[Greg Neagle]

Thanks for this, Hannes.

As a companion and to aid in testing, have you documented the reverse procedure, that is, how to turn off/disable Keystone updates for Chrome?

-Greg

[Hannes Juutilainen]

Yes, and there's two different approaches:

1. Remove Chrome registration from ticket store but leave Keystone installed. This might be desired if you have some other Google products installed.
2. Remove the whole Keystone and the ticket store (effectively removing Chrome registration too).

The Chrome ticket can be removed with the same ksadmin command that was used to register it. For example:
cd "/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/"
sudo ./ksadmin --delete --productid com.google.Chrome

The Keystone itself can be removed with the Keystone install script. For example:
cd "/Applications/Google\ Chrome.app/Contents/Versions/19.0.1084.52/Google\ Chrome\ Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/"
sudo ./install.py --nuke

The --nuke option removes Keystone files and the ticket store. Note that there's also the --uninstall option bat that leaves the ticket store on disk.

I created a script for this that can be used as a pre-uninstall script:
https://github.com/hjuutilainen/adminscripts/blob/master/chrome-disable-autoupdates.py


--
Hannes Juutilainen



On 30.5.2012, at 2.13, Greg Neagle wrote:

[tackyy]

Ran into a bit of a snag on this one. Since this is python it's sensitive to indenting and whitespace. Copying/pasting from the github link added all kinds of erroneous whitespace. I was able to fix it by making sure there was no whitespace between starting string tag and code, and end of code and closing string tag. Also TextMate's column select/delete was very handy to strip out most of the extra whitespace github added. Then I needed to fix return value indents on lines 93 and 131.

But now it works great!

Cheers,
tack

[Greg Neagle]

Best practice whenever adding a pre- or post- script to a Munki pkginfo:

1) Save the script to a file.
2) Test running the script from that file.
3) Once it runs correctly: /usr/local/munki/makepkginfo --postinstall_script=/path/to/the/script

You can substitute --preinstall_script, --postuninstall_script, --preuninstall_script, or --uninstall_script for the other types of scripts. By using makepkginfo to generate the key and value, you ensure the script is properly encoded for inclusion in a plist file.

-Greg

[Hannes Juutilainen]

On 30.5.2012, at 21.54, tackyy wrote:

> Then I needed to fix return value indents on lines 93 and 131.

Thanks for this. There were indeed erroneous tab characters on those lines caused by BBEdit defaults. Fix committed.

--
Hannes Juutilainen

[tackyy]

Hey, no prob. Thanks for the yummy script.

tack

[Henning Kessler]

Hi,

unfortunately this script stopped work for me with the new version (39.0.2171.65)

Munki gives me this error:

• Running postinstall_script for Chrome failed.

• ------------------------------------------------------------------------------

• Error: KeystoneRegistration.framework not found

• Error: Keystone install failed

• ------------------------------------------------------------------------------

Any idea?

Regards

Henning

Am Mittwoch, 30. Mai 2012 08:40:39 UTC+2 schrieb Hannes Juutilainen:

[Hannes Juutilainen]

The Keystone install tool changed in version 39. I've updated the script in GitHub:

https://github.com/hjuutilainen/adminscripts/blob/master/chrome-enable-autoupdates.py

--

Hannes

On 24.11.2014, at 13.37, Henning Kessler <he.ke...@googlemail.com> wrote:

[Henning Kessler]

Great, thank you so much 

Henning