trying to use a puppet forge module that uses a different style

101 views
Skip to first unread message

Craig White

unread,
Nov 17, 2014, 5:40:28 PM11/17/14
to puppet...@googlegroups.com
Not that it matters, but I am trying to use a module out of puppet forge - camptocamp-openldap

There's no hint of using it anywhere

It has an unusual style. There isn't any init.pp and the structure looks like this...

├── client
│   ├── config.pp
│   ├── install.pp
│   ├── ldapvi.pp
│   └── utils.pp
├── client.pp
├── server
│   ├── access.pp
│   ├── config.pp
│   ├── database.pp
│   ├── dbindex.pp
│   ├── globalconf.pp
│   ├── install.pp
│   ├── module.pp
│   ├── overlay.pp
│   ├── service.pp
│   └── slapdconf.pp
├── server.pp
└── wl.pp

The last file - wl.pp is my own file and it looks like this...

  $ensure    = present
  $directory = '/var/lib/ldap'
  $rootdn    = 'cn=admin,dc=wl,dc=com'
  $rootpw    = 'password'
  $dn        = 'dc=wl,dc=com'

  # Install openldap server
  class { 'openldap::server':
  }

  openldap::server::database { $dn:
    ensure => present,
    rootdn => "cn=admin,${dn}",
    rootpw => $rootpw,
  }

and if I use 'puppet apply -vd --modulepath /etc/puppet/modules wl.pp

it works fine but I can't put those variables into the server.pp file or any of the files in the /server subdirectory because they don't work.

I need a method - I thought a class openldap::wl class but I can't make that work either. How do I structure this so I can use one class to configure clients without resorting to re-writing the module completely so it comports to a style that I understand?

Steven Post

unread,
Nov 18, 2014, 7:32:54 AM11/18/14
to puppet...@googlegroups.com
Hi Craig,

If you scroll down on the website you mentioned, you'll see some usage instructions.
I recommend *not* to change the module (not even adding your own wl.pp file inside), but to set up your wl.pp file elsewhere.
You can use your own class (wl.pp, located outside this module) to set up the LDAP configuration using the module.

I use the roles/profile setup, but you can leave the roles out if that is easier for you, it takes some time getting to really know it all.
That said, the ldap module controls ldap, but not your node.
your node should have some other class assigned to it (such as wl.pp), which then uses the ldap module, unchanged.
More info about the roles/profile pattern: http://www.craigdunn.org/2012/05/239/
One of the ideas here is that you should never need to change a module you download from the forge (with some rare exceptions)

Regards,
Steven

jcbollinger

unread,
Nov 18, 2014, 9:27:20 AM11/18/14
to puppet...@googlegroups.com


On Monday, November 17, 2014 4:40:28 PM UTC-6, Craig White wrote:
Not that it matters, but I am trying to use a module out of puppet forge - camptocamp-openldap

There's no hint of using it anywhere

It has an unusual style. There isn't any init.pp and the structure looks like this...


It is a bit unusual to not have an init.pp, but only because it has become so common for each module to have an eponymous class (i.e. a class "openldap" in this case).  This module does not need or want that because the client and server pieces share nothing.  The init.pp is not a qualification for being a module, nor is it automatically loaded in general, it is just the manifest where Puppet expects to find the definition of the eponymous class, if there is one.
 

├── client
│   ├── config.pp
│   ├── install.pp
│   ├── ldapvi.pp
│   └── utils.pp
├── client.pp
├── server
│   ├── access.pp
│   ├── config.pp
│   ├── database.pp
│   ├── dbindex.pp
│   ├── globalconf.pp
│   ├── install.pp
│   ├── module.pp
│   ├── overlay.pp
│   ├── service.pp
│   └── slapdconf.pp
├── server.pp
└── wl.pp



