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
  • 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 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 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 and git config 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 >> /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.


2 thoughts on “Munki, Git and Munki-Do

  1. Graham (@grahamgilbert)

    Are you accepting feature requests yet? It would be awesome if changes were put onto a new branch – no one apart from my immediate team has direct push access to master, so it would be good if they could create a branch and then push to that automagically.


    1. Graham Post author

      Hi Graham, yes absolutely. I’ve been thinking about that exact thing, but still have some questions about it. I welcome your thoughts.

      • If a user creates a new branch with their first commit, there’s going to need to be a mechanism to check for the existence of that branch on future commits.
      • Would the intention be to delete the branches once the pull request was granted? (or, does that matter – maybe not)
      • How should the administrators handle the pull requests? I’m not yet sure how complicated it would be to build the process into Munki-Do, and/or whether people would prefer to handle pull requests outside of Munki-Do.
      • Should the main administrator account use the master branch, or still use a separate branch?
      • Out of interest, have you been thinking about the same thing for Munki-Trello? Or is this of interest purely for changes to manifests in your case?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s