Flash Player 11.9 .pkg installation feedback

[chris.campbell]

Starting a thread for discussions on the new .pkg installation format.  This new installation format will eventually be made available to customers that have signed up for Flash Player distribution but for now is available for everyone to test on our labs download page.  Thank you for trying out this build and we look forward to hearing your feedback!

[Patrick_Gallagher_Jr_]

Comparing the old pkg (inside the .app) and this new one, the new one adds "Adobe Flash Player Install Manager.app" to /Applications/Utilities. Since this installer is for managed enviornments (presumably), I don't think this needs to be included.

Thoughts?

--

Patrick Gallagher

[GregNeagle]

Unless the actual Flash Player bits have changed (and not just the install pkg), the "Adobe Flash Player Install Manager.app" must exist in /Applications/Utilities or System Preferences will crash if the user attempts to check for updates using the Flash Player preference pane.

See http://managingosx.wordpress.com/2012/08/19/more-on-flash-player-11-3/

Having the package install this is an improvement over the current state of affairs.

[Don_Montalvo]

Interesting entries in the postinstall script.

I would caution against using spaces in either the mounted DMG or the PKG installer.

Lastly, please put all Adobe stuff into /Applications/Utilities/Adobe or /Library/Application\ Support/Adobe folder.

Details matter...

Thanks for putting time/effort into this, it's great to see the Adobe Flash Player team taking enterprise seriously.

Don

[scott_blake]

I noticed a couple things while examining the package:

1. Since the package requires authentication, it shouldn't be necessary to have sudo commands in your install scripts.
2. As Don mentioned, I wish more installers placed their supporting files into directories, especially big companies like Adobe. Once you start to mix and match products, those directories become quite cluttered and a little forethought can go a very long way.
3. Since the Adobe Flash Player Install Manager.app only seems to be for the purpose of uninstalling, wouldn't it make more sense to provide an uninstall.pkg along with the installer?

Thank you for this tool. I think that with a little work, it could be a great help to admins everywhere.

Scott

[tritiut]

I tore the package apart and poked around. Here are my observations:

• preinstall script
  • A distribution package can do the minimum OS check for you--check the man page for productbuild.
  • Is the downgrade-prevention check even necessary? Installer already checks package versions based on installer receipts and shouldn't let you install an older package over a newer one.
  • It seems the entire preinstall script can be eliminated which means there's one less thing for you folks to test and maintain.
• postinstall script
  • The first part of the script is setting permissions which should be done in the payload. The Bom shows that all those files and directories get set with the right permissions so I guess you just want to make extra certain that permissions are set correctly?
  • sudo shouldn't be necessary if you're already running as root
  • Oh, finalize is a special-purpose lzma decompression tool that works for just one file? Really? (experiments with the package payload... decompresses the plugin... builds new package...) Ok... the lzma thing saves you 5.4 MB. I guess over a bazillion downloads that adds up to some real bandwidth savings for Adobe. Interesting.

[Kai Automatica]

Interesting that the custom compression tool saves over 5MB.

One thing to check though would be to make a compressed DMG with the original one, and with your uncompressed one and check what the final sizes of each DMG turns out to be...

[e_whizz]

Additionally, the preinstall script makes assumptions about the version of flash plugin and its specific path

SYS_PLIST="$3/Library/Internet Plug-Ins/Flash Player.plugin/Contents/PlugIns/FlashPlayer-10.6.plugin/Contents/Info.plist"

The version may or may not be newer than the version this path is referencing, plus what happens when....

Oh I get it now, the Plug-In is always called FlashPlayer-10.6.plugin, of course.

Even though the version is 11.9 d900 . Great

[Kai Automatica]

Thanks Chris for the direction that this project is going in. It's heartning to see Adobe listening to us poor neglected system administrators

I won't rehash everything that's been mentioned above, but instead will comment on the installation process.

I am using Munki as my managed software deployment mechanism.

Flash player was completely uninstalled off my system.

The new installer was imported as a .dmg into my Munki repository

I deployed it to my workstation, making sure I was logged out while the deployment happened (as I need to test that this scenario works)

I then logged back in and checked my flash player version at

http://helpx.adobe.com/flash-player/kb/find-version-flash-player.html

