On Jun 9, 10:20 am, Guillaume Rousse <guillomovi...@gmail.com> wrote:
> Hello.
>
> I'd like to enhance the classical package/configuration/service pattern
> with an additional stage: configuration syntax checking. The goal is to
> ensure a service won't be restarted with an invalid configuration first,
> but also to ensure this configuration error will get explicitly
> notified, not just buried in logs (we use nagios for this).
>
> In CFengine, it was quite easy to use the result of an external command
> execution to position a class in case of success:
>
> srv_dhcp.dhcpd_restart::
> "/usr/sbin/dhcpd -t /etc/dhcpd.conf" define=dhcpd_config_ok
>
> srv_dhcp.dhcpd_restart.dhcpd_config_ok::
> "$(service) dhcpd restart"
>
> srv_dhcp.dhcpd_restart.!dhcpd_config_ok::
> "$(notify) dhcp-config 2 'invalid dhcp configuration'"
>
> In Puppet documentation, I couldn't find how to use the result of an
> 'exec' resource to do something similar. There is an 'returns'
> parameter, defining expected returns code, and the documentation
> mentions triggering an error when the result differs, but I couldn't
> find documentation about how to use this behavior to trigger different
> actions.
If you want to trigger more than one action that is not simply a
Puppet result message in your log, then your options are:
1) Make a custom fact out of your command (it's not hard), and use a
Puppet conditional based on that fact to control which resources are
included in the node's catlog. This works well, but (a) the command
will be run before every Puppet run; (b) it captures the command
result *before* the Puppet run.
2) Make a custom function to perform the command. This is a bit more
complicated and a bit more flexible, but it has some significant
limitations, most importantly: (a) the command is run on the *master*.
3) Put it all in an Exec. The "onlyif" and "unless" parameters can
help (for instance, put the real command in an "unless" and the notify
command in "command"), or you can script the whole thing and exec
that. This is ugly.
4) Use Puppet resource dependencies, perhaps in combination with one
or more of the above. If resource A has a declared dependency on
resource B, and resource B fails, then resource A will not be applied.
5) If your Ruby-fu is strong, then write a custom type and provider
that do whatever you want.
I don't read CFengine, but the following Puppet example might do
something similar to your CFE code:
file { "/etc/dhcpd.conf":
# appropriate properties ...
}
exec { "check_dhcpd_conf":
command => "/usr/sbin/dhcpd -t /etc/dhcpd.conf",
refreshonly => true,
subscribe => File[ "/etc/dhcpd.conf" ]
}
service { "dhcpd':
ensure => "running",
# other parameters as appropriate ...
require => Exec[ "check_dhcpd_conf" ],
subscribe => File[ "/etc/dhcpd.conf" ]
}
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
