Awesome plugin for Quicklook which allows you to view markdown documents in a formatted style. This is really nice. I’ve taken to storing a lot of my documents in markdown, since I like using plain text files, but find the formatting in markdown a lot easier to use.

Since we deployed Leopard to the computers labs at work, I’ve been running in to this annoying problem involving Kerberos. I hadn’t spent any time trying to figure out how to circumvent it until now because it really only affects administrators. We can deal with our own problems right?

When a user logs in, they authenticate to our server using their account username (use Alice for this example). At this point they are given a Kerberos ticket. From then on, in Leopard, whenever the user attempts to connect to an AFP share on the server, Leopard assumes that they are connecting as the same user, Alice. Because the Kerberos ticket is still valid, the user is automatically authenticated as Alice. Of course, this makes perfect sense. That’s the whole point of Kerberos: single sign-on.

The problem resides in the assumption that the user wants to connect as the same user every time. What if Alice is actually an admin who needs to log on to a share using different credentials? Here’s an example: I’m testing a student account, with normal student privileges. During the course of my testing, I need to access a document from our administrative share point. Now, obviously the student account does not have access to the administrative share point. I would need to log in to the share using a user with permissions to access the administrative share point.

Unfortunately, Leopard will not even ask me what user account I want to use because I already have a valid Kerberos ticket for the student account. Fortunately, after finally getting fed up with this problem, a quick bit of googling solved it.

All that needs to be done is to destroy the Kerberos ticket. Simply open Keychain Access and select Kerberos Ticket Viewer from the Keychain Access menu. Select your Kerberos ticket from the window and click the destroy button. This doesn’t actually harm anything, it simply makes your Kerberos ticket expire. The next time you try and connect to the server, you will be asked to authenticate again; at which point you can authenticate as a different user.

Alternately, you could also create a new Kerberos ticket using a separate username to the same server. The before authenticating to a share, you would simply change the active user. Unfortunately it seems as though you can only access one at a time. For example, I could not mount two different user’s home directories at the same time. I would have to activate a user, mount their home directory, eject it, activate the second user, and then mount their home directory. Hmm, as you can probably see, there doesn’t really seem to be a reason why this would be useful. Probably simply destroying the ticket is the best bet.

For more information on this, check out the Mac OS X 10.5: About Kerberos in Mac OS X 10.5 clients knowledge base article from Apple.

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.

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:

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:

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.

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.