Categories
Uncategorized

Upping the logging level in Munki

As noted in the Troubleshooting section of the Munki wiki, you can increase the logging level for Munki clients.

The default logging level is 1, which looks like this:
Dec 12 2019 20:04:20 -0800 GoogleChrome version 79.0.3945.79 (or newer) is already installed.

If you increase the logging level to 4, it will look like this:
Dec 12 2019 20:08:23 -0800 DEBUG1: Found GoogleChrome, version 79.0.3945.79 in catalog testing
Dec 12 2019 20:08:23 -0800 DEBUG1: Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Dec 12 2019 20:08:23 -0800 DEBUG1: Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Dec 12 2019 20:08:23 -0800 DEBUG1: Using version_comparison_key CFBundleShortVersionString
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item has version 79.0.3945.79
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item is the same.
Dec 12 2019 20:08:23 -0800 DEBUG1: Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Dec 12 2019 20:08:23 -0800 DEBUG1: Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Dec 12 2019 20:08:23 -0800 DEBUG1: Using version_comparison_key CFBundleShortVersionString
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item has version 79.0.3945.79
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item is the same.

which looks very similar to the output from a manual sudo managedsoftwareupdate -vvv run:

Found GoogleChrome, version 79.0.3945.79 in catalog testing
Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Using version_comparison_key CFBundleShortVersionString
Installed item has version 79.0.3945.79
Installed item is the same.
Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Using version_comparison_key CFBundleShortVersionString
Installed item has version 79.0.3945.79
Installed item is the same.

So if you want to see the equivalent of managedsoftwareupdate -vvv in the /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log, I’d recommend using LoggingLevel 4.

Categories
Uncategorized

Yes, Munki’s makecatalogs runs on Linux

You can’t run all of Munki‘s admin tools on Linux, because some of the things the tools use involve Mac-specific tools, which is why even Munki admins who host their Munki servers on a Linux server will use a Mac for things like munkiimport.

You can, however, run makecatalogs on Linux, though. Here’s just a quick test you can do on a vanilla Ubuntu 18.04 LTS server…

Clone the latest Munki from GitHub

git clone https://github.com/munki/munki

Create a symlink for Python 3

sudo ln -s /usr/bin/python3 /usr/bin/python

Copy the Munki command-line tools to a directory

