A follow up from today’s earlier post: some commenters mention that the disk image they downloaded contains a package like “normal”.
I’ve found at least five versions of the 11.5.502.146 installer:
All of these were downloaded today. Which version you get seems to depend on which browser you use!
Safari may lead you to one (if you decline the suggestion to also install Chrome you get a different one); Chrome returns another, and Firefox returns still another! And if you register to redistribute Flash and use the special URL you are given if/when you are approved for redistribution, you get yet another version.
And yet none of these are simply Apple packages. Sigh. They are either disk images that contain an application that contains a package, or disk images that contain an application that downloads another disk image that contains an application that contains a package.
On a related note, I recently watched Inception.
Managing OS X 
“And yet none of these are simply Apple packages. Sigh. They are either disk images that contain an application that contains a package…”
This has been the standard Adobe behavior for a very long time now. Has Adobe ever offered a straight Apple installer package for Flash Player?
Also, I just tried downloading FP using Safari, Chrome and Firefox. All browsers linked me to: http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_11_for_Mac_OS_X_10.6_-_10.8
Not sure, but could it be a region / CDN thing? I’m in Japan, so maybe that’s why I’m seeing different behavior.
No they haven’t not for a long time and that’s really a major problem with them (and pretty obvious evidence of a terribly run company internally if you think about it!) Its beyond evident multiple teams work on packaging internally and all of them have they own way and none of them follow best practices for either the OS X or Windows platform. It’s almost as if they treat it like they unlike anyone else including the companies who created the OSes themselves know how to package apps right and to hell with companies having specific installation mechanisms for their platforms.
FWIW, trial and error led me to:
chrosx[ad]_d[yn]
Where:
a=accepted Chrome install
d=declined Chrome install
y=yes, set Chrome as default browser
n=no, don’t set Chrome as default browser
But it’s still a mess. This is one area I’m good with not having feature parity with Windows.
This is why I just use http://ftp.adobe.com from the Terminal to get my Adobe software. Much simpler, and you always get the simplest form of their stuff.
Argh…wordpress converted the url to ‘http://’ – I didn’t put that there. I just navigate around ftp[dot]adobe[dot]com from the ftp cli tool.
I don’t see a recent version of Flash at ftp://ftp.adobe.com/pub/adobe Do you have a complete path?
You’re right….it would seem that Flash Player is one of the few things they don’t post there. I’ve been so accustomed to getting my Adobe Reader updates that way that I just made the (erroneous) assumption that all of Adobes wares were posted there. Sorry for the false lead!
[…] Yesterday a new version of Flash Player was released and with it came some more challenges regarding the Flash Player installer. Greg Neagle has compiled some information regarding the new installers which you can check out over on his blog. […]
It appears that using:
http://www.adobe.com/products/flashplayer/distribution3.html
will get you a page with a list of all of the available installers?
The URL doesn’t seem to be effected by using Safari, Chrome, or Firefox.
The DMG does have the “Install Adobe Flash Player.app” which contains the PKG file.
Using the -install option on the executable in Contents/MacOS appears to work.
And if you want to have yet another way to get Flash Player, use the Archived Versions Page at:
http://kb2.adobe.com/cps/142/tn_14266.html
This will get you a zip archive containing debug- and non-debug versions and a lot of other stuff.
You are not allowed to redistribute those, however.
and it still fubars up the system preferences update if you install via the package directly and not all the chrome.
Really? We have to go through this again?
sigh…getting mah beatin’ stick.
I bet inception made more sense than this issue.
On a related note:
Shockwave_Installer_Full_64bit_11.6.8.638 now also contains a postflight script which launches a GUI application (possibly as root) to ask for installation of Google Chrome. At least it is one single file, and not 6 different ones.
Steps to get rid of that postflight script:
$ hdiutil attach ../Vendor\ Downloads/Shockwave_Installer_Full_64bit_11.6.8.638.dmg
$ pkgutil –expand “/Volumes/Adobe Shockwave 11/Shockwave_Installer_Full.pkg” Shockwave_Installer_Full_64bit_11.6.8.638_fixed/
$ cat > Shockwave_Installer_Full_64bit_11.6.8.638_fixed/shockwave11.pkg/Scripts/postinstall
#!/bin/bash
exit 0;
CTRL+D
$ pkgutil –flatten Shockwave_Installer_Full_64bit_11.6.8.638_fixed Shockwave_Installer_Full_64bit_11.6.8.638_fixed
…ala Citrix’s installer from hell (circa 2006).
Adobe’s Flash Player installer team manager hires cheap and delivers cr@p.
Don
If you’ve already gone to the trouble of initially deploying Adobe Flash via, say, Munki and you have then pushed out a script to install Flash Player from the .app that Munki drops in the /Applications folder, then for a point update like this one it seems that everything works OK if you download the Flash installer from http://www.adobe.com/products/flashplayer/distribution3.html (Thanks for the link, Jeffrey), open it, extract the .pkg installer from the Adobe .app installer and then push that out with Munki.
As the preference pane and the other things that get set up when you run the installer are already in place, this will update the plugin and everything seems to work. This saves you from having to repeat the initial installation process of pushing the .app installer to Applications and then bumping the version of your payload-free package with the postflight installer script.
From the Adobe Distribution Page…under the section Background Update Resources for Mac and Windows…
Does anyone know what the fb_background_update.cab is for and how to use it?
The Adobe distribution page lists it as applicable to the Mac platform, and the file does contain some items labelled as being for the Mac, but I have been unable to find out any other information on how to use this.
Update: I’ve found some info on how to use this on Page 19 of this guide —
Click to access flash_player_11_5_admin_guide.pdf
Is anyone using this method of updating Flash on their fleets?
i’m still not completely understanding the reasons why we can’t/shouldn’t deploy the .pkg that’s inside the ‘.app’.
i fetch the DMG from the same distribution3.html page that the above chap mentioned and deploy the PKG within. works fine as far as i’m aware. my students/staff are content.
am i missing something or setting myself up for a massive issue?
You’re going to have problems with the auto-update mechanism (basically, it’s going to crash instead of checking for updates)
Try going into System Preferences > Flash and check for updates to see what I mean…
Not too much of a problem, if you are not going to do updates via the Control panel, and instead run out the package from within the .dmg from a future update.
Make sure the prefs pane is disabled for users by deleting it, or moving to an Admin user’s PreferencePanes folder, perhaps.
Plus also add the following file
“/Library/Application Support/Macromedia/mms.cfg”
In this plain text file put the following two lines —
AutoUpdateDisable=1
SilentAutoUpdateEnable=1
Here’s yet another place to download the full installers….
http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html
Hi Admins,
I work on the Flash Player engineering team and over the last few months we’ve been working on creating an official .pkg installer for admin/it installs on the Mac.
We’re at the point were we believe it’s in good shape but we want to get feedback from experts like yourselves before releasing it publicly. If you’d be interested in trying a private beta release, please shoot an email to ccampbel@adobe.com.
I’ve also got a question regarding installation scenarios. We’ve been using the article titled “Commandments of Packaging in OS X” (http://bit.ly/1825Nbw) as a guideline but one of the items refers to “Check that your package works when no-one is logged in”. Is this a typical scenario? Can someone explain how this would work so we can try testing this internally?
Thanks,
Chris
Hello Chris,
I’d love to get onboard to help out so Adobe can get this right. I spend a lot of time dealing with working around the flash installer in managed environments and to have it as a straight-up installer package would really simplify things.
re: installing when no-one is logged in. Managed software deployment workflows have the ability to install software when a machine is idle, at the loginwindow. The managed software agent will perform a regular check of the software repository and if an installer or an update is tagged as a silent and mandatory install, then it will be installed while the machine is at the loginwindow. and no-one is logged in.
I would suggest visiting some of the larger Mac environments to get an understanding of how software is deployed to thousands of users. Different tools are used in different environments. If the PKG/MPKG is zero-touch, meaning can be pushed remotely to logged off Macs, everyone wins. Else, consider the time/effort in dealing with the Macs that are not logged off, users having open/unsaved documents, etc.
Don Montalvo
Would love to be part of testing the beta of the flashplayer .pkg installer.
I’ve been waiting for Adobe to get one of these together for a long time, we’ve having been scratching together other solutions for far too many years.
The specific requirement for running at the login screen, or without a user logged in, is for several reasons —
1. To make sure an installer is able to update all components without hitting roadblocks due to programs or processes still running.
For example, if Safari or other browsers are running, then Flash often (though not always) will either not update or not install.
Not that it should be balking at this situation anyhow. It should be able to handle updates in place without requiring a user to quit programs, logout or reboot.
2. Updates and installs are often done on fleets or labs of machines after hours to reduce the impact on users.
3. We can never guarantee a user will be logged in at all times when an update or installer is pushed out.
4. We want updates and installers to run in ‘batches’, so when logging out or shutting down is the most obvious time to run these.
5. Once an installer or updater is started, we don’t want users to launch other programs that might affect the update, hence best done when logged out
For the same reasons we require installers to work when no one is logged in, we also desire that no user intervention is required at all when installing software or updates.
We don’t require or desire users to change options on the software we push out to labs and fleets. Specifically, the decisions made to auto update or not are decided across the board for all our machines.
We also want to be able to turn off any other auto-update notifications when ever possible.