Since this is the first mention of Mandrill I’ve made on this blog, I should probably start with a brief description of what it is. As mentioned in README.md on GitHub, Mandrill is a..
Multi-user web front-end for managing a Munki repository.
Mandrill doesn’t try to hide any of Munki’s inner workings and provides a great in-browser text editor based on AceEditor. Even if Mandrill does end up providing a form-based interface for modifying your Munki repo, the text editor will remain for one simple reason: if something goes wrong, you shouldn’t need to ditch your browser and drop to a shell to fix the problem.
This version of Mandrill is fully functional on OS X and Linux hosts, but the main problem it has tried to solve from the get-go has been more about people than operating systems and software. More features are coming, but a very powerful one is already here: multi-user environment with customizable permissions.
I’ve had many discussions within the past year with multiple Mac admins about how user-level permissions could be applied on a per-file basis. Of course ACLs and POSIX-style user/group permissions always came up, but given that most Munki repos consist of hundreds if not thousands of files, it’s not reasonable to expect admins to grant or deny rights to a user or group on a per-file basis. Instead, I’ve opted for regular expression pattern matching. If you’re thinking I don’t know regex, but I’ve heard it’s hard, it’s not as hard as you might think!
Most of the time, we approach the problem of granting permissions in terms of patterns anyway. For example: I want to give John full access to all the scienceLab* manifests, and read-only access to everything else. That would be a pattern, would it not? In Mandrill, the rule patterns would look like this:
First of all, why don’t the checkboxes have labels? Well, you’re immediately presented with a popover label as soon as your mouse hovers over the checkbox, so it makes a lot more sense when you’re actually using the application. But let’s go through the rules and see how they do what we’re after.
manifests/scienceLab matches all files whose full path starts with ‘/Users/Shared/munki_repo/manifests/scienceLab’. If we wanted this rule to mean only the ‘scienceLab’ manifest, you’d just throw a ‘$’ after ‘scienceLab’, which you can think of as meaning, ‘and nothing else after scienceLab’. Since the readonly checkbox is unchecked, John has full access to files matching this rule.
(catalogs|pkgsinfo|manifests) matches pretty much everything in the munki repo, and is read as “catalogs or pkgsinfo or manifests”. Since the readonly checkbox is selected, files matching this rule are immutable for John. In addition, John can neither create nor delete files matching this rule.
Mandrill uses a fail-closed approach to rules, which is why the order of these rules doesn’t matter. John will always be given the most access possible for a file or path. First, Mandrill determines if the path in question is writable for John, and if not, is it at least readable for him? If both of those tests fail, John has no access. This also applies to new files, which means John can create new manifests, but only if they are in the manifests directory and the manifest name starts with ‘scienceLab’.
If you’ve got additional questions or want to talk about possible feature additions, either join the mandrill-dev mailing list, or use GitHub Issues. A step-through installation guide for Linux is available on the wiki.