Best Practices: Munki Deployment & Configuration

[Dan Stranathan]

Hello all

I just experimenting with Munki v2.  My goal is to roll it into production this fall (after other projects are completed and Munki v2 is safe for public consumption, etc).

My Munki test server is up and running on OS X 10.9.4/Apache, and working well. I have two OS X 10.9.4 Mac test clients (manually) configured and ready to go as well. Im ready to widen my test to more Macs in my IT dept (not production!). I don't want to manually configure the clients. I need to automate it a bit for obvious reasons.

I will likely push out the Munki v2 test client to the IT test Macs via ARD. This is due to the fact that I don't have Munki, JAMF Casper Suite or other mechanisms in place for software distribution. ARD works fine for me in limited remote deployments.

If I understand correctly, I need to have a couple Munki parameters set for my existing Mac test clients in my environment, including these two important values:

<key>ClientIdentifier</key>             = This is the manifest in which my test Macs will be organized in.

<key>SoftwareRepoURL</key>      = This is the http FQDN URL of my Munki Repo test server.

How do you suggesting deploying the client install - specifically a customized ManagedInstalls.plist configuration file?

Off of the top of my head, it appears that I have (2) primary options for such a task:

1) Push-out the Munki v2 client package installer via ARD that installs both the Munki client core resources (i.e.; the Managed Software Center.app binary bundle, various launchd resources, etc) and a pre-configured /Library/Preferences/ManagedInstalls.plist file. The /ManagedInstalls.plist file would contain the settings/values described above.

OR

2) Push out the Munki v2 client pkg installer that installs the Munki client resources (launched files, Managed Software Center.app binary bundle, etc) and a post-install script that configures the /Library/Preferences/ManagedInstalls.plist file using the /usr/bin/defaults command.

An example script would look something like this:

#!/bin/sh

# comments - blah blah

defaults write /Library/Preferences/ManagedInstalls ClientIdentifier standard_manifest

defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL http://server.domain.loc/munki_repo

exit 0

Once I get ready to deploy Munki v2 into production, I plan to tentatively push-out the Munki client to new Macs via DeployStudio, using one of the 2 options listed above. Existing Macs already in production will also likely use one of the two options described above as well. That is, unless you have a better idea on how to accomplish this.

Thanks!

[Josh Malone]

I use "method 2" from your list above. I have a mpkg that includes the
munki tools as well as a post-install script (actually, a payload-free
pkg) that sets the repo url as well as some HTTP headers for apache
authentication (this is documented in the wiki).

One difference is that I don't set a default manifest
(ClientIdentifier). Instead, I rely on the normal search pattern munki
uses to find a manifest. I have a site_default manifest that catches
most of my clients, but this allows me to create a specific manifest
for any client at any time without having to reconfigure munki on the
client. We find it very useful at my site.

-Josh

> --
> You received this message because you are subscribed to the Google Groups
> "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to munki-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mike Solin]

We do something similar to what Josh mentions - each Mac gets its own manifest, and we use site_default to catch the ones that don’t have a manifest.

Additionally, if your Munki server is named ‘munki’ and your repository is located at http://munki/repo, you don’t have to set the SoftwareRepoURL either. We’re doing that, too.

That way, getting Macs into our managed environment only requires installing the Munki tools.

Mike

--

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Gregory Neagle]

On Jul 13, 2014, at 9:14 PM, Mike Solin <mi...@MIKESOLIN.COM> wrote:

> We do something similar to what Josh mentions - each Mac gets its own manifest, and we use site_default to catch the ones that don't have a manifest.
>
> Additionally, if your Munki server is named 'munki' and your repository is located at http://munki/repo, you don't have to set the SoftwareRepoURL either. We're doing that, too.

I use this method as well. It's been pointed out to me that there is a security risk here. If I were to take my laptop and connect it to another network somewhere that also had a Munki repo available at http://munki/repo (either legit or malicious), worst case, my machine could be compromised; in any case, my machine could be directed to install software from a "foreign" Munki repo.