Other than not having an init.pp, that doesn't look particularly strange to me.  It's a bit big, but there are a lot of pieces to manage.

 
The last file - wl.pp is my own file and it looks like this...

  $ensure    = present
  $directory = '/var/lib/ldap'
  $rootdn    = 'cn=admin,dc=wl,dc=com'
  $rootpw    = 'password'
  $dn        = 'dc=wl,dc=com'

  # Install openldap server
  class { 'openldap::server':
  }

  openldap::server::database { $dn:
    ensure => present,
    rootdn => "cn=admin,${dn}",
    rootpw => $rootpw,
  }



Oh no, no, no.  You should not add code to a module in order to use the module.  Moreover, you should have top-level declarations only in your site manifest.  Your wl.pp is in fact functioning as a site manifest when you name it in a 'puppet apply' run, so it's not necessarily wrong in itself, it just doesn't belong in the module (and putting it there confers no particular advantage).

 
and if I use 'puppet apply -vd --modulepath /etc/puppet/modules wl.pp

it works fine but I can't put those variables into the server.pp file or any of the files in the /server subdirectory because they don't work.


I'm not clear on what you're trying to do.  When you say "it works" do you mean that wl.pp achieves everything you're after, or just that it runs without error?

 

I need a method - I thought a class openldap::wl class but I can't make that work either. How do I structure this so I can use one class to configure clients without resorting to re-writing the module completely so it comports to a style that I understand?
 

Well, it looks like you configure clients by declaring instances of class openldap::client, which sounds like what you want.  The module seems actually to have reasonably good documentation, including examples, at the URL you provided.


John

Craig White

unread,
Nov 18, 2014, 10:50:33 AM11/18/14
to puppet...@googlegroups.com
It seems that node inheritance is deprecated in Puppet 4 so this is a no go (role/profiles).

I suppose I should have mentioned that I will be using an ENC so I am trying to keep the cruft inside node definitions to a minimum which is why I am struggling to find a way to create a class - certainly I can create a new wl class for this but then I am struggling to make these things work inside a class.

Craig White

unread,
Nov 18, 2014, 10:57:17 AM11/18/14
to puppet...@googlegroups.com
On Tuesday, November 18, 2014 7:27:20 AM UTC-7, jcbollinger wrote:

On Monday, November 17, 2014 4:40:28 PM UTC-6, Craig White wrote:
The last file - wl.pp is my own file and it looks like this...

  $ensure    = present
  $directory = '/var/lib/ldap'
  $rootdn    = 'cn=admin,dc=wl,dc=com'
  $rootpw    = 'password'
  $dn        = 'dc=wl,dc=com'

  # Install openldap server
  class { 'openldap::server':
  }

  openldap::server::database { $dn:
    ensure => present,
    rootdn => "cn=admin,${dn}",
    rootpw => $rootpw,
  }



Oh no, no, no.  You should not add code to a module in order to use the module.  Moreover, you should have top-level declarations only in your site manifest.  Your wl.pp is in fact functioning as a site manifest when you name it in a 'puppet apply' run, so it's not necessarily wrong in itself, it just doesn't belong in the module (and putting it there confers no particular advantage).
----
As usual, John has identified what I am trying to do.

Yes, I want to have an assignable class to what is essentially site manifest coding in anticipation of using an ENC and Hiera. 
---- 

 
and if I use 'puppet apply -vd --modulepath /etc/puppet/modules wl.pp

it works fine but I can't put those variables into the server.pp file or any of the files in the /server subdirectory because they don't work.


I'm not clear on what you're trying to do.  When you say "it works" do you mean that wl.pp achieves everything you're after, or just that it runs without error?
----
works as in installs openldap-servers package, configures it per the database instructions I have provided.
---- 

 

I need a method - I thought a class openldap::wl class but I can't make that work either. How do I structure this so I can use one class to configure clients without resorting to re-writing the module completely so it comports to a style that I understand?
 

Well, it looks like you configure clients by declaring instances of class openldap::client, which sounds like what you want.  The module seems actually to have reasonably good documentation, including examples, at the URL you provided.
----
No - just looking for a way to create a class (or obviously now that everyone is suggesting modifying a 3rd party module is bad form), a new module that is basically site manifest code. I do have more that I want to do and just provided the two things that I just can't make work properly inside of a class but I will try doing it in a new class/module and see if that makes a difference.

