On Thursday, September 6, 2012 at 1:46 PM, Shane Sofos wrote:
Hey All,
I am running into an interesting problem with chef 0.12.0 on CentOS 6.2/6.3 nodes. Our CentOS systems are utilizing the nslcd and nsswitch to for central user authentication against LDAP.
This is part of the nss-pam-ldapd package on CentOS. The system nsswitch uses the ldap module for the following elementsconfiguration is as follows:
passwd: files ldap
group: files ldap
protocols: files ldap
services: files ldap
netgroup: files ldap
automount: files ldap
sudoers: files ldap
I have a users cookbook to create/manage any new local users, but when ever a the user resource is executed during a chef run, we get this error from nslcd per user:
Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] ldap_search_ext() failed: Can't contact LDAP server
Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] no available LDAP server found, sleeping 1 seconds
Turning on nslcd debug mode, it looks like the user resource is using nslcd/ldap to verify a user account instead of looking at the local files such as /etc/passwd or /etc/shadow. See the debug output below:
[2012-09-06T12:42:17-07:00] INFO: Processing user[testuser] action remove (users::local line 94)
nslcd: [3c9869] DEBUG: nslcd_passwd_byname(testuser)
nslcd: [3c9869] DEBUG: myldap_search(base="dc=***,dc=com", filter="(&(&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))(sAMAccountName=testuser))")
nslcd: [3c9869] DEBUG: ldap_initialize(***)
nslcd: [3c9869] DEBUG: ldap_set_rebind_proc()
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_OFF)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD)
nslcd: [3c9869] DEBUG: ldap_simple_bind_s("***","***") (uri="***")
nslcd: [3c9869] DEBUG: ldap_result(): end of results
The major question here is can we restrict Chef to manage local users accounts/groups only without querying to LDAP using nslcd? It looks like the resource itself is potentially bypassing checks of local passwd/shadow files or checking them and then moving onto the next nsswitch module, which in this case is ldap. Has anyone else experienced these issues or have any insight on the inner workings of the chef user resource when using with ldap enabled Linux systems?
All the best,
Shane Sofos
Archive powered by MHonArc 2.6.16.