Merging packages in Composer

[rongrw]

Hi guys,

Is it possible to merge multiple packages into a single package in Composer? We are currently packaging a software product which has a number of additional, optional components. It would be nice to package the optional components seperately and merge them into the base package as required.

Cheers,

Ron.
**
Author : Ron Grunwald
Position : IT Customer Support Officer
Organisation: Edith Cowan University
Faculty : ITSC / ITSS
Location : Joondalup, Western Australia
Email : ron.grunwald@ecu.edu.au
Alt. Email : rongrw@yahoo.com.au
Telephone : 6304 3629
Mobile Ph. : 0439 016 746
**
"They who play with root will eventually kill tree !"

[tlarkin]

I did this for MS office several years ago. You do the full snap shot thing and build your package. You then convert your dmg to read write. Mount it and drag specific folders paths into composer and then chop it up into separate packages. For example, I had a package called office required. In office required was every folder in /Library/Application Support. Also, any folder outside the /Applications folder. Then any shared folder with in the MS Office app folder. That was all the required and shared components. I then dragged each application itself (word, excel, so on and so forth) and created an individual package for it as well.

I also have done the same thing with iLife. I capture the whole thing, then take out things like Garage band extras and so forth. package them up separately and give users the optional installs via self service.

I pretty much follow the same model. To list it out to give you an idea of the work flow it goes pretty much like this:

1 - create full snap shot package
2 - convert to read/write and edit package, mount DMG on desktop
3 - Create a "required" package which is all shared folders and support folders of said software suite by dragging them from the disk image into composer
4 - then bundle each app separately
5 - If applicable, pull out any extra installs (plug ins, fonts, etc) and package them as an "Optional_install.dmg"

Then upload all my packages into Casper admin and create policies for them.

So, to merge packages you could do just the same. Mount each package and drag it's contents into composer and then create a new package.

-Tom

[rongrw]

Hi Tom,

Thanks for your reply. Unfortunately the procedure of mounting the (.dmg) files, dragging them into Composer and combining into one package didn't work for me. For one, when you drag contents from a mounted (.dmg) into Composer it keeps the full path starting from /Volumes/<volume_name>/
This can be overcome, but then to merge the contents of the different volumes doesn't take effect. For example, if I drag the folder "Library/xyz" from /Volumes/pkg_1 into the "Library" folder at the root level in Composer, it doesn't copy.

I've also come across a software product "DropDMG", which looks very promising. Unfortunately it also appears to not be able to merge multiple (.dmg) contents into a single file. This is probably due to my unfamiliarity with the software, so I've sent an email to their tech. support.

Cheers,

Ron.

[rmanly]

"It would be nice to package the optional components seperately and merge them into the base package as required."

Why?

There are tons of other ways to handle multiple configuration options if you don't want to give everyone everything. Make a new config in Casper Admin, use Self-Service so people can get the optional components they want, or use Smart Groups.

[talkingmoose]

User Casper Admin's Compile feature to merge .dmg files. It adds a little cruft that you may or may not want (jamf.log and Casper receipts) but can remove using Composer.

This won't compile .pkg installers that require a valid Mac OS to be installed first such as Microsoft Office.

[rockpapergoat]

start using luggage to generate your packages, and the process is easy. the makefiles are easily portable, diffable, and ready to drop in version control. the resulting pkgs are more flexible than the dmg "packages" created with composer, as they can be used in other non-casper workflows (deploy studio, puppet, munki, etc.).

https://github.com/unixorn/luggage

[tlarkin]

I was also going to suggest the compile feature in Casper admin as well. However, I think that if you have specific package priorities it may have conflicts with a compiled package in Casper Admin. Plus it will not be recognized as a package, it will be recognized as a compiled configuration, at least I think.

Testing it out now. I will also test out my composer method once that is done.

[talkingmoose]

