Archives / Search ›

Apparently I'm now syndicated at LiveJournal, through no effort of my own. (My guess is this was rugle's doing). If you're a LJ person, you may find it easier to follow my blog that way, I guess.

I've been seeing a great deal of flakiness with my desktop G4 over the past few weeks; it often crashes several times on startup, and recently coreservicesd has been acting up. Last night it decided to stop providing icons, and tonight it started using 100% CPU and locking up my Mac for a few minutes at a time. Each time the problem was solved by restarting, which was rather annoying: you shouldn't have to resort to this sort of problem resolution.

I've been working in the ACM office quite a bit recently, since it's nearly empty over the summer, and has newly installed lighting which is a lot easier on my eyes than the usual fluorescent stuff they have up in the Pablo lab. The ACM folks (primarily Ben, Chris and Don) have been working on an NFS to Kerberized AFS migration for a few weeks; it'll provide better flexibility, security, and speed than the current setup.

AFS is far from trivial to get running. We had no prior experience and four client platforms to support: OS X, Windows 2000/2003, Linux and Solaris. Several all-nighters later, we have two replacement KDCs and two AFS servers, all on obsolete machines (Sun Ultra 1s and HP Kayaks) the CS department donated to us. Linux and Windows clients are working, though Windows is running an older OpenAFS version which still needs to use Kerberos v4.

Coming back from dinner tonight, I decided to spend a few minutes trying to get OpenAFS working on OS X. Happily, a few minutes were all it took, given some instructions courtesy the University of Michigan and an aklog binary in addition to the base OpenAFS distribution. With Alexei Kosut's aklog Kerberos plugin installed, running kinit by itself is still problematic, though:

% kinit njriley
Kerberos Login:
Please enter the password for njriley\@ACM.UIUC.EDU: 
MacLeland: Couldn't get acm.uiuc.edu AFS tickets: Don't have Kerberos ticket-granting ticket
% aklog -d
Authenticating to cell acm.uiuc.edu (server afs1.internal.acm.uiuc.edu).
We've deduced that we need to authenticate to realm INTERNAL.ACM.UIUC.EDU.
Getting tickets: afs/acm.uiuc.edu\@INTERNAL.ACM.UIUC.EDU
Kerberos error code returned by get_cred: -1765328377
aklog: Couldn't get acm.uiuc.edu AFS tickets:
aklog: Server not found in Kerberos database while getting AFS tickets
% aklog -d acm.uiuc.edu -k ACM.UIUC.EDU
Authenticating to cell acm.uiuc.edu (server afs1.internal.acm.uiuc.edu).
We were told to authenticate to realm ACM.UIUC.EDU.
Getting tickets: afs/acm.uiuc.edu\@ACM.UIUC.EDU
About to resolve name njriley to id in cell acm.uiuc.edu.
Id 25170
Set username to AFS ID 25170
Setting tokens. AFS ID 25170 /  @ ACM.UIUC.EDU 

This is likely just a configuration problem which will go away when we move the AFS servers out from behind the firewall. Another possibility would be to reconfigure or recompile the aklog plugin to use the appropriate Kerberos realm.

Sleep, laundry (oops, no laundry, they're behind schedule and the laundry room is still being retiled), packing, and off to MacHack. I can't wait!

Comments are closed.