This reports that Flash Player is running (in Safari at least) and I'm running 11.9.900.85

This is good. Double-thumbs-up!

In the past, here's what we've had to do to initially deploy Flash player:

• Load the flash player installer .app into Munki
• As it's a .dmg with a single .app inside it, the deployment software makes the assumption that it's a drag and drop install (like Firefox or Skype for example)
• We then need to make a custom .pkg installer that has a post install script that runs the flash player installer, but does it in such a way it will work when no-one is logged in. Needless to say, this is a bit of a fragile solution that's liable to break with any update.

Then, for updates to Flash player

• Extract the .pkg from inside the flash player installer
• Load this into the managed software update repository
• Deploy as a normal .pkg and hope that the prefpane and other bits that aren't deployed in this fashion haven't been updated.

From today (or, from the release of Flash player 11.9) it will be the same for initial deployment as for updates

• Load the flash player .dmg into managed software updates
• Deploy it
• Sit back with a smile on my face as all the workstations under my control get the new version of flash player.

Thanks,

Kai

[e_whizz]

The naming structure of the .dmg could be imrpoved.

as it is now

flashplayer11-9_install_mac_pkg.dmg

might be better as

flashplayer-11.9_mac.dmg

The .pkg should could also have a similar naming structure

flashplayer-11.9_mac.pkg

The _mac part is probably superfluous.

The version as part of the name, whilst it should be implicit inside the .pkg is also useful in many situations where the .pkg is used with tools that do not utilise .dmg image files.

The .pkg does not have a version string when you Get Info on it.

The line in the preinstall script

logger "Flash Player Install Error: Non-OS install volume specified."

should have another colon between Flash Player Install and Error

logger "Flash Player Install: Error: Non-OS install volume specified."

The Crash that occurs if "Adobe Flash Player Install Manager.app" is not in the correct place, is just poor programming. The Prefs pane should not make hard assumptions about where the .app is stored and shoudl use System APIs to find it in the ideal scenario.

If there are components that the Prefs pane requires that are buried inside the "Adobe Flash Player Install Manager.app". They should be installed inside the Pref pane or in a mutually convenient location such as /Library/Adobe/Flash

Plus ALL the other things everyone else said above this reply!

[ShaneDPalmer]

On a personal level I like having the version as part of the pkg name, but for an enterprise workflow for something like Flash I do not.  My Casper and ARD workflow is to always replace the previous installer in my installer repository.  Since Flash updates usually contain fairly serious security fixes I only ever keep the current version of the installer around so there is no chance of accidentally installing an older out of date version.  To facilitate that I always keep my installer names the same "Adobe Flash Player.pkg".

Along those lines I wouldn't mind seeing Adobe at the beginning of the name for both the pkg and dmg.  Once you start managing a hundred or more pkgs and dmgs for enterprise deployment it helps to be able to group all pkg and dmg files from Adobe together.

I know everybody has there own workflows so which ever way the naming convention goes they can always be renamed to fit a specific workflow.

[chris.campbell]

Thank you guys for the excellent feedback!  The team is reviewing this thread and we'll get together over the next few days to discuss our action items.  It sounds like most of you have had generally positive results.  Has anyone found any "blocking" issues with your workflow?

I'll let the technical folks on the team respond to many of the items pointed out here but wanted to let you know that the current file name on labs will be changed when it's made available on the distribution page. I don't know the final name, but I'm assuming it'll be something similar to "install_flash_player_11_osx_pkg.dmg".  We already have a "install_flash_player_11_osx.dmg" file so I believe the pkg suffix will be needed.

[Per_Olofsson]

