same question on Server's Fault :
I'm trying to include puppetlabs-apache module (v1.10.0) in my deploiement, i'm having an issue just by running with default configs
puppet apply -e 'include apache'
or
puppet apply -e 'class { 'apache':
default_vhost => false,
default_ssl_vhost => false,
}'
I'm having dependency cycle as follows :
Error: Failed to apply catalog: Found 2 dependency cycles:
(File[15-default-ssl.conf symlink] => File[15-default-ssl.conf symlink])
(File[15-default.conf symlink] => File[15-default.conf symlink])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
Any help will be appreciated
CentOS 7.1
puppetlabs-apache 1.10.0
puppetdb-4.2.0-1.el7.noarch
puppet-agent-1.5.3-1.el7.x86_64
The issue was because of a missconfiguration in Hiera :
apache::vhost_dir: '/etc/httpd/conf.d/vhosts'
apache::vhost_enable_dir: '/etc/httpd/conf.d/vhosts'
I think we might add a condition so that the : apache::vhost_dir must be different from apache::vhost_enable_dir ass well as apache::mod_dir must be different from apache::mod_enable_dir
Related
I use puppet to update / maintain itself (among other things). For some reason every time the client runs I get these two actions:
Notice: /Stage[main]/Servers::Packages::Puppet/Package[facter]/ensure: created (corrective)
Notice: /Stage[main]/Servers::Packages::Puppet/Package[puppet]/ensure: created (corrective)
The definitions in question look like this:
package { 'puppet' :
ensure => 'latest',
require => Package['facter'];
}
package { 'facter' :
ensure => 'latest',
}
file { '/etc/default/puppet' :
ensure => 'file',
mode => '644',
source => 'puppet:///modules/servers/packages/puppet/default';
}
file{ '/etc/puppetlabs/puppet/puppet.conf' :
mode => '644',
content => template("servers/packages/puppet/puppet_conf.erb"),
require => Package[ 'puppet' ];
}
service{ 'puppet' :
ensure => 'running',
enable => true,
require => Package[ 'puppet' ],
subscribe => [
File[ '/etc/default/puppet'],
File[ '/etc/puppetlabs/puppet/puppet.conf'],
];
}
What's wrong with my definition(s)? Why do puppet / facter appear to be reinstalled with every run?
Since Puppet 4, Puppet, Inc. has provided only all-in-one packages of client-side components, not named either 'puppet' or 'facter'. The package for Puppet 6 is named puppet-agent -- this is what you should be managing, not packages named 'puppet' or 'facter'.
The messages you report indicate that Puppet does not see up-to-date 'puppet' or 'facter' packages, which is natural because these do not exist. They also indicate that puppet thinks it has corrected the problem -- which it will have attempted to do by installing / updating packages with those names, and which apparently succeeded. This seeming incongruity will have arisen because the puppet-agent packages declare that they provide features named "puppet" and "facter", which your package manager is using to associate those package names with the puppet-agent package. As a result, the installation / update succeeds without actually installing anything new, leaving the system primed to do the same thing over again on the next run.
I suspect that the "(corrective)" marks on the log output reflect package-manager exit statuses indicating success without doing anything.
I'm pretty new to puppet and I'm trying to use the module puppetlabs-dhcp (v0.3.0) with puppet master/agent v3.7.2. I'm using a very simple class declaration following the example given by the README file.
When I try to run the class on the node using puppet agent -t the run fails with the error
Error: Failed to apply catalog: Could not find dependency File[/etc/dhcp/dhcpd.conf] for Service[isc-dhcp-server] at /etc/puppet/modules/dhcp/manifests/init.pp:173
I tried adding a file resource before the dhcp class declaration but the file stays blank. None of the configurations are taken into account.
I checked the dependencies:
concat > 1.0.1 (using 2.0.2)
stdlib > 2.0.0 (using 4.13.1)
Here is the dhcp portion of the node in site.pp:
class {'dhcp':
dnsdomain => [
'jecks.lab',
'0.0.10.IN-ADDR.ARPA',],
nameservers => ['10.0.0.2'],
ntpservers => ['us.pool.ntp.org'],
interfaces => ['eth0','eth1'],
}
dhcp::pool{'ops.jecks.lab':
network => '10.0.0.0',
mask => '255.255.255.0',
range => ['10.0.0.100','10.0.0.254'],
gateway => '10.0.0.1',
}
dhcp::host {'debian-main':
mac => 'xxxxxxxxxxxxxx',
ip => '10.0.0.3',
}
What am I doing wrong? I assumed the dhcpd.conf file was created using concat from the parameters given in the class declaration.
This is a bug in puppetlabs-dhcp 0.3.0 when using concat 2.x that was fixed in 0.4.0. Using a newer version of the dhcp module or downgrading concat to 1.x would fix it.
Note that the puppetlabs-dhcp module moved to the Vox Pupuli community organisation a while ago, so you can find updates at puppet/dhcp on the Forge. The latest at the time of writing is 1.0.1, rather than 0.3.0.
I am starting the journey with Puppet.
I have installed stand-alone puppet on RHEL 6.0 (NO master/agent, just stand-alone)
Puppet version is 4.5.2
I have created a module /opt/puppetlabs/puppet/modules/common/manifests/init.pp as
class user {
user { 'wasadmin':
ensure => present,
comment => 'wasadmin user',
home => '/home/wasadmin',
managehome => true
}
}
my site.pp is here as /opt/puppetlabs/puppet/manifests/site.pp
node "CI-TEST-POC" {
include user
}
modulepath = /etc/puppetlabs/code/environments/production/modules:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules
when I execute with and without --modulepath, I am still getting the same error
root#CI-TEST-POC manifests# puppet apply site.pp
Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::user for ci-test-poc.corp.aal.au at /opt/puppetlabs/puppet/manifests/site.pp:2:4 on node ci-test-poc.corp.aal.au
root#CI-TEST-POC manifests# puppet apply site.pp --modulepath ../modules
Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::user for ci-test-poc.corp.aal.au at /opt/puppetlabs/puppet/manifests/site.pp:2:4 on node ci-test-poc.corp.aal.au
I have created a module /opt/puppetlabs/puppet/modules/common/manifests/init.pp as
class user {
The problem lies here, as Puppet requires that the layout of manifests matches the name of the classes/defines within them to help it quickly and correctly find the right file.
For your user class, it should be defined in /opt/puppetlabs/puppet/modules/user/manifests/init.pp.
My puppet structure is as follows
/puppet
/manifests
/nodes
redis.pp
site.pp
/modules
The site.pp resembles
class base {
include ml-basefw
include ml-users
include ml-filelimits
include repoforge
include epel
class { 'ml-yumrepo':
base_url => "http://${puppet_server}/yumrepo"
}
}
import 'nodes/*.pp'
node default {
include base
}
When I run
puppet apply --modulepath=/puppet/modules:/puppet/manifests --noop --debug /puppet/manifests/nodes/redis.pp
I receive
Error: Could not find class base for redis-1.test.ml.com on node redis-1.test.ml.com
Is there something non-standard about my file layout that precludes me from using apply?
I am not the maintainer of the puppet module so I am not able to alter the file structure or layout.
There are numerous related questions but I wasn't able to relate them to the problem that I am having.
Edit1 : Adding redis.pp
node /^redis-\d+(.stage)?(.test)?(.aws)?.ml.com$/ {
include base
include epel
class { 'redis':
package_ensure => '2.8.15-1.el6.remi',
service_ensure => 'running',
conf_bind => '0.0.0.0',
conf_port => '6379',
}
firewall { '176 allow port 6379 for redis traffic':
chain => 'INPUT',
state => ['NEW'],
dport => '6379',
proto => 'tcp',
action => 'accept'
}
}
What happens when you run puppet apply against your site.pp file instead? You probably don't have a node definition in your redis.pp file (nor should you).
This does in fact look a little messy and convoluted.
What you want is
an actual base module
defining class base in /puppet/modules/base/manifests/init.pp
You should also loose the import statement by arranging your manifests better. If your version of Puppet is recent enough (I think 3.6+), just see the docs.
fist of all, puppet have the entry manifest file.
in master mode, the entry is site.pp and puppet deprated deprecated it from version 3.5, it started auto imported all manifest files in specified directory.
in apply mode, the entry is specified file in your command.
so it works fine in your production environment, puppet master read site.pp(contains class base) and import nodes/*.pp(redis.pp, contains node definition). but when you use "puppet apply /puppet/manifests/nodes/redis.pp", puppet just read redis.pp, no anyone tell puppet where the base class is.
I'm trying to install the puppet module at https://github.com/dwerder/puppet-mongodb
One of the requirements for it to work is to have the mongodb repository set-up. Since I'm trying to deploy it on Debian I tried using the following class to add the source:
class mongodb::apt::repo {
include apt
apt::source { '10gen':
location => 'http://downloads-distro.mongodb.org/repo/debian-sysvinit',
release => 'dist',
repos => '10gen',
key => '7F0CEB10',
key_server => 'keyserver.ubuntu.com',
include_src => false
}
}
However, upon trying to install the module (on a test node) I get the following output:
root#debian:/etc/puppet/modules# puppet agent --test
info: Caching catalog for debian.lan
info: Applying configuration version '1353946258'
err: Could not apply complete catalog: Found 1 dependency cycle:
(Exec[apt_update] => Class[Apt::Update] => Anchor[apt::source::10gen] => Anchor[apt::source::10gen] => Apt::Source[10gen] => Class[Mongodb::Apt::Repo] => Package[mongodb-10gen] => Anchor[mongodb::install::end] => Anchor[mongodb::install::end] => File[10gen.list] => Apt::Source[10gen])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
notice: Finished catalog run in 0.06 seconds
The class is included in the module's install class at https://github.com/dwerder/puppet-mongodb/blob/master/manifests/install.pp
I'm not quite sure why this dependency cycle happens, any ideas?
What was your last change (that's probably the moment you added the cycle).
Try the suggestion to generate the graph. Post the generated dot file as gist so that we can investigate further.
Take a look at Debugging cycle or missing dependency.
Note that some dependencies are explicit (require, ->) or implicit (the resource provider add the dependency by it self)... having a look at the dot file should help.