Hello everybody,
I've got an sssd configuration with two ldap domains. The nss part of the configuration is this one :
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd override_shell = /bin/bash entry_negative_timeout = 15 debug_level = 0x02F0
I've got a program that crawl a filesystem. For some reason, a bunch of files have an uid which do not "resolve" to anything. My ldap backend are hammered with requests like this one :
slapd[31421]: conn=361745 op=1712 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))
In /var/log/sssd/sssd_nss.log, it correspond to a lot of :
.... [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [1047], fail! ...
I thought that the "entry_negative_timeout" in the nss part of the configuration would prevent this kind of behaviour, but I obviously didn't guess right.
Any advice ?
Jean-Baptiste
On Wed, Sep 18, 2013 at 10:39:42AM +0200, Jean-Baptiste Denis wrote:
Hello everybody,
I've got an sssd configuration with two ldap domains. The nss part of the configuration is this one :
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd override_shell = /bin/bash entry_negative_timeout = 15 debug_level = 0x02F0
I've got a program that crawl a filesystem. For some reason, a bunch of files have an uid which do not "resolve" to anything. My ldap backend are hammered with requests like this one :
slapd[31421]: conn=361745 op=1712 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))
In /var/log/sssd/sssd_nss.log, it correspond to a lot of :
.... [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [1047], fail! ...
I thought that the "entry_negative_timeout" in the nss part of the configuration would prevent this kind of behaviour, but I obviously didn't guess right.
Any advice ?
Jean-Baptiste
Hi Jean-Baptiste,
From the snippets you sent it indeed seems the UID is searched for. But
after one such search, the entry should be cached in the negative cache and no requests towards the backend should be issued. Is it not the case?
btw for your case you might want to either increase the negative timeout a bit or, if the list of unresolvable UIDs is not long, filter them out directly: filter_users = root, 1047
filter_users can be used in both the nss section and the domain section.
Hi Jean-Baptiste,
Hi Jakub,
From the snippets you sent it indeed seems the UID is searched for. But after one such search, the entry should be cached in the negative cache and no requests towards the backend should be issued. Is it not the case?
From my point of view it is not. Here is a simple version of what I'm
observing (I can reproduce it) :
From the client :
client $ getent passwd 1047
From the client, in another terminal :
client $ tail -f /var/log/sssd/sssd_nss.log (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [1047], fail! (Wed Sep 18 13:20:35 2013) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
On the ldap server (one line per sssd domain) :
ldapserver $ tail -f /var/log/openldap/slapd.log|grep "uidNumber=1047"|grep 1047
Sep 18 13:22:00 pantero slapd[31421]: conn=387670 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))" Sep 18 13:22:00 pantero slapd[31421]: conn=387671 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))"
Each time I issue a "getent passwd 1047" I've got those entries in the log.
btw for your case you might want to either increase the negative timeout a bit or,
Indeed. I just wanted to be explicit in the configuration to be sure of what I was testing
if the list of unresolvable UIDs is not long, filter them out directly: filter_users = root, 1047
Unfortunately, I don't know them in advance.
Some precision : CentOS 6.4 with sssd 1.9.2.
Here is my sssd.conf :
[sssd] config_file_version = 2 services = nss, pam domains = home, ldap_home
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd override_shell = /bin/bash entry_negative_timeout = 15 debug_level = 0x02F0
[pam]
[domain/home] override_homedir = /home/%u # comma separated list of users you want to honor their ldap homeDirectory (fallback to ldap_home) # filter_users = test ldap_tls_reqcert = demand auth_provider = ldap ldap_schema = rfc2307 ldap_search_base = ou=users,dc=example,dc=com ldap_group_search_base = ou=groups,dc=example,dc=com id_provider = ldap ldap_id_use_start_tls = True # We do not authorize password change chpass_provider = none ldap_uri = ldap://ldap.example.com/ cache_credentials = True ldap_tls_cacertdir = /etc/openldap/certs ldap_network_timeout = 3 # getent passwd will only list /etc/passwd, but id or getent passwd login will query ldap #enumerate = True ldap_page_size = 500 debug_level = 0x02F0
# exactly the same as domain/home, without the override_homedir # and the filter_users directive [domain/ldap_home] ldap_tls_reqcert = demand auth_provider = ldap ldap_schema = rfc2307 ldap_search_base = ou=users,dc=example,dc=com ldap_group_search_base = ou=groups,dc=example,dc=com id_provider = ldap ldap_id_use_start_tls = True # We do not authorize password change chpass_provider = none ldap_uri = ldap://ldap.example.com/ cache_credentials = True ldap_tls_cacertdir = /etc/openldap/certs ldap_network_timeout = 3 # getent passwd will only list /etc/passwd, but id or getent passwd login will query ldap #enumerate = True ldap_page_size = 500 debug_level = 0x02F0
On Wed, Sep 18, 2013 at 01:41:06PM +0200, Jean-Baptiste Denis wrote:
Hi Jean-Baptiste,
Hi Jakub,
From the snippets you sent it indeed seems the UID is searched for. But after one such search, the entry should be cached in the negative cache and no requests towards the backend should be issued. Is it not the case?
From my point of view it is not. Here is a simple version of what I'm observing (I can reproduce it) :
From the client :
client $ getent passwd 1047
From the client, in another terminal :
client $ tail -f /var/log/sssd/sssd_nss.log (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [1047], fail! (Wed Sep 18 13:20:35 2013) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
On the ldap server (one line per sssd domain) :
ldapserver $ tail -f /var/log/openldap/slapd.log|grep "uidNumber=1047"|grep 1047
Sep 18 13:22:00 pantero slapd[31421]: conn=387670 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))" Sep 18 13:22:00 pantero slapd[31421]: conn=387671 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))"
Each time I issue a "getent passwd 1047" I've got those entries in the log.
Hm, I think I see the problem as well...I'll poke to the code to see if there is some bug. I see utility functions for handling negative cache for UIDs and GIDs as well but as you said I'm also seeing the backed queried every time.
On Wed, Sep 18, 2013 at 02:44:04PM +0200, Jakub Hrozek wrote:
On Wed, Sep 18, 2013 at 01:41:06PM +0200, Jean-Baptiste Denis wrote:
Hi Jean-Baptiste,
Hi Jakub,
From the snippets you sent it indeed seems the UID is searched for. But after one such search, the entry should be cached in the negative cache and no requests towards the backend should be issued. Is it not the case?
From my point of view it is not. Here is a simple version of what I'm observing (I can reproduce it) :
From the client :
client $ getent passwd 1047
From the client, in another terminal :
client $ tail -f /var/log/sssd/sssd_nss.log (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed Sep 18 13:20:35 2013) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [1047], fail! (Wed Sep 18 13:20:35 2013) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
On the ldap server (one line per sssd domain) :
ldapserver $ tail -f /var/log/openldap/slapd.log|grep "uidNumber=1047"|grep 1047
Sep 18 13:22:00 pantero slapd[31421]: conn=387670 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))" Sep 18 13:22:00 pantero slapd[31421]: conn=387671 op=5 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=1047)(objectClass=posixAccount))"
Each time I issue a "getent passwd 1047" I've got those entries in the log.
Hm, I think I see the problem as well...I'll poke to the code to see if there is some bug. I see utility functions for handling negative cache for UIDs and GIDs as well but as you said I'm also seeing the backed queried every time.
Hi,
I have a local patch. Are you interested in testing it out?
Thank you very much for reporting the bug!
On Wed, Sep 18, 2013 at 04:18:47PM +0200, Jean-Baptiste Denis wrote:
I have a local patch. Are you interested in testing it out?
Of course.
OK, the patch is in the thread called "[PATCH] NSS: Set UID and GID to negative cache after searching all domains". Are you able to apply it yourself or shall I build you a test package?
OK, the patch is in the thread called "[PATCH] NSS: Set UID and GID to negative cache after searching all domains". Are you able to apply it yourself or shall I build you a test package?
Thank you for the feedback and the patch.
If you could build a test package, that would be nice.
If you don't have the time, tell me and I'll find it next week. It's "just" a matter of following the DevelTutorials and the wiki, applying your patches to the head and build the RPM ?
On Wed, Sep 18, 2013 at 07:00:41PM +0200, Jean-Baptiste Denis wrote:
OK, the patch is in the thread called "[PATCH] NSS: Set UID and GID to negative cache after searching all domains". Are you able to apply it yourself or shall I build you a test package?
Thank you for the feedback and the patch.
If you could build a test package, that would be nice.
If you don't have the time, tell me and I'll find it next week. It's "just" a matter of following the DevelTutorials and the wiki, applying your patches to the head and build the RPM ?
Just applying the patches on top of git HEAD and typing "make rpms" should build you the RPMs.
Just applying the patches on top of git HEAD and typing "make rpms" should build you the RPMs.
Ok, I'll do that. I think I should wait the new version of your patch (goto/errno).
By the way, I thought my initial post was directory to the user mailing-list, sorry about that.
Jean-Baptiste
On 09/19/2013 10:31 AM, Jean-Baptiste Denis wrote:
Ok, I'll do that. I think I should wait the new version of your patch (goto/errno).
I've tested the updated patch (just before Simo's remark) and tested it : it works, the negative result is cached and the request does not it the ldap domain provider. Cool.
Jean-Baptiste
On Fri, Sep 20, 2013 at 10:19:13AM +0200, Jean-Baptiste Denis wrote:
On 09/19/2013 10:31 AM, Jean-Baptiste Denis wrote:
Ok, I'll do that. I think I should wait the new version of your patch (goto/errno).
I've tested the updated patch (just before Simo's remark) and tested it : it works, the negative result is cached and the request does not it the ldap domain provider. Cool.
Jean-Baptiste
Great, thank you for testing!
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jean-Baptiste Denis