Multiple LocalOnlyManifests

44 views
Skip to first unread message

Chris Reinking

unread,
Feb 21, 2024, 7:43:17 PMFeb 21
to munki-discuss
Hi all,
I wanted to start a discussion regarding Munki's LocalOnlyManifest and propose a possible improvement.

Like most people, we utilize an MDM (Mosyle) alongside Munki.  As a school district with a 1:1 device initiative, we have 10k+ devices, mostly with just two client identifers - "student" or "staff" (along with some different ones for computer labs).

Munki's LocalOnlyManifest feature is fantastic for handling one off assignments of special programs.  For example, the lead student editor for the yearbook needs Adobe CC, or a engineering student needs AutoCAD.  The LocalOnlyManifest makes this simple - but in our example, what if the student needs both Adobe CC and AutoCAD?  Well we can define only one local manifest.  This would be a rare scenario, but a possibility nonetheless.

Has there been any discussion for modifying the LocalOnlyManifest pref to either a) support a directory location that contains all local manifests or b) accept a list of manifest values?  As a fairly capable dev, I'm happy to make a commit if anyone else sees the value in this.

Gregory Neagle

unread,
Feb 21, 2024, 7:45:23 PMFeb 21
to 'Gregory Neagle' via munki-discuss
I’m struggling to understand why you can’t put both "Adobe CC” and “AutoCAD” in the managed_installs of the local manifest.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/943df975-4628-40b1-80e9-ea743deb7be2n%40googlegroups.com.

Chris Reinking

unread,
Feb 22, 2024, 8:05:45 AMFeb 22
to munki-discuss
Sorry Greg, I should have elaborated about that.

In our MDM, we have a profile for each "special" application.  The profile runs a script that does the following:
  • Downloads the localonlymanifest which has the single application defined under managed installs
  • Copy the manifest to /Library/Managed Installs/manifests and set appropriate file permissions
  • Sets the Managed Installs LocalOnlyManifest pref to the downloaded manifest
If I were to apply both an "Adobe CC" and "AutoCAD" profile, the second script that runs will overwrite the first.  You are 100% right that we could create a third profile that contains both "Adobe CC" and "AutoCAD" under managed installs - and that's currently our workaround.  It's not a big deal with two applications - but if we're talking 5-10 different applications, the number of combinations would go up exponentially.  Hence if we could just drop multiple localonlymanifests in a folder and all would get processed, that would simplify things.

If you didn't want to make code changes to Munki, I'm sure I could work around this by adjusting the script in each profile to instead parse the existing manifests folder contents and merge them.  However if I'm gonna go that route, I might as well offer to contribute code to Munki if this functionality would be useful for others.  Either way, I gotta code something!

Ben Toms

unread,
Feb 22, 2024, 8:23:26 AMFeb 22
to munki-...@googlegroups.com

I think you’ll  be better off with an agent/script that manages the content of the manifest, which is basically the approach taken with jamJAR - https://github.com/dataJAR/jamJAR

 

Regards,

Ben.

 

Nick McSpadden

unread,
Feb 22, 2024, 11:05:30 AMFeb 22
to munki-...@googlegroups.com
Downloads the localonlymanifest which has the single application defined under managed installs
Copy the manifest to /Library/Managed Installs/manifests and set appropriate file permissions
Sets the Managed Installs LocalOnlyManifest pref to the downloaded manifest

This seems like an entirely unnecessary way to completely hobble the primary value of local manifests. Treat local only manifests like server side manifests - populate them with multiple items. Change your script to parse and update the plist on disk instead of just deploying a single file every single time.

In other words, I think your design has made this unnecessarily difficult and you should abandon it. 



--
--
Nick McSpadden
nmcsp...@gmail.com

Alan

unread,
Feb 22, 2024, 12:08:14 PMFeb 22
to munki-...@googlegroups.com
My understanding of local-only manifests is their main advantage is the leverage of a configuration management tool like Chef to create manifests on the fly.

If you just want to have machine-specific manifests, they don't need to be local-only, by any means. You can have serial number manifests on your Munki server (not local-only), and deploy specific (and, yes, multiple) items to a single Mac.

Adam M. Anklewicz

unread,
Feb 22, 2024, 1:23:21 PMFeb 22
to munki-...@googlegroups.com
Using the machine-specific manifests was how I managed it when I was at a school and needed to give specific devices specific apps. 


--
Adam Anklewicz
Pronouns: he/him/his


Alan

unread,
Feb 22, 2024, 1:39:41 PMFeb 22
to munki-...@googlegroups.com
I'm just trying to clarify that machine-specific and local-only are not the same thing.

You can have local-only manifests that are machine-specific. You can have local-only manifests that are all identical to one another.

You can also have server-served manifests that are machine-specific.

Nick McSpadden

unread,
Feb 22, 2024, 1:43:16 PMFeb 22
to munki-...@googlegroups.com
I think the main point here is that there's just no reason to only specify one app per local manifest. They can be treated just like other manifests, and contain multiple items across the main  manifest structure - managed_installs, managed_uninstalls, optional_installs. To Chris (OP's) question, treating each local manifest like it can only contain one item is incorrect and very suboptimal usage, and changing their model to treat it like a regular manifest (and thus populating a single file with multiple items) will be the way to go.

Chris Reinking

unread,
Feb 22, 2024, 2:21:22 PMFeb 22
to munki-discuss
I really appreciate all the feedback.  I do get the design decision and purpose behind the local manifests.  Out of our 10k+ Macs, we're talking about <20 "outliers" who would use this feature - my idea of using local manifests was to avoid having to create individual machine-specific manifests but I can pursue that route or pursue developing an in-house custom solution.
Reply all
Reply to author
Forward
0 new messages