KRB5_REALM_CANT_RESOLVE errors ?

[Ken Raeburn]

Christopher Burke <craznar at hotmail.com> writes:
> raeburn at mit.edu (Ken Raeburn) wrote in news:tx1g02kc98p.fsf at mit.edu:
> > If you've got developer time to invest into this, you could look at
> > the snapshots available from MIT where I've eliminated some of the
> > uses of gethostbyname in favor of getaddrinfo, which is supposed to be
> > thread-safe.  (Though I'll note that the NetBSD 1.5 implementation, at
> > least, is not.)  Whatever other unsafe routines might be in use in the
> > krb5 library we can also look at working around.  Note that some folks
> > at IBM are also working on the thread safety issue on a somewhat
> > larger scale.
> 
> I don't get to do ANY rewrites on the main application as it is a commercial 
> app (iPlanet Directory server).... all I get to do is write a plugin (.so) 
> which the main application loads and runs.

Sure.  I meant development time to help us make the krb5 library more
thread-safe.  (Still working on the assumption that that's the source
of the problems.)


Otherwise, your best bet may be to fork off one or more slave
processes you can pass name/password strings to and get back
success/failure indications.  If you can keep it localized within the
Kerberos parts of the plugin, you should be able to switch back to the
one-process form without too much pain later on when the thread safety
issues have been dealt with.  I think you indicated that you were
doing this earlier:

> Don't know for sure yet... but that latency between calls seems to be the 
> issue - but only on this 1 call at a time application. The multi threaded 
> apps that fork out multiple kerberos 5 auths work fine.

Just to be crystal clear -- this was using fork() to create new
processes with separate address spaces to do the Kerberos work, and
not a casual reference to splitting the control flow by creating more
threads, right?  That's certainly the easy way to sidestep the thread
safety problems.  And if you're using slave processes that stick
around and process lots of requests, even better, overall it'll save
on fork and process startup costs.

Ken