Bug #3159
LDAP groups are being mis-interpretted by RAL
| Status: | Duplicate | Start date: | 02/07/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | RAL | |||
| Target version: | - | |||
| Affected Puppet version: | 0.24.8 | Branch: | ||
| Keywords: | ldap, ral, centos, rhel, nss | |||
| Votes: | 2 |
Description
It seems puppet is getting confused regarding ldap users and groups
err: //Node[foo]/class/File[/var/log/httpd]: Failed to retrieve current state of resource: Could not find group readonly at /etc/puppet/svn/manifests/common/common.pp:26
[foo ~]# getent group | grep readonly readonly:*:4002:user1,user2
[foo ~]# ralsh group readonly group { ‘readonly’: ensure => ‘absent’ }
Using Centos 5.4 with Xen, and 389 Directory Server. Puppet version puppet-0.24.8-4.el5. Facter facter-1.5.7-1.el5. NSS ldap nss_ldap-253-22.el5_4.
Is this a known problem? I googled around a bit and found similar problems but nothing that looked exactly the same.
Thanks
Joel
Related issues
History
Updated by James Turnbull over 2 years ago
- Status changed from Unreviewed to Needs More Information
hmmm. Are the ruby-ldap bindings present?
Updated by Joel Heenan over 2 years ago
Sorry how do I find the ruby-ldap bindings?
It appears the issue “goes away” after a while. I think the problem is that we deploy the LDAP configuration itself through puppet, and while I set a require on the objects that use LDAP users/groups I think by that time the RAL fact gathering stage has completed. Sorry I think I have seen other bugs about this problem.
Assuming this is the issue – is there a better answer rather than just re-running puppet until it works, something that says ok you have deployed ldap configuration now I want you to re-gather all users-groups?
Updated by Jo Rhett 6 months ago
I am seeing this problem continue for weeks at a time.
Sat Nov 12 08:04:25 +0000 2011 /File[/local/tools] (err): Could not evaluate: Could not find group ops at /nas/puppet/manifests/actions/slashlocal.pp:22
[00:13 ~]# getent group |grep ops ops:*:10000:bhansen,isapelnikov,gmartin,ldunston,jrhett,ccord,mcuerdon,opsuser
[00:13 ~]# ralsh group ops warning: Group users found in both groupadd and groupadd; skipping the groupadd version group { ‘ops’: ensure => ‘present’, gid => ‘10000’, }
CentOS 5.7 with 389 Directory Server The following RPMs all from from yum.puppetlabs.com: Puppet puppet-2.6.12-2.el5 Facter facter-1.6.3-1.el5 (first saw problem with facter 1.6.2, tried upgrade with no change) NSS ldap nss_ldap-253-42.el5_7.4
I’d like to note I have 3 systems showing this problem every run right now, so I can actively recreate at will.
Oddly, “puppet agent —test” runs clean, but the scheduled 30min runs show this problem 48 times a day ;–)
Updated by Jo Rhett 6 months ago
Per the first question on this ticket, we do not have the ruby ldap bindings installed anywhere, on any system. Everything has always “just worked” ;–)
Updated by Jo Rhett 6 months ago
I found it!! It turns out that none of these puppet daemons had been restarted since they actually set up ldap on the client system
like, puppet added the ldap package, modified nsswitch.conf, ldap.conf etc. and puppet hadn’t been restarted since then restarting the daemon solved the problem.
This seems to relate to other bugs about caching information. What confuses me is that LDAP was installed over a month ago on these systems. That seems to be an awful long time to cache user/group information!
Updated by James Turnbull 6 months ago
- Status changed from Needs More Information to Duplicate
This is a duplicate of #791.