Re: [Puppet Users] Re: transitioning a file resource

Craig White
Thu, 03 May 2012 15:55:41 -0000

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