sudo mkdir -p /usr/local/munki
sudo cp -R munki/code/client/* /usr/local/munki

Run makecatalogs

/usr/local/munki/makecatalogs /path/to/munki_repo

P.S. Your mileage may vary, but I found without making the symlink for Python 3 that I would get a

/usr/bin/env 'python': No such file or directory

error.

Categories
Uncategorized

Using AutoPkg to distribute and test Munki 4 (or any new Munki version) in prerelease

10 December, 2019 update: Munki 4 is now an official (not pre-) release, so the below instructions are for when the next version is in prerelease…

25 November, 2019 (original post)
As of this writing, Munki 4 is in the late stages of testing (its current on release candidate 1), so if you want to be part of the testing process and distribute it to part of your fleet, you want to start by first importing it into your Munki repo.

There is a new AutoPkg recipe for this called munkitools4.munki.recipe

First, make the override for it:

autopkg make-override munkitools4.munki

Then, edit the override, so it includes prereleases by adding in the appropriate true to the override’s XML:

<key>Input</key>
<dict>
<key>INCLUDE_PRERELEASES</key>
<string>true</string>

Then, run it as you normally would, just to verify it works (before including it in your scheduled runs):

autopkg run -v munkitools4.munki MakeCatalogs.munki

Categories
Uncategorized

Forcing updates to Google Chrome using Chrome preferences / a Chrome profile

Why use Chrome relaunch notification instead of Munki

I’m a huge fan of using Munki to patch software on macOS, but Munki is generally polite—it usually won’t kill an application while the user is using it. There is an option in Munki to force an install after a certain date, but that will log the user out of her computer completely in order to install whatever item you set as a forced install.

The actual preferences for Chrome relaunch notification

If you want to just have Chrome update to the latest version without logging out the user, but you want to force that to happen (say, if there’s a fairly serious zero-day security vulnerability), you can use Chrome preferences to do so:

defaults write com.google.Chrome RelaunchNotification -int 2

defaults write com.google.Chrome RelaunchNotificationPeriod -int 3600000

The first command forces a relaunch instead of just recommending one. The second one gives the period of time (in milliseconds) the user has before the relaunch happens.

Using a profile instead of commands to manage the preferences

Those commands probably aren’t something you want to run at scale. You’d want to use that as a quick test, and then you could deploy those settings as a .mobileconfig profile, which you can use mcxToProfile to do. You can also apparently use ProfileCreator to do so as well (using ProfileManifests), but I haven’t fully explored that yet. And, if you’re a Jamf user, you can use plutil -convert xml1 to use custom settings for a Jamf-created profile.

Deploy (and undeploy) thoughtfully

I’m going to give a major caveat that, unless you want to perpetually annoy your users, you probably don’t want to have this profile installed all the time, because it means every single time there’s a Chrome update (and Google does update Chrome quite frequently), your users will have only an hour (or whatever time period you set for RelaunchNotificationPeriod) to relaunch Chrome. Not all Chrome updates are immediately critical, so use this obnoxious “you must relaunch” Chrome policy judiciously.

What your users will see

This is the type of warning users will see:

Will users lose their open tabs?

I can’t say definitively, because the functionality may change in the future, but as of the writing of this blog post (late November, 2019), even if users have not set Continue where you left off, this forced relaunch will, in fact, re-open the tabs that were open before:

Um, test for yourself, obviously. You don’t want to have a bunch of angry users. You could, alternatively, have your .mobileconfig profile manage the RestoreOnStartup preference.

What’s the actual user experience like for the restart?

In my testing, it seems the 6-minute warning is the last one you can dismiss, and then when it’s ready to relaunch to install the update, Chrome gives absolutely no notification that the relaunch is happening when it happens. Chrome just closes out and then relaunches.

Further reading

More details at Google’s Notify users to restart to apply pending updates.

Even more technical details at Chrome Enterprise policy list.

Categories
Uncategorized

Setting up Reposado without downloading Apple update pkgs

Reposado allows you to set up your own local repo of Apple software updates. This can be handy if you want to control the flow of updates (having a testing branch, for example, and then promoting items from testing to production).

With Apple deprecating custom catalog URLs in Catalina (they still work for now, though), you may not want to actually create a full Reposado repo. Maybe you just want a way to check for product keys without replicating the entire repo, including pkgs.

It’s fairly simple to do this:

git clone https://github.com/wdas/reposado
sudo mkdir -p /usr/local/reposado
sudo cp -R reposado/code/* /usr/local/reposado/
sudo mkdir -p /Library/Application\ Support/reposado/html
sudo mkdir -p /Library/Application\ Support/reposado/metadata

This is the key part, when you go to configure Reposado, you want the Base URL to be blank:

sudo /usr/local/reposado/repoutil --configure
Filesystem path to store replicated catalogs and updates [/Library/Application\ Support/reposado/html]: /Library/Application Support/reposado/html

Filesystem path to store Reposado metadata [/Library/Application\ Support/reposado/metadata]: /Library/Application Support/reposado/metadata

Base URL for your local Software Update Service
(Example: http://su.your.org -- leave empty if you are not replicating updates) []:

Then, you can run

sudo /usr/local/reposado/repo_sync

and the total download should be only about 150 MB (as opposed to hundreds of GB if you were to download all the pkgs as well).

Categories
Uncategorized

Munki hack: force uninstall after a certain date

Munki has an option to force install by a certain date (specifically, using the force_install_after_date key), but it doesn’t do a force uninstall after a certain date.

You can make an item a managed uninstall, which means Munki will uninstall it when possible, but if that requires a logout or reboot, you don’t know when that might happen.

So to force an uninstall after a certain date, there’s a messy hack you can employ, which is to create an uninstall nopkg.

So, for example, if you want to force remove item X, you would have, of course, an item X in your repo, but you would then create a nopkg item for uninstall-X, which, when “installed” would uninstall X.

Now, this can be a bit tricky, because Munki has built-in logic for how it does its installs. For example, let’s say item X had a relationship with item Y, where item Y is an update for X. If you use Munki’s built-in installation logic to make item X a managed uninstall, Munki would know to remove item Y as well. But if you create a separate nopkg that just runs some script to remove item X, the nopkg doesn’t also necessarily know item Y is an update for item X.

Likewise, if you have item X as a managed install as well, you could have Munki fighting with itself, since it will try to install item X but also (via your hacky nopkg) install item uninstall-X. (In ordinary circumstances, make an item both a managed install and a managed uninstall would usually have Munki just keep it installed.)

But if you are careful with how you construct things, this can definitely work. I wouldn’t recommend it (better to just let managed uninstalls do its job), but if you absolutely need to remove a certain piece of software by a certain date, this can do it.

Another potential hack is to have item Z force install by that same date, and then make item X a regular managed uninstall, and when users are forced to install item Z, item X will uninstall at the same time.

Categories
Uncategorized

Using Munki to ignore Catalina upgrade in macOS

Apple used to make you go out of your way to download an OS upgrade. Then, Apple started having those OS upgrade installers auto-download to the /Applications folder. Then Apple made it so OS upgrades appeared as regular updates.

For Mac admins who aren’t ready to have their clients upgrade to Catalina (and potentially have a lot of things break), there is a way to tell the client machine to ignore the update and thus not advertise it to the user.

For those who are Munki admins, I’ve created a nopkg that will allow you to “install” ignoring the Catalina upgrade (but you can easily tweak the script to ignore any update) and also “uninstall” ignoring the Catalina upgrade (or any update).

Categories
Uncategorized

Scripting changing the user picture in macOS

Sometimes, you may want to programmatically set a default user picture (with the option for the user to change it later to a picture of her own choice).

You used to be able to delete the JPEGPhoto attribute and just add in a Picture attribute, but that seems to have broken somewhere between October 2018 and September 2019.

In macOS 10.14.6, if you use dscl to delete the JPEGPhoto attribute, and then add in a Picture attribute, you’ll see one of the user pictures change, but the other one will default to the generic silhouette:

Unfortunately, you also can’t just script writing in the hex of the photo via a dscl . -create /Users/username JPEGPhoto ALLOFTHEHEXTEXT command. You will get a /usr/bin/dscl: Argument list too long error.

Someone on Stack Exchange managed to find a solution using dsimport.

Note: I did some further testing, and you may need to first run

sudo dscl . delete /Users/username JPEGPhoto
sudo dscl . delete /Users/username Picture

before successfully running the script linked to below.

If you run that script, you’ll see it changes both photos.

This script works for now in 10.14.6, and it also works in Catalina beta build 19A578c.