https://managingosx.wordpress.com/feed

Here are links to things in my presentation at Penn State MacAdmins 2023:

Fleet: https://fleetdm.com
Munki: https://github.com/munki/munki
Disney Animation: https://www.disneyanimation.com
Filewave: https://www.filewave.com
PSU MacEnterprise mailing list: https://lists.psu.edu/archives/macenterprise.html
Radmind: https://radmind.org
munki-dev: https://groups.google.com/g/munki-dev
Google Code Munii site: https://code.google.com/p/munki/
Workspace ONE UEM: https://www.vmware.com/products/workspace-one/unified-endpoint-management.html
SimpleMDM: https://simplemdm.com
Quest KACE: https://www.quest.com/kace/
Munki client cert auth: https://github.com/munki/munki/wiki/Using-Munki-With-SSL-Client-Certificates
Gurl.py: https://github.com/munki/munki/blob/main/code/client/munkilib/gurl.py
Munki middleware: https://github.com/munki/munki/wiki/Middleware
Munki authorized restarts: https://github.com/munki/munki/wiki/Authorized-Restarts
MunkiAdmin: https://github.com/hjuutilainen/munkiadmin
MunkiServer: https://github.com/munkiserver/munkiserver
MunkiReport PHP: https://github.com/munkireport/munkireport-php
Sal: https://github.com/salopensource/sal
Munki Force Install After Date: https://github.com/munki/munki/wiki/Pkginfo-Files#force-install-after-date
Simian: https://github.com/googlearchive/simian
AutoPkg: https://github.com/autopkg/autopkg
Munki releases: https://github.com/munki/munki/releases
Staging OS Installers: https://github.com/munki/munki/wiki/Staging-macOS-Installers
Default Installs: https://github.com/munki/munki/wiki/Default-Installs
The Curious Case of the Responsible Process: https://www.qt.io/blog/the-curious-case-of-the-responsible-process
MacAdmins Open Source: https://macadmins.io
jamJAR: https://github.com/dataJAR/jamJAR/
Munki wiki: https://github.com/munki/munki/wiki/
MunkiWebAdmin2: https://github.com/munki/mwa2
Munki-pkg: https://github.com/munki/munki-pkg

I had thought I wasn’t going to be able to attend or present at PSU Mac Admins this year — a bummer since I love the conference and it’s back in person for the first time since 2019. But some last minute developments — thank you, Fleet (https://fleetdm.com) — mean I will be able to be there, and I’ll be talking about the Past, Present and Future of Munki!

https://psumac2023.sched.com/event/1OIYF/the-past-present-and-future-of-munki

Register for PSU Mac Admins Conference today! https://macadmins.psu.edu/conference/registration/

macOS Ventura should be available soon. I talked about some issues that might affect you as a Mac admin last week at MacSysAdmin Online 2022:

https://www.macsysadmin.se/video/day3session7.mp4

Some Ventura topic timestamps:

18:38 Login items

22:09: Application update protections

24:00 Deferring Ventura issues

TL;DR: 

It looks like Munki is going to need a signed binary and an MDM-delivered PPPC/TCC config profile to continue working properly on macOS Ventura. 

Details 

Last week was Apple’s Worldwide Developer Conference 2022. Among others things announced and introduced was macOS Ventura, or macOS 13. 

As is not unusual for macOS releases, this release contains changes that may affect the functionality of Munki (and other similar tools). 

Two changes in particular have the potential to affect Munki functionality (and there may be more, but these were discussed in WWDC sessions): 

1) A new “Login Items” section in the System Settings (formerly System Preferences) application. This settings view allows users to easily disable Login Items, Launch Agents, and Launch Daemons. Users require admin rights to disable Launch Daemons. Since Munki makes heavy use of Launch Agents and Launch Daemons, a user could easily and trivially disable Munki from running. At present there appear to be no management options/tools to prevent this. File Feedback with Apple about how important managing would be to your organization. 

2) A new privacy protection around “App Management”. This prevents software from changing or removing items from /Applications without user approval. Its effect on Munki can be subtle and easy to miss in simple testing. 

On a fresh Ventura install, Munki can install software as it does under Monterey and earlier. But when updating or removing software, it may be blocked from making changes to apps in /Applications. Again, this can be easy to miss in testing. It’s common to have Terminal set for Full Disk Access, and also common for ssh to have Full Disk Access (via /usr/libexec/sshd-keychain-wrapper). Running managedsoftwareupdate via either of these methods will allow Munki to update and/or remove app bundles in /Applications. But Munki operations triggered via launchd jobs will fail to update or remove app bundles in /Applications. 