Steven Post

unread,
Nov 18, 2014, 11:06:34 AM11/18/14
to puppet...@googlegroups.com
The roles/profile pattern does not use node inheritance, only class inheritance.
Strictly speaking, this isn't even necessary, it can just make some things easier.

At my company, we don't even use any real node definition, everything is done with an ENC and hiera.
The roles/profile model still fits here, and we use it actively, as do many other people.
A role is just a simple class, that includes roles (mostly), there is only 1 'node' definition in the manifests: default.

It goes something like this:
ENC assigns a node to a role (regular class), a role includes 1 or more profiles and sometimes some extra stuff such as packages (RPM)
the profile does the actual modules. Also there is still hiera in all this, mostly using the automatic class parameters.
A node actually gets both the 'default' node definition and the 'role'.

Craig White

unread,
Nov 18, 2014, 11:09:32 AM11/18/14
to puppet...@googlegroups.com
OK - but I still need to figure out how to call one class with parameters from another class...

class wl::config { :
    class openldap::server::database { $dn:

Steven Post

unread,
Nov 18, 2014, 11:18:33 AM11/18/14
to puppet...@googlegroups.com
If you use hiera and puppet 3 (or later), you can use the automatic class parameters for that, and just 'include openldap::server::database'.
Of cause you can set up some class parameters on your own class if you want to and do that.
Typically, this is where I would use hiera for.

Craig White

unread,
Nov 18, 2014, 12:19:56 PM11/18/14
to puppet...@googlegroups.com


On Tuesday, November 18, 2014 9:18:33 AM UTC-7, Steven Post wrote:
If you use hiera and puppet 3 (or later), you can use the automatic class parameters for that, and just 'include openldap::server::database'.
Of cause you can set up some class parameters on your own class if you want to and do that.
Typically, this is where I would use hiera for.
----
I understand that but now I have to have a whole lot of instructions for people to spin up a server with ENC parameters without even getting into the fact that I will still need a class to do all of the things I have to do with this (post install scripts) after it is installed. That is why I am so eager to not have this code anywhere in a site manifest or anything resembling a site manifest but rather in its own class. 

No matter how I try, I simply cannot figure out how to have this work...

jcbollinger

unread,
Nov 18, 2014, 12:51:51 PM11/18/14
to puppet...@googlegroups.com


On Tuesday, November 18, 2014 10:09:32 AM UTC-6, Craig White wrote:
OK - but I still need to figure out how to call one class with parameters from another class...

class wl::config { :
    class openldap::server::database { $dn:
    ensure => present,
    rootdn => "cn=admin,${dn}",
    rootpw => $rootpw,
  }
}



Oh, is THAT all?  You are mixing the syntax for defining a class with that for declaring one.  A resource-style class declaration looks like this:

class { 'mymodule::myclass':
  param1
=> value1,
  param2
=> value2
}

HOWEVER, your specific example also seems to imply that you think openldap::server::database is a class, whereas it's actually a resource type (specifically, a defined type).  You would declare instances of that type just like you declare instances of any other resource type:


openldap::server::database { $dn:
 
ensure => present,
  rootdn
=> "cn=admin,${dn}",
  rootpw
=> $rootpw,
}

The docs of the openldap module provide additional examples of both.

Do note, however, that an ENC cannot emit resource declarations, only class declarations and global variables.  Moreover, be aware that for most purposes it is poor form to use resource-like class declarations.  They do have their purposes, but it is usually better form to bind data to classes via Hiera than to bind it explicitly in the class declaration (whether via node block or via ENC).  Use the 'include' family of functions to declare classes wherever it is feasible to do so.


John

Craig White

unread,
Nov 18, 2014, 2:27:38 PM11/18/14
to puppet...@googlegroups.com
yes that was all  ;-)

Got it - thanks

yes, the intent is to use hiera on all of this but I have to knock down one hurdle at a time. Now that I can have made it work, I can start fooling with hiera which I never used before.

Thanks so much
Reply all
Reply to author
Forward
0 new messages