On 05/10/2010 06:56 AM, Sumit Bose wrote:
On Sun, May 09, 2010 at 02:56:07PM -0400, Simo Sorce wrote:
> On Fri, 7 May 2010 17:23:57 +0200
> Sumit Bose<sbose(a)redhat.com> wrote:
>> On Fri, May 07, 2010 at 11:00:34AM -0400, Stephen Gallagher wrote:
>>> On 05/07/2010 09:34 AM, Sumit Bose wrote:
>>>> this patch should solve #470 by calling be_resolve_server_send()
>>>> during startup.
>>> Nack. As discussed off-list, we need to write a kdcinfo even when
>>> we're offline at startup, so that services trying to get service
>>> tickets will receive "Cannot contact any KDC for realm
>>> 'EXAMPLE.COM' while getting initial credentials" instead of
>>> locate any KDC for realm 'EXAMPLE.COM'" Presumably network
>>> will handle for themselves retrying to get the service ticket at a
>>> future time if it's only unavailable, but if it can't find the KDC
>>> at all, it may simply refuse to start.
>> New version attached.
> Sorry, I am not really sure this is a good idea. How do we know that
> this faulty address is not going to be cached somewhere and will end up
> making the app fail ? Do we have assurances it is never cached in
> libkrb5 ?
I think kibkrb5 will not cache the address otherwise having locators
plugins wouldn't make much sense. Nevertheless I maybe have a better
idea to solve this, because it looks that libkrb5 will return the error
code of the locator plugin unmodified. So if we let the locator plugin
return the error code for "Cannot contact any KDC for realm
it should work without returning a random address. I'll check if this
really works and on success send a new patch.
I definitely like this idea better, if possible.
Simo, the problem was this: if the kdcinfo file didn't exist, the
locator plugin would return "Can't locate any KDC for realm
'EXAMPLE.COM'" instead of the more appropriate "Cannot contact any KDC
for realm 'EXAMPLE.COM'". This was causing issues with kerberized
services, because the latter is treated as a permanent error, rather
than a temporary one.
So we came up with the solution of using a temporary address for the
locator until we went online. But as I said above, if this approach
Sumit has suggested is possible, it's far preferable.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.