Anyone who supports graphic designers learns to hate fonts. As tiny pieces of software loaded directly into the operating system, they're responsible for more than their fair share of system issues. So it goes with Tiger users whose systems freeze up on login, displaying nothing but their desktop background and a lonely spotlight icon in the upper left corner of the screen. The issue is so common, it's worth talking about for any shop that hasn't yet adopted Leopard. And like so many common problems, this one comes down to fonts again.
If you've got a box in this not-uncommon state, the important thing to remember is that it isn't locked up completely. The graphical interface may be frozen, but the Unix subsystem is still running just fine underneath. It's for times like these that it's so useful to have SSH (Secure Shell) enabled on client machines, which is done by checking "Remote Login" in the "Sharing" pane of System Preferences.
Faced with a machine that consistently lets users log in, but get no further, the problem is very often a corrupt font cache. This causes the system to have issues rendering type, prevents the menu bar from displaying properly, and therefore stops the login process before the user can take control of their work environment (even after reboot). One way to correct the problem is to type the following from the Terminal of another machine:
ssh USER@MACHINE 'rm -r /Library/Caches/com.apple.ATS/*'
Replace USER with the name of any administrative user, and MACHINE with the hostname or IP, belonging to the workstation. You'll be asked for that user's password, after which the command will remove the Apple Type Server caches from the frozen machine, and with them this issue. You can then safely restart, and login (as well as fonts) should function normally again.
Special Thanks: We were reminded of this problem (and this succinct solution) by Aaron Robinson, systems administrator at Seattle's fine Hornall Anderson Design Works.
Recommended Reading: For more information on corrupt font caches (and some products to clear them without the command line), you can check out the CreativeTechs QuickTips blog.
Posted on 20 August 2008 by Ellis Jordan Bojar
Aside from the files an OS X Server shares across your entire enterprise, there's often the desire within individual workgroups to have private storage areas for their own projects. These group folders are essential for departments like HR and Accounting, but they can also be helpful for less security-conscious groups as a staging area before sharing their final work company-wide. Fortunately, while the process of creating these file shares isn't obvious, it also isn't complicated.
First, select a group from your Open Directory domain in the "Accounts" pane of Workgroup Manager. Then click the "Group Folders" button, and select a share point under which you'd like the group folders to appear. By default, Mac OS X uses /Groups, which comes pre-configured as a share on a new installation. Next, you'll need to choose an owner for your new folder. Your directory administrator account makes the most sense here, as you'll be using the group (not owner) attribute to determine access permissions. With these options configured, hit "Save".
For whatever reason, you can't actually use Workgroup Manager to create the folder you've just configured (as you can with user's home directories). Instead, you'll need to open the Terminal and type:
sudo CreateGroupFolder
This will build a folder for every group assigned a share point, not just the most recent, so if you're deploying multiple group folders it makes sense to run this command after they've all been set up in Workgroup Manager. This also sets the permissions for each group folder as read-only to the group itself, and only read-write to the individual user defined as it's owner. To remedy this in the Terminal, type the following, replacing PATH-TO-FOLDER with the full Unix path to each group folder:
cd PATH-TO-FOLDER
sudo chmod 770 Documents/ Library/
This will allow access by workgroups to their own group folders with a simple permissions scheme. For more complex sharing setups, you may wish to add an access control list as well, in the sharing pane of Server Admin.
Finally, if you're utilizing managed preferences in an Open Directory environment, you can set group folders to automatically mount when a member of that group logs in to their workstation. Moving to the "Preferences" pane of Workgroup Manager, click the "Login" icon, then the Items button on the far right. Check "Mount share point with user's name and password" and "Add group share point", then click "Apply Now".
Not only can each workgroup have their own private file share, but users will connect to those shares automatically when logging in to their Open Directory account.
Posted on 30 July 2008 by Ellis Jordan Bojar
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.
Posted on 9 July 2008 by Ellis Jordan Bojar
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.
Posted on 4 June 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
Earlier Posts »
