Twenty Ways

As many have noted, recent Google software releases for OS X now include Google Software Update, a background daemon that checks for and installs updates to Google software with no user intervention and no option for disabling it.

In theory, GSU is removed automatically when the last Google software to utilise it is uninstalled from your computer… but this assumes that you use the uninstallers bundled by Google, and don’t attempt to remove the software by hand.

I’ll save my disappointment for another editorial.
Instead, here is a workaround:
sudo rm /Library/LaunchAgents/com.google.keystone.agent.plist
sudo rm /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo rm /Library/LaunchDaemons/com.google.keystone.daemon4.plist


sudo touch /Library/LaunchAgents/com.google.keystone.agent.plist
sudo touch /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo touch /Library/LaunchDaemons/com.google.keystone.daemon4.plist


sudo chmod 000 /Library/LaunchAgents/com.google.keystone.agent.plist
sudo chmod 000 /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo chmod 000 /Library/LaunchDaemons/com.google.keystone.daemon4.plist


This hint does not uninstall GSU – it only “disables” the launchd entries that would run GoogleSoftwareUpdateAgent.app at boot time.

We first remove each entry (sudo rm …) and create empty files (sudo touch …) in their place.  We then change their POSIX permissions (sudo chmod) to deny any access to these files (000) for all accounts except root.

Creating inaccessible dummy files is important.  Without them, the launchd entries can simply be replaced whenever Google software is run.  But with these steps taken, no Google app can reinstall the GSU launchd entries, unless they:

• ask for your username and password (to authenticate as root),
• use different filenames, or
• create local launchd entries (~/Library/Launch[…])

This hint is easily adapted for each of these cases. You can also use this technique to remove GSU completely.

By default, Leopard Server disables Spotlight indexing on its system drive.

I assume that this decision was made to avoid confusion when administrators search the global catalog for system files on other machines. However, I find this to be a hassle when I need to locate a file on the server itself.

You can easily include a server’s local drives in its Spotlight index using mdutil:

sudo mdutil -i on /

The same command can be reissued with the off parameter to reverse the change.