Speakers: Shea Craig Elliot Jordan
Level: Advanced, Lecture
Excerpt: Plenty of guides already exist on how to get started with Munki to manage your Mac fleet. However, beyond basic suggestions on how to make use of catalogs for testing new software, the design of a Munki repository is left as an exercise to the administrator.
In this session, we’ll reveal some of the enterprise-tested “best practices” that may not be immediately apparent to new or smaller-scale administrators. We’ll focus on how to structure Munki to be self-documenting, consistent, and as automated as possible. We’ll also demonstrate tools for keeping your repo optimized.
Description: Munki is an elegant solution that makes it relatively simple to begin managing a fleet of Macs. However, as the quantity of managed software grows, as users’ needs change, and as new IT staff participate in the use of the management toolset, individual deployment discrepancies can begin to proliferate, exaggerate, or ossify.
If there were a “perfect” way to manage Macs with Munki, chances are good that someone would have posted about it, the wiki would be updated, and everyone would do it that way. Each organization is different, operates at different scales, with different needs, locations, staff, and hardware. These variables make a prescription for ideal management difficult.
As professionals, however, “good-enough” is rarely that. This talk is about going beyond the “it works” mentality, and exploring some of the tactics used by IT consultants and large enterprises to manage Macs in the best way possible. Indeed, always striving for the best rather than the adequate is what constitutes professionalism in this field.
You won’t be in the same position at the same company forever, and there’s no reason to wait until you’re halfway out the door before creating critical documentation. Documentation should be built as you go, with constant editing and improvement done as needed. Design documents should describe the way major components of your architecture fit together. Documents should describe where customizations or deviations from standard configurations have been done. Everything should be in version control, with meaningful commit logs and carefully written comments. This benefits the organization, future collaborators or managers of these systems, and most importantly, you!
It would be reckless to auto-update everything possible. Instead, we’ll demonstrate a strictly defined automated testing process in which trusted individuals can test, comment on, and ensure the quality of patches before they are released. This includes third-party software, internal code, and all configuration changes. Some organizations even have a approval and notification process before these changes can be made.
Large-scale changes are risky, and can easily result in having to touch large quantities of individual computers when something goes wrong. We will discuss techniques for transitioning between “major” services or configurations, like changing Munki servers, adding client-certificate security, forcing an OS upgrade, or deprecating an older major version of software for a newer one. We will also discuss the benefits of making small, incremental changes in well-documented steps.
AutoPkg has a habit of quickly taking up drive space, especially with the use of dozens of recipes from numerous authors. Fortunately, tools exist for taming this mess, allowing you to audit your repo for unused packages, miscategorized items, and other cruft. Tools also exist to help automate generating recipe overrides for every managed software package in your organization to prevent further drift.
Finally, we will discuss the concept of “Self-Service IT” in the context of Munki. This means building a series of scripted tools and helper applications that clients can access through Managed Software Center to solve common issues.
Smaller organizations may find that the complexity of some of these ideas may not be worth the results. However, when employed carefully at scale, many of the practices discussed will more than pay back the time you invest.
About the speakers
Shea Craig – IT Systems Engineer – SAS (Twitter: @shea_craig)
High Cleric of Vim, Destroyer of Burritos, Scourge of Coffee Beans.
Elliot Jordan – Senior Consultant – Linde Group (Twitter: homebysix)
Elliot Jordan is a senior consultant at the Linde Group in Emeryville, California. He has been a professional Mac geek for 15 years (and an amateur Mac geek for 15 years before that). Elliot has worked on and led projects large and small for San Francisco Bay Area companies who are in the headlines as well as those yet undiscovered. Elliot is a member of the core AutoPkgr and Recipe Robot development teams, and maintains over 1000 public AutoPkg recipes. He lives with his wife Jacqueline in Oakland, California.