Twelvetide, Day 11: Share and Blog

This is the eleventh part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

Since you are writing all your documentation anyway, some of that is probably very interesting for the wider MacAdmin audience. The best way is to just get a free blog on WordPress or Tumblr or some other free blog service and start writing.

“But, but, but… I want my own domain,” you say! “And my own design!”

If you already have a domain, or know exactly what you want for a domain, then go ahead, get it, install WordPress and start blogging. Otherwise you are overthinking and procrastinating. If a common wordpress blog is good enough for Rich Trouton and Greg Neagle, it is certainly good enough for every one.

Writing post for everybody is a great way to focus your thoughts on a problem and find flaws in your own reasoning. I often stumble over some preconception I have, research it, and then learn a lot while writing up a blog post (or book chapter). A blog post will obviously make your solution available to other admins through a search engine. Also sharing your problem and the solution to it will make it easier for you and other admins to share the solution in emails and forum posts by linking to your excellent post.

A good blog post should have a description of the problem and how and when you encountered it. What you tried to solve the problem (including the more interesting failed attempts) and then your solution. If the code or scripts required to solve the problem are longer you can post them on gist or turn them into a public GitHub repository. You need to remember to remove data from the scripts such as hostnames, user names and passwords before posting, though.

You should also mention the versions of macOS and any other software involved, so that future readers can quickly figure out if this applies to their problem. (Pet peeve of mine: make sure the post date is visible on your blog. I hate it when I read an article and can’t quickly tell how old it is and if it is still relevant.)

You should aim to post regularly to train the habit and your writing skills. However, since most of us have day jobs, ‘once or twice a month’ is a perfectly fine frequency. You can also use your blog to re-post and promote other administrators’ posts.

Most admin bloggers I know put links to their posts on Twitter. For me Twitter has replaced an RSS reader as the main means of getting notified on blog news. It is usually easy to connect your blogging engine to a twitter account (if not, choose another blogging engine). The MacAdmins Slack has a #blog-feeds channel which can notify for new posts.

A blog is also a vanity project. You can and should use it as an asset when you are applying for a new job or position. Of course, you should check with your current employer, on what and how you can blog about your work.

Some blogs worth following: (in no particular order)

This list is obviously far from complete. Feel free to add your blog and your favorite blog to read in the comments.

Twelvetide, Day 10: Write Documentation

This is the tenth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “File Bugs”)

We have all had this this moment when you are trying to figure how to do something you know you have done before, but just cannot remember what the thing was that made it work.

Documenting everything you do, no matter how trivial it may seem at the time is your protection against these moments.

But also, problems will occur, whether you are present or not. If you want to go on an extended vacation trip away from the internet, spend your week-end with your family, or just go home to sleep, you need the basic documentation so co-workers can resolve the most urgent issues without you. The better and more complete your documentation is, the farther and longer you can be away.

If you are working in a team or organisation, you probably have some tool in place, usually a wiki or CMS. You can spend days, weeks and months discussing and choosing the proper tool. Though I am not saying the tool doesn’t matter at all, any tool that is actually being used is better than a tool that is not used.

There are several great tools for personal documentation:

Finally, I will hand the virtual microphone to Rich Trouton, who has (repeatedly) said all of this so much better than I can.

Twelvetide, Day 9: File Bugs

This is the ninth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

As Mac administrators we are often very deep in parts of the OS that most other users, even developers and other power users, never touch. We need support for features from a software vendor that is very specialized. Often the vendors themselves do not understand the needs of admins, even Apple.

So we need to let them know about those needs and if necessary educate them. Not just Apple but all software vendors. And this is not just in the software itself but also the deployment workflow (installers).

For Apple the main way to file bugs is bugreport.apple.com, also known as Radar. Since the interface can be a bit cumbersome, there is a nice tool called QuickRadar that will simplify the process. (Rich Trouton has a nice write-up on Quick Radar.)

If you have an Enterprise Support you should also file your bugs through that channel. Talking with your Apple Systems or Consulting Engineer can also help. They may surprise you with a solution, but at the very least they are aware of your issues and have different channels inside the company to make them heard.

Don’t expect quick resolutions. Apple is a big company and macOS a very big and complex project. However, when requests and bug reports pile up from multiple sources and channels, Apple does take notice.

Don’t forget to file bugs with other vendors, too!

Twelvetide, Day 8: Check the Competition

This is the eighth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Open Source”)

