munki client settings

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:

Key Type Default Description
AppleSoftwareUpdatesOnly boolean false If true, only install updates from an Apple Software Update server. No munki repository is needed or used.
InstallAppleSoftwareUpdates boolean false If true, install updates from an Apple Software Update server, in addition to «regular» munki updates.
UnattendedAppleUpdates boolean false If true, updates that declare no «must-close» applications, or have one or more «must-close» applications, none of which is running, and do not require a logout or restart will be installed as part of a normal periodic background run without notifying the user. (OS X 10.10+, Munki 2.5+)
SoftwareUpdateServerURL string Catalog URL for Apple Software Updates. If undefined or empty, Munki will use the same catalog that the OS uses when you run Apple’s Software Update application or call /usr/sbin/softwareupdate.
SoftwareRepoURL string http://munki/repo Base URL for munki repository
PackageURL string <SoftwareRepoURL>/pkgs Base URL for munki pkgs. Useful if your packages are served from a different server than your catalogs or manifests.
CatalogURL string <SoftwareRepoURL>/catalogs Base URL for munki catalogs. Useful if your catalogs are served from a different server than your packages or manifests.
ManifestURL string <SoftwareRepoURL>/manifests Base URL for munki manifests. Useful if your manifests are served from a different server than your catalogs or manifests.
IconURL string <SoftwareRepoURL>/icons (New for Munki 2) Base URL for product icons. Useful if your icons are served from a different server or different directory than the default.
ClientResourceURL string <SoftwareRepoURL>/client_resources (New for Munki 2) Base URL for custom client resources for Managed Software Update. Useful if your resources are served from a different server or different directory than the default.
ClientResourcesFilename string manifest name.zip or site_default.zip (New for Munki 2) Specific filename to use when requesting custom client resources.
HelpURL string none (New for Munki 2) If defined, a URL to open/display when the user selects «Managed Software Center Help» from Managed Software Center’s Help menu.
ClientIdentifier string Identifier for munki client. Usually is the same as a manifest name on the munki server. If this is empty or undefined, Munki will attempt the following identifiers, in order: fully-qualified hostname, «short» hostname, serial number and finally, «site_default»
ManagedInstallDir string /Library/Managed Installs Folder where munki keeps its data on the client.
LogFile string /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log Primary log is written to this file. Other logs are written into the same directory as this file.
LogToSyslog boolean false If true, log to {{{/var/log/system.log}}} in addition to ManagedSoftwareUpdate.log.
LoggingLevel integer 1 Higher values cause more detail to be written to the primary log.
DaysBetweenNotifications integer 1 Number of days between user notifications from Managed Software Update. Set to 0 to have Managed Software Update notify every time a background check runs if there are available updates.
UseClientCertificate boolean false If true, use an SSL client certificate when communicating with the munki server. Requires an https:// URL for the munki repo. See ClientCertificatePath for details.
UseClientCertificateCNAsClientIdentifier boolean false If true, use the CN of the client certificate as the Client Identifier.Used in combination with the UseClientCertificate key.
SoftwareRepoCAPath string (empty) Path to the directory that stores your CA certificate(s). See the curl man page for more details on this parameter.
SoftwareRepoCACertificate string /Library/Managed Installs/certs/ca.pem Absolute path to your CA Certificate.
ClientCertificatePath string /Library/Managed Installs/certs/[munki.pem|client.pem|cert.pem] Absolute path to a client certificate. There are 3 defaults for this key. Concatenated cert/key PEM file accepted.
ClientKeyPath string (empty) Absolute path to a client private key.
AdditionalHttpHeaders array (empty) 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.
PackageVerificationMode string hash Controls how munki verifies the integrity of downloaded packages. Possible values are: none: No integrity check is performed. hash: Integrity check is performed if package info contains checksum information. hash_strict: Integrity check is performed, and fails if package info does not contain checksum information.
SuppressUserNotification boolean false If true, Managed Software Update will never notify the user of available updates. Managed Software Update can still be manually invoked to discover and install updates. Suppress User Notification – By default, if a user is logged into the Mac and Munki detects and update, it will display the Managed Software Update application. If this is not what you want (for example in an education environment), use the below command:
SuppressAutoInstall boolean false If true, munki will not automatically install or remove items.
SuppressLoginwindowInstall boolean false Added in version 0.8.4.1696.0. If true, Munki will not install items while idle at the loginwindow except for those marked for unattended_install or unattended_uninstall.
SuppressStopButtonOnInstall boolean false If true, Managed Software Update will hide the stop button while installing or removing software, preventing users from interrupting the install.
InstallRequiresLogout boolean false If true, Managed Software Update will require a logout for all installs or removals.
ShowRemovalDetail boolean false If true, Managed Software Update will display detail for scheduled removals.
MSULogEnabled boolean false Log user actions in the GUI. See [MSU-Logging]
MSUDebugLogEnabled boolean false Debug logging for Managed Software Update/Managed Software Center. See [MSU-Logging]
LocalOnlyManifest string (empty) Defines the name of your LocalOnlyManifest. Setting this activates the feature. Unsetting it means Munki will remove the file on the next run. See LocalOnlyManifest
FollowHTTPRedirects string none Defines whether Munki will follow all, some or no redirects from the web server. See FollowHTTPRedirects

 

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:

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:

Edit the manifest:

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)


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):
  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:

     
  6. While you’re at it, you might want to restrict access based on IP address as well:
  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):
  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:
  6. While you’re at it, you might want to restrict access based on IP address as well:
  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:

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

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

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

9. März 2016 9594 webadmin  OS X Server  
Total 0 Votes:
0

Tell us how can we improve this post?

+ = Verify Human or Spambot ?

Add A Knowledge Base Question !

+ = Verify Human or Spambot ?

Add A Knowledge Base Question !

+ = Verify Human or Spambot ?