Poorly packaged OS X BESAgent installer - RFE Please Vote!

Ideas
1

This RFE addresses a major issue we’ve been seeing for a long time related to how poorly built the BESAgent installer package is for OS X.

We created this RFE over a year ago:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=45759

2

(I’ve moved this to the “Enhancements” category)

1 Like
3

As I can’t see the RFE can you tell me whats bad about it?

1 Like
4

Here is the description from the RFE:

The BESAgent .pkg installer is poorly built and does not follow best practices for software packaging on Mac OS X.

  1. The payload permissions are set incorrectly. Instead it relies on
    the post install script to set permissions which is unnecessary.
    This causes numerous issues with package portability and for using
    the package receipt database to repair package permissions using
    Disk Utility.
  2. The package scripts do not use proper package variables and
    environment checks meaning they will not work unless installed on
    the currently booted volume.
  3. The .app payloads (TriggerClientUI, BESAgent) are marked as
    relocatable when this should never be the case because the client
    will not function and the post install script does not support
    alternate volumes. This is a major issue because it causes the
    installation to fail when a matching bundle ID is found and the
    payload does not install causing the post install script to fail.
5

The latter (relocatable) is known but I did put that it wasn’t relocatable in the install scripts and put every element as root/wheel but for some reason the installers won’t keep that information. Anyone an installer expert out there?

It could be that we are using an older version of XCode that has some bugs or that we are using PackageMaker to make the package and not XCode projects but changing the latter is difficult.

6

Alan,

With PackageMaker, the best method I’ve found is to change the actual files on disk to match the permissions you want set by the package. The permissions should then stick in the PackageMaker interface.

The relocatable setting is in the package settings distribution file, not the install scripts. If you open up the Distribution file it is clear that both the TriggerClientUI and the BESAgent components are still marked as relocatable.

In our environment we don’t need the client settings and masthead logic in the pre/post install scripts so we end up expanding and modifying the package scripts but because of the incorrect permissions set by the package we keep the permissions fixes and add the ${3} script variable to specify the target volume. The other parts of the pre/post install scripts really aren’t doing anything that complex so it could easily be adapted to work on un-booted volumes.

I understand you may have dependencies with older versions of Xcode and PackageMaker but I’d highly recommend switching to the pkgbuild and productbuild utilities for creating OS X packages.

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html

1 Like
7

Thanks, that’s a big help. The relocation part has bothered me so its interesting that only those 2 of the 4 internal packages have the relocation turned on so I’ll try and fix that. The permissions may be interesting due to the build system but that gives me clues at least.

1 Like
8

I believe it is because those two components contain the application bundles. So by design, during installation it searches the filesystem for items with matching bundle ids and attempts to update them in place, wherever and on whichever volume they reside.

We frequently run into issues where there may be an old copy of the installer or the application bundles on a connected flash drive or buried deep in a backup volume and the relocatable components won’t actually get installed to the proper location which causes the postinstall script to fail, causing the entire package to fail.

1 Like
9

Hi Alan,

I recommend that consider a more programmatic way to create your packages, it should make your life much easier in the long run.

Matt’s recommendation on pkgbuild and productbuild is a good one. You might also want to consider using The Luggage or Whitebox Packages, which also has a command line tool.

References:

Home unixorn/luggage Wiki

The Luggage
http://luggage.apesseekingknowledge.net/

The Luggage: An Introduction - graham gilbert
http://grahamgilbert.com/blog/2013/08/09/the-luggage-an-introduction/

WhiteBox - Packages (Iceberg is the older project from the same developer)
http://s.sudre.free.fr/Software/Packages/about.html

Using pkgbuild and productbuild

The Grey Blog: OS X: Creating Packages from the Command Line - Tutorial and a Makefile - Part I

The Grey Blog: OS X: Creating Packages from the Command Line - Tutorial and a Makefile - Part II

Sign Packages with Luggage - Just another tech blog
https://clburlison.com/sign-packages-with-luggage/

Tenets of Packaging
http://macadmins.psu.edu/wp-content/uploads/sites/1567/2013/06/psumacconf2013-Practical-Packaging.pdf

Thank you,
Ben

2 Likes
10

Thanks @bengross
These will help in the long run. This is a lot cleaner than the pmdoc method of PackageManager. Now to just figure out how to fit this into the build system :slight_smile:

1 Like