[SSSD] [PATCH] Remove duplicates detection in SRV resolving

Stephen Gallagher sgallagh at redhat.com
Fri Apr 15 15:39:00 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2011 08:42 AM, Stephen Gallagher wrote:
> On 04/15/2011 05:08 AM, Jakub Hrozek wrote:
>> On 04/14/2011 07:54 PM, Stephen Gallagher wrote:
>>> On 04/11/2011 04:36 PM, Jakub Hrozek wrote:
>>>> On 04/11/2011 06:07 PM, Stephen Gallagher wrote:
> 
>>>>>
>>>>> Nack.
>>>>>
>>>>> While it's not as if we call this function often, it seems
>>>>> counter-intuitive to me that we'd be looping through all the server
>>>>> lists (which could be arbitrarily long, if we're using SRV records) on
>>>>> every state update, rather than just eating this cost once when adding
>>>>> new servers to the list.
>>>>>
>>>>> In other words, we should do a duplicate check before calling
>>>>> create_fo_server() and skip creating it if the name and port matches.
>>>>>
> 
>>>> I actually think it is more convenient to allow duplicates than to 
>>>> detect them on create_fo_server() time and disallow them. Let me explain:
> 
>>>> It is quite possible (and actually the default for ipa-client-install) 
>>>> to have the same server name as a result of a SRV query and a hard coded 
>>>> hostname. The problem is the ordering of servers.
> 
>>>> Consider that srv query resolves to "ldap.example.com, 
>>>> ldap2.example.com" and the config file contains "_srv_, 
>>>> ldap.example.com". If we discard duplicates after the SRV query is 
>>>> resolved, the order would be "ldap2.example.com, ldap.example.com" which 
>>>> is wrong.
> 
>>> Why would that be the order? Wouldn't it be simplest to just check the
>>> list before adding each entry, and if it already exists, just not add it?
> 
>>> The result then would be ldap.example.com, ldap2.example.com (because
>>> the attempt to add the hard-coded name after the _SRV_ processing would
>>> be ignored since it's already present (and appropriately ordered).
> 
> 
>> Right, the problem is that this is done dynamically and the SRV lookups
>> can expire, which means that if you skip adding a hardcoded name, you
>> need to add it back at the right place when the SRV query expires.
> 
>> It's not impossible, it just seemed like a lot of work for a little gain
>> -- and actually if we gown down this route, I would prefer skipping the
>> duplicate that was resolved from SRV query and place the hardcoded
>> "original" there.
> 
> You've convinced me. I think your original patch is probably the most
> sensible. Ack.
> 
> 

Patch 0002 pushed to master.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2oZpMACgkQeiVVYja6o6MsMQCeNqJ7ESz1PFDIq2M9pH8aagwl
/cwAn3yn9vv8r8Ku/i1SW3HPKpP8KWF6
=kevB
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list