On 08/19/2011 12:28 PM, Simo Sorce wrote:
> On Fri, 2011-08-19 at 10:40 -0400, Dmitri Pal wrote:
>> On 08/19/2011 09:59 AM, Simo Sorce wrote:
>>> On Fri, 2011-08-19 at 09:14 -0400, Dmitri Pal wrote:
>>>> On 08/19/2011 06:32 AM, Jan Zelený wrote:
>>>>>> On Fri, Aug 19, 2011 at 09:30:44AM +0200, Jan Zelený wrote:
>>>>>>>> On Thu, 2011-08-18 at 13:47 +0200, Jakub Hrozek wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In light of
https://bugzilla.redhat.com/show_bug.cgi?id=726467 I have
>>>>>>>>> been thinking about improving how we handle DNS
timeouts in general.
>>>>>>>>>
>>>>>>>>> Currently there is one timeout option we pass to
c-ares. However,
>>>>>>>>> that option is per-nameserver. I guess that makes
sense from a
>>>>>>>>> resolver library POV - as a resolver library you
want to control how
>>>>>>>>> long you talk to each name server.
>>>>>>>>>
>>>>>>>>> We have been mostly OK with this because in most
situations the
>>>>>>>>> resolver can't connect the socket to the name
server at all at times
>>>>>>>>> out immediatelly. Problems arise when the server is
very slow to
>>>>>>>>> respond, drops packets.
>>>>>>>>>
>>>>>>>>> To solve this in SSSD we need to have control over
how long a name
>>>>>>>>> resolution takes regardless of the number of name
servers and also
>>>>>>>>> regardless of the number of servers in failover.
>>>>>>>>>
>>>>>>>>> The failover in SSSD has the concept of
"services". LDAP is a
>>>>>>>>> service, Kerberos is a service etc. From back end
you don't care and
>>>>>>>>> don't know how many servers there are in a
service. From fail over
>>>>>>>>> we don't know and don't care how many name
servers there are.
>>>>>>>>>
>>>>>>>>> My proposal is to:
>>>>>>>>> 1) change the current
"dns_resolver_timeout" to be per-service, so
>>>>>>>>> the semantics would be "How long to wait until
we get an LDAP server
>>>>>>>>> IP address" for example
>>>>>>>>> 2) introduce a new option, something like
>>>>>>>>> "dns_resolver_server_timeout", that would
control a per-server
>>>>>>>>> timeout. This option could maybe be undocumented, it
seems quite
>>>>>>>>> low-level.
>>>>>>>>> 3) hide the per-nameserver resolver timeout (only
#define it). It is
>>>>>>>>> too low level.
>>>>>>>>>
>>>>>>>>> Thoughts, comments and ideas are welcome.
>>>>>>>> I have nothing to add to this. It sounds like exactly
the right
>>>>>>>> approach to me.
>>>>>>> Agreed.
>>>>>>>
>>>>>>> Just one thought: would it make sense to distinguish time to
resolve
>>>>>>> LDAP, KRB, ... by having different config options for each
of them?
>>>>>>>
>>>>>>> Jan
>>>>>> I can't think of a situation where you would like to wait
different
>>>>>> amount of time for id versus auth?
>>>>> Yeah, me neither. That's why I asked if perhaps someone else
knows.
>>>> Just a speculation...
>>>> What if it is not LDAP or SC auth is used but identity is from LDAP
>>>> (when we support it).
>>>> Would in these cases expectations be different?
>>>> Also auth is one operation per many hours while id lookup happens all
>>>> the time.
>>>> So expectation for id lookup to be much faster and timeout much
>>>> shorter than for the auth.
>>> You do not want to wait long times at the login prompt for things to
>>> timeout anyways.
>>> So no real difference between auth and id resolution, they both have to
>>> happen as fast as possible or fallback to offline.
>>>
>>> Simo.
>>>
>> If the fail over includes bouncing over several potential servers I am
>> willing to wait extra for the real online auth since it will give me the
>> ticket but Ok to fail over to the cached identities earlier since I do
>> not care if they are local or not. If the timeout is too low for auth it
>> might never have enough time to figure which server is available if it
>> is at the bottom of the list.
> That's not what people want when they are offline though.
> Perhaps we should resolve all servers at the same time with parallel
> searches so at least for the DNS step we have one single timeout and no
> risk of leaving stuff out.
>
> Simo.
>
I am not sure what people want but is seems that if you have Auth and ID
servers in different parts of the network like KDC and LDAP now or in
case when KDC on one of the IPA servers stopped functioning you might
want to setup different timeouts for establishing connection to
authentication server and to the identity server because having online
authentication is more important than online identity lookup. How it
translates to the internal logic is an implementation detail.
The implementation details involve a forced id check during auth, so
nope, identity servers are not less important then auth servers.
Simo.
--
Simo Sorce * Red Hat, Inc * New York