When compiling .dmg files with Composer the problem shouldn't be with priority but rather with whether or not they contain the exact same files. If they do contain files with the same names then the last installed will definitely trump any others. However, .dmg packages really shouldn't have the same files. If they do then the admin may need to revisit his packaging strategy.

So long as the compiled .dmg is moved from the CasperShare/CompiledConfigurations folder back into the main stream packages area then Casper should treat it as any other .dmg package.

[tlarkin]

When compiling .dmg files with Composer the problem shouldn't be with priority but rather with whether or not they contain the exact same files. If they do contain files with the same names then the last installed will definitely trump any others. However, .dmg packages really shouldn't have the same files. If they do then the admin may need to revisit his packaging strategy. So long as the compiled .dmg is moved from the CasperShare/CompiledConfigurations folder back into the main stream packages area then Casper should treat it as any other .dmg package.

Yes I totally agree with you, but scoping it via policy and not at imaging time will not be possible since you cannot add a compiled configuration as a package option in the JSS for a policy. Plus if you start to nest things and do a modular tiered support package priority will get in the way, as you cannot use compiled configurations as parent configs for smart configurations. Unless that has changed recently.

I am compiling some packages right now and it is almost done and I will test your theory by simply moving it to the Packages folder in the CasperShare. However, I don't think it will work unless I actually copy it back through Casper Admin and it recognizes it as a package. We will see in a few minutes I suppose.

[rmanly]

Someone give me a use case for this.

I am interested just because you are so interested.

[rongrw]

Hi Ryan,

Some of our buildings have flaky network connectivity and we see quite a lot of policy error notifications for installing software packages. So, but merging packages for various additional tools and plugins, I'm talking about Autodesk Maya in particular, into the main package we only have to worry about a single package rather than 5 separate ones.

Cheers,

Ron.

[tlarkin]

Ron,

Have you ever looked at caching the packages first or using HTTPS for resume-able downloads?

[rongrw]

Hi Tom,

Thanks for your reply. We haven't dealt much with cached packages, but we're well acquainted with HTTPS downloads, which really don't work well in our environment where larger packages are deployed. There have been many instances where, once a package download has failed, that package always fails to download thereafter. In fact we've had to enable the option "Force Distribution Points to use AFP/SMB instead of HTTP" for those policies, and then the package would download and verify correctly.

I still like the idea of bundling relevant software components into a single (.dmg) file because of its simplicity. The reason I thought "merging" a new (.dmg) into the base software product would be very useful is that it would save us from having to rerun the snapshot of the base product before adding in the new component and then closing the snapshot.

I've emailed the author of DropDMG and he is willing to consider adding a DMG merge option into the next release of their product.

Cheers,

Ron.

[tlarkin]

So I finally got around to testing this out and it seems to work. However, the method is a bit of a work around. I created a compiled configuration called "compiled install" then used the JAMF command line binary to install said compiled configuration on my work station here in my office.

bash-3.2$ sudo jamf install -package "compiled install.dmg" -path /Volumes/CasperShare/CompiledConfigurations/ -target /

It is installing as we speak, so I guess it can work. Not sure if it would show up as a package in the JSS unless you actually copied it out of the CasperShare and then renamed it and copied it back.

[tlarkin]

I just want to update that it indeed worked out just fine. Installed all the packages that were compiled. I am not sure if this will address your needs or issues you have with large packages on your network being deployed.

You could easily write a script that does this, since whenever Casper runs a script it does in fact mount the CasperShare along with it.

-best regards
Tom

[rmanly]

@rongrw Thanks for the reply. I get what you are doing now. Recreating that huge snapshot from scratch would be a PITA. :)

Incidentally I have seen this,

"There have been many instances where, once a package download has failed, that package always fails to download thereafter."

as well. When cacheing http://www.ableton.com/suite-8 I found that on the 2 or 3 machines that failed the only solution was to delete the failed download from .../Waiting Room/.

Maybe we need to bug this? Not that 40GB dmgs get cached all that often...lol