When you have your management system running happily it is time to build a new one. There is much to learn by having an alternative management system up and running, even if it never leaves your testing environment. You will have to question and re-analyze many of your scripts, workflows and presumptions. You will become a better sys admin in the process.

Since you built a solid testing environment after Day 3, you can dedicate part of your testing infrastructure to building a second environment for testing an alternative management system.

If you have a commercial management system, then Munki is the obvious choice for an alternative server. If you have Munki running, you can usually get a demo license for one of the commercial servers. Even if you come to the conclusion that the management system you started out with is the best for your setup, you find pieces of your workflow that can be improved while re-building everything in a different way.

This doesn’t just hold for the management system, but also for the imaging system (DeployStudio, Imagr, Casper Imaging etc.) or your packaging tool (Jamf Composer, Packages, pkgbuild, munkipkg) or any other tool really.

Twelvetide, Day 7: Open Source

This is the seventh part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Automate”)

I have already mentioned open source projects in previous days’ articles. There is a great and vibrant open source community among Mac admins. You can take part by just using the tools, but if you got into git and GitHub (follwing the Day 4 resolution) you can also, fork and extend and contribute.

Some projects are larger and complex, others are just quick simple tools.
Munki: open source Mac management system
autopkg: automate package download and creation
Imagr: automate netboot installation
AutoDMG: automate system image creation
AutoCasperNBI and AutoImagrNBI: creates netboot image sets for Casper and Imagr
BSDPy: cross-platform NetBoot alternative
NoMAD: alternative Active Directory connection without permanent binding
outset: provides hooks for login and startup scripts
ProfileCreator: (still early development) UI tool to build configuration profiles
micromdm and commandment: both still in development, open source projects to create MDM servers
osquery: cross-platform endpoint monitoring

This list is far from complete. There are so mnay other interesting tools. Tim Sutton has a longer list just for Python MacAdmin tools.

Twelvetide, Day 6: Automate

This is the sixth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Replace a Legacy Practice”)

There a many tedious and repetitive tasks for system administrators that are ripe for automation. However, automation always brings with it an initial time cost. You need to put time and effort into analysing the task and writing an script or tool to automate. In some cases the time invested may not pay off.

Even if you do not know how to code (yet! see: Day 2) you can profit from the automation tools others have written. Most management systems have some level of automation, and hooks to extend that.

  • autopkg and AutoPkgr: tools to automate detection, downloading, re-packaging and import of software.
  • Recipe Robot: tools to automate the creation of autopkg recipes to automate the download and packaging of software (very meta)
  • outset: outset lets you put scripts and packages in a folder structure to be executed at login or startup etc.
  • Imagr: automate NetBooted installations
  • python-jss: access to the Jamf server API through python
  • quickpkg: quickly build packages from dmg or zip wrapped applications
  • munki-pkg: automate package building
  • mcxToProfile and makeProfilePkg: simplifies the creation of configuration profiles and installer packages to install them
  • Managing Printers With Munki: process can also be transferred to other management systems

Twelvetide, Day 5: Replace a Legacy Practice

This is the fifth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Version Control”)

If you have been doing Apple Administration for a few years or more, you will appreciate how quickly the environment is changing. The amazing rise and popularity of iPhones and iPads ahve forced Apple and Apple admins to revisit many aspects of management. Not only has Apple drastically advanced the MDM spec (though I would still argue it is far from complete) but Apple administrators have developed and publized many new practices.

Imaging

It is not that long ago that “monolithic” or “golden master” imaging was the most common practice to preload Mac with the OS, applications and configurations. However, there are many issues with this setup as it is very hard to prepare and even harder to manage and update once it is deployed. Apple likes to introduce new hardware with specific OS builds, and you would have to re-build your entire image for new Macs.

The next step is what I call “thick imaging” (the names for Imaging are not used consistently among Apple admins). This involves build a large monolithic image with tools such as AutoDMG, CasperImaging or FileWave Lightning. This will create a never booted, hardware independent (except for those pesky new macs with new specific OS builds) image. Getting the process to build this “thick image” with scripts, configuration profiles and package installers can be very tedious. However, once you have the workflow. You can re-create new images after a software update quite easily. When you use target disk mode over Thunderbolt or USB3 you can re-image huge images very, very quickly. Use this practice when you need to be able to re-image machines fast, like in a classroom or laptop loaner setting.

