JAMF JSS can create Smart Groups, which are similar to Smart Playlists in iTunes or Smart Folders in the Finder. When it comes to string comparisons, the following search operators are available: “is,” “is not,” “like,” and “not like.”
OS X version comparison using strings (the introduction to this series) works with JAMF JSS. Searches with the “like” and “not like” operators do not anchor on periods, in my experience. This switches to the second kind of comparison I described in the pseudocode.
Create the first one, then use the JSS’ “Clone” function, to make additional comparisons for other OS X versions. Edit the copies as needed.
No ongoing maintenance of older Smart Groups should be required. I had previously up with a scheme that used Smart Groups relying on other Smart Groups. It required one update to the prior “and greater” group for each new OS X release. The maintenance effort can be avoided with the technique above and both produce the same effect.
Munki can use Python’s version comparison tools to perform mathematical version comparisons for the minimum and maximum OS versions and minimum Munki version specified in pkgsinfo files.
In manifest files’ conditional items, though, only string comparisons are available. The OS X version comparison using strings (the introduction to this series) technique can be useful with the “os_vers” attribute in manifests.
Conditional items use NSPredicates support for regular expressions. These searches can anchor on periods.
The OS X version comparison using strings (the introduction to this series) can be implemented with a UNIX shell script. I figured the most direct method was to use grep. I also like case statements.
These searches can anchor on periods.
This OS X version comparison solution (the introduction to this series) takes some setup for each version comparison.
Once created, the comparison can be copied or cloned to form the basis for the next comparison. The duplicate copy can be edited to create new clauses for another comparison (adding “is this OS X 10.9 or later?” and “is this OS X 10.10 or later?” when needed). It also accommodates new OS X versions without any changes, assuming that the version numbering scheme continues with either 10.x (or increments above 10.x to 11.x and beyond).
The pseudocode to answer the “is this OS X 10.8 or later?” question could be expressed this way:
If the result of evaluating those statements is true, then the OS X version is 10.8 or greater.
Note the periods: This technique works as long as the periods can be evaluated, to serve as anchors between the numbers.
In some circumstances, the periods cannot be used as anchors. In cases like that, I have dropped off checking for OS X 10.0, 10.1, and 10.2. I expect that those are the three versions most likely to conflict with any further OS X releases in the 10.x series.
These techniques can be applied in a few different environments.
There are many system administration tasks in OS X that require version comparisons. Looking back over my time managing OS X, I’m surprised that this still presents some complexities in 2015. This article is the first in a short series on this topic and presents a solution to one of the common problems.
I have found that the most robust tools for these comparisons are available in the Python Standard Library, which makes them available up through at least OS X 10.10 Yosemite. The modules in Python have the advantage of treating versions more like numbers — so greater than, less than, and equal comparisons are possible.
With Python, I believe we have at least two good choices of libraries that handle versions as versions.
I wrote about “distutils.version” just over eight years ago, after talking about the problem with my friend Steve. It offers two classes, StrictVersion and LooseVersion, that are each helpful in their own way. It is probably more popular on OS X, by the shear volume of everyday usage.
My friend Nate and I included “pkg_resources.parse_version” in our Penn State Mac Admins Conference 2013 talk, “Practical Python for Sysadmins” (slides 50 and 52). That module does the job and sounded good in PEP 386. It presents an alternative to “distutils.version” if you want one.
Many system management tools resort to string comparison. Many scripts break down strings for numeric comparisons of components. These two techniques can accomplish what needs to be done, but have they have limits.
Especially when it is all that’s available, string comparison feels very limited. I have struggled trying to figure out how to handle “greater than” or “greater than or equal to” comparisons within those confines. In my own work, that particular comparison is a common, recurring need. There are many instances when I need to answer a basic question like “is this OS X 10.8 or later?” In number line terms:
With some trial and error, I now have a way that appears to work reliably. I realized it could apply generally to different tools. I don’t know if it’s novel, since I haven’t found any references elsewhere to a similar technique. (If you know of one, I’d like to link to it.)
Find out more about this.
I found that there is a way to get only one button in a Munki preinstall alert. By default, there are two, one for “OK” and the other for “Cancel.”
The alert dictionary looks like this:
It results in a dialog with a single, default button labelled “OK,” instead of two buttons. It looks like this:
It wasn’t immediately obvious to me that setting a blank label for one of the alert buttons would make that button disappear, but I’m glad it did.
Update: This could be used for an optional deployment with conditions. It provide an indication that an installation is available but conditions need to be met.
I created an automated workflow to help me archive the OS X Installer application when I download updates from the Mac App Store. The release of OS X Yosemite and all these inadequately-labeled installer apps I have lying around at home spurred me on.
Each archived installer is saved as a disk image to /Users/Shared and named with its OS X version number and build.
The march towards responsive design — now with Size Classes — is a watershed moment for iOS. I can’t help but think that some of the moves Apple has made — and might make at its October 2014 announcement tomorrow — are centered around screens. This is all speculation on my part, but it’s been rolling around my head for a while now.
What if there’s no 5-inch iPhone 6 because Apple wants to move developers to update for Size Classes? No longer having the same iPhone screen as last year in the flagship phones is strong encouragement; both the iPhone 6 and 6 Plus demand that apps be updated. The big screens are a marquee feature of both new phones. Adding Notification Center interfaces is probably another part of this.
I could certainly see more encouragement coming from an expansion of the iPad line, adding a larger model alongside the existing 8 and 10 inch devices. Split screen display of multiple apps? More encouragement.
My conceit for some time has been that the establishment of the iPad Mini would eventually free Apple to increase the resolution and screen density of the iPad Air. There’s not necessarily a reason for the Mini and the Air to share the same resolution. Bumping up the resolution and density on the Air this year would give one more reason to throw out the pixel-perfect designs of the past. (I just hope the GPUs can handle such a move.)
Here are links to the resources related to my talk with Rich Trouton on Friday, July 11, 2014, at the Penn State MacAdmins Conference 2014.