Apple has not yet provided supported/documented management controls to affect or manage this behavior. It _appears_ at present that managing/allowing Full Disk Access will allow processes to update or remove app bundles in /Applications, but I’d really like to see official Apple documentation and recommendations on this topic. 

It is possible to “pre-approve” binaries or apps for Full Disk Access via an MDM-delivered profile, but the binary or app must be signed. In the case of Munki, this will most likely have to take the form of a signed binary wrapper/launcher that calls munki-python and the needed Munki scripted tools. 

But this surfaces another problem. I don’t want to sign this binary with my personal Apple Developer ID and then distribute that as part of the official Munki release. And (while I have not asked) I suspect my employer doesn’t want to publicly distribute a Munki binary signed by them. While orgs using Munki could sign the tool themselves (and some will), many orgs will find this hard to do. I’d like to find some way to have a “Munki Project” or “Mac Admins” identity for a publicly-distributed release of the Munki tools. If anyone has useful thoughts, ideas, or information on how that might happen, I’d greatly appreciate it. 

(Original Google Groups posting here: https://groups.google.com/g/munki-dev/c/yRKhUGjNibY/m/eZ91OxZ5AAAJ)

Mac admins: if you haven’t already, read Anthony’s article here:

https://maclabs.jazzace.ca/2021/07/18/recognition-retirement-remembrance.html

His well-written, well-researched thoughts inspired some thoughts of my own.

It occurs to me that many of the “first” generation of Mac admins came from no-traditional backgrounds. This makes a bit of sense, since the Mac appealed to a new set of computer users.

My college degree was in Theater. I know many Mac admins who were (or are) musicians. Many many Mac admins come from Liberal Arts backgrounds or no college at all.

It’s far more common for “newer” Mac admins to come from more “traditional” backgrounds: they’ve studied computer science or software development.

Anecdotally, it seems to me that many of us who’ve come to this from non-traditional backgrounds are here for the long haul. One might speculate as to the reasons, but the fact remains that some of use have been doing this for _decades_.

It’s fantastic that we’re getting more people with deeper technical experience into the field — it’s what’s needed for the field to become more professional. Concepts like DevOps and Configuration Management and Version Control come from CompSci/Software development.

But: it also seems to me that admins coming from CompSci/software development backgrounds are far less likely to stay in the field long term. They are far more likely to move on to other things (bigger and better?!)

This, then, possibly presents another challenge for the community. Yes, we are starting to see a generational change, but we’re going to see faster “churn” overall.

We’re going to see new admins contribute exciting new things, but we’re also going to see those admins not stick around as long to shepherd what they’ve contributed.

Just as Anthony doesn’t really have any answers on how the community should deal with the generational change, I also don’t (yet at least) have any real suggestions on how the community should adapt to faster “churn”.

I do hope, however, that the community will take this opportunity to start talking about the changes and what can be done.

Official release of Munki 5.2:
https://github.com/munki/munki/releases/tag/v5.2.0

Early experimental build of Munki 5.3:
https://github.com/munki/munki/releases/tag/v5.3.0a1

https://github.com/munki/munki/releases/tag/v5.1.2

This is the official release of Munki 5.1.2: an update to the Munki tools.
There are two changes in this release from version 5.1.1: 

• Code signing has been removed from files in the embedded Python framework; the existing code signing was broken because of the process making the framework relocatable. 

• When importing a Big Sur installer, the pkginfo will reflect the 35.5GB required space for upgrading from macOS Sierra or later. (See https://support.apple.com/en-us/HT211238): https://github.com/munki/munki/commit/0714196b87e35b2862723a66bc5a95e736d8449b

The main focus for the Munki 5.1.x releases is compatibility with macOS Big Sur, but there are other changes.

See release notes for Munki 5.1 (https://github.com/munki/munki/releases/tag/v5.1.0) and 5.1.1 (https://github.com/munki/munki/releases/tag/v5.1.1) for more details on those changes.

See https://github.com/munki/munki/wiki/Munki-5-Information for information on the changes in Munki 5.

Find out more here: https://github.com/munki/munki/releases/tag/5.2.0RC1

Let’s hope this is the last beta! https://github.com/munki/munki/releases/tag/v5.2.0b4

Check it out: https://github.com/munki/munki/releases/tag/v5.2.0b1