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

Jakub Hrozek jhrozek at redhat.com
Fri Apr 15 09:08:31 UTC 2011


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

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2oCw8ACgkQHsardTLnvCUoVACfSc87C0upEddcjiJ33PTEtjCT
idAAn08Z2Gz7yUDCEE9Vrt7I7s07gQC8
=erEY
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list