When are nopkg items in Munki appropriate?

Greg Neagle (author of and primary developer on Munki) makes a good point that in most cases, a real .pkg (instead of a nopkg) is the best choice, because of versioning and receipts.

One thing that nopkg items in Munki are good for, though, is checking to make sure a setting stays. If you want to “install” a setting on a user’s Mac and you use a .pkg to do so, the only thing Munki is going to check is that the receipt is there. So if the user changes the setting afterwards, the Munki client will never know the setting reverted.

If, however, you use a nopkg, any reverted setting will switch back when the client checks back in with the Munki server (roughly every hour by default).

The final nopkg and lessons learned along the way

I wanted to put together a System Settings > Sharing > Remote Management nopkg, but I had do a lot of Googling and trial and error to get a working version of the nopkg. Here are a few things I learned along the way:

• ps aux | grep “[A]RDAgent.app” seems to be the most reliable way to check whether Remote Management is enabled, as far as my own testing and based on commands I’ve found through Google searches. Unfortunately, it isn’t always reliable. I’ve done significant testing and sometimes if you uncheck the Remote Management box in System Preferences > Sharing, the ARDAgent.app will still be “running.”
• Both dscl . -list /Users dsAttrTypeNative:naprivs and dscl . -list /Users naprivs list which users are listed as Remote Management–enabled users. For the eventual script, I went with the latter, since it’s easier to type and remember.
• If you want only specific users, it is not enough to run sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers. For example, if there are two users in naprivs and then you specify only one, both will still be in there. Even if you disable Remote Management and then specify only one, both of the old ones will pop back in there, so you do actually have to run sudo dscl . delete /Users/username naprivs on each username that’s in there before you give privileges to the one or two users you want instead of the previously existing one.
• Likewise, enabling Remote Management for all users is completely independent of the specific users. So if you switch to all users and then switch back to specific users, OS X will still look for users with naprivs.

Acknowledgements

I got a lot of help from rtrouton’s remote management script for the ARD_AllLocalUsers setting, and from haircut’s remote management script for the loop on removing users in the naprivs group, as well as Apple’ official documentation on Remote Management.