(Apologies if I'm repeating things that have already been mentioned, I wrote this offline earlier.)

First off I want to say that I'm really happy that you're making an effort to make a well behaved deployable package, and I hope you can get other product teams on board.

I picked apart the 11.9.900.85 beta installer and noted the following:

• Since the plugin itself is lzma'd, there's no <bundle> reference in the PackageInfo file. With a proper bundle /usr/sbin/installer will handle the version check and determine if it's a new install, an upgrade, or a downgrade.
• The preinstall script performs minimum OS checking, which should be handled in the Distribution file - see allowed-os-versions in the Distribution Definition XML Schema Reference.
• The preinstall script prevents downgrades of the plugin, but if the plugin isn't lzma'd the Distribution can manage that for you.
• The preinstall script exits with the status of the last logger command, which may have failed. Use exit 0 to guarantee a successful exit, or even better omit the preinstall script and use the Distribution file for the version checks.
• The postinstall changes the permissions of three items in the payload, and as a general rule the scripts shouldn't modify the payload, the payload should be fixed instead. In this case though the payload already has the correct  permissions, so unless I'm missing something they can be omitted.
• The postinstall calls launchctl with sudo, which is unnecessary since the postinstall is already running as root.
• The postinstall exits with the status of the finalize utility. It might be better to log a message and explicitly exit with the proper status code.

To summarize the only feature that actually needs scripting is the loading of the launch daemon, the rest can be moved into the payload and the distribution spec, which would make for a package with very few moving parts.

[nlfdss]

As I came here to provide some feedback, pretty much anything I'd want to point out (and more) is covered in Per Olofsson's response, so I won't repeat it all again, but consider this a "+1" to his reponse.

As many others have also said, I'd like to also thank Chris and Adobe for making attempts to do right with OS X software deployment. It makes our lives as sysadmins much easier.

[Matt_Talistu]

Hi all! I am one of the engineers working on the .pkg installer. First, I'd like to thank everyone for the great feedback. Your expertise is necessary to validate this feature, and we appreciate everyone taking the time to test this beta.

We have gone over all of the feedback from this forum and the emails we've received, and we hope to address some of your issues before the initial release. I plan to make some of the suggested enhancements to the pre/postinstall scripts, including removing the commands that were identified as unnecessary. I'll also look into using the standard install mechanism for specifying the minimum supported OS.

Soon after the initial release, we will look into implementing some of the other changes that were mentioned, such as moving the Install Manager to /Applications/Utilities/Adobe/ and consolidating our logging across the installers

As for the issue with the LZMA compressed plugin, we will not be able to address that for the initial release. The .app installer also includes this .pkg, which is the majority of the .app installer's file size. An increase from 17MB to 22MB may not seem like much for an individual .pkg download, but a 25% increase in the .app installer's file size multiplied by the number of downloads we see over the course of each release adds up quickly. It's more than an engineering issue. That said, there are a few options that we can consider to try and solve this problem and we will look into it for a future release.

We also won't be able to address the need for the .pkg installer to include the Install Manager.app at this time. As mentioned in one of the earlier comments, the Install Manager is more than just an Uninstaller. The Preference Pane and the Plugin both currently rely on the Install Manager for some of their functionality. We will not be able to decouple those components for the initial release of the .pkg installer.

I know those last two paragraphs sound negative, but don't worry! We will continue to incorporate your feedback to improve the .pkg installer after this initial release.  It may not be perfect at the moment, but we hope that it will simplify your deployment  process and remove some of the drawbacks of the .app installer in enterprise environments. Please feel free to file any issues at https://bugbase.adobe.com/ or continue the discussion in this forum. We will try to get some of these changes into next week's beta release.

[Per_Olofsson]

Hi Matt,

  I experimented a bit with various compression schemes, e.g. keeping the package Payload uncompressed and using UDBZ for the dmg, but nothing comes close to LZMA. However, the flat pkg is actually a xar archive, and xar does support LZMA as a compression method - it might be worth to check with Apple's engineers if there's a way to leverage that.

On a related note, tvsutton disassembled the finalize binary with Hopper, and a quick check shows that it performs a few tasks that may be problematic when the pkg is installed with no one logged in, or when installing to a non-booted target volume:

• The removing of legacy plugins in the user's home directory won't work when the package is deployed with no one logged in, and it doesn't respect $3.
• Likewise the creation of ~/Library/Preferences/Macromedia/Flash Player/version.txt will create it in an unexpected location, and doesn't respect $3.
• There appears to be a typo with two joined strings in the array of legacy plugins: @"Flash Player.plugin", @"Flash Player Enabler.pluginShockwave Flash NP-PPC", @"flashplayer.xpt"
• It's a little hard to follow the disassembled logic, but the open of installerRedirect.html probably won't perform as expected when the package is deployed.

[Matt_Talistu]

Hi Per,

Thanks for your observations. I will investigate whether we can use LZMA for the pkg compression instead of compressing the plugin ourselves.

Your concerns about the finalize binary should not be an issue. As I mentioned before, the pkg is also included as part of our .app installer. We do some checks in the finalize utility to only execute those user-dependent steps if a user is logged in and we are installing to the root volume. If the installation is to a non-root volume or no user is logged in, the finalize utility will just decompress the plugin.

That is a good catch on the typo in the string array. I will make sure that gets fixed.

[Don_Montalvo]

Soon after the initial release, we will look into implementing some of the other changes that were mentioned, such as moving the Install Manager to /Applications/Utilities/Adobe/ and consolidating our logging across the installers

It may be best to put it into /Library/Application\ Support/Adobe/ as per Apple guidelines:

https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/App...

Application Support directory

The Application Support directory is where your app stores any type of file that supports the app but is not required for the app to run, such as document templates or configuration files. The files should be app-specific but should never store user data. This directory is located inside the Library directory.

Never store files at the top level of this directory: Always put them in a subdirectory named for your app or company.

If the resources apply to all users on the system, such as document templates, place them in/Library/Application Support. To get the path to this directory use theNSApplicationSupportDirectory search path key with the NSLocalDomainMask domain. If the resources are user-specific, such as workspace configuration files, place them in the current user’s~/Library/Application Support directory. To get the path to this directory use theNSApplicationSupportDirectory search path key with the NSUserDomainMask domain.

[ShaneDPalmer]

I totally agree with Don.

I would love to see Adobe start utilizing Apple guidelines for ALL of their applications.  It would go along way towards cleaning all of the cruft that Adobe puts in the /Applications and /Applications/Utilities folder.  Installer and Uninstaller tools should not be in locations that the average user will look at daily.  It only tempts them to "fix" the work that you have done getting their computer set up just right and you also get people that think they know how to clean up the other cruft that Adobe creates and will often break something.  These situations in turn give them a reason to demand admin rights when they do try to "fix" and clean up things and find out that they don't have admin rights.

The worst is when Creative Suite puts installer and updater files in the /Applications/Adobe/AdobePatchFiles/ folder that I often have to manually clean up later to save space and reduce clutter.  I know this isn't a Creative Suite discussion but since moving the Install Manager is an option on the table for later Flash releases Adobe needs to start somewhere with adhering to Apple guidelines and this is a good place to start since it is a small application with a fairly simple install process.

Also, I would like to see you start using proper plist files, in the correct locations of /Library/Preferences (for system wide settings) or ~/Library/Preferences (for user settings), for all Flash settings or at least begin with the important ones like enabling and disabling automatic and/or silent updates.  This gives you more, and possibly better, management options using enterprise tools like the Casper Suite to push out MCX settings or Configuration Profiles instead of relying on the /Library/Application Support/Macromedia/mms.cfg text file.  This would also give you a chance to start weeding out the Macromedia name that still exists in some of the files and folder paths because its only been close to 10 years since you bought out Macromedia!

[Don_Montalvo]

ShaneDPalmer wrote:

I totally agree with Don.

I would love to see Adobe start utilizing Apple guidelines for ALL of their applications.

This is actually the root of the problem. Adobe engineers are "winging it" instead of taking the time to study Apple's well defined standards/guidelines.

I mean the "engineer" title implies the person has the capability to read and abide by established standards, which would eliminate much of these duct-tape "fixes" (house of cards effect).

[ShaneDPalmer]

Another rule to add:  Always be sure that posix permissions on the pkg are set correctly.

Most pkg installers are created with read/write permissions for the owner and read privileges for group and everyone (i.e. rw_r__r__ OR rwxr_xr_x) but sometimes we are given installers (the Shockwave 12.0.4.144 installer released yesterday, hint... hint...) that are set to No Access for group and everyone (i.e. rw_______ OR rwx______).  This can cause problems with some enterprise management tools, like the Casper Suite, that don't get caught until you see a bunch of failures in various logs.

Even though this already appears to be correct with the beta Flash installer I just wanted to explicitly state this as another rule that should be adhered to.  It can be easily corrected by IT once it is noticed, but it is not always noticed right away until you see errors pop up in installation logs.