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 Bosesbose@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:
Hi,
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 "Can't locate any KDC for realm 'EXAMPLE.COM'" Presumably network services 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 'EXAMPLE.COM'" it should work without returning a random address. I'll check if this really works and on success send a new patch.
bye, Sumit
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.