I use puppet to install apache with the following code in the manifest.
class{ 'apache':
docroot => '/var/www', # ubu default, ignored
default_vhost => false,
default_ssl_vhost => false,
service_enable => false, # Do not start at boot
service_ensure => stopped, # Apache should be stopped if puppet runs
}
In my puppet.conf I have mentioned like below.
mod "apache",
:git => 'ssh://git.*.*.com:7999/xyz/jira-apache-puppet-module.git',
:ref => 'master'
when i checked apache is getting installed with latest version as in my ubuntu repo.So is puppet using ubuntu repo for installing the package or the module as defined in puppet.conf
So is puppet using ubuntu repo for installing the package or the module as defined in puppet.conf[?]
Both.
The declaration in your manifest simply tells Puppet to include a class named 'apache' in the target node's manifest, with the specified parameter values. Puppet itself knows nothing about such a class, or any associated other classes, defined types, files, templates, data, etc. that belong to its module and support it. That's where your puppetfile entry comes in: tells Puppet which module you mean, and where to find it.
The Puppet module contains instructions for how to install and configure Apache, but it will not contain Apache itself. The approach to installation is sure to be to obtain the software from a package repository appropriate for the target system, as determined by the target system and its configuration. Puppet will use the same command-line interface for that purpose that you could use manually.
All the modules in Puppetfile will get installed during r10k run.
r10k deploy environment -pv
Related
I am facing a problem with installing a package from Debian buster repo in a system which have two repos, this problem will affect the majority of the packages we deploy with puppet. Puppet is trying to install it form our local repo instead.
We are running multiple Ganeti cluster with Ubuntu 16 on the hardware as well as on the VM's. Now we decided to move to Debian stable for the hardware. We have a local repo in the company to provide our specific packages as well as some Ubuntu packages. I set up a new Ganeti cluster with Debian and some VM's for the testing phase.
the code I am using is the following:
package { 'haproxy':
ensure => latest,
}
on the VM I have installed the package haproxy manually because I had the error described below and I tried to see what will happen if the package is already present on the system so that I have the following situation:
# apt-cache policy haproxy
haproxy:
Installed: 1.8.19-1
Candidate: 1.8.19-1ppa1~xenial
Version table:
1.8.19-1ppa1~xenial 500
500 http://our.local.repo/local-xenial local-xenial/main amd64 Packages
*** 1.8.19-1 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
.....
.....
.....
When I run puppet agent on the node I get an error:
The following packages have unmet dependencies:
haproxy : Depends: libssl1.0.0 (>= 1.0.2~beta3) but it is not installable
E: Unable to correct problems, you have held broken packages.
Error: /Stage[main]/puppet_haproxy::Base/Package[haproxy]/ensure: change from 1.8.19-1 to 1.8.19-1ppa1~xenial failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install haproxy' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
haproxy : Depends: libssl1.0.0 (>= 1.0.2~beta3) but it is not installable
E: Unable to correct problems, you have held broken packages.
So obviously puppet is trying to upgrade the package to 1.8.19-1ppa1~xenial which is related to the latest in the package resource.
I don't want to change the ensure attribute to installed or present, rather trying to get the code working on Ubuntu (which it does) as well as on Debian.
Changing the Pin-Priority will be also not a good idea, since we need some our standard packages from the local repo to be installed on each system without modifying the puppet code in each module.
The only work around I thought of is to add the attribute install_options so that the package resource will be as follows (I didn't test it yet):
if $facts['operatingsystem'] == 'Debain' {
package { 'haproxy':
ensure => latest,
install_options => ['-t', 'buster'],
}
} else {
package { 'haproxy':
ensure => latest,
}
}
But that means I have to modify all package resources in each module when a conflict occurs, which I want to avoid.
Is there a better way to achieve this?
Thanks
If you were installing packages manually from the command line, subject to the repository configuration you describe, then you would need to provide a command-line option each time, right? You would need either to specify a particular package version or to modulate the source list.
Puppet has no magic solution for that. If you need to override the repository configuration with respect to particular packages, then you need one way or another to provide attributes appropriate for that purpose on the affected Package resources. There are two basic avenues of approach:
Update your repository configuration so that you don't need extra options. For example, perhaps you can split your local repo into two, one that has lower priority than the distro, and one that has higher. Or perhaps you need a separate repo for Debian than for Ubuntu. OR
Modify Package resources declared in your Puppet manifests, possibly in a distro-specific way. Although you can use conditional statements to achieve any needed distro-specificity, I'd suggest instead a data-driven approach relying on parameterized classes and Hiera.
Have a basic doubt about puppet package resource.If I have a package resource declared in the the manifest file for eg:to install apache using apt-get.
1.During the first run of puppet agent,apache will get installed.
2.If I run the agent(using the existing code for package resource) again after ubuntu repo is refreshed with latest version of apache.
Will puppet update/refresh the apache in agent server?
The Package's ensure attribute determines the state.
What state the package should be in. On packaging systems that can retrieve new packages on their own, you can choose which package to retrieve by specifying a version number or latest as the ensure value. On packaging systems that manage configuration files separately from “normal” system files, you can uninstall config files by specifying purged as the ensure value. This defaults to installed.
Version numbers must match the full version to install, including release if the provider uses a release moniker. Ranges or semver patterns are not accepted except for the gem package provider. For example, to install the bash package from the rpm bash-4.1.2-29.el6.x86_64.rpm, use the string '4.1.2-29.el6'.
Valid values are present (also called installed), absent, purged, held, latest. Values can match /./.
Source: https://puppet.com/docs/puppet/5.3/types/package.html#package-attribute-ensure
I am trying to install a puppet module in master and the agent node. The installation on the master is successful, the new module is visible in module list. Then I changed the site.pp file and included the new module. After that I ran the puppet agent -t command on the agent and expected the module to be installed in the agent. The command is running without any issues but the module is not getting installed.
Following is the sequence of steps which were executed on master:
puppet module install puppetlabs-ntp --version 6.2.0
puppet agent -t
puppet module list
Output:
/etc/puppetlabs/code/environments/production/modules
├── puppetlabs-ntp (v6.2.0)
└── puppetlabs-stdlib (v4.17.1)
Updated site.pp file as follows:
Content:
node default {
include ntp
}
And the following is the steps executed on agent:
puppet agent -t
puppet module list
Output:
/etc/puppetlabs/code/environments/production/modules
└── puppetlabs-stdlib (v4.17.1)
Have even compared the output of puppet agent -t --debug from both master and agent but did not see any specific errors which might be causing this issue.
What am I missing here ?
You are misunderstanding how Puppet works. If everything is set up correctly, the result you should expect when you run puppet agent -t on the agent is for Puppet on that node to configure the ntp service for you. It will not transfer the ntp module to the agent. The Puppet code itself is supposed to remain on the master.
I have a problem while configuring Puppet 4 master to work with HTTP requests so I can use CouchDB for hiera.
These are the steps I did so far:
created new CouchDB with test database
created new document called common
gem install hiera-http-1.0.0
put the http_backend.rb file in /opt/puppetlabs/code/environments/production/mpdules/hiera_http and /opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/hiera-http
When I run gem list I can see:
Hiera (3.2.0)
Hiera-http (1.0.0)
Now, when I try running hiera common or anything else I get ERROR :
'require' : cannot load such file -- lookup_http (LoadError)
My hiera.yaml looks like :
:backends:
- http
And, of course, all the required settings (host,port..)
When i run puppet agent -t on the agent I get
cannot load backend http: no such file to load -- hiera/backend/http_backend at site.pp
Your steps 3 and 4:
gem install hiera-http-1.0.0
put the http_backend.rb file in /opt/puppetlabs/code/environments/production/mpdules/hiera_http and /opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/hiera-http
need to be replaced by:
/opt/puppetlabs/puppet/bin/gem install hiera-http
That will ensure the hiera-http hiera backend gem is automatically properly installed and configured for the ruby that puppet uses.
If you want to use the system ruby for puppet so that it recognizes the hiera-http installed from the system gem, then you need to install puppet, facter, and hiera with gem and not your OS package manager.
Primary goal is to add all puppet modules automatically, so that all dev-env's and prod-env could be started with one command. How can I install puppet modules through puppet manifest?
We've been happily using librarian-puppet to sync all 3rd party modules, it supports setting the modules' locations and versions. So production and dev run the exact same code.
The usage is one liner
librarian-puppet install
In other cases we have a shell script that runs puppet two times, one time a minimal module that is only responsible for fetching the required modules, and then the full blown puppet flow when all modules are available.
The "Puppet module" type and provider does exactly that:
module { 'author/mymodule':
ensure => present,
}
module { 'puppetlabs/stdlib':
ensure => '2.6.0',
}
module { 'puppetlabs/stdlib':
ensure => present,
modulepath => '/etc/puppet/modules',
}
Recent versions of Puppet also have a puppet module command that allows you to install arbitrary Puppet modules from the Puppet forge, example:
$ puppet module install rcoleman/puppet_module
Notice: Preparing to install into /home/anarcat/.puppet/modules ...
Notice: Created target directory /home/anarcat/.puppet/modules
Notice: Downloading from https://forgeapi.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/home/anarcat/.puppet/modules
└── rcoleman-puppet_module (v0.0.3)
Other alternatives include:
librarian
r10k (cited as a replacement for librarian), supports dynamic environments and much more
r10k is now part of Puppet Entreprise 2015.03, so it can certainly be considered best practice.
Here is an example of mine:
$module_stdlib = 'puppetlabs-stdlib'
exec { 'puppet_module_stdlib':
command => "puppet module install ${module_stdlib}",
unless => "puppet module list | grep ${module_stdlib}",
path => ['/bin', '/opt/puppetlabs/bin']
}
Where $module_stdlib is a module I whant to install.
The /bin path is a path where the grep comes from.
And the /opt/puppetlabs/bin is a path where for the puppet binary exists in my installation.
Seems that writing module for installing puppet modules is possible - it'll be just wrapper for puppet module tool. However, I didn't hear about such module yet.
I suppose this mechanism of installation is not popular because often you need to modify installed module, do some customizations. Practical tool for management of such modifications is version control system. For example, in our team we keep /etc/puppetlabs/puppet directory in git repostitory. After installation of any module from Puppet Forge we add its files to version control and push it to remote git server. Our internally developed modules are also kept in this repository. This way, several puppet masters (dev and prod environments) are synchronized with this central repository and always have up-to-date versions of all modules.
I did this and it seemed to work
exec { 'puppet-fstab':
path => '/bin:/usr/bin',
command => 'puppet module install -i /usr/share/puppet/modules/AlexCline-fstab >>/tmp/err.log',
}