multi-line key/value pairs in Puppet Dashboard?
Scott Merrill
We have a baseline for this file on all our servers, but frequently
some of our applications require additional tweaks. These tweaks are
generally more than a single line.
I know that we could create a class in our module repository with the
necessary additions, then define that class inside Dashboard and apply
it to hosts as needed. That seems a little inflexible, as we'd need to
create a class for each app, and define inside that class the changes
that we need.
I'd prefer a more extensible solution that abstracts this a bit. A
"sysctl-additions" class, for example, that relies upon a
Dashboard-defined variable that contains the additions to place into
the file. But how can I (easily?) add multiple lines to the Dashboard
variable? Or do I have to create multiple key/value pairs for each
line I wish to add?
When using Puppet Dashboard, how does one easily add multiple lines to
a Puppet-controlled file? Or should we not be using Dashboard for
that?
Jeff McCune
We'd like to control, among other files, /etc/sysctl.conf with Puppet.
We have a baseline for this file on all our servers, but frequently
some of our applications require additional tweaks. These tweaks are
generally more than a single line.
Scott,
The traditional way to solve this problem is with the file fragement pattern, which would use a defined resource type to manage small file fragments of a line or two each. An additional resource would be related to all of these fragment resources and would then concatenate them together into the final sysctl file.
I notice the only sysctl puppet module that's published to the Forge [1] doesn't employ the file fragment pattern, but instead manages the file in it's entirety.
I know that we could create a class in our module repository with the
necessary additions, then define that class inside Dashboard and apply
it to hosts as needed. That seems a little inflexible, as we'd need to
create a class for each app, and define inside that class the changes
that we need.
If you'd like to use the Dashboard to add new entries, then I may not employ the file fragment pattern.
This is actually a pretty big shortcoming of the current Dashboard. It's difficult to have an arbitrary number of resources (sysctl entries in your case) added to the catalog based on information in the Dashboard.
Today, you can accomplish this by either splitting a comma separated string, or pasting a YAML or JSON hash into the dashboard wholesale and using the create_resources() function with the resulting Puppet variable as input..
I'd prefer a more extensible solution that abstracts this a bit. A
"sysctl-additions" class, for example, that relies upon a
Dashboard-defined variable that contains the additions to place into
the file. But how can I (easily?) add multiple lines to the Dashboard
variable? Or do I have to create multiple key/value pairs for each
line I wish to add?
You can definitely do this today, but it's far from ideal. If you'd like some examples or have more questions about the high level overview I described above I'd be happy to work with you more on this problem.
When using Puppet Dashboard, how does one easily add multiple lines to
a Puppet-controlled file? Or should we not be using Dashboard for
that?
I'd really only use the Dashboard if I had to make the UI available through a browser. If you can get away with it, data in a YAML or JSON file on disk or in something like extlookup() or hiera() may be a better fit with Puppet today.
[1] http://forge.puppetlabs.com/ghoneycutt/sysctl
Hope this helps,
-Jeff McCune
Luke Bigum
alternative to file fragments that you might find easier to work with. I
would use a Defined Type wrapped around Augeas where the $namevar of the
Defined Type is the name of the systctl.conf key. This way if you tried
to turn ipv6 on and off at the same time you'd get a Puppet resource
conflict.
Something like this:
define syssctl_line($value) {
$sysconfig_file = "/etc/sysctl.conf"
augeas { "set ${name} in ${sysconfig_file}":
context => "/files${sysconfig_file}",
incl => "$sysconfig_file",
lens => "shellvars.lns",
changes => [ "set ${name} ${value}"]
}
}
And used like this:
class foo {
sysctl_line { "net.ipv4.ip_forward": value => "0" }
sysctl_line { "kernel.sysrq": value => "0" }
#And this would cause an error on a node...
sysctl_line { "net.ipv4.ip_forward": value => "1" }
}
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke....@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.
Scott Merrill
After reviewing Luke's suggestion and thinking things through a little
more, I think this is the right way to go for us. I hadn't really
considered the long-term ramifications of putting configuration
declarations in both Puppet manifests and in Dashboard. Much better to
keep all configurations in manifests under version control, and use
Dashboard to associate configurations to nodes.
Cheers,
Scott
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>