Packaging Software/Plugins - Composer = Bad?

ChickenDenders
New Contributor III

Hello!

We use JAMF to manage our Graphics department. Most of the packages we build are plugins for After Effects. I've heard conflicting suggestions from colleagues/JAMF Nation discussions about the best method of packaging everything. We are in the middle of rebuilding our entire package database for a new push to OSX 10.11.6 (From OSX 10.9.5), along with updated versions of all the artists' applications and associated plugins.

In the past, I have used Composer to snapshot and package everything we are deploying. This caused a few issues with file permissions - my own fault, but we're at a point where everything has (mostly) been running smoothly since the initial deployment last year.

Now, as I've learned more and more about JAMF deployment, I get the impression that using Composer snapshots to create packages is no good. The alternative that has been recommended to me is to cache the actual installer for the app locally, usually in /private/tmp/, and then execute with a script afterward. This is the method we currently use for After Effects and Maya, but not yet for their associated plugins or other products.

I have also read about, but not used (other than for the creation of our OSX Image) the AutoDMG/PKG application. Is that as simple as dropping the installer into it, and then deploying what is spit out? To be honest, I'm only familiar with Bash scripting on a very basic level.

Thank you!

9 REPLIES 9

bvrooman
Valued Contributor

There's no one way to create packages; it depends completely on the app.

I build a lot of one-off packages with Composer (random apps' license files, command-line binaries, McAfee agent nonsense, assorted files that I need to shove somewhere on a disk), but the majority of my packages come either from autopkg or the vendors themselves. Adobe apps I package almost exclusively with the Creative Cloud Packager.

That doesn't make any of those options bad – it just means that none of them are optimal for every situation. There are a lot of good videos from previous JNUCs and MacAdmins conferences online that cover packaging; it might be worth reviewing some of those to answer your questions and see some examples.

thoule
Valued Contributor II

The problem with Composer is not a technical one. It can appear to build an installer with a snapshot so easy anyone can do it. However, you're left with multiple problems including permissions, extraneous data, and overwritten data.

If you are aware of those pitfalls, then you can use Snapshot feature to create your package. You just need to be aware, that sometimes you need to add data to a configuration file instead of overwrite it, and fix permissions. And just in general be aware of what every item there is doing.

chris_miller
Contributor

I too use Creative Cloud Packager with success. That being said, I've also used composer quite a bit and thoule is right, you have to be careful of the permissions, etc. How are the plugins managed? Aren't they in a local user folder? If so, Composer should work after the main file has been installed and opened by the user. You might try letting them grab their plugins via self service after opening the new app. I would normally encourage you to make sure that Fill User Templates and Home Directories is checked in Casper Admin, b24422c8fe5e4d4e8b252f1689aa0315
but that seems to be greyed out since updating to 9.6. But that would make sure the plugins push down to a specific local folder.

Either way, I'm really interested in what you get working. Please keep updating the thread.

ChickenDenders
New Contributor III

Thanks for the responses! I'm aware of the problems that can arrive from using Composer. With all the problems I've had to troubleshoot, I had a much better idea of what to look out for when recreating all my older packages through Composer. Much cleaner this time around.

@bvrooman - That's a good idea, checking out some of the older conferences. Everything I know now was something of a crash course introduction by the old Mac Administrator before he left. I have not tried bringing vendor installers straight into Casper Admin. Most of our software uses floating licensing, so a simple pointer file dropped after the fact will let me skip most of the configuration needed.

@csm0004 - Plugins are typically dropped in /Applications/Adobe After Effects CC2015.3/Plug-ins/, so they're pretty easy to manage. Sometimes they go to /Library/Application Support/Adobe/Common/Plug-ins/7.0, but that's just as easy to get to. The few plugins that do require things to be installed in the User's home folder, we can scope that out to install on login with a policy frequency of "Once per user per computer"

davidacland
Honored Contributor II

There's two main issues with snapshot packages:

  • You end up with the files you want, plus a load you don't
  • If the original installers run any pre/post install scripts, you only capture the end result of those scripts, rather than the process they go through

As long as you're being surgical about it, and only deploying files that you know are needed, with the right permissions etc, all will be fine.

Personally, I only use snapshots for investigative purposes.

ChickenDenders
New Contributor III

@davidacland - I think I've got a good handle on what items to prune out after taking a snapshot, but I know I can be creating packages more efficiently. If you aren't using Composer to create packages, then what do you do instead? Drop vendor installers straight into Casper Admin? Run them through AutoPKG to do whatever it does?

ChickenDenders
New Contributor III

Looking at this thread here, it seems like there are a few people that recommend dropping the app installer straight into Casper Admin, and are pretty opposed to any use of Composer other than for analytics.

davidacland
Honored Contributor II

Ah, got it.

I still use Composer, just not the snapshot functionality to create packages.

If the vendor supplied installer is a .pkg, I add it straight into Casper. If it needs modifying, I use a combination of either supplementary packages, scripts and/or configuration profiles.

ChickenDenders
New Contributor III

@davidacland - Thank you, I'll do some experimenting with that today. For anything that requires supplementary packaging, are you just grouping these packages together by adding multiple packages within a policy? Or is there a better way to do it?

Thank you!