We've written about launchd (the daemon which governs OS X system processes) before. We've detailed its xml-based syntax, even as we've struggled to remember every tag and attribute. We could have saved ourselves the trouble and pointed to Peter Borg's Lingon, the free graphical editor for launchd plist files.
Inexplicably named for a swedish berry, with an icon like the giant red ball from Alias, Lingon's odd presentation quickly gives way to its powerful and convenient functionality. Its main panel allows you to create and edit launchd jobs with just their names, the Terminal command or script they run, and their scheduling options.
An advanced mode offers syntax-colored construction of the full range of launchd options (such as inetd compatibility, hard resource limits, and listening sockets). For power-users, Lingon is a tremendous time-saver, eliminating a great deal of referencing and proofreading for what amounts to an occasional task. For the novice, it's like Dreamweaver for dangerous system modifications.
Lingon has one major annoyance: The inability to save files anywhere other than live system directories. This isn't so bad if you're composing your plist files on a system that's meant to run them. If you're composing a launchd job for another machine (or many others), you must save it first without enabling it, then fish it out of the directory Lingon squirreled it away in. A "Save As" feature would go a long way here, and the absense of one could cause serious trouble for a careless user.
Despite its eccentricities, Lingon is an impressive tool, simple when it needs to be and complex where it has to. It's also a generous open-sourced contribution to the Macintosh administration community.
Lingon is available free of charge.
Posted on 28 May 2008 by Ellis Jordan Bojar
The Kerberos authentication protocol is an encrypted ticketing system at the heart of Apple's Open Directory. It is the basis for Mac OS X's "Single Sign On" features, and a required component for integration with Windows Active Directory domains. Unfortunately, it's possible for the Kerberos service to stop functioning properly, and when it dies, a good number of your network services die with it.
Ideally, you can simply click the "Kerberize" button in the "General" pane of Server Admin's Open Directory settings. That should restart the service. This article for when you find yourself in less than ideal circumstances.
Why Kerberos Can Stop On OS X Server:
When the Kerberos service fails, the likely culprit is a DNS issue. This isn't the only reason Kerberos can break, but it's most common and the easiest to test for. The Kerberos KDC service (or Key Distribution Center), requires matching forward and reverse DNS lookups, and changing a server's hostname or IP manually (or losing connection to your DNS servers) can require the machine to be re-Kerberized. Since Tiger, Mac OS X has also been designed to dynamically set a machine's hostname on boot using a reverse lookup, meaning that external changes to a server's DNS listings can cause it to change names and break its original Kerberos realm.
Before you try to restart Kerberos, you'll want to know which (if any) of these things went wrong. If you aren't sure how to go about this, check with whomever in your organization controls Domain Name Service, or use the procedure from the beginning of our article on setting up Open Directory.
How To Start Kerberos From The Command Line:
Once your server is properly registered in DNS, you can begin reconstructing your Kerberos realm. The first step is to create a new edu.mit.Kerberos file, which Mac OS X can fortunately do (somewhat) automatically. Open the Terminal and type:
sudo kerberosautoconfig -r REALM -m HOSTNAME
For this command, HOSTNAME is the fully qualified domain name of your server, such as server.example.com. REALM is the server's DNS name again, but this time in all capital letters, like SERVER.EXAMPLE.COM. Next you'll create a KDC database for the new Kerberos realm:
kdcsetup -f /LDAPv3/127.0.0.1 -w -a DIRADMIN -p PASSWORD REALM
Here DIRADMIN is the name of any user with directory administration privileges, and PASSWORD is their actual login password. Once that's done, you can Kerberize the server's Open Directory domain with the following:
sudo slapconfig -kerberize -f DIRADMIN REALM
Finally, configure the Single Sign On mechanism to utilize Kerberos authentication for all applicable OS X services.
sudo sso_util configure -r REALM -a DIRADMIN -p PASSWORD all
This should once again leave you with a fully-functioning Kerberos installation on your Open Directory server, all without ever having had to reboot the machine.
If you're following this procedure, keep one additional things in mind: Because the kdcsetup and sso_util commands unfortunately requires that you provide a password on the command line (and therefore store that password in your command history), it's good security practice to change that user's password immediately after this process.
Recommended Reading: For an illustrated overview of the Kerberos authentication Process, there's the handy Kerberos Chart [PDF - 72KB] at Computer World. For more depth into how Kerberos works on OS X, there's an excellent three-part article at AFP548.com.
Posted on 21 May 2008 by Ellis Jordan Bojar
If your job is to administer Macintosh computers, odds are that much of your time is spent working with Adobe's Creative Suite. And while many have been tempted to uninstall CS3 out of frustration, removing Creative Suite entirely can be an important troubleshooting step when faced with a corrupt, damaged, or expired installation.
The only way to completely remove Creative Suite 2 from a system is do so manually, using the list of CS2 files posted at Adobe's own support site. Unless you have a pressing need to continue using the older version, it's best to remove it before ever even installing CS3.
Loading Creative Suite 3, on the other hand, isn't always as easy as following a checklist. The installer can become convinced that some or all of the suite is already present, even when there isn't any usable software available. For this very reason, Adobe has a script to uninstall the Photoshop CS3 beta, the non-bundled version of Acrobat 8, or even just a previous install that somehow went wrong.
CS3Clean, once double-clicked, runs in the Terminal to remove every application, file, preference, and driver that might be preventing a fresh installation. The script offers three "levels" of cleaning, the first removing everything *but* Acrobat 8, the second removing all CS3-associated files, and a mysterious third option which isn't listed (or explained) but is often recommended by Adobe's phone support representatives.
The script also uninstalls CS3 in about 10% of the time the programs actually take to install initially. That means that rather than installing CS3 individually on the machines that require it, you can often save time by including Creative Suite in company-wide disk images, then removing it on the workstations where it isn't needed.
Recommended Reading: If you're considering a full uninstall procedure to merely address a licensing issue, check out how to reserialize Adobe CS3 instead at the CreativeTechs QuickTips blog.
Posted on 14 May 2008 by Ellis Jordan Bojar
When you're at your desk, or have your laptop with you, remote control of other Macintosh computers is easy with Apple Remote Desktop. When you're running from desk to desk, trying to solve everybody's problems before their next big deadline, remote support can be a little trickier.
Leopard's new Screen Sharing feature is a big help. Browse to the "Shared" section of the Finder sidebar, and you can select the machine you'd like to control. Click the "Screen Sharing" button that appears in that window, and type in a username and password.
The only drawback is that Remote Desktop features like curtain mode (which shields the screen from all but the remote user), quality control (which allows you to adjust the appropriate color depth for your bandwidth), and full screen rendering aren't available in the basic Screen Sharing application. At least, not by default.
To take advantage of the full complement of remote control features (though none of Remote Desktop's deployment or reporting functionality), you simply need to edit the screen sharing preferences. Log in as an administrative user, and in the Terminal type the following, replacing FEATURESET with a comma-separated list of any of the following controls you'd like to add: Scale, Control, Share, Curtain, Capture, FullScreen, GetClipboard, SendClipboard, and Quality.
defaults write com.apple.ScreenSharing \
'NSToolbar Configuration ControlToolbar' -dict-add \
'TB Item Identifiers' '(FEATURESET)'
If you find yourself using these features often from machines other than your own, you may wish to simplify things even further, and add Screen Sharing to the administrative account's Dock. Simply drag it onto the Dock from it's home in /System/Library/CoreServices/, being careful not to move the original.
Now you've got 90% of Remote Desktop's troubleshooting tools on every desktop, without having to pay for additional licenses.
Posted on 7 May 2008 by Ellis Jordan Bojar
