App Packaging advice

Hi and welcome to JAMFNation and Mac management.

Your question is valid and not at all stupid, and there are a number of ways to handle such scenarios.

So, something that isn't very obvious to people new to Casper Suite is that its not always necessary to have a single package installer for a given software. You might think it needs to be that way, but it really doesn't. For example, you could have a package that installs the software by itself built as a package (pkg) and another one that only deploys user preferences for that software built as a disk image (dmg)
If they're split up this way, you can just add them both into the policy that deploys them, making sure to use FUT (Fill User Template) and/or FEU (Fill Existing Users) options for the dmg one with user preferences. With either of those options, as long as the preference is captured in an account in a default path like /Users/username/Library/Preferences/ it should be fine to leave them as captured and build them out as a disk image. Again, the FUT and FEU options will be important. If you fail to check those on, then the Casper Suite won't know what to do with it, so will create an empty shell of an account folder with the /Library/Preferences/com.company.someplist.pist file dropped in it.

As for the process of building packages, what you'll find is that a lot of experienced admins here don't use Composer's snapshot mechanism. If at all possible, use vendor supplied pkg or mpkg installers. Trying to capture them can cause issues because any embedded script logic isn't going to be captured in Composer, and you sometimes end up capturing stuff that is being randomly updated or created by the OS, and not the installation. So you need to be careful with that.
That said, there are unfortunately times when only a Composer capture may fit the bill, for example if you come across those wonky InstallerVise or java based installers (ugh!) that can't be deployed as-is.

There's plenty to know in the realm of packaging, and there a lot of good tools out there you can use in conjunction with Casper Suite, like AutoPkg for example. Hope the above at least helps answer your question.

I'll second mm2270's approach. Welcome to the Mac Admin community. We are a friendly group that is usually ready to lend a hand.

The reason I second his approach is that yes...it is usually in your best interest to use a vendor's package when possible and then use a second package to deal with user preferences or organization file structures, corrected permissions or whatnot. Many times if you don't use a vendor's package, then users won't get everything the way they are supposed to and the software starts acting wonky.

That being said, I have seen some sloppy vendor installers that leave horrible permissions on things that I don't like or our org doesn't like. I also like to include all optional content or documentation from a vendor in a standardized place on our machines so I don't get tickets asking "what about the optional content or fonts" later.

