I have a class definition which requires the build-essential package:
class erlang($version = '17.3') {
package { "build-essential":
ensure => installed
}
...
}
Another class in a different module also requires the build-essential package:
class icu {
package { "build-essential":
ensure => installed
}
...
}
However, when I try to perform puppet apply, the error I receive is:
Error: Duplicate declaration: Package[build-essential] is already declared in file /vagrant/modules/erlang/manifests/init.pp:18; cannot redeclare at /vagrant/modules/libicu/manifests/init.pp:17 on node vagrant-ubuntu-trusty-64.home
I was expecting classes to encapsulate the resources they use but this doesn't seem to be the case? How can I resolve this clash?
This is common question when dealing with multiple modules.
There's a number of ways of doing this, the best practise is to modularise and allow the installation of build essential as a parameter:
class icu ($manage_buildessential = false){
if ($manage_buildessential == true) {
package { "build-essential":
ensure => installed
}
}
}
Then, where you want to include your ICU class:
class {'icu':
manage_buildessential => 'false',
}
However, for a quick and dirty fix:
if ! defined(Package['build-essential']) {
package { 'build-essential': ensure => installed }
}
Or if you have puppetlabs-stdlib module:
ensure_packages('build-essential')
If you control both modules, you should write a third class (module) to manage the shared resource.
class build_essential {
package { 'build-essential': ensure => installed }
}
Contexts that require the package just
include build_essential
Do not touch the defined() function with a 12" pole. There can be only pain down this road.
There are multiple ways as the other answers explain but this is another reliable way of doing it if you want to use the same resource multiple times.
Declare once and then realize it multiple times.. For example, Create a new virtual resource like this:
in modules/packages/manifests/init.pp
class packages {
#package{ 'build-essential':
ensure => installed
}
}
Then, in your both classes, include the below lines to realize the above virtual resource
include packages
realize Package('build-essential')
Related
I have a Puppet class which, among other things, sets up a whole bunch of Debian repositories, performs an apt-get update and then installs a few packages.
The ordering must be strictly as follows:
setup apt sources
apt-get update
install application packages
To define the ordering, I have used the following chaining after declaring all of my resources:
File['/etc/apt/apt.conf','/etc/apt/sources.list'] ->
Exec['apt-get update'] ->
Class['vim','sudo', ..., ..., ]
However, here is the issue:
If I set vim to install only if the host is a virtual machine, and the host I am performing the Puppet run on is physical, the run will fail. I assume this is because it is attempting to run Class['vim'] as per my chaining but cannot find the class declaration due to the contents of the if statement not being parsed.
Here is the code:
if $::is_virtual == 'true' {
class {'vim':
set_default => true,
}
}
I can work around this by adding a "requires => Exec['apt-get update']" to my vim resource declaration and removing from my chain, but this feels a bit hacky. Here is what my class declaration looks like once I do this:
if $::is_virtual == 'true' {
class {'vim':
requires => Exec['apt-get update'],
set_default => true,
}
}
Does anybody have any other methods of dealing with such ordering issues? Is there anyway I can deal with ordering classes held within conditional statements which may or may not be triggered via chaining? Any advice is appreciated.
Your approach using require is sound. If you really have to stick to the chaining operator, you can wrap the if block in yet another class.
class site::vim {
if $::is_virtual == 'true' { ... }
}
Then include and chain Class[site::vim], which will honor the is_virtual value on its own.
In puppet, I have the following two classes:
class zabbix-agent {
package { 'zabbix-agent': }
->
service { 'zabbix-agent':
ensure => running
}
}
class zabbix-agent-cassandra {
include zabbix-agent
Class['zabbix-agent']
->
file { '/etc/zabbix/zabbix_agent.conf.d/cassandra.conf':
}
~>
Service['zabbix-agent']
}
This looks great at first, since it allows to add new configurations files to /etc/zabbix/zabbix_agent.conf.d/ from any class, and to restart zabbix-agent when doing so.
However there is a dependency cycle:
Service[zabbix-agent] => Class[Zabbix-agent] => File[/etc/zabbix/zabbix_agentd.conf.d/cassandra.conf] => Service[zabbix-agent]
It there a way to avoid the dependency cycle ?
You're telling Puppet to
manage the zabbix package and service
do this before managing the config file
if the config file changed, manage the service (again)
This is problematic, given that Puppet will touch each resource exactly once.
The best approach will likely be to bring more structure to your zabbix module.
class zabbix::agent {
include zabbix::package
include zabbix::service
Class['zabbix::package'] -> Class['zabbix::service']
}
This allows you to just
Class['zabbix::package'] -> File[...] ~> Class['zabbix::service']
which is DRYer and, in your particular case, avoids circular dependencies.
I'd like to use and configure the puppet-nginx module, although this is a general question about Puppet configuration.
Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }
class nginx-setup {
class { 'nginx': }
}
include nginx-setup
Works great! Now, if I follow the docs for configuration I end up with something like this:
Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }
class nginx-setup {
class { 'nginx': }
class { 'nginx::package':
package_source => 'nginx-mainline'
}
}
include nginx-setup
Error: Duplicate declaration: Class[Nginx::Package] is already declared
I tried include nginx instead of my first class declaration, but I think the module's init.pp is declaring the nginx::package class already and I still get duplicate declaration error. Even if that worked, what if I wanted to apply more configurations to another class within the nginx module? For example:
Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }
class nginx-setup {
class { 'nginx': }
class { 'nginx::package':
package_source => 'nginx-mainline'
}
class { 'nginx::config':
nginx_error_log => 'syslog:server=localhost',
}
}
include nginx-setup
Many duplicate definitions!
So it feels like I should be passing everything required into my initial class declaration, but I can't seem to find the right way to do it. What is the best way to achieve this?
TL;DR
Consider using Hiera after all, for this module is tricky to use otherwise, due to some shortcomings in Puppet's handling of class parameters.
Long answer:
That's a loaded question, actually, even though it should not be. You correcly inferred the gist already. But let's take it step-by-step.
Module structure
It is now considered best practice (citation needed, although Ryan Coleman from Puppet Labs mentioned this in a recent presentation at FOSDEM) to expose all tunables of a module in its central class (here, class nginx).
This way, it is clear for the user that they need to look up the appropriate parameter for this one class, instead of going on a hunt for the appropriate class to tune.
The nginx module you picked seems to adopt this in large parts, but not consequently.
Hacks using defined()
As you have noticed, the module author added some shortcuts to allow you to declare your classes "safely" if you make sure the nginx::config class is encountered before the nginx class proper, lexically.
This is dangerous, because in a complex manifest, this might not be easy to assert.
include vs. class { }
Class parameters are problematic, because they lead to include being less safe than it used to be, because they don't mix well with class { 'name': ... } style declarations. The latter are always bad news because they have to be unique, as you are now experiencing.
It is best to stick to include as much as possible, which leads to the next issue.
Hiera
With parameterized classes, you really want to adopt Hiera as soon as possible. Defining class parameters as data is almost universally superior to doing it in the manifest. I understand the desire to stick to simple constructs first, but due to the issue described above, it can really make life harder on yourself.
It turns out it was module-specific. jfryman/puppet-nginx module classes are loaded automatically except for nginx::config (unless it isn't declared already) and most other classes inherit their settings from nginx::config. The correct solution for this module is;
class nginx-setup {
class { '::nginx::config':
http_access_log => 'syslog:server=localhost,tag=nginx,severity=info',
nginx_error_log => 'syslog:server=localhost,tag=nginx,severity=info',
}
class { '::nginx':
package_source => 'nginx-mainline',
}
}
include nginx-setup
jfryman/puppet-nginx is moving towards Hiera configurations and this might not work for long. I wanted a pure Puppet solution (to learn) before integrating Hiera but I wouldn't recommend it for everyone...
I'm new to puppet and I'm trying to figure out how to get different hosts installing different packages, but I've stumbled upon an issue I can't figure out. These are my manifests:
My site.pp:
node default {
}
node 'debh3' inherits default {
}
node 'debh4' inherits default {
import "db"
}
node 'master' inherits default {
}
My db.pp:
package { 'mysql-server':
ensure => installed
}
service { 'mysql':
ensure => true,
enable => true,
require => Package['mysql-server']
}
With this setup, mysql-server is being installed on debh3.
If I replace the "import db" with the actual code inside my db.pp, then mysql-server is only installed on debh4 (which is the behaviour i'm after).
Does anyone have a clue what I'm doing wrong here? I've put it all in site.pp to ensure there are no other dependencies affecting anything.
Also note that the import statement is deprecated and about to be removed from Puppet 4.0.
You should move your code to modules. In this case, you want to create a db module.
In /etc/puppet/modules/db/manifests/install.pp
class db::install {
package { 'mysql-server':
ensure => installed
}
}
an in /etc/puppet/modules/db/manifests/service.pp
class db::service {
include db::install
service { 'mysql':
ensure => true,
enable => true,
require => Class['db::install'],
}
}
From you node block, you can then just
include db::install
include db::service
or even just include db::service.
You could have both resources in one class, but it's good practice to structure your code through multiple classes.
Upon further digging, I found this in the "import" documentation at https://docs.puppetlabs.com/puppet/latest/reference/lang_import.html:
Import statements have the following characteristics:
They read the contents of the requested file(s) and add their code to top scope
They are processed before any other code in the manifest is parsed
They cannot be contained by conditional structures or node/class definitions
These quirks mean the location of an import statement in a manifest does not matter.
This points to why what I was doing was incorrect and why it caused the behaviour. As for a solution, I will look into best practices and determine the "correct" way to structure my manifests.
I'm writing some puppet modules and have a package defined in two modules hence get the following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate definition: Package[gnome-session-fallback] is already defined in file /etc/puppet/modules/vnc4server/manifests/init.pp at line 3; cannot redefine at /etc/puppet/modules/vino/manifests/init.pp:7 on node l
Hence want to ensure that the package has not already been defined but the following does not work:
if ! defined ('gnome-session-fallback') {
package { 'gnome-session-fallback':
ensure => installed,
}
}
Can anyone suggest how to fix this, and on the broader scale, what is the "proper" approach to avoiding clashes such as this in modules?
You are missing Package[] inside defined(). The correct way to do it:
if ! defined(Package['gnome-session-fallback']) {
package { 'gnome-session-fallback':
ensure => installed,
}
}
The cleanest way to do this is to use the ensure_resource function from puppetlabs-stdlib:
ensure_resource('package', 'gnome-session-fallback', {'ensure' => 'present'})
To answer my own question about what the "proper" approach is : This issue is discussed at https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/julAujaVsVk and jcbollenger offers what looks like a "best-practice" solution - resources which are defined multiple times should be moved into their own module and included into the classes on which they depend. I applied this and solved my problem.
This doesn't actually answer why "if !defined" fails however...
One cleaner way (among multiple ways) is to create a virtual package resource and then realize it. You can realize the same virtual package multiple times without error.
#package { 'gnome-session-fallback':
ensure => installed,
}
And then where you need it:
realize( Package[ 'gnome-session-fallback' ] )