Introduction

Munki stores its configuration info in the «ManagedInstalls» preferences domain. By default, this info is stored in /Library/Preferences/ManagedInstalls.plist, but you can also use MCX, configuration profiles, or /private/var/root/Library/Preferences/ManagedInstalls.plist, or a combination of these locations with the normal defaults precedence:

• MCX/Configuration profiles
• /private/var/root/Library/Preferences/ManagedInstalls.plist
• /Library/Preferences/ManagedInstalls.plist

Details

Here’s a sample /Library/Preferences/ManagedInstalls.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ClientIdentifier</key>
    <string>arbitrary_name</string>
    <key>SoftwareRepoURL</key>
    <string>http://munkiwebserver/repo</string>
    <key>LoggingLevel</key>
    <integer>1</integer>
    <key>DaysBetweenNotifications</key>
    <integer>1</integer>
</dict>
</plist>

Additional Notes

LogFile

munki normally writes its logs to /Library/Managed Installs/Logs/, with the main log written to ManagedSoftwareUpdate.log in that directory. Other logs are named «Install.log», «errors.log», and «warnings.log». If you’d like the logs to be written somewhere else (for example /var/log or /Library/Logs), set LogFile to the desired pathname of the main log:

sudo defaults write /Library/Preferences/ManagedInstalls LogFile "/var/log/munki/managedsoftwareupdate.log"

The other logs will be written to the same directory.

InstallAppleSoftwareUpdates

If this key is present and set to True, munki will call softwareupdate and attempt to install Apple Software Updates.

SoftwareUpdateServerURL

This key can be used to point to an internal Apple Software Update server.

SuppressUserNotification

This key (when present and value is set to True) causes munki to never notify users of available updates. This might be useful in a lab environment, where you’d like updates to be applied only when no-one is logged in and the machine is at the login window.

SuppressAutoInstall

Normally, munki automatically installs and removes software if there are changes needed and that machine is at the loginwindow with no users logged in. If you have a need to do updates always and only with the consent of the user, setting SuppressAutoInstall to True prevents munki from automatically installing updates (and processing removals).

SuppressLoginwindowInstall

(Added in version 0.8.4.1696.0) If this preference is set to true, Munki will not install updates when idle at the loginwindow, with the exception of updates marked for unattended_install or unattended_uninstall.

ShowRemovalDetail

By default, Managed Software Update.app suppresses detail on what will be removed, instead showing a simple «Software removals» entry in the list. If you’d like Managed Software Update.app to show specific detail about what will be removed, set ShowRemovalDetail to True. This key has no effect on /usr/local/munki/managedsoftwareupdate, which always shows all detail.

InstallRequiresLogout

Managed Software Update.app enforces a logout before it installs or removes software only if one or more items to be installed/removed requires a logout or restart. You can force a logout for all updates by setting InstallRequiresLogout to True. This key has no effect on running /usr/local/munki/managedsoftwareupdate from the command-line.

AdditionalHttpHeaders

This key provides the ability to specify custom HTTP headers to be sent with all curl() HTTP requests. AdditionalHttpHeaders must be an array of strings with valid HTTP header format. For example:

<key>AdditionalHttpHeaders</key>
<array>
    <string>Key-With-Optional-Dashes: Foo Value</string>
    <string>another-custom-header: bar value</string>
</array>

One could use this to obtain a cookie in a preflight script and update ManagedInstalls.plist with the appropriate header. However, it is recommended that you use Secure Config for sensitive data (i.e. cookie) since ManagedInstalls.plist is world-readable.

LocalOnlyManifest

Defines the name of a locally controlled manifest.

Creating a LocalOnlyManifest enables administrators to specify additional managed_installs or managed_uninstalls in a local file that supersedes or augments those defined on the server.

For example, if your Munki client is inheriting the site_default manifest and you wanted to add a managed_install without editing that server-side manifest, you could define a LocalOnlyManifest and populate it with the selected package …

Define a LocalOnlyManifest:

sudo defaults write /Library/Preferences/ManagedInstalls LocalOnlyManifest extra_packages

Edit the manifest:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>managed_installs</key>
    <array>
        <string>Firefox</string>
    </array>
    <key>managed_uninstalls</key>
    <array>
        <string>GoogleChrome</string>
    </array>
</dict>
</plist>

Save it as: /Library/Managed\ Installs/manifests/extra_packages

This example ensures Firefox remains installed and GoogleChrome remains uninstalled, overriding any other references to these packages in site_default.