Consider a tool like Pacifist (http://www.charlessoft.com) if you wish to see what a PKG installer is going to do before it does it.

This board is definitely a Mac admin's friend so feel free to share any questions or discoveries.

@mm2270][/url wrote:

As for the process of building packages, what you'll find is that a lot of experienced admins here don't use Composer's snapshot mechanism. If at all possible, use vendor supplied pkg or mpkg installers. Trying to capture them can cause issues because any embedded script logic isn't going to be captured in Composer, and you sometimes end up capturing stuff that is being randomly updated or created by the OS, and not the installation.

Snapshots are also a problem if you capture changes to existing files (merges, etc.).

*I sent a request to Glove And Boots for a "10 reasons why snapshots are dangerous" video:

http://www.youtube.com/watch?v=flRg9Q1d3kY
http://www.youtube.com/watch?v=EOar7toRw80*

This isn't strictly a packaging question, you're talking about a pref file in a users home directory. Those can sometimes be managed at the computer level with something like MCX or a (configuration) profile depending on your preferred delivery method. There's a book which predates profiles but lays a great foundation of knowledge when it comes to the management framework profiles builds upon: http://www.apress.com/9781430229377
@mm2270's recommended technique of having Casper 'filedrop' for you may cut the mustard in many cases, but there are other ways available for certain apps. Good luck,
Allister

Thanks everyone! This has been really helpful!

It depends on the app. Some apps look in both "~/Library/Preferences" and "/Library/Preferences", but defaults to creating prefs in each user's home folder. If that's the case, than the easy approach would be to place your shared preferences in /Library within your package.

If that's not an option, than my approach would likely be to create a Launch Agent that writes the preference to the users's home folder on login. You can build logic into the the script the Agent runs to exit if it finds the pref file already there (thus you are setting the prefs once, rather than enforcing them, that is of course unless you want to enforce them).

A caveat to all of this, I don't use Composer, so I have no idea how feasible any of this would be to setup within that tool. As others have stated snapshots have their issues, not the least of which (aside from the loss of logic others have mentioned) is that you may end up installing hardware-speciifc (or OS-version-specific) components on contrary configurations

@c0n0r][/url wrote:

As others have stated snapshots have their issues, not the least of which (aside from the loss of logic others have mentioned) is that you may end up installing hardware-speciifc (or OS-version-specific) components on contrary configurations

A good example, a VPN client checks HW specs and either installs, or doesn't install, a kext. Snapshots eliminate logic built into vendor provided packages. Dangerous...

I pretty much wrap all of the packages that don't just drop in casper. If it requires to be installed at boot time especially and i have a launch daemon and script that will install them. I had so many problems with checking the box to install at boot time in imaging. Adobe AAMEE packages are much more reliable when wrapped from my experience too.

I install the vendor supplied PKGs then the settings post via MCX or scripts.

While we use Casper for a lot of it's management tools (FileVault key escrowing especially), and deploy some scripts and management-related packages, but we do not distribute software for the end user through it. We have our own internal distribution methods. But we pretty much have to touch every package going into distribution. We apply a couple of security settings, as well as put in our Casper script to ensure that the user is under management each time they install a package. Not to mention the customization of the installer UI elements (welcome screen, success screen, installer background, etc.).

Nessts - Could you please elaborate on your process to "wrap" all the packages? Thanks

in short. If a package needs to install on a live system, or is an adobe package, I wrap it. put the pkg payload and install it to something like /tmp or /.installfiles. the postinstall then checks to see if the target is / or not. if not its likely being done at some sort of imaging time, therefore it installs a launch daemon and an install script to the OS, then at boot the install script is smart enough to know whether it needs to wait for something else, for instance a java install to finish or exist, or Adobe CS to install before the font management tool etc. Then when appropriate it kicks off the install of the package. We can embed things like cocoa dialog for status and user input etc.

Is that enough? I can expand if you have specific questions.

@Gallagher There are a couple of different approaches to rewrapping packages. The problem is really that you have to come up with a customized solution based on your particular environment, and the specific application. Are your users admins or standard users? Do you support users that have multiple partitions, can they have a separate boot partition and application partition? Do you need to support a net boot environment for pre-imaging, or will installs only happen on live environments? Are you using a device management agent to push silent packages or are you building for an interactive installation with an active console user?

Personally, I try to avoid deploying the package just to have it installed via command line. Not only does that feel like not letting Installer do it's actual job, but it makes the user sit through a long copy process before even starting the actual installation (not a big deal with say Firefox, but when you start repackaging stuff like Office or CS6 and have multiple GB files, copy time is a pretty big negative user experience). Rich Trouton, over on his Der Flounder blog recently posted a great article about repackaging, listing the original package as an additional resource, so you at least avoid the copy time.
http://derflounder.wordpress.com/2013/11/03/re-packaging-installer-packages-with-packages/

Another option (especially if you have non-admin users) is to use LaunchD (since everything it runs is exited as root, with no input from the user needed). I know of several folks that keep an active LaunchD process that automatically runs any script or package placed in a specific folder. You just drop the original package (or your repackage) into that folder and at the next timed interval (or next reboot, depending on how you setup the LaunchD job). You could even script some kind of verification that the installation was successful (specific for each app, check if the app is present and any related agents/processes/etc are operational) before removing the package (if not present, you likely want the installation to repeat), have it write a log or something that you can suck up with Casper.

The TL:DNR version is that there is no one "right" way to handle every package, each vendor, if not each software title, has their own idiosyncrasies that you have to account for.