Anyone whose ever imple­mented net­worked home direc­to­ries on and OS X Server has prob­a­bly come across the need to add or remove pref­er­ence files from user accounts. Chang­ing set­tings for new accounts is easy, just add the files to the User Template folder.

Exist­ing users is a dif­fer­ent story though. They already have their home direc­to­ries. Depend­ing on how many users you have, adding/deleting files from you old users can be a daunt­ing task. Ten users is easy enough, but 50 is silly and over 100 is ridiculous.

Long ago I wrote a series of scripts (well actu­ally just one) that I use and modify for what­ever files I need to change. I basi­cally just loops through each home folder in a spec­i­fied direc­tory. It’s really a pretty basic script. Here’s an exam­ple 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 dif­fi­cult (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 soft­ware writ­ten by Nicole Jacque called Home Direc­tory Helper. It does exactly what all of my scripts did, except with an easier to use GUI inter­face. Very nice, and highly recommended.

I stum­bled across this great tip the other day about solv­ing that pesky error mes­sage that hap­pens when you try and eject a that is busy disk. This seems to happen all too often, I’ll try and eject one of my exter­nal hard drives and get the mes­sage even though there are no vis­i­ble pro­grams using it. Sigh. Use this com­m­mand in Terminal:

lsof | grep DISKNAME

Read the full tip from Mac OS X Hints.

Corey Carson was writ­ten a fan­tas­tic quick­start guide for Leop­ard Server.

This updated quick­start guide is very sim­i­lar to the Tiger Server Quick­start Guide posted in 2005. It’s pri­mary pur­pose is to get you up and run­ning quickly, over­com­ing common hur­dles such as DNS and bind­ing con­fu­sions. With the move to launchd over cron, those steps are now included as well.

You can grab the pdf at AFP548.com.

The arti­cle includes some par­tic­u­larly good instruc­tions on using and set­ting up rsync, launchd, and Net­work Home Redirector.

Via Infinity’s End.

This one is just a quickie, but I thought I’d post it because I know that I’ve gotten this mes­sage before and that there is very little useful infor­ma­tion turned up in a rel­e­vant Google search.

At my work we use an OS X server to host the home direc­to­ries of all of our users who log in to our lab com­put­ers. We cur­rently only sup­port OS X clients, so we’re only doing this over AFP. Last semes­ter we used a Tiger server and clients, but this summer we are upgrad­ing every­thing to Leopard.

After set­ting up a test client com­puter in Direc­tory Util­ity (used to be Direc­tory Access in Tiger) to con­nect to our server I fig­ured we were good to log in with one of migrated user accounts. We don’t do bind­ing or Active Direc­tory or really any­thing com­pli­cated so usu­ally the process is pretty straightforward.

After set­ting up the client and restart­ing, I attempted to log on using one of our net­work users, and was met with this big fat error message:

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

This error wasn’t entirely for­eign to me. I remem­bered seeing it occa­sion­ally in Tiger, but couldn’t remem­ber if we had ever estab­lished a cause, let alone a solu­tion. Just for kicks I tried log­ging on with the same account on one of our older Tiger clients (that was known to work with the old Tiger server). The mes­sage is slightly more ver­bose, but gen­er­ally still the same:

I knew that AFP was work­ing because we had some share points up and run­ning. So, AFP and at least some level of authen­ti­ca­tion were work­ing. After inspect­ing the server fire­wall and open direc­tory logs, as well as the client logs, it seemed clear that the user was authen­ti­cat­ing prop­erly. It was some­thing that was hap­pen­ing after the actual suc­cess­ful authen­ti­ca­tion that was caus­ing the error message.

After some research and thought, it occurred to me that it was very likely that there was some sort of con­fig­u­ra­tion gone awry with the actual home direc­to­ries. Then I real­ized that I had com­pletely neglected to actu­ally con­fig­ure the old home direc­to­ries on our server to be shared at all!

So basi­cally the user was log­ging in and authen­ti­cat­ing suc­cess­fully. Then when the client asked for the home direc­tory the server was like, what home direc­tory? 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. Some­thing like that.

After some simple home direc­tory shar­ing con­fig­u­ra­tions, every­thing was run­ning with­out another episode. Sigh.

For the past sev­eral weeks at work I’ve been grad­u­ally work­ing on upgrad­ing our OS X server from Leop­ard to Tiger. The process has cer­tainly not been with­out hic­cups, but it has gone smoothly for the most part.

After an ini­tial false start attempt­ing to simply upgrade the server, I ended up simply installing the Leop­ard server from a blank disk. This seemed to take care of most of the really strange things that were hap­pen­ing after the upgrade.

This par­tic­u­lar server is of the head­less XServe vari­ety, so we pri­mar­ily use Apple Remote Desk­top to access it in addi­tion to the Server Admin Tools and SSH. Since installing Leop­ard on the server how­ever, I’ve been notic­ing that at times it is acting errat­i­cally. Usu­ally I’ll first notice that the server will either stop show­ing up in ARD or it show up as black, indi­cat­ing that there is no ARD agent on the com­puter. I’ve tried restart­ing the com­puter, which will fix it, but that’s not a very good solu­tion for obvi­ous reasons.

I had also noticed while using Server Admin that some­times the server CPU is run­ning at com­pletely full capac­ity, like in this screenshot:

The other day the server stopped respond­ing 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 com­mands, which includes this one-​liner:

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

Run­ning this com­mand 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 con­trol­ling 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 remem­bered that I had also been having prob­lems with VNCDragHelper freez­ing. I found this on an Apple dis­cus­sion page:

When remotely man­ag­ing an XServe with OS 10.5.1 from a 10.4.11 client with ARD 3.2, sev­eral times (3 up till now) the server UI becomes unre­spon­sive, at least finder. This even gets worse when trying to start the Appli­ca­tion Mon­i­tor, then also the Dock freezes, and the Appli­ca­tion Mon­i­tor UI never opens. When doing an ssh> sudo top, it shows that both “Application Monitor” and “VNCDragHelper” do con­sume almost 100% CPU. Luck­ily only on a Single core, but that keeps two cores (one proces­sor 100% busy). kil­lall “Activity Monitor” brings the activ­ity mon­i­tor down, when send­ing it with Remote Desk­top Unix command.

Per­fect, that must be it. In SSH, I ran the fol­low­ing command:

sudo killall -9 VNCDragHelper

I also killed the loginwindow because that appeared to be frozen as well (judg­ing from the top com­mand that I ran):

sudo killall -9 loginwindow

Sud­denly after run­ning both those com­mands, the server leapt back to respon­sive­ness. I was able to access it in ARD with­out prob­lem. Also, after about an hour I checked the CPU dia­gram in Server Admin and was able to see a notice­able improvement.

Now that’s a sight for sore eyes. For ref­er­ence, I was run­ning 10.5.3 and ARD 3.1 when this prob­lem hap­pened. I’m not sure that any­thing has been fixed in 10.5.4 though.