On May 3, 2012, at 6:09 AM, jcbollinger wrote:
On May 2, 6:10 pm, Craig White craig.wh...@ttiltd.com wrote:
for reasons probably not important to the discussion, I am trying to
transition my Ubuntu setups from using libnss-ldap / libpam-ldap over to the
libnss-ldapd / libpam-ldapd. There some files that have minor differences
such as /etc/pam.d/common-session.
So I have my ldap module which manages this file and all my servers are
currently using this setup.
I have essentially duplicated the ldap module into ldap_alt module which I
thought could peaceably coexist with the ldap module as long as both weren't
assigned but alas...
Indeed they could and should.
I was thinking that this shouldn't be a problem as long as both classes weren't
configured for the same node. Perhaps this is a problem because the 'previous'
class was used on this node and thus puppet still believes that it is
maintaining the files even though I've removed the previous class from the node
(using foreman ENC). Thus I removed all the ldap configuration from the foreman
ENC for this node, successfully did a puppet run, then enabled the 'ldap_alt'
and it failed sort of disputing this theory of mine.
notice: Ignoring --listen on onetime run
info: Retrieving plugin
info: Loading facts in passenger_version
info: Loading facts in datacenter
info: Loading facts in passenger_version
info: Loading facts in datacenter
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: File[/etc/pam.d/common-session] is already defined in
file /etc/puppet/modules/ldap/manifests/configure.pp at line 103; cannot
redefine at /etc/puppet/modules/ldap_alt/manifests/configure.pp:103 on node
nxpc.ttinet
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
which makes me think that I will have to have to do all of the package
management within a single module unless I am missing something.
Very likely you are missing something. Puppet should not even be
reading both the configure.pp files unless the classes therein are
both assigned to your node, directly or indirectly. Since you created
one module by duplicating the other, my guess would be that you missed
changing one or more namespaces in the copy, leaving them referring to
the original module. For example, you might have something like this:
ldap_alt/manifests/foo.pp:
---
class ldap_alt::foo {
# oops:
include 'ldap::configure'
...
}
did extensive checking for this before mailing the list. All of the classes
template references reference the new module but the files being managed (and
there are a few of them to be sure) are necessarily the same such as
/etc/ldap.conf
/etc/ldap.secret
/etc/nsswitch.conf
/etc/pam.d/common-password
/etc/pam.d/common-session
and this is the latest error...
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: File[/etc/ldap/ldap.conf] is already defined in file
/etc/puppet/modules/ldap/manifests/configure.pp at line 94; cannot redefine at
/etc/puppet/modules/ldap_alt/manifests/configure.pp:94 on node nxpc.ttinet
where the original (/etc/puppet/modules/ldap/manifests/configure starting at
line 87)
file {/etc/ldap/ldap.conf:
content = template(ldap/openldap_ldap.conf.erb),
owner = root,
group = root,
mode= 0644,
require = Class[ ldap::client_install ],
notify = Class[ nscd::service ],
}
and the new module (/etc/puppet/modules/ldap_alt/manifests/configure.pp
starting at line 87)
file {/etc/ldap/ldap.conf:
content = template(ldap_alt/openldap_ldap.conf.erb),
owner = root,
group = root,
mode= 0644,
require = Class[ ldap_alt::client_install ],
notify = Class[ nscd::service ],
}
You could try grepping ldap_alt's manifest for the string ldap::.
already did before mailing the list but anyway...
root@polonium:/etc/puppet/modules/ldap_alt/manifests# grep ldap:: *
root@polonium:/etc/puppet/modules/ldap_alt/manifests# grep ldap:: *
root@polonium:/etc/puppet/modules/ldap_alt/manifests#
nada ;-(
So it seems obvious that even though the classes ldap::client_install and
ldap::configure are not in the ENC, not currently being assigned to this
system, the past inclusion is somehow hanging on causing the conflict (and
indeed they are there in /var/lib/puppet/state/classes.txt). So I manually edit
this file, remove the references to them with vi and the next puppet run they
return. ;-(
Thanks
Craig
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group
