Let us say that I have a case in which I need to apply only two files from a Puppet configuration on some production servers, without touching the rest of the configuration.
/opt/aservice/myfile/thekey.conf
/opt/myfile/thekey.salt
Let's also say that these are controlled by the following Puppet manifest:
#
# author: Nathan Basanese (nathan#basanese.com)
# date: 04/17/2048
#
class keyconfig ( $cluster ){
notify {"Deploying key config. files to $fqdn":}
file {'/opt/aservice/key/config/thekey.conf':
ensure => present,
mode => '0644',
owner => 'aservice-serv',
group => 'aservice-serv',
source => "puppet:///modules/keyconfig/$cluster/thekey.conf",
}
file {'/opt/aservice/key/config/thekey.salt':
ensure => present,
mode => '0644',
owner => 'aservice-serv',
group => 'aservice-serv',
source => "puppet:///modules/keyconfig/$cluster/thekey.salt",
}
}
How would I apply ONLY these two files to a given server from a Puppet Master?
Perhaps, in the puppet agent command that is run on the target server, could I specify a specific Puppet class to use?
I have used the puppet resource command before, but I'm not sure that would work, here.
Every resource is automatically tagged with the fully qualified name of the class or defined type in which it is declared, and with every namespace segment of the class or type name, among other tags. You can use those tags to filter the resources that will be applied during a given catalog run. In the particular example you describe, you could use
puppet agent --no-daemonize --onetime --tags keyconfig
to apply only the resources declared in class keyconfig (and in any other class declared by keyconfig, recursively, but in this case there are no such other classes).
You can also declare tags manually by using the tag metaparameter in your resource declarations. That can allow you to provide for identifying custom collections of resources. And speaking of collections, you can use tags in the selection predicates of resource collectors, too.
The only way to do that is to have that node contain only the class you are wanting to have applied. In your site.pp you would have the following where the 'myhost.dns' is your fqdn. and $mycluster would be replaced by your cluster string.
node 'myhost.dns' {
class { 'keyconfig':
cluster => $mycluster,
}
}
Related
I'm trying to set up a Puppet cron job with the following structure:
file { '/usr/local/sbin/file.py':
mode => '0755',
source => 'puppet:///modules/file.py',
require => File['/usr/local/sbin']
}
cron { "cronjob":
require => "ALL_THE_FILES_ABOVE"
command => "...command_to_run_script..."
minute => '*/1'
}
All of the above is in one file run_script.pp. I'm wondering how I can code the require => "ALL_THE_FILES_ABOVE" part.
Thanks!
Based on the information provided in your question, I am going to make the assumption that the contents of run_script.pp is many file resources and the listed cron resource. You state that you want the cron resource there to require all of the file resources in that class. Based on this, here is a clean and efficient solution.
There are a few complicated/advanced ways to arrive at a clean and efficient solution, but the easiest to understand is to use a resource default: https://puppet.com/docs/puppet/5.3/lang_defaults.html
With this, we can establish attribute/value pair defaults for all file resources contained in that scope. This would make it easier to use the before metaparameter on the file resources instead: https://puppet.com/docs/puppet/5.3/metaparameter.html#before
This simplifies the solution to a one-liner in your class:
File { before => Cron['cronjob'] }
Note there will be a caveat to this method, which is that if you are declaring, requiring, or containing a class within this manifest, then this default could be expanded to that "area of effect" and cause a circular dependency. In that case, you should use a per-expression resource default attribute: https://puppet.com/docs/puppet/5.3/lang_resources_advanced.html#per-expression-default-attributes
You can use a multiple require
file{'path/foo':}
file{'path/bar':}
file{'~/foobar':
require => [ File['path/foo'], File['path/bar'] ]
}
or you can use the ordering arrow
-> (ordering arrow; a hyphen and a greater-than sign) — Applies the resource on the left before the resource on the right.
file{'path/foo':} ->
file{'path/bar':} ->
file{'~/foobar':}
Here is more information about relationships and ordering in Puppet
I've created a puppet resource for interfaces. Most of the interface names on my switch are lowercase with the exception of Ethernet interfaces, so I munged the interface name to hopefully reduce errors in the manifest; e.g.:
manifest:
cisco_interface { 'Ethernet1/1': description => 'foo' }
type/cisco_interface.rb:
newparam(:name) do
munge { |value|
value.downcase
}
end
My provider code also downcases the interface names when I collect the list of interfaces with self.instances.
Okay, so this works great when I test with the manifest, but not so great with the puppet resource command which only works when I call it with the name already downcased:
switch# puppet resource cisco_interface 'Ethernet1/1'
cisco_interface { 'Ethernet1/1':
ensure => 'absent',
}
switch# puppet resource cisco_interface 'ethernet1/1'
cisco_interface { 'ethernet1/1':
ensure => 'present',
description => 'foo',
}
The puppet resource command name field seems to just be a simple filter so I think I'm stuck, but I thought I'd seen other resource types munging title values like this.
Is it possible to munge the title values in a way that works for both scenarios?
If not then I'm not sure whether it would be better to leave it case-sensitive since that is what users will see in the switch config, or to "help" them avoid errors in the manifest.
You are correct about what is happening here, puppet currently requires that the name passed into the command line exactly matches the name according to the type. It's buried a couple levels deep, but look at the find and resource_name methods of the RAL.
It doesn't seem to me like this would be a major change, so you might want to log a defect or make the change yourself!
I have a service implemented in Java which depends on 3 property files. I have defined 'define' for each of the property file in a common properties module and consuming them from service specific module. The 'define' for one of the property file is shown below:
define properties::rabbitmq (
$property_file,
$service_name,
$rabbitmq_host,
$rabbitmq_username,
$rabbitmq_password,
$rabbitmq_port,
$rabbitmq_vhost) {
file { $property_file:
ensure => file,
content => template('config/rabbitmq.properties.erb'),
mode => '0644',
notify => Service[$service_name],
}
}
I am following roles and profile pattern in my puppet code and doing all hiera lookups in service specific profile. Now because of this whenever there is a change in property files, I need to make cascading changes to all of my puppet modules that consumes that property file. The changes are needed in profile (hiera lookup), module init.pp (addition/removal of parametes from constructor) and config.pp (parameter adjustment when invoking 'define' for a property file).
I feel that the above problem can be solved by incorporating hiera lookups in 'define' for a property file, like this:
define properties::rabbitmq ($property_file, $service_name,) {
$rabbitmq_host = hiera('rabbitmq_host')
$rabbitmq_username = hiera('rabbitmq_username')
$rabbitmq_password = hiera('rabbitmq_password')
$rabbitmq_port = hiera('rabbitmq_port')
$rabbitmq_vhost = hiera('rabbitmq_vhost')
file { $property_file:
ensure => file,
content => template('config/rabbitmq.properties.erb'),
mode => '0644',
notify => Service[$service_name],
}
}
But, above is a violation of roles and profile pattern. The above is doing hiera lookup in a module instead of doing it in profile. Now, the module has a tight dependency on hiera. It being an internal module (not meant for puppet forge), I guess, it should be OK to violate the guideline in favor of code maintainability.
I seek opinion from others on above.
Is it possible to add a global resource?
I have about 1000 nodes with different configurations and now I want to install a package on every single node. Can it be done in site.pp?
I have a default node, but from what I can tell it is only for unrecognised nodes so I don't think this is the way to change it.
This will depend on the way you have written your puppet manifests. If you have a class included on every node, then you could add the definition to that.
You could user hiera to allow you to customise the default packages on a per machine basis. If you had a module called siteconfig, then you could could create a class something like;
modules/siteconfig/manifests/init.pp
class siteconfig {
include siteconfig::defaults
package{$::siteconfig::params::packages:
ensure => 'present',
}
}
modules/siteconfig/manifests/params.pp
class siteconfig::params(
$packages = []
) {
validate_array($packages)
}
and then define siteconfig::params::packages in hiera as an array of packages to be installed by default. This means that you could easily add more default packages by editing the array in hiera, and you could customise it on a per-host basis.
Bonus points if you work out how to use create_resources instead!
I have code similar to the following:
class someclass($ensure = installed)
{
if($ensure == installed)
{
$installValue = installed
file { "someprogram.msi":
ensure => file,
source => 'somewhere',
path => 'C:/puppet-files/someprogram.msi',
}
}
else
{
$installValue = absent
}
package{ "someprogram":
ensure => $installValue,
source => 'C:/puppet-files/someprogram.msi',
}
}
Does the if statement containing the file resource ensure that the file resource will get applied before the package resource? Or do I need to explicitly state this in the metaparameters? Also, I am assuming that the $installValue will always be set before the package is installed, is that correct?
Thank you,
Derongan
You should specify the ordering explicitly, however the variable will be initialised correctly.
The ordering of resources in Puppet 3 is deterministic, but essentially random as it's based on hashes of the resource titles. In Puppet 3.3, this behaviour can be changed to the manifest order (release notes), but I wouldn't recommend relying on this - certainly if you're sharing the module, there's no guarantee that others use the same setting.
Since the file resource may not exist (if ensure => absent), you can't specify the relationship on the package resource. Instead, add before => Package['someprogram'], to the file resource.