Next more advanced step is “thin imaging”. Here an admin will lay down the base OS and install the client software and configuration needed to connect to a management system. (Munki, Jamf Pro, Filewave, etc.) Then the management system takes over and installs all necessary configuration and applications or provides them as optional installations to the user.

You can either find a way to install the management client on the existing OS (Target Disk Mode, Recovery HD) or create a base OS (like thick imaging, but just the management client settings) and lay that down with NetInstall or disk-to-disk imaging.

Finally, with MDM and Apple’s Device Enrollment Programm (DEP) you can give up on ‘imaging’ entirely. When a Mac enrolls into an MDM service, client software for a management system can be installed and take over more installations and configurations from there. When a device is registered with DEP at purchase it will be enrolled with your MDM automatically at first boot and after every clean re-install.

This is likely the way Apple wants to move the macOS management strategy in the future. It is after all the only option with iOS.

Other Legacy Practices

Local MCX

It used to be a great trick to put enforced configuration settings (MCX) into the local directory (where the local users are stored). At the time this solution was introduced it solved a few problems for which there was no other solution. Now, Configuration Profiles, wether pushed from an MDM or installed locally solve those problems. You should be moving all settings that can be managed to Configuration Profiles. And you should file bugs with Apple for those settings that cannot be managed with Profiles.

Login Hooks

While login hooks still work with macOS Sierra they have been deprecated for a while now. The modern supported alternative is to use Launch Agents. Thankfully, you do not have to re-invent the wheel and build launchd property lists for everything, but you can use outset instead.

Capturing Files for Installer Packages from Disk

Composer encourages this practice by default. However, there are many pitfalls with this. When you can, you should install or build packages directly from the disk image or archive downloaded. Capturing files should be a last resort for truly horrible installers, not a common practice.

You can read more about building proper installers in my book “Packaging for Apple Administrators” is on sale!

Twelvetide, Day 4: Version Control

This is the fourth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Test”)

Version Control is one of those habits that are a bit hard to get into, but once you have, you will wonder how you ever did without.

If your organization already has a version control solution and infrastructure in place, it is probably best to use that. There should be documentation, experienced users, and best practices which can help you get started.

If you are entirely new to this, however, git is probably the best place to start. git and GitHub are also very popular in the Mac admin community.

The easiest way to install git on macOS is to download and install Xcode. You can get Xcode for free from the Mac AppStore or from the Apple Developer download page. You can also get a standalone installer from the git page directly.

Version Control systems work best against text based files, such as code, xml, html and plain text or markdown files. However, they are not entirely useless when applied to files stored in a binary format.

The command line tool git has everything you need to start with version control. You can have local repositories or connect to a server over http[s] or ssh. Xcode and most text editors have git integration built in. There are a plethora of GUI git clients to choose from.

There are countless tutorials and books available. An astonishing amount of them are free:

Twelvetide, Day 3: Test

This is the third partof a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Learn to Code (again)”)

Building and maintaining a testing environment is crucial for good system administration. Every bug, error and problem that you, your team and your testers catch during the testing and beta phase is one less problem that you may have to “urgently” fix right now for some user.

As admin you want to test every configuration, and every script or package that configures something.

A good testing environment helps you catch and identify problems early and efficiently.

I believe a good testing environment should have three tiers.

Tier 1: Virtual Machines

Virtual Machines are great. They can be quickly created, duplicated and destroyed. You can have VMs with different configurations available and only start those that you actually need.

There are currently three major VM solutions that allow you to virtualize macOS:

All of these provide snapshots, a feature that let’s you ‘freeze’ a system in a given state and quickly revert to it, discarding changes you made in between.

Your first level of testing should be against a ‘clean’ macOS system. I.e. a system which has a little configuration applied to it as you can get away with. Usually you will have to create a user or two, configure the network, enable remote access with ssh and/or screen sharing, apply updates and security patches and any tools or drivers the vm solution may require.

The next level of testing should be against a virtual machine that is connected to your management machine and setup in way that is as close to your production machines as possible. This way you can test all the interactions between software and configurations. This may include testing the imaging/system installation process over NetBoot et al on the VM.

You need a clean and a managed virtual machines for every major macOS/OS X version you support. (and possibly a few of the recent minor update versions as well)

Tier 2: Real Hardware

