Posted on 10-03-2016 08:53 AM
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!
Posted on 10-03-2016 09:19 AM
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.
Posted on 10-03-2016 09:24 AM
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.
Posted on 10-03-2016 09:48 AM
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,
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.
Posted on 10-03-2016 10:35 AM
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"
Posted on 10-03-2016 10:56 AM
There's two main issues with snapshot packages:
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.
Posted on 10-03-2016 11:24 AM
@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?
Posted on 10-03-2016 12:12 PM
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.
Posted on 10-03-2016 12:14 PM
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.
Posted on 10-03-2016 12:21 PM
@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!