The small corner of the ‘net I inhabit is already abuzz with things that have broken with the Mac OS X 10.4.10 update. Software seems to be breaking not because of significant changes in this update, but because of poor version checking routines.
Awesome — isn’t it?
Anyway, here are some reports I’ve heard:
Yeah, I know … I guess I’m becoming a Python fanboy. Apologies.
I’ll admit it: I’m a bit slow when it comes to the shell. I use it a lot, but never feel like I’m using it as well as I could. But today, I figured out how to turn on Z Shell completion system. And it is very, very good.
This guide helped me, leading me to add the following to my .zshrc file:
autoload -U compinit
Once I’d done that, I could begin completing various commands and parameters. Within a few moments, using the tutorial above, I’d already completed:
This is cool.
When scripting for system administration, it’s often helpful to know what edition and version of Mac OS X is installed.
By edition, I mean whether you are using Mac OS X or Mac OS X Server — Server generally being a superset of the client operating system. The version, of course, is an indentifier such as “10.4.9” or “10.3” or “10.2.8.”
Given the version number, you can deduce the marketing name of the system software: “Tiger,” “Panther,” and “Jaguar,” respectively. Interestingly, I’m aware of no string in the system that identifies that marketing name; even “About This Mac” in the Apple menu does not display it. (However, you can find all of the names in the Mac OS X entry in Wikipedia.)
You can obtain the version information in a number of ways. From a scriptability standpoint, the quickest way to the chase is probably the
sw_vers utility. The basic usage and output looks like this:
ProductName: Mac OS X
… but you can also, as of Mac OS X 10.3 or later, narrow it down to get just the string you want. (Note that you can only run
sw_vers, without modification, in Jaguar and earlier.) So, if you just need the ProductVersion, ask for it:
$ sw_vers -productVersion
One drawback of this solution is that you can only get the version information for a running copy of Mac OS X. According to its man page,
“prints version information about the Mac OS X or Mac OS X Server operating
system running on the local machine.” It can’t detect the version of a
non-running Mac OS X installation.
Happily, the same information is stored in two property list files in the /System directory. Therefore, you can read the version data directly from these plist files.
… where $volume is the path to the target volume. The ServerVersion.plist file does not exist on workstation/client edition of Mac OS X. The mere presence of the ServerVersion.plist, therefore, indicates that you have encountered Mac OS X Server.
So, from the command line, you could enter:
$ defaults read /System/Library/CoreServices/SystemVersion 'ProductVersion'
… or even …
$ defaults read '/Volumes/Mac OS X Install DVD/System/Library/CoreServices/SystemVersion' 'ProductVersion'
Reading the plists comes in handy if you’re trying to detect the version of Mac OS X on a disk other than the current startup disk, where
sw_vers fails. This means you can even detect the version of Mac OS X installed on Apple’s boot CDs and DVDs!
The plist method is also useful if you’re using a scripting language — such as Python, with its plistlib module (I’m sure there’s something for Perl, too … and you could also try
defaults as above) — that can read them. If the files can be read directly, you don’t need to call out to a shell command, even one as simple as
defaults, from within the scripting language. That means you won’t be spawning an additional process, and your scripts can therefore gain a slight speed increase.
Here is example
defaults output from a running Mac OS X workstation (a Core 2 Duo-based MacBook Pro):
ProductBuildVersion = 8P2137;
ProductCopyright = "1983-2007 Apple Inc.";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.4.9";
ProductVersion = "10.4.9";
And from a Tiger install DVD, originally for PowerPC:
ProductBuildVersion = 8A428;
ProductCopyright = "1983-2005 Apple Computer, Inc.";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.4";
ProductVersion = "10.4";
To show that this is not a fluke, here’s the same result from a Panther install CD (you must use Disc 1, as it is the startup disc in the set):
ProductBuildVersion = 7B85;
ProductCopyright = "Apple Computer, Inc. 1983-2003";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.3";
ProductVersion = "10.3";
I expect that this applies all the way back to Mac OS X 10.0 from March 24, 2001. To date, though, I’ve verified this behavior as far back as a Jaguar install CD:
ProductBuildVersion = 6C115;
ProductCopyright = "Apple Computer, Inc. 1983-2002";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.2";
ProductVersion = "10.2";
Update: I did run the same test on a Mac OS X 10.0 install CD from 2001. The results show that you can use the property list reading method to obtain the version information for any release of Mac OS X:
ProductBuildVersion = 4K78;
ProductName = "Mac OS X";
ProductVersion = "10.0";
However, note that the ProductUserVisibleVersion and ProductCopyright keys are not in the plist of the Cheetah system.
The information above was adapted from my+similar+post+on+the+MacEnterprise+list.
Here is how I colorized my shell environment in Mac OS X Tiger:
I don’t recall exactly how I got to this point, but I’d never seen a hint that provided color with this level of ease — and I recently fell into a pique of wanting but not having colorized shell output.
When deploying system software with disk images, it is helpful to have various checkpoint images that you can revert to while you’re building up a fully-fledged template computer. This is something they teach you in school (really, I was taught it in a systems administration class) and it’s more or less encoded in the solution accelerator documentation for Microsoft’s Business Desktop Deployment 2007 for Windows.
However, if you’re updating images, keeping the base and intermediate images can strain your storage capacity. Mac OS X lacks the compelling live editing features of Microsoft’s new WIM image format — which if it had appeared first on the Mac, I’d be trumpeting loudly, so I feel compelled to at least give a nod to Microsoft here.
Since I’m always struggling with storage capacity and I prefer having an up-to-date base image, I thought about this problem a bit in the context of Mac OS X imaging and have come upon what seems to be a unique solution: the use of shadow files.
Here’s the basic idea:
Congratulate yourself on this use of shadow files, because you’ve saved at least one intermediate step and the space required for a full read-write disk image — or worse, an extra local partition needed only for restoration and updating the base image.
Unmount that volume and throw away the shadow file at this point if you want, because you’ve now got two system images ready for deployment. One has the base system software, and serves as a checkpoint that you can return to later; it’s the base for all future updates of that major revision of Mac OS X. The other image has the latest version of Mac OS X. If you’re deploying that image with ASR, the result will be a more secure system because it’s closer to being fully patched — and it should take less time to update it with the additional security updates and application installs — whether you use installers or Radmind or another solution — because you’ve got the bulk of the operating system done.
Unfortunately, many updates can only be installed on the startup disk and thus cannot be included in the updated base image. Beyond the combo operating system updates, few of Apple’s other installers will work on a non-startup volume. But you can install them after deploying the updated base image, using your tool of choice. For reasons like this, Geoff doesn’t see updating the base image as valuable, but in some IT environments, it may be very worthwhile.
My next step is to script this process and tie it to a watched folder. Imagine dropping a combo update into a watched folder … and letting a script generate the new, updated image for you.
Based on my reading of the MacEnterprise.org extended knowledgebase article on Mac OS X 10.4.9, some interesting changes have been made. Here are some of my comments on items listed in that article:
[Via Philip Rinehart on the MacEnterprise.org list.]
I’ve just done a quick search on zsh at Amazon. I think I’ve finally hit the final frontier — or is it just rock bottom? I’m obsessed with a technology without any books specifically devoted to it. Ha!
The closest is “From Bash to Z Shell,” as far I can tell.
Extra Pepperoni: The Apple Keychain is cool, but also strange and problematic. This article obviously caught some attention, since Perry the Cynic is the first poster in the comments. Heh.
[Via Daring Fireball.]
I figure that I’ll probably save around that much electricity per month by not having to run my server at home. I’ll regain some upstream bandwidth on my Internet connection, which can be put to other uses. And, my son will not have so many whirring fans running in his room, since we haven’t finished remodeling the room all the technology is moving to.
I had been hoping to get:
I had to compromise on several points, but ultimately the price point was important to me. I had to balance some items that I wanted versus what I felt was needed, and consider some items which could be added onto an account locally rather than by the hosting provider.
It’ll take a little time for me to sort it out, but I’ll be moving this site to my new hosting account shortly. Hopefully, I can make it happen without an outage.
I had also considered the following hosting companies, and each had compelling offerings that were just not outweighed by $5 per month. I’ll list some of the benefits and drawbacks for each of these well-reviewed major hosting firms.
In the future, I'm still considering some arrangement with Rsync.net or another off-site backup/storage provider. I think it’s an interesting time to be on the Internet, when you can really start to take advantage of some truly useful hosted services.
Geoff got me thinking about zsh last fall, and it’s on my mind again. I’m pondering a switch to it.
I’m still stuck on tcsh because it’s what I started with for my heavy interactive shell use. All my shell config files and knowledge reside in tcsh, because that’s what you used by default in Mac OS X 10.0. But, I dislike that the tcsh syntax is different than what I’m used to when it comes to shell scripting with bash. Bash is what I learned when I first took up scripting. Well, more to the point, I learned sh, and have grown a bit into using some bash-isms.
So I’m reading more about zsh, which means I’ll probably be firmly rooted in analysis paralysis for a while. But it looks good, and my chances in converting will improve if I can get my .tcshrc custom-tailoring moved over with reasonable ease.
In the meantime, here’s a search for zsh on Del.icio.us.