Virtual machines are great and flexible and will usually allow you to home in on most software realated issues quickly. However, sometimes you will get problems that come from interaction with hardware, that you cannot re-create in a VM. You should always verify everything on “real” hardware that is representative of what is being used in your deployment. With Apple’s habit of delivering new hardware with new ‘special’ versions of macOS, you need to have new hardware for testing as soon as it is going to be deployed (or before).

Also test everything on different network environments. Today that can be on wired network, (corporate) Wi-Fi, public (guest) Wifi, and from outside the network (home/hotel/coffee shop network). And once again you need to test this for every major macOS (and some minor) macOS version you support. This is harder to achive on real hardware, but large hard drives and multiple partitions are obviously a good place to start.

Tier 3: Beta Users or Machines

Depending on your deployment identify a group of users and/or a group of machines that can be used for early release/beta testing. For users, you want to look for users that can identify and report problems in a way that helps you with the fix. You do not, on the other hand wnat users that will fix the problem on thier own and never tell you. If you have a machine based deployment (labs, classroom, kiosks) you either want machines that are physically close to you, or managed supervised by a lab tech with good error reporting skills.

In both cases you want machines that are not critical for day to day business and can easily or quickly be replaced. (For example we did not install the early release on podium/lecture Macs, unless we had a spare available.) However, you do want to have early release/beta machines in all use scenarios.

You could have multiple groups of early release users, or alpha/beta groups. This really depends on how much testing you need or want to do.

Tier 4: Production

Not really a testing tier any more. You can stagger rollout into production, to give you another chance to catch any issues. Depending on the size of your deployment you may do this to lessen the load on your servers anyway. You should always have a rollback plan (and test the rollback plan!)

Servers

And now that you have a good testing workflow for your clients, you also need to build a plan a testing strategy for updating your management servers.

Twelvetide, Day 2: Learn to Code (again)

This is the second part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Read a Book”)

Knowing how to write scripts and code is very helpful for an administrator. Even basic scripting skills will go a long way.

macOS provides has a plethora of scripting and programming languages available. Even if you already know one language, adding another to your tool box can be very helpful. Different languages have different strengths and weaknesses. Also, sometimes just looking at a problem through a different view point, i.e. trying to solve it with a different language can be very insightful.

I believe these languages are most important for an Apple administrator:

  • shell scripting, bash
  • Python
  • Swift, Objective-C, Cocoa
  • AppleScript

Shell Scripting, bash

Since macOS is a UNIX, there is a shell to execute Unix commands and scripts. On macOS the default shell is bash. bash has been around for a long time. You can write very complex and powerful scripts. However the syntax is often quite arcane and there are many pitfalls for the unexperienced scripter.

bash on macOS has one major advantage over Python in that bash is included in the minimal OS used on the Recovery Partition or installer systems (for NetInstall). So if you want to use scripts there, you can’t use Python, but bash will work. Since custom packages can be installed at this stage, scripts included in packages should also be shell.

Python

Python is very popular among Apple administrators. Its learning curve is not as steep as bash or Perl. It’s syntax is much less cryptic, even though Python is odd about whitespace. (I think that mandatory indenting is a good idea, but Python can be very picky about what it considers ‘good’ indenting.)

While Python is comparatively easy to learn, you can build complex and powerful tools with it. Munki, AutoPkg and Reposado are some tools for admins written in Python. Tim Sutton has a very thorough list of open source tools for admins in Python.

When you learn Python, note that the Python version included with macOS is 2.7, which is distinctly different from Python 3. It’s not that you can’t switch from one Python to the other if you’ve learnt the ‘wrong’ version. However, you will have to download and install Python 3 seperately on macOS. (It can co-exist with Python 2.7.)

Swift, Objective-C, Cocoa

Swift is a very exciting, comparatively new programming language. Apple started the project but has since made it open source. Apple clearly plans Swift to be the successor for Objective-C. So far most of the macOS and iOS frameworks (collectively known as Cocoa or Cocoa touch) were native in Objective-C. They still are, but Apple is transitioning them to also have a Swift interface.

So with Swift you get native access to the macOS frameworks, but can also use it cross-platform, on servers or in command line scripts. You could also use the same language to write UI macOS or iOS applications. This makes Swift very interesting for the Apple administrator.

As a downside, since the language is new, it has changed drastically from version to version (it is now on version 3.0.1). However, the fast pace of the initial releases is expected to slow down somewhat now.

AppleScript

AppleScript is certainly an awkward language to write with. But there are still some things, especially when it comes to inter-application communication, where AppleScript is the fastest, easiest and sometimes the only way to go.