Flush Network Caches

You've just installed a new hardware firewall with the same IP as one that's being replaced. Your routers can all see it, but traffic from your Macs seems to just disappear. Or you've renamed a series of servers the whole company uses, and the Macs can only find them by IP now. You know you can just reboot the problem machines, like you'd power-cycle an unmanaged switch, but that solution is impractical during business hours (and time-consuming on nights or weekends). How can you force a couple hundred Macintosh computers to update their network caches?

The ARP (Address Resolution Protocol) DNS (Domain Name System) caches are very different, but they server very similar purposes. ARP tables hold the information mapping ethernet MAC addresses (0a:1f:b5:c0:8e:4a) to network IPs (192.168.0.75), while DNS servers translate fully qualified domain names (like router.makemacwork.com) into IP addresses. Both types of information are cached to make subsequent lookups faster, but when changes take place on your network it's hard to predict when that information will get updated.

Fortunately, it's trivial to flush these caches on the Macintosh command line, and those commands can be sent to hundreds or even thousands of machines at once using Apple Remote Desktop's "Send Unix Command..." function.

On individual machines, you can clear the ARP cache in the Terminal and typing:

sudo arp -d -a

The DNS cache (along with all Directory Services caches) can be reset by typing:

sudo dscacheutil -flushcache

If you're sending the commands out with Apple Remote Desktop, leave out sudo and instead be sure to set the "Run command as" user to "root".

That's all it takes to force your Macs to fetch new routing and domain information, without ever having to interrupt the people working on them.

Restrict Download Warnings

One of Leopard's less beloved security features is the warning that appears when users first open downloaded applications. Given that most software now comes from the internet, this dialog has become a common part of the average Mac user experience. In some cases, though, that one-time process never ends, displaying the same dialog at every launch. The problem is especially common when applications are installed (but not run) by an administrative user.

"Example" is an application which was downloaded from the Internet.
Are you sure you want to open it?

The warning is triggered by an "extended attribute", an addition to the HFS+ file system that allows additional information on a file-by-file basis. In this case, a tag named "com.apple.quarantine" is added to any file downloaded on Leopard by an internet application. If that signature is added by an administrative user, it can't be removed using a standard account.

The solution is to remove that attribute through the Terminal, replacing FILENAME with the actual application name and typing:

sudo xattr -d com.apple.quarantine "FILENAME"

The command can be run on individual machines or, if you've already deployed a tagged application in a system image, it can be run via Apple Remote Desktop. This will remove the quarantine attribute and put an end to the constant nagging.

Recommended Reading: The new xattr command doesn't even have a manpage yet, but what little documentation exists can be found by typing "xattr -h". An enthusiastic explanation of extended attributes in OS X ran back in John Siracusa's exhaustive review of Tiger at Ars Technica.

Restart Kerberos Manually

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.

Users Can’t Rename Their Files

You've just bought your art department new Mac Pros. You've cleanly imaged the machines, and you've carefully migrated the existing user data. Everyone loves their fast new computers, until the first call comes in. Someone went to change the name of a file on their desktop, and what they got instead was a cryptic error message:

You do not have sufficient access privileges to
rename the item "Example.psd".

You've run afoul of Leopard's "invisible" Access Control Lists. When you move an existing user's files to an account on a new system, you have to re-permission them to belong to the new account. In the past, you could just move them into the appropriate home directory, then selecting "Apply to enclosed items" in the "Sharing and Permissions" section of the Finder's "Get Info" window.

There's no indication that process works any differently now, but in Leopard certain default folders have ACLs applied automatically. Unfortunately, those default ACLs aren't displayed in the Finder as others are. User home directories use these defaults, and unknowingly propagating those permissions to the files inside can prevent users from renaming (and often deleting) their own files.

To see the access controls applied to any given file, open the Terminal and type:

ls -le FILENAME

Replace FILENAME with the full (or absolute) Unix path, like /Users/Jordan/File.txt. The shell should then return a file listing that includes your ACL information:

-rw-r--r--+ 1 Jordan staff 0 Apr 1 20:00 File.txt
0: group:everyone deny delete

That second line, the default applied to certain OS X directories, is at the root of this issue. It denies the group "everyone", to which all users belong, the ability to delete (and therefore rename) the file in question.

To remove this access control entry from individual files, type:

sudo chmod -a "everyone deny delete" FILENAME

For entire directories, replace FOLDERNAME with the appropriate path:

sudo chmod -R -a "everyone deny delete" FOLDERNAME

Leopard install DVDs include a new option in their "Reset Password" utility to "Reset Home Directory Permissions and ACLs". That's fantastic, but it only resets Apple's default user directories. Used judiciously, the above commands can restore all files and folders to their original ACLs, allowing users to happily rename and delete their data once again.

Special Thanks: This problem was solved by Jasson Lewellen, who handles Apple hardware repairs and corporate maintenance at CreativeTechs, and let me steal his great solution to meet my deadline.

Secure Instant Messaging

In many business environments, instant messaging has replaced email (and even the telephone) as the tool of choice for brief and casual contact. While easy, real-time chat has been embraced by most users, it still poses a number of challenges for network administrators. Most message services use no encryption by default, run your private conversations through their own servers, and offer no means to retain a permanent record of what could be important business communications. Running your own iChat Server can solve those problems.

In Server Admin, select your server from the left column, then click "Settings" from the toolbar. In the "Services" pane, check "iChat", and save your changes at the bottom of the window. Now choose the iChat service on the left, then hit "Settings" once again and begin with the "General" configuration pane. The current hostname of your server will already be listed under "Host Domains". If you'd prefer to use a service-specific name, such as ichat.makemacwork.com, you'll need that set up in your DNS listings.

Next, select the SSL certificate you'd like to encrypt message traffic with. You can use the unsigned "Default" certificate that's created by OS X Server, but many Jabber clients (including Apple's own iChat) will complain that they can't verify the server's identity. If your company doesn't already act as it's own certificate authority, it's easiest to use a third-party vendor such as Digicert, Thawte, or Go Daddy.

For "Authentication", Kerberos is the most secure option, but becomes unwieldy for users outside of your domain. The "Any Method" option will use Kerberos when possible, and otherwise default to a username and password. If you're required by law or policy to archive chat transcripts, move to the "Logging" pane, and check "Automatically save chat messages". When you're finished, click "Save".

Now everyone with a user account on your server can log in using any "Jabber-compatible" client. This includes iChat and Adium for Macintosh, as well as Trillian and Pidgin for Windows, among others. If you're planning to offer instant messaging from outside your office (for traveling employees, clients, or vendors) you'll also need to forward ports 5060, 5190, 5222, and 5223 through your firewall for this configuration.

Finally, there's one feature in Leopard's "Standard" server setup that somehow missed inclusion in the more flexible and configurable "Advanced" option. To automatically add every iChat user to every other user's Buddy List, you'll currently need to run the following on the command line after each user logs in initially:

sudo /usr/bin/jabber_autobuddy -m

Keep in mind that "Auto-Buddy" is a neat idea for small workgroups, but can quickly become unwieldy as your user base grows. If the feature appeals to you, it makes the most sense to automate the process by adding a launchd script that runs the command on a scheduled basis.

With these steps in place, anyone involved with your organization can send and receive secure instant messages through your OS X Server.

Recommended Reading: To learn more about the Jabber protocol (on which iChat Server is based), check out the information at Jabber.org.