NOTE: Adding additional catalogs to your LocalOnlyManifest will have no effect. Packages managed using a LocalOnlyManifest must already be present in the available catalogs.

FollowHTTPRedirects

By default, Munki will not follow redirects that are returned by the web server. The FollowHTTPRedirects preference defines whether Munki should follow all redirects or only redirect to HTTPS URLs. The possible values for FollowHTTPRedirects are:

• none – This is the default and is the same as the present behaviour. No redirects are followed.
• https – Only redirects to URLs using HTTPS are followed. Redirects to HTTP URLs are not followed.
• all – Redirects to both HTTP and HTTPS URLs are followed.

Secure Configuration

If there are parts of your Munki configuration you consider sensitive information (for example, repo authentication information, special HTTP headers, or even the Munki repo URLs), instead of storing those preferences in the world-readable /Library/Preferences/ManagedInstalls.plistfile, you can use a more secure location for some Munki preferences: /var/root/Library/Preferences/ManagedInstalls.plist.

Use of this alternate preferences location is completely optional. If you do decide to use it, make sure you fully understand the implications.

Munki uses Apple’s defaults mechanism to store and access its preferences. Since the core Munki tools run as root, they can access preferences from this file: /private/var/root/Library/Preferences/ManagedInstalls.plist as well as the «normal» /Library/Preferences/ManagedInstalls.plist file.

Non-admin users of machines managed by Munki will not be able to access or read the contents of /private/var/root/Library/Preferences/ManagedInstalls.plist, so this provides some additional security for possibly sensitive preference values.

Note: preferences defined in /var/root/Library/Preferences/ManagedInstalls.plist have a higher precedence than those defined /Library/Preferences/ManagedInstalls.plist, so any preferences set here will override preferences defined in /Library/Preferences/ManagedInstalls.plist! This might confuse you or other admins who think only to look in /Library/Preferences/ManagedInstalls.plist and forget that some preferences are also defined in /private/var/root/Library/Preferences/ManagedInstalls.plist.

VERY IMPORTANT NOTE: the following preferences are required to be defined in /Library/Preferences/ManagedInstalls.plist (or set via MCX), as the GUI portion of Munki runs as the logged in user, not root. Do not place them in /var/root/Library/Preferences/ManagedInstalls.plist, or you may encounter unexpected behavior from Managed Software Update.app/Managed Software Center.app, since it can’t read the contents of /var/root/Library/Preferences/ManagedInstalls.plist:

• ManagedInstallDir
• InstallAppleSoftwareUpdates
• AppleUpdatesOnly
• ShowRemovalDetail
• InstallRequiresLogout
• HelpURL

Using the defaults command

If you use the /usr/bin/defaults command to set values for keys in ManagedInstalls.plist, remember that values default to the «string» type. If you are writing a boolean, integer, or array value, be sure to add the appropriate type flag. For example:

defaults write /Library/Preferences/ManagedInstalls SuppressAutoInstall -bool false

See man defaults for a complete list of type flags.

Munki Software-Updates bei jedem Boot triggern (bei gemanagten Rechner)

touch /Users/Shared/.com.googlecode.munki.checkandinstallatstartup

Using Basic Authentication

Introduction

