Tag Archives: munki

Munki, Git and Munki-Do

Munki-Do inherited from its father MunkiWebAdmin by Greg Neagle et al., the ability to commit to a Git-initiated Munki Repo when making changes to Munki manifests.

Over the past few days I’ve been looking at how Git can interact with Munki. Using Git with Munki is covered in the Munki Wiki. It describes how to set up a git repository on a server with which you have CLI access.

In my tests, I’ve been using a private repository on Bitbucket. I also started with an existing Munki repo, rather than setting up a new one.

Setting up git on an existing Munki Repo

Setting up the test Munki repo with Git was done as follows:

  • An empty repo was set up on Bitbucket.org
  • The existing munki_repo folder was initialised for git using the commands: cd /path/to/munki_repo; git init
  • The pkgs folder was set to be ignored, as I didn’t want the large pkg/dmg/app files to be uploaded to the repo. This was done by editing /path/to/munki_repo/.gitignore and simply adding the line pkgs to the file.
  • Then, sync the repo to the server:

$ git add .
$ git commit -m "Initial import"
$ git remote add origin git@bitbucket.org:myaccount/my_test_munki_repo.git
$ git push --set-upstream origin master

Munki-with-Git challenges

Version control is an essential tool in any Mac Administrator’s workflow. However, using Git with Munki has challenges due to the munki repository containing potentially very large packages, unsuitable for free cloud Git repositories such as Bitbucket, and challenging for paid private repositories on Github or elsewhere due to bandwidth issues. Even using your local organisation’s Git service could have bandwidth issues.

A solution such as Git Fat could help with these issues, as the large files are dealt with separately. Alistair Banks describes an example Git Fat setup here. Git-LFS is another solution that could help. I intend to test these out and report in a future post.

Configuring Munki-Do for Git

I have extended the functionality of Munki-Do so that it can now update Git repos when changes are made to pkginfo files, and therefore catalogs. In Munki-Do, Git is enabled by setting the path to the git command on the system hosting Munki-Do, in settings.py. In my case, I’m running Munki-Do in a Docker Container, and the path is as follows:

GIT_PATH = '/usr/bin/git'

Bitbucket doesn’t respond to --author flags in git commit commands, so Munki-Do has been recoded to set the author variables based on the current user using git config user.name and git config user.email commands.

Since the Bitbucket repository is a private one, to enable automated interaction with the Bitbucket server, an ssh key needs to be generated on Munki-Do’s host, and the public key imported to the Bitbucket repo. The process for doing this is described here.

My test Munki-Do host is a Docker Container, so I imported my SSH key from my host Mac into the Docker Container using commands in the Dockerfile:

ADD id_rsa /root/.ssh/id_rsa
RUN touch /root/.ssh/known_hosts
RUN chown root: /root/.ssh/id_rsa && chmod 600 /root/.ssh/id_rsa
RUN ssh-keyscan bitbucket.org >> /root/.ssh/known_hosts

Note that id_rsa must be first copied from ~/.ssh/ to the same folder as the Dockerfile.

In my testing, sometimes the above ssh-keyscan command is not successful during docker build, in which case your git commits will fail. Take notice of the output of the build to ensure success! You can run the command again in a bash shell in the container if it fails during build.

Advertisements

Munki-Do (beta): a web tool for managing Munki packages

Disclaimer: Munki-Do is still a very much work in progress, so shouldn’t be used in production. I welcome the raising of issues, and pull requests.

Screen Shot 2015-09-30 at 16.37.22

Munki-Do (as in “munki see, munki do”) enables the manipulation of Munki packages via the web. Munki-Do is based on MunkiWebAdmin (v1) from Greg Neagle, and was forked from Steve Kueng’s own forked version (https://github.com/SteveKueng/munkiwebadmin) – this version utilises a more recent version of Django, and has significant UI changes in comparison with the original MunkiWebAdmin.

Some existing functionality from MunkiWebAdmin has been retained:

  1. Manifests: create/delete manifests, and manage the contents of manifests.
  2. Catalogs: view the contents of catalogs, view pkginfo file contents in tabular form.

New functionality has been added:

  1. Add multiple packages to a new or existing catalog
  2. Remove multiple packages from a catalog
  3. Move multiple packages to a new or existing catalog (i.e. replace existing catalog entry with another one, e.g. batch move a set of packages into the ‘production’ catalog)
  4. Delete packages and their associated pkginfo files

The remaining functionality of the original MunkiWebAdmin has been removed from Munki-Do, such as reporting and licensing tools, as there are other products that can do this better. I recommend:

The function to manipulate pkginfo files utilises munkitools (specifically, the makecatalogs command). This has been tested on an Ubuntu 14.04 VM, but you will need to ensure that your nginx user has write permissions to your munki repo. Use of group permissions is recommended.

The code which enables movement of packages between catalogs is a derivation of code from Munki-Trello by Graham Gilbert: https://github.com/grahamgilbert/munki-trello

A Docker container for Munki-Do is available here: https://github.com/grahampugh/docker-munki-do

I’ve also made a Docker container for Steve Kueng’s fork of MunkiWebAdmin, available here: https://github.com/grahampugh/docker-munkiwebadmin

MunkiWebAdmin2

Greg Neagle announced at MacSysAdmins this week that he is working on MunkiWebAdmin2, which will allow full editing of pkginfo files including the catalog key. He also announced that MunkiWebAdmin2 will drop licensing and reporting tools, as with Munki-Do. I decided to put Munki-Do in production anyway, since I’d been working on it for a while, and as it may still provide the additional benefit of bulk changes to catalogs, and the ability to delete packages and pkginfo files to keep your repository from becoming too large and unwieldy.

I welcome all feedback on whether this could become a useful tool in your workflow. I’ll revisit the tool once MunkiWebAdmin2 is released.

A “Do Not Disturb” application for Munki

UPDATE: I’ve tweaked this app based on the idea of Arjen van Bochoven in his comment

A Mac user complained that Managed Software Center popped up in the middle of a conference presentation. I started looking into how to suppress notifications.

do-not-disturbAs a quick fix, I created an AppleScript application which suppresses notifications for 24 hours, utilising the SuppressUserNotification key in /Library/Preferences/ManagedInstalls.plist.

The application sets the key to TRUE, and runs a preflight script every time Munki runs on a client to check whether 24 hours have passed or not, after which it will reset the key back to FALSE.

The application

If you use MunkiReport-PHP and/or Sal clients in your organisation, or else have no reporting tools, then you can download my pre-made package for distribution:
https://github.com/grahampugh/munki-do-not-disturb/releases

If you use MunkiWebAdmin or some other reporting tool which uses an incompatible preflight script, then follow the instructions for compiling it yourself, here:
https://github.com/grahampugh/munki-do-not-disturb.

(See also my earlier post on getting MunkiWebAdmin to work with MunkiReport-PHP and/or Sal).

Screen Shot 2015-07-04 at 00.46.39

Importing into Munki

Now import to Munki and place in the manifest of the people you wish to have access. The uninstall method needs changing to ensure proper removal:

Alternatives

You could permanently disable notifications, but that would mean users never become aware of updates, so some applications that require intervention such as closing blocking applications could get somewhat out of date.

There is interest in the use of Apple’s Notification Centre for Managed Software Updates, but this is not yet considered reliable. If it becomes suitable, then Apple’s built in Do Not Disturb feature could be utilised.

I’ll update this post if/when better solutions emerge.