When you open Composer for the first time, you will be greeted by a dialog offering a choice of different ways to capture the sources that will be used to create a package:
One way that you can create a package using Composer is by taking a snapshot of your system before and after an installation. Once the before-and-after snapshots are made, Composer compares them to figure out which files were affected by the installation, then copies them into a .DMG or .PKG that you can deploy using JAMF. There are three snapshot "methods" that you can use with Composer:
- Normal Snapshot - Composer creates a listing of all files that exist on the boot drive before and after the installation process, then compares them to find only the new files that have been created.
- New & Modified Snapshot - Like a Normal Snapshot, Composer compares files that exist before and after the installation. In this mode, it also takes into account any files that were modified between the two snapshots (it's unclear whether it does this by checksum, modified date, etc.). This means that, for example, you can install one program and change some settings in another, and both of these actions will be captured. If you install the created package on a computer, both the new software and the changes made to the other program will be installed.
- Monitor File System Changes - Rather than creating a full-disk snapshot before and after an installation, Composer will listen for FSEvent events processed through the filesystem, and will use these to figure out which files need to be captured. Composer warns that, in cases where a lot of filesystem activity happens quickly, this may not capture everything correctly.
In most cases, you will want to use a Normal Snapshot. A New & Modified Snapshot is useful if you need to make changes to some files or programs related to the installation, but this can also cause problems, as it captures all files that change between the start and finish of the process, including browser history, login/logout records (if the computer locks itself, etc.), and, most importantly, any changes made to the Keychain on your Mac. Luckily, it's possible to selectively remove certain files from a Composer snapshot before building the package, but it's very important to be aware of what's actually being captured using the New & Modified Snapshot mode. To be absolutely safe, you can use a separate machine for Composer (I use an old Mac Mini), or a virtual machine, to make sure you build packages in a "clean" environment.
Another option Composer gives is Build OS Package, which is exactly what it sounds like. You can configure a Mac exactly the way that you want, then use Composer to capture an image of the disk that can be deployed to other Macs using JAMF as part of an Imaging Configuration. Effectively, this is analogous to capturing a base image from a PC, then using it in a Task Sequence in SCCM.
Unfortunately, as you can see in this screenshot, the version of Composer that I currently have access to does not support APFS disks, so going forward this will be a less viable tool for High Sierra, Mojave, etc. However, this isn't such a big deal, since Mac imaging is dead. For older, Sierra-based environments, though, this is a handy tool.
Composer also provides some pre-made "manifests", lists of files known to be changed by certain software installers, in the Pre-Installed Software section. You can use these to capture common software without having to wait the minute or two it takes to capture a snapshot.
This main section shows manifests that come with Composer, or that you have installed yourself. In the Not Installed sub-section, many more manifest files for other programs are available. All of the manifests available by default were created by JAMF themselves, but the JAMF Nation website also has a list of community-created manifests for almost any piece of software you could need to package.
Finally, Composer can also capture certain settings on the computer, which can be deployed in a package just as if they were an application. The available settings for capture can be found in the User Environment section.
These work similarly to the software manifests described above, in that Composer knows which files hold which settings. Unfortunately, this also means that if you are stuck with an older version of Composer, or if Apple decides to change where settings files are located, this portion of the tool may not be able to capture everything. Even if it does, because of the way Mac OS preferences work, it may not be desirable to do so - for example, the Dock settings you capture with Composer will completely overwrite users' Docks, including any customizations they may have made. For most of the settings here, a more appropriate method of management would be to use a Policy or Configuration Profile, which offer more fine-grained control over exactly what you want to change.
So, what is the process to create a package using a Snapshot? First, go back to the Snapshot section, and select Normal Snapshot. Then, click Next.
Enter the name of the package you want to create (usually, the name of the program, its version number, etc.), then click Next.
Composer will then begin to capture its pre-installation snapshot. You can see its progress as it indexes various parts of the operating system and user data directories.
Once the snapshot is complete, you will see this screen. This is your cue to perform the installation, make changes to files, and perform any other actions you want to capture. Once you have made your changes, click Create Package Source.
When you click the button to create the package source, Composer takes another snapshot, capturing any files that have been created since the first snapshot.
Once the "After" snapshot is created, Composer will present you with a list of the files it found to have been created. As you can see, I created a folder on my desktop called "test folder", and a text file within called "test.txt".
This is the main work area in Composer. Here, you can make changes to the files in the snapshot - you can delete them, change their owner/group/permissions using the handy dialog in the bottom-right, and even drag-and-drop them into different folders. In most cases, for software installations, you will want to leave things as they are.
When you have everything set up the way that you want it, you are ready to build the package using one of the two Build buttons in the toolbar at the top of the window. Composer offers a choice of two different kinds of package that you can build: .DMG or .PKG. These both perform the same basic task, but accomplish it in different ways:
- .DMG packages are what they sound like. Composer creates a .DMG disk image file duplicating the structure and properties of the folders and files captured in the screenshot. When you deploy such a package via Policy or Casper Remote, the JAMF binary on the client Mac copies everything out of the DMG to the same location on the computer. .DMG packages are indexable in Casper Admin, which means that you can use JAMF to uninstall them as well.
- .PKG packages are like "normal" installer packages that you might download from a vendor. You can deploy these packages via JAMF tools, or you can copy them to a flash drive and install them using the normal double-click method, even on a Mac not managed by JAMF. In addition, these packages can include preinstall and postinstall scripts (and a few other kinds, for non-flat packages) that allow you to perform pre-installation checks, post-installation cleanup, or any other scriptable actions that you might want to happen alongside the installation of files. However, .PKG packages cannot be indexed by Casper Admin, so they are not easily uninstallable without creating a separate uninstaller package.
Either of the Build options will let you choose where to save the created package, and will then build and save it there. Depending on the size of the installation you captured, it may take a long time (upwards of 45 minutes for OS captures or very large applications), but it is usually relatively quick.
If you have an installation that you know will not require much customization - for example, an application whose installation process is "drag me to the Applications folder", you can skip the normal snapshot-install-snapshot process, and create a package source with only the files you choose. For example, to create a package that just installs the Google Chrome app in the Applications folder, you can do this:
First, open Composer to the main package work area. Then, drag-and-drop the Google Chrome .app file to the left-hand pane, in the empty lower area.
Composer copies the files for the Chrome app to a temporary storage area, then creates a package source for it, just like it did using the snapshot method above.
You can now build a .DMG or .PKG package for this, and deploy it using whatever method you may choose to install Google Chrome. The disadvantage of this method is that you do not capture any settings changes made - with Chrome, for example, you may want to set a default homepage, etc. when capturing the package; in that case, the Snapshot method is more appropriate.
More and more applications are moving to models where the Snapshot method does not work, whether because it writes changes to the system-wide Keychain, or other files that are not appropriate to copy from one user to the next, especially across different machines. Some of these, like Chrome and Firefox, allow you to embed special configuration files directly into the .app itself to change things like default homepages, etc. This is in keeping with Apple's changes to macOS installation, where direct captures and deployments will be less and less viable going forward. Therefore, this app-only package creation method will become more and more useful as time goes on.
No comments:
Post a Comment