If you’re a beginning Munki administrator, you’re probably pretty familiar with adding software to these categories:
- Managed Installs: Software that has to be installed on the client machine and does not appear as an optional install to be removed.
- Managed Uninstalls: Software that must be removed, so if it’s installed will be force-removed from the client machines.
- Optional Installs: Software that users can install or uninstall themselves using Managed Software Center.
- Managed Updates: Software whose update-for software will install automatically. For example, if you have MSOffice2011 installed and then have MSOffice2011Updates set as an update package for MSOffice2011, you would want MSOffice2011 in Managed Updates.
But what if you want to keep a package in optional installs but trigger it to install for a group of users (based on a script or a nopkg, for example)?
The terminal command you want to kick off is something like
/usr/libexec/PlistBuddy -c “Add :managed_installs:0 string ‘Firefox‘” /Library/Managed\ Installs/manifests/SelfServeManifest
where the name (the actual name—not the display name) of the package is in single quotes (example above is Firefox, but you’d substitute in whatever package you want to trigger). This is equivalent to the user launching up Managed Software Center and then clicking the Install button next to an optional install.
Not that functionally there is any difference in having a duplicate managed install in the SelfServeManifest, but if you want to check first that the entry isn’t in there, you can use this command (perhaps assign it to a variable) to see if the entry’s already there before you decide to add it:
/usr/libexec/PlistBuddy -c Print:managed_installs /Library/Managed\ Installs/manifests/SelfServeManifest | grep “Firefox“
Acknowledgements: Full credit goes to Arjen van Bochoven’s post on the Munki Dev mailing list for this tip.
12 responses to “Terminal command to mark a Munki optional install for installation”
Due to licensing limitations, I need to limit the scope to small groups authorized for specific software.
We are testing creating a new Manifest and a new catalog for test group “Video”. How do I modify the ManagedInstalls.plist to offer the scoped software for this limited group.
Hi, Monica!
You wouldn’t actually need to create a catalog for the group, but you would create a new manifest. For your test group, you’d simply change their client identifier to be Video.
Is it the case that optional installs, once installed, will never be updated unless the process is initiated by the user? If so, then combining this command with one that checks which optional installs were installed and need an update would be useful.
1. Get list of optional installs from /Library/Managed Installs/manifests/client_manifest.plist
2. Look to see if it’s installed by checking /Library/Managed Installs/ManagedInstallReport.plist
3. Use the command above to add software to pending.
4. managedsoftware –installonly
If you want optional installs to be updated in the background, put those in as managed installs:
https://github.com/munki/munki/wiki/Manifests#managed_installs
But I don’t want them to be managed though. I’d like them to remain as optional, but be updated automatically. For now this seems to work:
1. Find optional installs that have updates via /Library/Managed Installs/InstallInfo.plist
(optional pkgs have a “needs_update” key with a string of true/false)
2. Add them to “managed_installs” in /Library/Managed Installs/manifest/SelfServeManifest”
I believe (not 100% sure) that this pretty much mimics the user selecting the optional install for update.
My bad.
I was thinking managed_updates but typed managed_installs.
You want to make them managed_updates:
https://github.com/munki/munki/wiki/Manifests#managed_updates
Thanks for that!
I should have been clearer: I work in an environment where some admins may not have access to the manifest they are using. Therefore, I’m writing a script that can automate the process of updating optional installs.
I’d still recommend doing managed_updates, since that’s functionality built into Munki. I would make all manifests include a master manifest, and then have that master manifest have managed_updates for just about anything you would ever want automatically updated.
In my experience with Munki, there’s no harm in having a managed_update for something that’s not installed. So if it’s not installed, nothing happens. If it is installed, it gets updated automatically.
You’re welcome to do what works for you, of course. That’s just what I’d recommend.
I think what happened is that I had a host that was using a manifest which had some packages that were managed installs. Therefore they were installed automatically on the machine. It later switched manifests, and under the new one, the packages were optional installs. That is the reason these packages were never added to the machine’s SelfServeManifest. Not sure if this qualifies as a bug or not. Definitely an unusual use case.
No, that’s not a bug. That’s expected behavior, unless the user decides to uninstall the optional install and then reinstall it. Either way, I’d go with managed_updates to keep the apps updates, whether they’re optional or not.
[…] Terminal command to mark a Munki optional install for installation, I showed a one-off command to mark a Munki optional install item for […]
[…] I have two previous posts about using Plistbuddy to add to an array in a .plist file (specifically Munki's SelfServeManifest file): Bash script to add optional installs for Munki Terminal command to mark a Munki optional install for installation […]