6:42 a.m.
On 05/12/2010 03:13 PM, Stephen Gallagher wrote:
On 05/12/2010 02:06 AM, Eugene Indenbom wrote:
> On 05/12/2010 12:19 AM, Stephen Gallagher wrote:
>> Simo and I had a long discussion on IRC today regarding how to handle
>> the kdcinfo and kpasswdinfo files for the Kerberos locator plugin.
>>
>> The basic problem is this: our recent changes made it so that when we
>> shut down the SSSD, we remove the kdcinfo files. When we start back up,
>> we write a new kdcinfo file with a correct IP address if available, or
>> with a fake one if we're offline.
>>
>> This is causing problems with non-SSSD kerberized services. Prior to
>> these changes, we always left the kdcinfo file around, so when we went
>> online (such as connecting to a VPN), the locator plugin would already
>> have the old IP saved, so we would be able to hand it off and continue
>> to work.
>>
>> Now, we continue to return "Can't contact KDC" until the SSSD
performs
>> an online kinit. This may not happen immediately (or for a very long
>> time). And until that happens, kerberized servers and applications
>> won't
>> work.
>>
> It is essential to (re-)locate KDC as soon as VPN (or other type of)
> connection is up. It can be done by installing appropriate hooks for
> ifup/ifdown and NetworkManager.
>
This is my long-term plan, but we're on a tight deadline for 1.2.0.
If we are talking about 1.2.0 deadline, the solution suggested by you
and Simo seems to be the only one available in current time frame.
Also, if you have thoughts on how to hook into ifup/ifdown, please
share them. Figuring out how to do that is keeping me up at night.
I see 2 options:
1. Modify network scripts so they will call all scripts in predefined
folder after bringing interface up or down (e.g. all scripts in
/etc/sysconfig/network-scripts/hooks). I wonder why nobody has done this
up to now?
2. Use ugly do_netreport interface (start a special process and register
it's pid in /var/run/netreport folder). See Fedora's
/etc/sysconfig/network-scripts/network-functions.
> Actually the best solution would be for the locator plugin not to
read
> configuration files, but to contact SSSD directly over DBUS. This way
> locator plugin can wait for KDC detection process to complete or even
> start the detection on-demand if not started by ifup/NetworkManager
> hooks.
>
This is even more complex, as we don't currently have a reliable way
of determining whether we have this information yet. Right now, the
SSSD won't even TRY to resolve the KDC until it needs to, though I
have been readying a patch to mitigate this.
Why is it complex? When locator plugin is called it will connect SSSD
and if it is time to repeat offline check or KDC is currently being
located, it will wait for KDC location process to complete. We can use
this solution even without receiving notifications about ifup/ifdown
events.
Sure the solution require programming and does not fit into 1.2.0 time
line, but in long term it's a good way to ensure that if kerberised
service detects change in interface state earlier then SSSD (which is
possible), it will get newly available KDC address from SSSD locator
plugin instead of KRB5_KDC_UNREACH.
>> After much discussion, Simo and I have come up with the
following
>> approach: When the SSSD is offline (mark_offline() is called) we should
>> remove the kdcinfo and kpasswdinfo files. In the locator plugin, if
>> those files are not present, we should return the appropriate error
>> code
>> to pass the handling on to the krb5.conf.
>>
>>
> I disagree with this approach. It seems appropriate to return "NOT
> HANDLED" from locator plugin when SSSD is down. In this case application
> or service should locate KDC itself as SSSD is not available.
>
I think you misunderstand the plugin API. That's what "NOT HANDLED"
means. It says that our plugin is turning over responsibility for this
domain (potentially to /etc/krb5.conf if it is configured there as well)
Hmm... It
looks that we are saying the same thing. When SSSD is down,
the application or service should locate KDC by other means (e.g. using
/etc/krb5.conf)
> When SSSD backend is offline, SSSD has already determined that no KDC is
> reachable and put backend offline. So SSSD has an authoritative answer
> and it does not make sense to repeat search and wait for another couple
> minutes for search to fail. My opinion is that in OFFLINE state locator
> plugin must return KRB5_KDC_UNREACH.
The problem is that we AREN'T authoritative right now for some time
after we go online, having no current hooks into NetworkManager (and
no guarantees that NetworkManager is even in use), we can only poll to
see whether it is time to go back online. And we don't poll actively,
because that's a waste of resources. We only poll if a request happens
AND it's been more than 60s since the last time we determined
ourselves to be offline.
So the idea behind this (temporary) solution is to ensure that we at
least let krb5.conf do our job until we're in a position where we can
consider ourselves authoritative.
I fully agree with you for 1.2 branch. As I have written above, my
comments were addressed for master branch development.
>> We will then allow the configuration in krb5.conf to handle
requests
>> until we go online, at which time we will write out the kdcinfo files
>> and handle it ourselves.
>>
>> This will probably require the following changes:
>> 1) Enable providers to register a callback for "mark_offline()"
>> 2) Create a callback for the kerberos provider to remove kdcinfo and
>> kpasswdinfo files upon going offline (and also when shutting down)
>> 3) Modify the locator plugin to return "not handled" if the kdcinfo
>> file
>> is missing.
>>
>>
Thank you for your feedback.