Home Directory Helper

Anyone whose ever implemented networked home directories on and OS X Server has probably come across the need to add or remove preference files from user accounts. Changing settings for new accounts is easy, just add the files to the User Template folder.

Existing users is a different story though. They already have their home directories. Depending on how many users you have, adding/deleting files from you old users can be a daunting task. Ten users is easy enough, but 50 is silly and over 100 is ridiculous.

Long ago I wrote a series of scripts (well actually just one) that I use and modify for whatever files I need to change. I basically just loops through each home folder in a specified directory. It’s really a pretty basic script. Here’s an example of one that I was using:

# Copy new dock and fix permissions

echo "\ncpdock.sh"

dir=`ls $1`

cd ${1:?"No directory specified!"}

echo "PWD = `pwd`"

echo "\n$dir\n"

for folder in $dir; do
    echo "...copying dock plist to $folder"
    cp /com.apple.dock.plist $folder/Library/Preferences/com.apple.dock.plist
    chmod -R 700 $folder/Library/Preferences/com.apple.dock.plist
    chown -R $folder:staff $folder/Library/Preferences/com.apple.dock.plist
done

That’s easy enough. It’s kind of a pain though to modify the scripts all the time. Also, it’s very difficult (and scary) to try and explain how to use these scripts to my less Bash-inclined co-workers.

The other day I found this great little piece of software written by Nicole Jacque called Home Directory Helper. It does exactly what all of my scripts did, except with an easier to use GUI interface. Very nice, and highly recommended.

Leopard Server Quickstart Guide

Corey Carson was written a fantastic quickstart guide for Leopard Server.

This updated quickstart guide is very similar to the Tiger Server Quickstart Guide posted in 2005. It’s primary purpose is to get you up and running quickly, overcoming common hurdles such as DNS and binding confusions. With the move to launchd over cron, those steps are now included as well.

You can grab the pdf at AFP548.com.

The article includes some particularly good instructions on using and setting up rsync, launchd, and Network Home Redirector.

Via Infinity’s End.

You Are Unable to Log in to the User Account at Time

This one is just a quickie, but I thought I’d post it because I know that I’ve gotten this message before and that there is very little useful information turned up in a relevant Google search.

At my work we use an OS X server to host the home directories of all of our users who log in to our lab computers. We currently only support OS X clients, so we’re only doing this over AFP. Last semester we used a Tiger server and clients, but this summer we are upgrading everything to Leopard.

After setting up a test client computer in Directory Utility (used to be Directory Access in Tiger) to connect to our server I figured we were good to log in with one of migrated user accounts. We don’t do binding or Active Directory or really anything complicated so usually the process is pretty straightforward.

After setting up the client and restarting, I attempted to log on using one of our network users, and was met with this big fat error message:

You are unable to log in to the user account [username] at this  time

Not only did not logging in not work, but the entire description of the error read “Logging in to the account failed because an error occurred”. Gee, thanks Apple. Very useful.

This error wasn’t entirely foreign to me. I remembered seeing it occasionally in Tiger, but couldn’t remember if we had ever established a cause, let alone a solution. Just for kicks I tried logging on with the same account on one of our older Tiger clients (that was known to work with the old Tiger server). The message is slightly more verbose, but generally still the same:

You are unable to log in to the user account [username] at this  time (Tiger Message)

I knew that AFP was working because we had some share points up and running. So, AFP and at least some level of authentication were working. After inspecting the server firewall and open directory logs, as well as the client logs, it seemed clear that the user was authenticating properly. It was something that was happening after the actual successful authentication that was causing the error message.

After some research and thought, it occurred to me that it was very likely that there was some sort of configuration gone awry with the actual home directories. Then I realized that I had completely neglected to actually configure the old home directories on our server to be shared at all!

So basically the user was logging in and authenticating successfully. Then when the client asked for the home directory the server was like, what home directory? And the client was like aww shit. I’m gonna log you out right now ’cause I need your home to work. And the server was like, all right, fine. Something like that.

