Unattended installs of Flash Player 11.3

GregN

Flash Player 10
For some time now, OS X admins have been downloading the latest Flash Player disk image, opening the “Install Adobe Flash Player.app” application, pulling out the “Adobe Flash Player.pkg” package, and using that package to do unattended installs of Flash Player.

Recently, people have discovered an issue with that method: some component related to the Flash updater is not properly installed. If you use this installation method, open the “Flash Player” preferences pane in System Preferences, select the “Advanced” tab, and click “Check Now” under “Updates”, it crashes.

It turns out that Adobe has changed their recommended method for “silent” installs of Flash Player: see this article.

The method outlined in Adobe’s article works, and resolves the crashing issue in the Preferences pane, but there are several issues:

  1. This “silent” install causes an icon to appear in the Dock as it runs.
  2. Executing this method as described by Adobe fails when the machine is at the loginwindow — the process hangs indefinitely.
  3. It turns out there is an “–uninstall” flag for Adobe Flash Player Install Manager, but it cannot be done silently; it always displays a confirmation dialog and a success/failure dialog.
  4. Uninstall is therefore impossible at the loginwindow, as the OS prevents display of the dialogs (not that you’d want to rely on people clicking on the dialogs anyway)

We can fix (or at least work around) issues 1 and 2.

To prevent an icon from appearing in the Dock, you’ll need to modify the Info.plist in the Install Adobe Flash Player.app. So you must first copy it from its disk image to writable media (or use a shadowfile to mount the disk image as read-write. Details on this technique are outside the scope of this post.)

defaults write /path/to/Install\ Adobe\ Flash\ Player.app/Contents/Info LSUIElement -int 1
chmod a+r /path/to/Install\ Adobe\ Flash\ Player.app/Contents/Info.plist

This causes Launch Services to treat Install Adobe Flash Player.app as a “UIElement” – a type of application that should not display a menu or Dock icon. (The defaults command has an unfortunate side-effect of changing the permissions of files it modifies so that only the owner can read them; the chmod command sets the “read” bit for everyone once again.)

To run this thing at the loginwindow, we’ll need to resort to an old trick also used here. This technique uses `launchctl bsexec` to run the process in the same “bootstrap context” as the loginwindow. This allows the process to run to completion.

To do this manually, we must first find the process ID for loginwindow:

sudo ps axwww | grep loginwindow
 1485 ?? Ss 0:00.36 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console

The process ID is 1485.

We can then use launchctl:

sudo launchctl bsexec 1485 /path/to/Install\ Adobe\ Flash\ Player.app/Contents/MacOS/Adobe\ Flash\ Player\ Install\ Manager -install

Ugh.

The next step is to wrap all of this into a nice script, and maybe stuff it all into a payload-free package. Maybe I’ll get around to that next week.

These changes make setting up automated installs of Adobe Flash Player a royal pain, so you might want to consider turning on automatic background updates so you never have to do this again.

It turns out there is another flag you can pass to Adobe Flash Player Install Manager: -setUpdateMode.

  • -setUpdateMode 0 turns on “Silent Auto Updates” – updates are downloaded and automatically installed.
  • -setUpdateMode 1 causes updates to be auto downloaded, but the user is prompted to install them.
  • -setUpdateMode 2 turns off automatic checking for updates.

So our final command might look more like this:

sudo launchctl bsexec 1485 /path/to/Install\ Adobe\ Flash\ Player.app/Contents/MacOS/Adobe Flash Player Install Manager -install -setUpdateMode 0

UPDATE 20-Aug-2012:

It turns out that you cannot set the update mode by calling the Adobe Flash Player Install Manager binary; instead, after install, call this:

/Library/Application\ Support/Adobe/Flash\ Player\ Install\ Manager/fpsaud -setUpdateMode 0

or just create the /Library/Application Support/Macromedia/mms.cfg file with the desired contents.

Still to solve: unattended uninstalls. This will almost certainly involve custom scripting.

But really, Adobe?

UPDATE 17-Aug-2012, 16:07 PDT

Patrick Fergus reminds me by way of a comment below that there are issues if you enable “Silent Auto Updates”. So you may want to wait until Adobe fixes the bugs around that process as well.

Advertisement
Unattended installs of Flash Player 11.3

11 thoughts on “Unattended installs of Flash Player 11.3”

    1. I’d guess the reason is related, yes. Of course, that’s a reason why you should _not_ turn on automatic silent updates just yet.

  3. Adobe also documents a piped command on page 72 of of the CS Enterprise Deployment guide to get the process PID (which may be the same as what Joe originally posted, the Adobe blog link in your post from 2010 doesn’t seem to work anymore). That guide’s linked to here:

    http://www.adobe.com/devnet/creativesuite/enterprisedeployment.html

    The command is:

    launchctl bsexec `ps auwwx |grep [l]oginwindow | awk ‘{ print $2 }’` /path/to/installer -with -undocumented -command -flags

    However, this ps command would return multiple results if it is run when multiple users are logged in, and may mean the command is run more than once (it definitely would in a shell environment).

    Have you noticed if it is safe to run the installer in this bootstrap context even if a user is logged in, assuming one also makes the necessary UIElement modification in the bundle plist to suppress the appearance of the dock icon?

    Something like ” | tail -n 1″ could be added to the end to return only the first result in the case of multiple loginwindow processes, assuming it doesn’t matter which one it’s running in.

    The command provided by Adobe is the way I’ve been handling AIR updates in Munki using a forced logout, although it’s been reported by at least one person on munki-dev (Jim Zajkowski) that this approach was too unreliable. I believe I’ve seen a small number of failures, but in the single-digit percentages. I rarely need to update the AIR components, so it hasn’t gotten much use in the field – but I get the impression that’s about to change.

  4. Not this either... says:

    *confused* Why are you going to this effort when you only need to Compose /L/IP-Ins/Flash Player.plugin & flashplayer.xpt, /L/PP/Flash Player.prefPane as a .dmg?

    1. I’m actually not going to any effort at all. I’m currently still just installing the package that’s inside the app. What I *am* doing is pointing out that Adobe’s supported deployment method is half-baked and full of holes. But nothing is forcing you to use Adobe’s recommended deployment mechanism; if some other method works for you, by all means use it.

  6. FTBZ says:

    Here, we simply disable the auto-update when we deploy Flash with the package. Our users are not allowed to update their computers themselves.

Comments are closed.