[SSSD] getent returns only single users

Jakub Hrozek jhrozek at redhat.com
Mon Apr 15 15:34:58 UTC 2013


On Mon, Apr 15, 2013 at 04:53:30PM +0200, steve wrote:
> On 04/15/2013 02:09 PM, Jakub Hrozek wrote:
> >On Mon, Apr 15, 2013 at 01:29:52PM +0200, steve wrote:
> >>On 04/15/2013 12:36 PM, Jakub Hrozek wrote:
> >>>On Mon, Apr 15, 2013 at 12:17:33PM +0200, steve wrote:
> >>>>On 04/15/2013 11:33 AM, Jakub Hrozek wrote:
> >>>>>Have you been able to check what kind of searches (with wireshark or similar
> >>>>>or even just looking at the debug logs) sssd is doing? There should be
> >>>>>one search for users and one for groups every 300 seconds by default
> >>>>>(can be overriden with ldap_enumeration_refresh_timeout).
> >>>>>
> >>>>>Also how many users/groups do you have on the server?
> >>>>>
> >>>>Hi
> >>>>Test setup with 2 users and 2 groups. The ldap server (Samba4 AD) is
> >>>>flooded with requests every second. I attach small bits from each
> >>>>log. If you coud have a look that would be great.
> >>>>
> >>>Thanks for the logs. I suspect that what happens is that the sssd_be
> >>>crashes or is restarted for some reason and after being respawned starts
> >>>another enumeration which is why you are seeing so many searches.
> >>>
> >>>As a matter of fact, there is a patch on the list to fix a potential
> >>>crash when enumerating. Which version are you running? Maybe you're
> >>>hitting that exact problem.
> >>>
> >>>>TIA
> >>>>Steve
> >>>>
> >>>[snip]
> >>>
> >>>>sssd_default.log
> >>>[snip]
> >>>>(Mon Apr 15 12:00:43 2013) [sssd[be[default]]] [dp_get_options]
> >>>>(0x0400): Option ldap_dns_service_name has value ldap
> >>>>(Mon Apr 15 12:00:43 2013) [sssd[be[default]]] [dp_get_options]
> >>>>(0x0400): Option ldap_krb5_ticket_lifetime has value 86400
> >>>Is there something more in the log? The part you pasted pretty much
> >>>describes the option being loaded.
> >>Hi
> >>The log got bounced because it was too big. I've put it here:
> >>https://dl.dropboxusercontent.com/u/45150875/sssd_default.log
> >Thank you, I will cancel the pending request, then.
> >
> >This is the most important part of the log:
> >(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server '192.168.1.100' as 'working'
> >(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [dc=dolores,dc=site]
> >(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(&(objectclass=user)(samAccountName=*)(uidNumber=*)(gidNumber=*))(&(objectCategory=user)(uidNumber=*)))][dc=dolores,dc=site].
> >(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9e3c5f0]
> >(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
> >
> >Now sssd_be crashed and the two following lines are already the newly
> >spawned process.
> >
> >(Mon Apr 15 13:16:34 2013) [sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
> >(Mon Apr 15 13:16:34 2013) [sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel
> >
> >Judging by the log, this is a different bug :-/ Is it possible to
> >get the core file from the crash? Or maybe a text backtrace?
> Sorry, but I don't know how to do that. Could you guide me?

In general you should install the packages with debug information
(sorry, I don't know exactly how they are called in Ubuntu). 

Next, generating core files must be enabled on the system as they might
contain sensitive information. At least on Fedora, the limits are
defined in /etc/security/limits.conf:
    soft core <max-size-in-bytes>
    root soft core <max-size-in-bytes>

And finally, the cores are dumped to location defined by the
core_pattern sysctl parameter:
# sysctl kernel.core_pattern

But maybe Ubuntu has some tool similar to Fedora's abrt that would help
you with generating the core. Timo, is there something like that?



More information about the sssd-devel mailing list