What's a good way to test the current date/time in puppet in order to implement a temporary change?
e.g. we've just had a security issue with NTP, and it took a while for Debian to come out with an update. It seemed simplest to just turn ntp off for a while.
service { 'ntp':
# remember to re-enable this after ntp is secured. CVE-XXXXXXXXXX
ensure => "stopped",
...
}
So that requires remembering to come back and change it back. What I'd like to have done would be to have made the value of the ensure
attribute dependent on a selector which tested the date at run time.
Can anyone suggest a nice way to do that?
I can imagine making a function available through the puppet parser to do it, and it'd be nice to know if someone has written that already, but bonus points if you have a way to do it without an extra module.
service { 'ntp':
ensure => date_is_after("23 Dec 2014"): {
true => "running",
false => "stopped"
}
...
}
It occurs to me also that a test based on the current version of the ntp package would be quite elegant, but I'm also not sure how you'd do that in puppet.
To be able to get the current version of the NTP package you would need to write a custom fact that gets pushed to each managed host via
pluginsync
and discerns the value by querying the local package manager. See https://docs.puppetlabs.com/facter/2.3/custom_facts.html for writing custom facts.You can then use the
versioncmp()
function in your manifest to conditionally enable or disable the NTP daemon using the value of that fact and comparing it with the known good version of NTP that contains your fix.To use the date on the master, you can write a simple shell wrapper for
date
and invoke it from the manifest using the generate function.You can fetch the result into a variable and go crazy.
Since Puppet will not compare strings using
<
and>
likebash
orawk
do, you will probably want to usedate +%s
instead, so that you can numerically compare the timestamp to whatever target date you defined.As an aside, I would personally refrain from implementing this kind of thing. It comes with a high risk of falling onto your foot pretty heavily. Consider defining a global Hiera key instead, which you can flip manually after your calendar reminded you to do that. Don't build your friendly surprises into Puppet.
You can write an external fact like that:
To distribute it you can put it into a new module (for example
modules/date/facts.d/date
).And then you can do