This isn't really much of a concern for desktop machines, but if you are concerned about this issue for laptops, you could use the default repo (http://munki/repo) to serve a manifest (IE site_default) that, among other things, installed a package that configured a more secure/specific/non-default munki repo (perhaps even using https: Sam Keeley had a interesting session at PSU Mac Admins where he discussed the possibility of a "Munki-in-the-middle" attack. Using an https repo makes such an attack far more difficult.)

>
> That way, getting Macs into our managed environment only requires installing the Munki tools.

Yes, I like leveraging Munki's defaults for this as well. I don't need to install any package or script to get my Munki clients to "talk" to my Munki server.

[Mike Solin]

That makes sense. I suppose setting the SoftwareRepoURL to something unique would prevent a client from accidentally talking to another Munki server if they both used the default URL, but even something non-standard could be tricked by another network’s DNS (if someone were being malicious). SSL is probably the safest method, yeah.

I missed Sam’s talk, I’ll check it out when the video is available. I really wanted to use as many “out of the box” features as possible, but I can see how that might lead to problems down the road.

Mike

--

mi...@mikesolin.com / @flammable
http://mikesolin.com

On Jul 14, 2014, at 9:15 AM, Gregory Neagle <gregn...@mac.com> wrote:

>
> On Jul 13, 2014, at 9:14 PM, Mike Solin <mi...@MIKESOLIN.COM> wrote:
>
>> We do something similar to what Josh mentions - each Mac gets its own manifest, and we use site_default to catch the ones that don't have a manifest.
>>
>> Additionally, if your Munki server is named 'munki' and your repository is located at http://munki/repo, you don't have to set the SoftwareRepoURL either. We're doing that, too.
>

> I use this method as well. It's been pointed out to me that there is a security risk here. If I were to take my laptop and connect it to another network somewhere that also had a Munki repo available athttp://munki/repo (either legit or malicious), worst case, my machine could be compromised; in any case, my machine could be directed to install software from a "foreign" Munki repo.

[Dan Stranathan]

Thanks for the input, much appreciated.

So, if I understand correctly, if no manifest (ClientIdentifier) is declared on a Munki client, the client will try and use the "site_default" manifest on the Munki server? If so, I assume this Manifest must exist (be created by the Munki administrator), correct? Or is "site_default" baked-in to Munki server with some special sauce?

Can a client have multiple Client Identifiers? I ask because I'm still wrapping my head around the logistics of how to best organize/structure my Mac Munki clients. Examples: Give each Mac/user a unique ClientIdentifier? Give each department a ClientIdentifier? Or organize in some manner that I haven't considered yet?

I'd like to hear more about the various ways the community is strutting their Catalogs and Manifests.

[Gregory Neagle]

On Jul 16, 2014, at 1:39 PM, Dan Stranathan <dstra...@gmail.com> wrote:

> Thanks for the input, much appreciated.
>
> So, if I understand correctly, if no manifest (ClientIdentifier) is declared on a Munki client, the client will try and use the "site_default" manifest on the Munki server?

See the description for ClientIdentifier here https://code.google.com/p/munki/wiki/configuration#Supported_ManagedInstalls_Keys

If ClientIdentifier is not set/defined, the client requests several manifests, one at a time. If any request is successful, it uses that manifest. The last manifest it attempts to retrieve is named "site_default".

> If so, I assume this Manifest must exist (be created by the Munki administrator), correct?

Yes.

> Or is "site_default" baked-in to Munki server with some special sauce?

Since a Munki server is usually just generic Apache, no. And what would such a "baked-in" default manifest _include_? How could the code possibly know what you wanted on machines by default?

>
> Can a client have multiple Client Identifiers?

No.

> I ask because I'm still wrapping my head around the logistics of how to best organize/structure my Mac Munki clients. Examples: Give each Mac/user a unique ClientIdentifier?

I create a manifest for each client, but I name it after the short hostname, so I don't set the ClientIdentifier on the client.