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.

Twelvetide, Day 1: Read a Book

This is the first 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!

Well, yes, I wrote a book and I would be grateful if you bought and read it.

However, there are many other good and useful books for Apple Administrators. First, obviously, the canonical “Managing Apple Devices” by Arek Dryer and Kevin White. (iBooks, Amazon US UK DE) This is the official book that is also used in many macOS management trainings. We are still waiting on the iOS 10/macOS Sierra version, but it is worth it to keep up to date.

The other books I like to recommend are for the command line:

  • “Take Control of the Mac Command Line” by Joe Kissel, iBooks, Amazon US UK DE
  • “Learning Unix for OS X” by Dave Taylor, iBooks, Amazon US UK DE
  • “Classic Shell Scripting” by Arnold Robbins and Nelson H. F. Beebe, iBooks, Amazon US UK DE

I have not read these, but it they are on my reading list:

  • “Enterprise Mac Administrators Guide” by Charles S. Edge Jr. and William Smith, iBooks, Amazon US UK DE
  • “Enterprise Mac Security” by Charles S. Edge Jr. and Daniel O’Donnell, Amazon US UK DE

Books on Computers tend to be on the expensive side, but there are also great free resources online. I started a list, but then stumbled over this one list of free books to rule them all.

Enjoy!

Twelvetide: 12 Resolutions for Mac Administrators

Merry Christmas and Happy Holidays!

According to Wikipedia ‘Twelvetide’ is another word for the ‘Twelve Days of Christmas.’. I am going to do a Twelvetide feature on this blog. There will , however, be no partridges, doves, milking maids and leaping lords. No golden rings either, sorry.

Instead, I will introduce twelve resolutions for how to become a better Mac Administrator. Not I believe I am the sole authority on this, but these are things that I want to do more, or do better or start doing in the next year. And I thought sharing these and writing them on the weblog might help others. Also, sharing what you do is one of the resolutions.

To go along with the resolutions, I will reduce the price of my book “Packaging for Apple Administrators” by 20% for the Twelvetide (through Jan 6, 2017). Yes, “reading a book” is also a resolution, but it does not have to be mine.

Happy New Year 2017!

Holiday Deals for Mac Admins

Several apps on the iOS App Store and Mac App Store have dropped prices for the holidays:

Also, my book “Packaging for Apple Administrators” is on sale for 20% less! Go get it and read it over the break!

The following apps are not necessarily just for admins I but I use and enjoy them all regularly:

  • TweetBot is simply the best Twitter client. Both iOS and Mac versions are on sale until Christmas Day
  • Deliveries is the best package tracker and will sync packages tracked between the Mac and iOS versions. Both iOS and Mac versions are on sale
  • Mini Metro is a fun puzzler where you have to build and maintain an insanely fast growing urban metro system.

Merry Christmas!

Duet Display adds Touch Bar

I like to use Duet Display to add some screen real estate to my 13" MacBook Pro. When you connect the iPad with a Lightning cable Duet turns it into an external second screen. Depending on your settings there can be a slight lag, so you won’t play action games, but it works wonderfully for normal tasks (such as writing a book.) It will also translate touch input to mouse inputs and if you have an iPad Pro it also works with the Apple Pen.

I have the 2015 MacBook model, so no Touch Bar and I have no urgency to upgrade yet, even though I think the Touch Bar seems to be very interesting.

So, I am very excited to see that Duet Display added an option to add a Touch Bar at the bottom of the iPad screen). Since the iPad will probably be sitting next to your MacBook screen, rather than right above your keyboard, this is not perfect. But a great way to test an application’s support and see how the Touch Bar works without having to shell out for a new MacBook. This will take away a bit of your second screen on the iPad, but you can enable or disable the Touch Bar at whenever you want.

They have also reduced the price for the iOS application by 50% ‘for a limited time.’ Duet Display uses a Mac or Windows application, which is free and an iOS application which usually costs US$19.99 (now $9.99). Full Apple Pen support which turns the iPad Pro into a retina drawing pad for your Mac is an extra in-App purchase.

Book Presentation at Dutch MacAdmin Meetup

I will be presenting my book at the MacAdmin meetup/ontmoeting in Schiedam (Netherlands) next week. The presentation will be on my first book “Packaging for Apple Administrators” with a sneak peek in to future projects.

The meet up will be on Tuesday, Dec 20, 13:30-16:30. LAI has been kind enough to host it at their offices.

My presentation will only be a small part of the meeting, there will also be a discussion on Active Directory and NoMAD and maybe some other presentations.

It’ll be great to see you all there!

On hidden Files, especially Library

I published a book: “Packaging for Apple Administrators

While writing on the next book “Automated Packaging for Apple Administrators”, I will keep publishing small side notes and excerpts. There is a nice gem for macOS Sierra in the last section, so keep reading.;)

Mac OS X has always hidden certain folders and files from the user. The more ‘UNIXey’ folders like /usr, /bin, and /etc were considered too confusing or even dangerous for most users and hidden away. Most users noticed this in OS X Lion when Apple started hiding the user’s Library. Messing with files in the Library can cause damage or data loss if a user does not know exactly what they are doing. Here is the summary on hidden and invisible files.

Dot Files

In UNIX, files or directories with a name beginning with ‘.‘ (period or dot) are considered hidden and will not be shown in a normal file list with ls. You can however easily list them with the option ls -a. Usually dot files are configuration files or folders.

When does Finder consider a File hidden?

Like the ls command Finder will not show files beginning with a ‘.‘ (period or dot). However, there is also an extra hidden flag that Finder will check to see wether it should hide a file. You can see this hidden flag in Terminal with the -O (capital o) option for ls

$ ls -lO 
drwx------+ user  staff  -        Downloads
drwx------@ user  staff  hidden   Library
drwx------+ user  staff  -        Movies

(I removed lines and columns to make the output more legible.)

You can also use the find command to show all files with the hidden flag:

$ find ~ -flags +hidden -print

Use the chflags command to set or unset the hiddenflag:

$ chflags nohidden ~/Library
$ chflags hidden ~/Library

Finder will show or hide the file or folder immediately.

Navigating to your hidden Library

When you click on Finder’s ‘Go’ Menu with the option key, Library will appear as an option.

You can also use Finder’s ‘Go to Folder…’ menu and enter ~/Library as the target. This is especially useful since you usually want to go to a subfolder of Library anyway. This panel supports tab-autocompletion like the shell. OS X 10.11 and earlier would autocomplete to the alphabetically first match so ~/Library/Pref would complete to ~/Library/PreferencePanes rather than ~/Library/Preferences. macOS Sierra will show a popup list if the completion is ambiguous. The keyboard shortcut for ‘Go to Folder…’ command-shift-G will also work in open and save panels.

If you are already in a Terminal window you can use the open command:

$ open ~/Library/

Show all hidden Files and Folders

macOS Sierra has added a great Finder keyboard shortcut to quickly show hidden files and folders. Command-Shift-. (dot or period) will quickly show all hidden files and a second time will re-hide them.

This keyboard shortcut has worked in open and save dialogs for a while already.

In older versions of OS X you have to open Terminal and run:

$ defaults write com.apple.Finder AppleShowAllFiles true
$ killall Finder

Change the true to false to switch it back.