I am trying to create a puppet manifest using inifile. This would be for a configuration file where I need to have the following format.
[safe]
directory = /home/foo
directory = /home/test
directory = /home/something
I know that there is a way to use directory1, and directory2 but I was wondering if there is a way to do it without changing the directory since it needs that specific attribute. This implementation is meant for puppet manifest.
Also, I was thinking puppetlabs/inifile module but if there is another option to achieve this would be great too.
Thanks for the help in advance
So far, I have an implementation like:
ini_setting { 'procedure cache size':
ensure => present,
path => '/var/lib/somethning/test.config',
section => 'safe',
setting => 'directory',
value => '/home/foo',
indent_char => "\t",
}
This is for each directory. The purpose for this implementation is to address the new git configuration for safe.repository in the recent update. My understanding is that for multiple directories, it adds a new value as directory = <directory> I don't believe that it likes directories separate by commas.
First I thought about file_line, but this is not idempotent for multi-line settings (you get problems when you run again). You can try:
Sample puppet code dir.pp
$safe_directories="directory = /home/foo
directory = /home/test
directory = /home/something"
notice "Testing\n${safe_directories}"
file { "/tmp/result.ini":
ensure => present,
content => template('/tmp/layout.erb'),
}
notice "Check /tmp/result.ini"
Sample template /tmp/layout.erb
[unsafe]
directory=/unsafe
[safe]
<%=#safe_directories%>
otherfield=secure
[header3]
nothing = here
Now run command from commandline
puppet apply dir.pp
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 have a small custom fact in a my php module
Facter.add('php_extension_version') do
setcode do
Facter::Core::Execution.exec("php -i | awk '/^PHP Extension =>/ { print $4}'") || nil
end
end
This obviously requires the php binary to be installed. However, I noticed that all facts are run once before applying the catalog, so this fact is invalid before php installed.
Is there any way of gathering the information after the module is installed? Is there perhaps another way of exposing this information except facter?
Update
I'm using the two facts to determine which of multiple .so files is the right one to install:
if $php_zts_enabled {
$so_name = "newrelic-$php_extension_version.so"
} else {
$so_name = "newrelic-$php_extension_version-zts.so"
}
file {"/usr/lib64/php5/extensions/newrelic.so":
source => "file:///opt/newrelic-php5-$version-linux/agent/x64/$so_name",
owner => root,
group => root,
mode => 0644,
notify => Service['apache'],
require => Exec["extract-php-agent-$version"]
}
The files that are located in the agent/x64 directory can be
newrelic-20060613.so newrelic-20090626-zts.so newrelic-20121212.so newrelic-20131226-zts.so
newrelic-20060613-zts.so newrelic-20100525.so newrelic-20121212-zts.so
newrelic-20090626.so newrelic-20100525-zts.so newrelic-20131226.so
You essentially have only two opportunities to execute code on the node:
As part of a Facter fact. As you are aware, this happens before puppet applies a catalog, so any facts dependent on the results of the puppet run will not be useful until the next run.
As part of a custom provider. You can create a custom type and provider for installing the extensions that checks the node state before deciding what to do. Providers execute on the node, and as long as you know the overall provider lifecycle you can make this happen after the PHP install. However, this is incredibly complex compared to normal puppet modules.
Outside of those options, the normal way of doing this would be to enforce the version and configuration of php within your own manifests, and then pass that information to here. You should already know the version of PHP and its extensions based on what packages you have installed.
I would modify the fact so that it's present only when the binary is present (hence it won't be present at the very first run).
Facter.add('php_extension_version') do
setcode do
if system("which php > /dev/null 2>&1")
Facter::Core::Execution.exec("php -i | awk '/^PHP Extension =>/ { print $4}'") || nil
end
end
end
and then in your manifest you'd wrap the original code in the if
if $php_extension_version {
if $php_zts_enabled {
$so_name = "newrelic-$php_extension_version.so"
} else {
$so_name = "newrelic-$php_extension_version-zts.so"
}
file {"/usr/lib64/php5/extensions/newrelic.so":
source => "file:///opt/newrelic-php5-$version-linux/agent/x64/$so_name",
owner => root,
group => root,
mode => 0644,
notify => Service['apache'],
require => Exec["extract-php-agent-$version"]
}
}
This is most likely an anti-pattern, but I'd like to know nonetheless:
I need to extract a tgz which is in puppet and then move the contents somewhere else. Is it possible, in a puppet exec { }, to refer to the file where it is stored on disk?
For example, puppet is available at /usr/local/puppet, and the tgz file I need it in /usr/local/puppet/modules/components/files/file.tgz. In the exec { } can I do something like command => "/bin/cp $modules/components/files/file.tgz /somewhere_else" ? Or do I have to declare a file { source => "..." } block first?
Both approaches are correct if you run puppet with puppet apply.
In master-agent architecture using exec to copy file probably will not work at all.
In my opinion using file resource is more "puppet-like" but is has one significant drawback.
You can use:
file { '/some_path/somewhere_else':
source => '/usr/local/puppet/modules/components/files/file.tgz',
}
This will create file /some_path/somewhere_else with the same content as /usr/local/puppet/modules/components/files/file.tgz (it will make a copy of the original file).
But if /some_path doesn't not exist in the file system, the command will fail.
If you are working with tgz files you can also consider using some of the archive puppet modules e.g gini.
UPDATE:
I can propose two approaches:
Use puppet file server to serve files (or define module path for old puppet versions). Next just use it e.g:
file { '/some_path/somewhere_else':
source => "puppet:///modules/components/file.tgz',
}
Define custom facter fact 1, 2 that points path in your filesystem containing required files. E.g:
file { '/some_path/somewhere_else':
source => "${::my_custom_fact}/some_path/file.tgz',
}
I do not think that any of the core facts might be useful for you.
I have a rails app and I'd like to change the ./config/environment/production.rb file to have a different config based on what I want that server to do.
So, I'm going into the .rb file from the .pp file and changing some strings then restarting the service. This just seems really poor form to me. Is there a better way to do this? I've been asked to deliver 1 RPM and change the config via puppet, so...
class Cloud-widget($MServer, $GoogleEarthServer, $CSever) {
package { "Cloud-widget":
ensure => installed
}
service { "Cloud-widget":
ensure => running,
}
<%
file_names = ['./config/environment/production.rb']
file_names.each do |file_name|
puts text.gsub(/.*config.mserver(.*)/, "config.mserver_root = \"#{$Merver}\"")
puts text.gsub(/.*config.google_earth_url(.*)/, "config.google_earth_url( = \"#{$GoogleEarthServer}\"")
puts text.gsub(/.*config.cserver_base_url(.*)/, "config.cserver_base_url = \"#{$CServer}\"")
end
File.open(file_name, "w") {|file| file.puts output_of_gsub}
%>
service { Cloud-widget:
ensure => running,
subscribe => File["./config/environment/production.rb"],
}
}
No, that is not a good way to achieve what you need.
You could look at templates and generate the config files that way. That way, you can use variables in the config file.
If you need create conf from pattern you should use INI-file module from Puppetlabs
ini_setting { "sample setting":
path => '/tmp/foo.ini',
section => 'foo',
setting => 'foosetting',
value => 'FOO!',
ensure => present,
}
install this module from puppet:
puppet module install cprice404-inifile
I'm installing a package from a module (Nginx in this specific case) and would like to include a configuration file from outside of the module, i.e. from a top level files directory parallel to the top level manifests directory. I don't see any way to source the file though without including it in a module or in my current Vagrant environment referring to the absolute local path.
Does Puppet allow for sourcing files from outside of modules as described in the documentation?
if I understand your question correctly, you can.
In your module a simple code like this
file { '/path/to/file':
ensure => present,
source => [
"puppet:///files/${fqdn}/path/to/file",
"puppet:///files/${hostgroup}/path/to/file",
"puppet:///files/${domain}/path/to/file",
"puppet:///files/global/path/to/file",
],
}
will do the job. The /path/to/file will be sourced using a file located in the "files" Puppet share.
(in the example above, it search in 4 different locations).
update maybe you're talking about a directory to store files which is not shared by Puppet fileserver (look at http://docs.puppetlabs.com/guides/file_serving.html), and in this case you can't i think, Vagrant or not, but you can add it to your Puppet fileserver to do it. I thinks it's the best (and maybe only) way to do it.
If you have a number of Vagrant VMs you can simply store files within your Vagrant project directory (containing your VagrantFile).
This directory is usually available to all VMs as /vagrant within the VM on creation.
If you want other directories on your computer to be available to your VMs just add the following to your VagrantFile
# see http://docs.vagrantup.com/v1/docs/config/vm/share_folder.html
config.vm.share_folder "v-packages", "/vagrant_packages", "../../dpkg"
Then to use the files within puppet you can simply treat them as local files to the VM
# bad example, bub basically use 'source => 'file:///vagrant/foo/bar'
file { '/opt/cassandra':
ensure => directory,
replace => true,
purge => true,
recurse => true,
source => 'file:///vagrant/conf/dist/apache-cassandra-1.2.0',
}
This is probably only wise to do if you only using local puppet manifests/modules.
Probably too late to help bennylope, but for others who happen across this question, as I did before figuring it out for myself ...
Include stuff like this in your Vagrantfile ...
GUEST_PROVISIONER_CONFDIR = "/example/destination/path"
HOST_PROVISIONER_CONFDIR = "/example/source/path"
config.vm.synced_folder HOST_PROVISIONER_CONFIDIR, GUEST_PROVISIONER_CONFDIR
puppet.options = "--fileserverconfig='#{GUEST_PROVISIONER_CONFDIR}/fileserver.conf'"
Then make sure /example/source/path contains the referenced fileserver.conf file. It should look something like ...
[foo]
path /example/destination/path
allow *
Now, assuming example-file.txt exists in /example/source/path, the following will work in your manifests:
source => "puppet:///foo/example-file.txt",
See:
Puppet configuration reference entry for fileserverconfig
Serving Files From Custom Mount Points