If you’re using munki to distribute licensed software, you’ll want to restrict access to the repository. It’s possible to use client certificates (as described in Using Munki With SSL Client Certificates, but HTTP Basic Authentication is much easier to set up.

Details

HTTP Basic Authentication (RFC2617) is a very simple authentication scheme that simply sends a username and a password (separated by a colon and base64 encoded) in the headers of each HTTP request. If it’s used over unencrypted HTTP it’s insecure (as it’s trivial to sniff the password on the network), but in combination with HTTPS and a signed server certificate it’s reasonably secure.

Restricting Access to the Repository

Using Mac OS X Server 10.6

I will assume that you already have a repository set up that clients can connect to – if not, refer to the 10.6 Web Technologies Administration guide. I strongly recommend that you use SSL for your munki repository, with a signed server certificate. If you don’t have one, refer to the 10.6 Getting Started guide.

Since you can’t edit the Apache configuration files directly (well you can, but they will get overwritten by Server Admin), you have to enable overrides.

1. Launch Server Admin and connect to your server.
2. Select the Web service, and switch to the Sites tab.
3. Select the site that hosts your munki repository.
4. Select the Options tab, and enable Allow All Overrides.
   • NB: Your repository has to live under the Web Folder root, and not under an Alias. Overrides (.htaccess files) will not be enabled for folders under Aliases.
5. Click Save.

You then have to create a .htaccess file in the root of your munki repository:

1. Launch Terminal.app and cd to your repo_root.
2. Create a user that will be used to access the repository using htpasswd (here munki is used as an example):

   $ htpasswd -c .htpasswd munki
   New password: 
   Re-type new password: 
   Adding password for user munki

3. You can add more users to the .htpasswd file using htpasswd .htpasswd ANOTHERUSER if you don’t want to use the same username and password for all clients.
4. Using vi, emacs, pico or nano, create a new file called .htaccess (including the leading dot, making the file hidden).
5. Enable basic authentication with:

   AuthType Basic
   AuthName "Munki Repository"
   AuthUserFile /path/to/your/munki/repo_root/.htpasswd
   Require valid-user

    

6. While you’re at it, you might want to restrict access based on IP address as well:

   Order Deny,Allow
   Deny from all
   Allow from 192.168.0.0/16
   

7. Save the file and exit.

Using an Apache Server

I will assume that you already have a repository set up that clients can connect to.

1. In the terminal, cd to your munki repo_root.
2. Create a user that will be used to access the repository using htpasswd (here munki is used as an example):

   $ htpasswd -c .htpasswd munki
   New password: 
   Re-type new password: 
   Adding password for user munki

3. You can add more users to the .htpasswd file using htpasswd .htpasswd ANOTHERUSER if you don’t want to use the same username and password for all clients.
4. Open the Apache configuration file (typically /etc/apache2/httpd.conf) in a text editor (as root or using sudo).
5. Find the <Directory> section for your munki repository, and after the existing configuration directives add:

   <Directory "/path/to/your/web/root">
         Options All +MultiViews -ExecCGI -Indexes -Includes  # Just an example
         AllowOverride None                                   # Just an example
         AuthType Basic
         AuthName "Munki Repository"
         AuthUserFile /path/to/your/munki/repo_root/.htpasswd
         Require valid-user
     </Directory>

6. While you’re at it, you might want to restrict access based on IP address as well:

   Order Deny,Allow
   Deny from all
   Allow from 192.168.0.0/16
   

7. Save the file and exit.

Verify the Configuration

1. Verify that you get an authentication prompt if you try to view a catalog file in a web browser (e.g. https://your.munki.server:8043/repo_root/catalogs/testing).
2. Verify that you can authenticate as the user you created in step #2.
3. Verify that if you run /usr/local/munki/managedsoftwareupdate --checkonly on a client you get an error message saying that it can’t access its manifest.

Configuring the Clients to Use a Password

HTTP Basic Authentication consists of an extra Authorization header, which we can add to the munki configuration file in the AdditionalHttpHeaders array. But first we have to base64 encode the username and password:

python -c 'import base64; print "Authorization: Basic %s" % base64.b64encode("USERNAME:PASSWORD")'

Substitute the username and password you created in the .htpasswd file in your repository. Add this line to ManagedInstalls.plist:

<key>AdditionalHttpHeaders</key>
<array>
    <string>Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=</string>
</array>

Or if you prefer you can set it with defaults (e.g. to push it to your existing clients with ARD):

defaults write /Library/Preferences/ManagedInstalls AdditionalHttpHeaders -array "Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ="

If you have multiple AdditionalHttpHeaders use -array-add, otherwise the whole array will be overwritten by the defaults command.

Protecting the Password From Local Users

As all users on a machine can read /Library/Preferences/ManagedInstalls.plist, they’ll be able to read the password and access the repository. You can put the AdditionalHttpHeaders in /private/var/root/Library/Preferences/ManagedInstalls.plist instead, which is only readable by administrators.

Verify the Configuration

1. Verify that if you run /usr/local/munki/managedsoftwareupdate --checkonly on a client with the Authorization header configured that it successfully downloads the manifest and checks for updates.

References

• Munki’s preferences
• http://en.wikipedia.org/wiki/Basic_access_authentication
• http://en.wikipedia.org/wiki/Base64
• http://tools.ietf.org/html/rfc2617
• http://httpd.apache.org/docs/2.2/howto/auth.html
• http://httpd.apache.org/docs/2.2/howto/access.html
• http://httpd.apache.org/docs/2.2/howto/htaccess.html
• http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride
• http://images.apple.com/server/macosx/docs/Getting_Started_v10.6.pdf
• http://images.apple.com/server/macosx/docs/Web_Tech_Admin_v10.6.pdf
• http://images.apple.com/server/macosx/docs/Network_Services_Admin_v10.6.pdf