Using this puppet-module for apt, how can i import this key:
https://www.dotdeb.org/dotdeb.gpg
What i want to achieve is a puppet-related solution for both shell commands:
wget https://www.dotdeb.org/dotdeb.gpg
apt-key add dotdeb.gpg
The documentation of this puppet-modul isn't clear about this. How to do this?
You have to use apt::key
https://github.com/puppetlabs/puppetlabs-apt/blob/master/manifests/key.pp
something like this in your hiera -
apt::keys:
varnish-3.0:
key: C4DEFFEB
key_source: http://repo.varnish-cache.org/debian/GPG-key.txt
https://ask.puppetlabs.com/question/4845/add-key-with-puppetlabs-apt/
or in your puppet manifest file -
apt::key {'HEXKEYID':
source => 'https://www.dotdeb.org/dotdeb.gpg',
id => 'ID_OF_YOUR_KEY'
}
Related
I am working a Puppet manifest that configures a router in the equipment that I support. The router runs pretty much plain vanilla Debian 8 or 9.
The problem is in the way the SSD on the router is partitioned.I am not able to change the partitioning, so have to work around the fact that the root file system is small. I have found a solution that I am trying to implement in Puppet but my first attempt doesn't feel right to me so I thought I would ask the community.
I have been and am reading the Puppet docs. Unfortunately I don't have my router hand to play with today so I am unable to test my current solution.
My issue is that by df -H the root file system is at 95% capacity and puppet is failing complaining about not enough space. Because of quirky decisions made a long time ago by others, the /opt/ file system is 5 times the size of / and is at 10% usage.
So my solution, tested manually, is to move /var/cache/apt/archives/ to /opt/apt-archives and then create a symlink using:
ln -s /opt/apt-archives /var/cache/apt/archives
That works and allows the puppet run to finish without errors.
My challenge is to implement this operation in a Puppet class
class bh::profiles::move_files {
$source_dir = '/var/cache/apt/archives'
$target_dir = '/opt/apt-cache'
file { $targetDir :
ensure => 'directory',
source => "file://${source_dir}",
recurse => true,
before => File[$source_dir]
}
file { $source_dir :
ensure => 'absent',
purge => true,
resurse => true,
force => true,
ensure => link,
target => "file://${target_dir}"
}
}
It just doesn't feel right to have ensure repeated in one file resource. And based on what I understand of creating links in puppet I would need the same name for the file resource that deletes the archives directory and the one that creates the link.
What am I missing?
Use exec:
exec { 'Link /var/cache/apt/archives':
command => 'mv /var/cache/apt/archives /opt/apt-archives
ln -s /opt/apt-archives /var/cache/apt/archives',
path => '/bin',
unless => 'test -L /var/cache/apt/archives',
}
Note that Puppet was not really designed to solve automation problems like this one, although using Exec it is possible to do most things anyway.
Your solution sounds like a work-around and it is therefore totally ok to implement a work-around using Exec. I would say, just make sure you add some comments explaining why you had to do something like this.
I am trying to add a line to an existing file /etc/fuse.conf. I tried this
added a folder two folders under modules directory
sudo mkdir /etc/puppet/modules/test
sudo mkdir /etc/puppet/modules/test/manifests
Then created a test.pp file and added following lines
sudo vim /etc/puppet/modules/test/manifests/test.pp
file { '/etc/fuse.conf':
ensure => present,
}->
file_line { 'Append a line to /etc/fuse.conf':
path => '/etc/fuse.conf',
line => 'Want to add this line as a test',
}
After that I ran this command
puppet apply /etc/puppet/modules/test/manifests/test.pp
Then I opened this file /etc/fuse.conf and there was no change in the file. The line was not added to the file. I don't understand what I am missing here. How can I do this?
Interesting. I ran the same test you did without an issue, and as long as you have stdlib installed in your environment you should be fine.
https://forge.puppet.com/puppetlabs/stdlib
The results of running the same steps you outlined were successful for me:
[root#foreman-staging tmp]# puppet apply /etc/puppet/modules/test/manifests/test.pp
Notice: Compiled catalog for foreman-staging.kapsch.local in environment production in 0.18 seconds
Notice: /Stage[main]/Main/File[/etc/fuse.conf]/ensure: created
Notice: /Stage[main]/Main/File_line[Append a line to /etc/fuse.conf]/ensure: created
Notice: Finished catalog run in 0.24 seconds
What did your puppet run output?
You should use templates (ERB) to handle file configuration. Its easier and cleaner.
Check the puppet docs for it in :
https://docs.puppetlabs.com/puppet/latest/reference/lang_template.html
There are other options though. e.g. Augeas which is an API for file configuration and integrate very well with Puppet. http://augeas.net/index.html
[]'s
There are a few ways to handle this. If it's ini file you can use ini_setting. If it's supported by augeas you can use that. Otherwise try specifying the after parameter to file_line
First, I'm a newbie about Puppet (Configuration Management Tool).
-- And Please consider my poor English...
I got the order from my boss.
"Use Puppet, change the inner file of app.war"
The file is a property file that should be changed for each app server.
(but included in app.war ; it's a constraint.)
The workflow is like this (short description).
GOCD makes the app.war (conf.properties already included)
Our custom tool delivers this app.war to nodes.
At each node, Puppet runs the scripts below (not real, just a naive example).
-=-=-
exec { 'unzip':
command => 'gzip -d /temp/puppet/app.war',
path => '...',
}
exec { 'changefile':
command => 'cp /temp/puppet/conf.properties /temp/puppet/app/conf/conf.properties',
path => '...',
subscribe => Exec['unzip'],
}
exec { 'zip':
command => 'gzip /temp/puppet/app/ /temp/puppet/app.war',
path => '...',
subscribe => Exec['changefile'],
}
-=-=-
I just want to know about that this is a normal (or right or non-problematic) way to solve my situation.
Hmm... I think that Configuration Tools like Puppet are not suitable for this Application Deployment situation. (Though I'm a novice about CM.)
I tried to insist to use Rundeck, but I had no power (knowledge or executive).
Could you give me comments about this?
Thank you for all kind of comment...
I am attempting to use puppet to manage my /etc/yum.repos.d/CentOS-Base.repo file. The built-in puppet yumrepo resource type is adding the baseurl value that is expected, but it's placing the line after the comment for the next repo in the file, [updates].
How can I force puppet to format the [base] repo more prettily? Ideally I would like puppet to replace the commented baseurl entry with the line after "#released updates", as seen below.
[base]
name=CentOS-$releasever - Base
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#released updates
baseurl=http://SERVERXXX/distros/CentOS/$releasever/os/$basearch/
[updates]
Here is the puppet code snippet:
class repos {
case $operatingsystem {
"CentOS", "RedHat": {
yumrepo { "base":
baseurl => 'http://SERVERXXX/distros/CentOS/$releasever/os/$basearch/',
gpgcheck => "1",
gpgkey => "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6",
mirrorlist => absent,
}
The yumrepo type (as it stands) is not capable of any formatting.
You might be able to combine it with augeas to do some tinkering, but it's likely not worth the hassle.
Your mileage will likely be best when each repository has a file for itself. But the settings will still be ordered rather chaotically.
your best bet is to use another resource as part of the class to add the comment line (augues, line in file, template) among other are several ways to handle this, or just use the descr attribute so that the manifest and its effect are much clearer and you do not need the extra comment then as the name will be more informative.
class repos {
yumrepo { 'epel-testing-source':
ensure => 'present',
descr => 'Extra Packages for Enterprise Linux 6 - Testing - $basearch - Source',
enabled => '0',
failovermethod => 'priority',
gpgcheck => '1',
gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6',
mirrorlist => 'https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel6&arch=$basearch',
}
}
I have to create one CFENGINE 3 Policy which should take input from defined input list and then want to perform some bunch of commands on that set one by one.
For Eg:
For only one Package here I have the example:
bundle agent test_tester_install
{
commands:
"/usr/bin/wget http://something.example.com/perl-modules/Test-Tester-0.104.tar.gz;
/usr/bin/gunzip Test-Tester-0.104.tar.gz;
tar -xf Test-Tester-0.104.tar;
cd Test-Tester-0.104;
/usr/bin/perl Makefile.PL;
/usr/bin/make;
/usr/bin/make install"
contain => standard,
classes => satisfied("Test-Tester Installed");
}
body contain standard
{
useshell => "true";
exec_owner => "root";
}
body classes satisfied(new_class)
{
promise_repaired => { "$(new_class)" };
}
But I am not sure that how to do it if I want to do the same for 100 packages. I think "slist would do this but how exactly i need to draft that policy i am not sure"
This is very similar to applying "for" loop in bash shell where we iterate input one by one and perform some operations
Experts Please help
The way to do something like this is to use CFEngine's implicit looping. You store the values in a list, and then iterate over them in the promises. For your example, it would be something like this:
bundle agent install
{
vars:
"packages" slist => { "Test-Tester-0.104", "Foo-Bar-1.001" }; # etc.
commands:
"/usr/bin/wget http://something.example.com/perl-modules/$(packages).tar.gz;
/usr/bin/gunzip $(packages).tar.gz;
tar -xf $(packages).tar;
cd $(packages);
/usr/bin/perl Makefile.PL;
/usr/bin/make;
/usr/bin/make install"
contain => standard,
classes => satisfied(canonify("$(packages)-installed"));
}
Note that I'm using $(package) whenever you previously had Test-Tester-0.104. Of course this only works if all the names are consistent in this respect. To add more, you'd only need to add the names to the packages variable. Not also that I used canonify() to make the string that gets passed to the satisfied() body a valid class name.
Now, if you are going to be doing a lot of installs like this, what I would suggest is defining a new package_method definition, which takes care of following the right steps internally, so that in your policy you can have something much cleaner, like this:
vars:
"packages" slist => { "Test-Tester-0.104", "Foo-Bar-1.001" }; # etc.
packages:
"$(packages)"
package_policy => "add",
package_method => perlsrcpkg; # or whatever you call your new package_method
You can find the documentation for packages promises here: http://cfengine.com/docs/3.5/reference-promise-types-packages.html#packages, and a bunch of package_method definition examples in the CFEngine Standard Library: https://github.com/cfengine/masterfiles/blob/master/lib/3.5/packages.cf
Finally, if the packages you are installing are from CPAN, you could just use the Packages::Installed::cpanm sketch from the Design Center: https://cfengine.com/cfengine-design-center/sketches/packages-cpan-cpanm