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... 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. -- Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com Need help communicating between generations at work to achieve your desired success? Let us help! -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I''ve done this sort of thing (upgrading puppetmasters in my case) by having one class (thing::mainclass) manage all the resources of the new one and depend on another class (otherthing:removeclass) which restored/defaulted/removed everything that shouldn''t be there. You might need to be more careful when reconfiguring ldap, though. When done in the wrong order I''ve had my lab host block and need a reboot. On Wed, May 02, 2012 at 04:10:07PM -0700, Craig White 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... > > 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. > > -- > Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com > 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com > > Need help communicating between generations at work to achieve your desired success? Let us help! > > -- > 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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.> 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'' ... } You could try grepping ldap_alt''s manifest for the string "ldap::". John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On May 3, 2012, at 8:55 AM, Craig White wrote:> On May 3, 2012, at 6:09 AM, jcbollinger wrote:>> 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:> 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. ;-(---- out of sight - out of mind. Even though I''m using foreman as ENC and I would think that /etc/puppet/manifests/nodes.pp (default node) shouldn''t have any impact, it clearly did as was doing the dirty deed of adding the classes back in each catalog run. Thanks - solved 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.