[1717] in Kerberos_V5_Development
Re: Solaris UDP connect() lossage
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Sep 6 13:22:34 1996
Date: Fri, 6 Sep 1996 13:22:29 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>, krbcore@MIT.EDU
In-Reply-To: Marc Horowitz's message of Fri, 06 Sep 1996 13:04:41 EDT,
<199609061704.NAA06293@beeblebrox.MIT.EDU>
Date: Fri, 06 Sep 1996 13:04:41 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> I first noticed it in login.krb5 when it's trying to convert the
>> tickets to krb4 tickets and was hanging because krb524d wasn't runnign
>> on fmult.mit.edu.
Do you just want to put in a timeout? This seems reasonable, as it is
pretty straightforward, and will help all platforms when the host is
down. I wouldn't go out of my way to figure out a way to get solaris
not to pause for n seconds if the daemon is down, though.
My current plan is to disable krb4_convert by default. The issue is
that we compile with v4 compatibility by default, and if you're a new
krb5 site which doesn't care about V5 compatibility, it seems better
that you not be forced to run krb524d just to keep your Solaris rloginds
to keep from hanging. Even if you're a site which is migrating from V4
to V5, the news that you'd have to keep krb425d runnign forever probably
isn't going to sound that exiciting.
This impacts Cygnus as well, since you probably don't want to distribute
two binary distributions for people who want V4 compatibility, and there
are a lot of Solaris machines out there.....
I think that as a free software group, there's only so much effort we
can put into working around braindamage in various vendor operating
systems.
This is certainly true in principal, and the amount of time that I'd
spend working around serious braindamage in, say, NeXTStep would be
measured in milliseconds. However, some platforms are popular enough
that we'd be foolish to ignore the reality that if we don't work on some
popular OS just because the "OS" is broken, users will blame us, not the
OS provider.
- Ted