After some simple home directory sharing configurations, everything was running without another episode. Sigh.

Unresponsive Server in ARD

For the past several weeks at work I’ve been gradually working on upgrading our OS X server from Leopard to Tiger. The process has certainly not been without hiccups, but it has gone smoothly for the most part.

After an initial false start attempting to simply upgrade the server, I ended up simply installing the Leopard server from a blank disk. This seemed to take care of most of the really strange things that were happening after the upgrade.

This particular server is of the headless XServe variety, so we primarily use Apple Remote Desktop to access it in addition to the Server Admin Tools and SSH. Since installing Leopard on the server however, I’ve been noticing that at times it is acting erratically. Usually I’ll first notice that the server will either stop showing up in ARD or it show up as black, indicating that there is no ARD agent on the computer. I’ve tried restarting the computer, which will fix it, but that’s not a very good solution for obvious reasons.

I had also noticed while using Server Admin that sometimes the server CPU is running at completely full capacity, like in this screenshot:

OS X Server CPU gone crazy

The other day the server stopped responding in ARD again. As usual though, I was still able to access it through both Server Admin and SSH. After a little research, I found this useful page of commands, which includes this one-liner:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -menu

Running this command restarts the ARD Agent, which is what we want if it is frozen. Once I did this things got a little better, and the server came up in ARD as active. I tried controlling the server through ARD, but no dice, still no connection.

At this point I noticed that there was a user logged on to the server and I remembered that I had also been having problems with VNCDragHelper freezing. I found this on an Apple discussion page:

When remotely managing an XServe with OS 10.5.1 from a 10.4.11 client with ARD 3.2, several times (3 up till now) the server UI becomes unresponsive, at least finder. This even gets worse when trying to start the Application Monitor, then also the Dock freezes, and the Application Monitor UI never opens. When doing an ssh> sudo top, it shows that both “Application Monitor” and “VNCDragHelper” do consume almost 100% CPU. Luckily only on a Single core, but that keeps two cores (one processor 100% busy). killall “Activity Monitor” brings the activity monitor down, when sending it with Remote Desktop Unix command.

Perfect, that must be it. In SSH, I ran the following command:

sudo killall -9 VNCDragHelper

I also killed the loginwindow because that appeared to be frozen as well (judging from the top command that I ran):

sudo killall -9 loginwindow

Suddenly after running both those commands, the server leapt back to responsiveness. I was able to access it in ARD without problem. Also, after about an hour I checked the CPU diagram in Server Admin and was able to see a noticeable improvement.

OS X Server CPU back to normal

Now that’s a sight for sore eyes. For reference, I was running 10.5.3 and ARD 3.1 when this problem happened. I’m not sure that anything has been fixed in 10.5.4 though.

Firefox 3 and OS X Networked Home Directories

AFP548 is reporting a bug with Firefox 3 where apparently it doesn’t work with Macs that are set up to use a networked home directory.

When I updated to Firefox 3, I immediately noticed that Bookmarks were not visible under bookmarks menu. The Search engine field had a generic icon and when I selected ‘Manage Search Engines’, the dialog box was frozen and I couldn’t get out of it without quitting Firefox. When I tried to enter a URL into the URL field and press ‘enter’, nothing happens. However, when double-click on a URL in an e-mail message, that appears to work. […] When I switched to a local admin account (i.e., Firefox profile on the local hard drive), it seems to work fine. However, when I switch back to my network home account (on our XServe), it still displays the problems described above. I tried other user accounts on our XServe with the same problems.

This is kind of unbelievable to me that Firefox 3 was released with such a show-stopping bug on the Mac side. I’m pretty sure that most companies that use Macs use them with networked home directories (at least in the Academic world). It’s good to know though before I start adding Firefox to the images for fall semester.

Apparently this is a documented bug and as a commenter suggested, will be fixed in the future. You can read the bug track in Bugzilla to see how the fix is progressing.



appointive
appointive
appointive
appointive