And, if a client manifest somehow got deleted or was unavailable, Munki would default to site_default anyway and the client state really wouldn’t change much. This way, we would have the granularity to make certain pieces of software available to specific devices as needed, without having to assign every device every piece of standard software. We then made it an included_manifest in the per-device manifests. We chose to utilize the site_default manifest that Munki defaults to as our primary manifest that all general software would be assigned to. I saw several folks recommending the per-device/per-user manifest method (examples here and here), but from our point of view it was hard to see the need for per-client manifests as the majority of our software/patches are deployed to all equipment. But trusting that these folks knew what they were talking about, and knowing that they had used Munki for far longer than we had, we decided to trust the advice of those smarter than us. While recently setting up Munki in our environment, I was doing some Googling, and asking for advice on how to handle client manifests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |