AutoPkg recipes for NexThink Collector

A while back, I posted about how to build an installer for NexThink Collector, but my preference is to not do manual packaging if I can avoid it. Instead, my preference is to have AutoPkg handle packaging tasks whenever possible for the following reasons:

1. I can ensure that the packaging task is handled the same way every time.
2. Once I have the correct recipe written for AutoPkg, all I should need to do for future versions of the app is to run the AutoPkg recipe, wait a few minutes and then collect a properly-built installer.

With that in mind, I decided to revisit building an installer for NexThink Collector but this time build AutoPkg recipes which handle the following:

1. Creating an installer package for NexThink Collector
2. Creating an uninstaller for NexThink Collector

I was able to do this, so for those interested, please see below the jump for more details.

Downloading installer packages from Jamf Pro when no other options are available

Every so often, Mac admins who administer Jamf Pro may run into a situation like this:

1. They need an installer package For Reasons.
2. That installer package is only stored on their Jamf Pro server.
3. They don’t have access to the distribution point which stores their Jamf Pro server’s installer packages.

In a situation like this, you can use a Jamf Pro policy to provide the installer to a specified Mac. For more details, please see below the jump.

20 years of Der Flounder

I noticed that I first wrote an entry on this blog twenty years ago. I figured that deserved some commemoration and recognition.

The blog started out as a personal blog (as evidenced by its early entries) and gradually morphed into being what it is today. I plan to keep writing it because it’s still fun for me and I can see that it’s helped folks out. First blog entry was naturally about starting the blog:

Subject? I don’t need no steenking subject!

At the time, I was using LiveJournal as they had a client app for Mac OS X and that made it easy for me to get started with blogging. Over the years, the blog moved a few times:

• LiveJournal
• Mac OS X 10.4.x Server’s Blojsom-based blog platform
• Self-hosted WordPress
• WordPress.com

I moved to WordPress.com in September 2008 and they’ve been graciously hosting me ever since. Thanks, folks.

I’ve been using MarsEdit for at least the last six years to write my blog posts, so thanks also to Daniel Jalkut at Red Sweater for putting out a quality product that helps me stay focused on the writing of a blog post and not the fiddly bits of how to post it.

For my past, present and future readers:

Thank you. This place wouldn’t be what it is without you.

Setting user-level global preferences in a macOS configuration profile

When managing user settings with a profile, you often need to define what the preference domain is in order to specify which settings to manage. Usually you can check the CFBundleIdentifier of an application to get the unique identifier used to define the preference domain.

Normally, these unique IDs (and corresponding preference domains) use a reverse-DNS-lookup scheme. For example, the preference domain for Apple’s web browser Safari is the following:

com.apple.Safari

This is derived from:

a. Apple using the following domain name:

apple.com

b. The application in question being named Safari.

Note: This is a convention, rather than a hard and fast requirement, but most applications’ unique identifiers and corresponding preference domains will use this naming convention.

However, there’s an exception to be aware of. macOS uses a special domain to identify settings which should apply to all applications started by the same user. This preference domain is called the NSGlobalDomain, but unlike most preference domains, you don’t use NSGlobalDomain to define the preference domain when trying to manage their settings with a profile. This can cause some confusion when trying to manage these settings. The preference domain in this case is the following:

.GlobalPreferences

For more details, please see below the jump.

Using Script2Pkg to create payload-free installer packages

Payload-free packages are something I’ve discussed from time to time, as I’ve found them to be very useful additions to my Mac admin toolkit. For those not familiar with the concept, payload-free installer packages are installer packages that exist only to run scripts. They don’t install any files, which would be referred to as the installer package’s payload. With no payload included with these installer packages, the installer packages built by this tool are referred to as payload-free.

A while back, I wrote a tool that would let me easily create them from existing scripts named Payload-Free Package Creator.app. The general idea was that you could use this tool to select a script, and then Payload-Free Package Creator.app would create an unsigned payload-free installer package which would run the selected script.

I’m happy to say that my team at work has expanded on that idea and has both built and open-sourced a tool for building payload-free packages named Script2Pkg. Script2Pkg includes the following functions:

1. Building an unsigned payload-free installer package
2. Building a signed payload-free installer package
3. Building a signed and notarized payload-free installer package
4. Verifying signing and notarization status of any installer package

For more details, please see below the jump.