On 12 September 2017 at 17:59, John Beranek wrote: > On 11 September 2017 at 14:28, Jakub Hrozek wrote: >> On Mon, Sep 11, 2017 at 12:23:26PM +0100, John Beranek wrote: >>> On 1 September 2017 at 15:54, Lukas Slebodnik wrote: >>> > >>> > On (01/09/17 09:33), William Edsall wrote: >>> > >Had a few communications with Michal but we're still stuck. >>> > > >>> > >One issue is that we have dozens of domain controllers globally. A >>> > >standard >>> > >dns lookup could give me a domain controller overseas which will be slow, >>> > >or maybe even a domain controller that isn't responding. As such, I have >>> > >been inserting ad_server = x into the sssd.conf to improve performance. >>> > > >>> > >I noticed that if I do not insert ad_server = x, I'm getting different >>> > >results. My initial id request is very slow but seems to produce results. >>> > >While searching, it seems to also be 'inserting' users into the users >>> > >hash >>> > >table - almost as if it's searching and inserting our entire user >>> > >database? >>> > >For example there are countless lines of the following: >>> > >(Fri Sep 1 09:28:37 2017) [sssd[be[example.com]]] >>> > >[sdap_nested_group_hash_insert] (0x4000): Inserting >>> > >[CN=user_name,OU=bla,OU=bla Users,DC=dow,DC=com] into hash table [users] >>> > > >>> > >As my initial id request returns, it seems to return several chunks of my >>> > >group ids at once as if it's processing them individually and searching >>> > >all >>> > >users in that group (thus the above log entries). >>> > > >>> > >Not sure if this helps or just muds up the issue but it's strange indeed. >>> > > >>> > You needn't hardcode ad_server. You can still rely on dns discovery. >>> > I assume you use sites in AD. So you can "pin" sssd to your local/nearest >>> > site >>> > with option ad_site. >>> >>> I've got something to add to this, some behaviour we're seeing with >>> CentOS 7 servers using sssd-ad. >>> >>> sssd-1.14.0-43.el7_3.18.x86_64 >>> sssd-ad-1.14.0-43.el7_3.18.x86_64 >>> sssd-client-1.14.0-43.el7_3.18.x86_64 >>> sssd-common-1.14.0-43.el7_3.18.x86_64 >>> sssd-common-pac-1.14.0-43.el7_3.18.x86_64 >>> sssd-ipa-1.14.0-43.el7_3.18.x86_64 >>> sssd-krb5-1.14.0-43.el7_3.18.x86_64 >>> sssd-krb5-common-1.14.0-43.el7_3.18.x86_64 >>> sssd-ldap-1.14.0-43.el7_3.18.x86_64 >>> sssd-proxy-1.14.0-43.el7_3.18.x86_64 >>> >>> In our case we have some DCs which are located at a partner site, and >>> are therefore inaccessible to clients on our standard LANs. >>> >>> When SSSD starts it will correctly determine there are 2 primary DCs >>> (these are the ones for the site) and 7 backup DCs. >>> >>> However, what is happening from time to time is that for some reason >>> I've not yet determined the connection(s) to the primary DC(s) are >>> dropping, and then sssd attempts to connect to one of the DCs that are >>> inaccessible. >>> >>> In what circumstances would sssd prefer a backup server to a primary server? >>> >>> I've got a chunk of log which I've anonymised: >>> >>> https://paste.fedoraproject.org/paste/G69lC9COQfbnWFI~qtFLZw >> >> The issue is here: > [snip] >> >> So this is a known bug where locating the site (even though we know it >> already) can contact the DCs outside that site. >> >> In the meantime, until the fix is released, you can hardcode the site >> using the 'ad_site' option. > > Thank you Jakub, is there a ticket/BZ for this? I noticed after my > post that it's evident on CentOS 6 too.
Ah, https://pagure.io/SSSD/sssd/issue/3265 ? John -- John Beranek To generalise is to be an idiot. http://redux.org.uk/ -- William Blake _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
