Mostly OS X Admin Related
Monthly Archives: December 2015
Recently I was asked to deploy an updated Adobe AIR-based application. I asked the requestor if they’d like the most current version of AIR (version 220.127.116.11) to go along with it and the response was “Sure”. I installed the application and imported it into Munki with a straightforward munkiimport of the application itself.
Later in the day I received a call back from the requestor letting me know the newly updated application crashed instantly upon launch. Digging further, I discovered that when the application was launched, the following happened:
- Air Application.app/Contents/MacOS/Air Application
was renamed to
Air Application.app/Contents/MacOS/Air Application_32
- A new Air Application.app/Contents/MacOS/Air Application was generated
Upon further examination, this appears to be a result of AIR 20 becoming a 64-bit runtime. An Adobe support article (Issues while downgrading from AIR 20 to a lower version on Mac OS X) says the following:
After you install AIR 20, any previously installed AIR app using the Shared Runtime that is launched gets updated. So the app’s launcher code will now be a 64-bit binary. The previously used 32-bit launcher gets renamed with a ‘_32’ suffix.
This provides an interesting issue for system administrators:
- The bit architecture of an AIR application is a reflection of the version of AIR (either pre-AIR 20 or AIR 20 and beyond) that was installed when the AIR application was installed if the application was installed from an “.air” archive. Note an “.air” archive requires AIR to manually be installed on the target computer before installation of the “.air” archive
- The bit architecture of an AIR application is a reflection of the developer’s computer used to package the AIR application if the application was a “Native Installer”. Note a Native Installer can include AIR
- If the installed version of AIR is upgraded from a previous version of AIR to AIR 20, an existing AIR-based application will attempt to generate a 64-bit executable in the “MacOS” directory
- The default POSIX permissions of the “MacOS” directory of an AIR-based application are 755 (i.e. only the owner can modify the directory) and the default POSIX ownership of an AIR-based application is either root:admin (if a Native Installer was used and no version of AIR was previously installed) or the default user and group of the user who installed the application. These do not work well in a managed environment
- If the application cannot rewrite its executable, it may prompt for administrative rights (and refuse to run without them) or just crash (I’ve seen both)
Previously-distributed AIR applications that may have functioned normally under AIR 19 may not initially run properly with AIR 20. Options to handle AIR 20 might include:
- Repackaging 64-bit versions of AIR-based applications. These would need to be generated by installing AIR 20, running a 32-bit AIR-based application, and then capturing and repackaging the resulting application
- Reinstalling AIR-based applications following the installation of AIR 20, however this will only work for .air-archive based installations
- Giving users write permission to the “MacOS” directory for all AIR-based applications, however this is a last resort
Also notable is that applications repackaged on a computer with AIR 20 may not function properly on computers where an earlier version of AIR is installed. This is due to the 64-bit executable being packaged under AIR 20 and being distributed to a computer with an earlier 32-bit version of AIR.
To determine what architecture an executable is, use the “file” command:
$ file /Applications/Zinio\ Reader\ 4.app/Contents/MacOS/Zinio\ Reader\ 4 /Applications/Zinio Reader 4.app/Contents/MacOS/Zinio Reader 4: Mach-O 64-bit executable x86_64
Ensure AIR-based applications are 64-bit ready so they continue to work when AIR 20 is installed.