Re: Bad behavior vith LDAP backend.

[Anders Magnusson <ragge@ltu.se>]

I think it would be OK to just don't answer as long as the LDAP server 
is non-responsive.
Forcing the kdc to exit may be a bad thing; in theory the ldap server do 
not have to be on
the same machine, and a network glitch shouldn't cause the kdc to die.

-- Ragge

Henry B. Hotz skrev:
> I'd vote for just returning nothing at all.  If the kdc finds an 
> empty/absent/inaccessible database it should just quit IMO.  If the 
> kdc is down the clients will try the next kdc after a second anyway.
>
> It's kind of fun the *first* time you find a kdc running with an empty 
> db and telling everyone they don't exist.  Thanks to some procedural 
> errors on my part I just did it the fifth time in production last 
> night.  (This is still 0.7.2 BTW, and has nothing to do with LDAP.)
>
> Since this is LDAP going down, I suppose there are things you can do, 
> but they seem really messy.  IMO (as a non-LDAP-backend user) better 
> to just require whatever restarts slapd to restart the kdc as well.
>
> On Mar 27, 2008, at 8:08 AM, Love Hörnquist Åstrand wrote:
>
>>
>> 27 mar 2008 kl. 09.16 skrev Anders Magnusson:
>>
>>> I just noticed an unwanted behavior when using LDAP backend and 
>>> slapd dies:
>>> The clients do not fail over to another kdc.  I assume that this is 
>>> because the kdc returns
>>> something, the log says:
>>>
>>> Mar 27 08:19:50 gran kdc[24288]: AS-REQ helstr-4@LTU.SE from 
>>> IPv4:130.240.42.40 for krbtgt/LTU.SE@LTU.SE
>>> Mar 27 08:19:50 gran kdc[24288]: Failed to open database: Wrong 
>>> database version
>>>
>>> I don't know what can be returned, but I think that either the kdc 
>>> should return "try next kdc"
>>> or something, or just stop answering requests.
>>
>> In addition to stop answering question, KRB5KDC_ERR_SVC_UNAVAILABLE 
>> can be returned, however, its not supported by all clients.
>>
>> Cant make up my mind where the error should be returned.
>>
>> Love
>
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>
>
>