Ok, this time the word “fun” is sarcastic. I had it working this afternoon and couldn’t figure out why it all of a sudden stopped working or… at least… subversion via kerberos. I was getting this error whenever I did a “svn ls http://svn.example.com/svn/anthill/ on my server):
ah_post_send (#0), code is 401 (want 401), WWW-Authenticate is Negotiate, Basic realm="Kerberos Login" auth: Got challenge (code 401). auth: Got 'Negotiate' challenge. auth: Got 'Basic' challenge. auth: Trying Negotiate challenge... 2009-07-16 20:49:37.593 svn[6357:10b] *** NSInvocation: warning: object 0x1005dc040 of class 'ReplicaFile' does not implement methodSignatureForSelector: -- trouble ahead 2009-07-16 20:49:37.594 svn[6357:10b] *** NSInvocation: warning: object 0x1005dc040 of class 'ReplicaFile' does not implement doesNotRecognizeSelector: -- abort [1] 6357 trace trap svn -vv ls http://svn.example.com/svn/anthill/
Googling it showed one other guy who had it and never had an answer to his question.
Persistence is the codeword of the day, so I finally figured it out. Seems that OS X does things a little wonky with kerberos. A tutorial I read about using mod_auth_kerb indicated you had to use the hostname of the server, regardless of any virtualhost names (so my server name is hades, the virtualhost alias is svn; the made-up domain is, originally, example.com). Safari kept popping up the authentication dialog whenever I tried accessing the repository, which is not at all what I wanted. I had to ktadd a new principle (HTTP/svn.example.com) with the virtualhost alias (which the tutorial said not to do). Then Safari started working, but svn bombed.
Of course, in Fedora 11, none of this was a problem. But here’s the weird part: klist on F11 showed HTTP/hades.example.com (from subversion or firefox), whereas on OS X subversion crapped out and crashed and Safari showed HTTP/svn.example.com. So I decided to see what firefox on OS X would do and it (properly) used HTTP/hades.example.com.
Now, the weirdest part is that svn is working again! Why? For some reason (and I’m not quite sure whether I should be blaming OS X here or neon or a combination of the two), svn is not initiating obtaining a ticket for HTTP/hades.example.com. I’m not sure why, because on F11 it did. If I kdestroy and kinit (so I only have krbtgt’s ticket), svn craps out. However, once I used Firefox to obtain the ticket, svn could re-use it and all worked well. If I remove the HTTP/svn.example.com principle on the server, svn still doesn’t work and neither does Safari (I get the login dialog). Obviously that’s not my problem. I’m wondering if these Collab binaries built for OS X are messed up somehow; I’ll have to try from fink or build from source.
This was like pulling teeth tonight. Definitely an interesting puzzle that I probably could have done without. It’ll be interesting to see if other svn builds on OS X do the same thing (of course, I could dispense with making svn use GSSAPI for this, but half the fun is seeing how many passwords I don’t need). At this point I have no real idea why svn even worked at all in the first place — unless during the course of testing with Firefox I already had HTTP/hades.example.com’s ticket. Hmmm….