Puppet Augeas Plugin
Joel Nimety
http://git.et.redhat.com/?p=ace.git;a=blob;f=modules/augeas/plugins/puppet/type/augeas.rb;h=2346c37d724d7607ed4e09b0413700bec2b7cbed;hb=HEAD
I'm running into a behavior that I wouldn't expect. I'd like to confirm
an entry in sysctl.conf by changing the value if necessary or appending
the key/value if it doesn't exist in the file. This seems like a common
scenario. However, the following example does not add
net.ipv4.tcp_max_syn_backlog if it doesn't already exist in sysctl.conf.
class sysctl {
file { "sysctl_conf":
name => $operatingsystem ? {
default => "/etc/sysctl.conf"
},
}
config { "net.ipv4.tcp_max_syn_backlog": ensure => 4096 }
exec { "sysctl -p":
alias => "sysctl",
refreshonly => true,
subscribe => File["sysctl_conf"],
}
}
define sysctl::config ($ensure) {
augeas { "sysctl_conf_$name":
notify => Exec["sysctl"],
context => "/files/etc/sysctl.conf",
changes => "set $name $ensure",
onlyif => "get $name != $ensure"
}
}
poking around in augeas.rb I noticed that "onlyif" is only processed if
the result is not nil. Is this intended behavior? I propose that if
the return value is nil it should be treated as an empty string so
comparisons can still happen, I've attached a patch if this suits you.
--
Joel Nimety
Perimeter eSecurity
Product Architect, Email Defense
203.541.3416
jni...@perimeterusa.com
http://www.perimeterusa.com
--
The sender of this email subscribes to Perimeter eSecurity's email
anti-virus service. This email has been scanned for malicious code and is
believed to be virus free. For more information on email security please
visit: http://www.perimeterusa.com/email-defense-content.html
This communication is confidential, intended only for the named recipient(s)
above and may contain trade secrets or other information that is exempt from
disclosure under applicable law. Any use, dissemination, distribution or
copying of this communication by anyone other than the named recipient(s) is
strictly prohibited. If you have received this communication in error, please
delete the email and immediately notify our Command Center at 203-541-3444.
Thanks
Bryan Kearney
> resending, not sure the original made it to the mailing list.
>
> Bryan -- I'm using the puppet augeas plugin at
> http://git.et.redhat.com/?p=ace.git;a=blob;f=modules/augeas/plugins/puppet/type/augeas.rb;h=2346c37d724d7607ed4e09b0413700bec2b7cbed;hb=HEAD
>
> I'm running into a behavior that I wouldn't expect. I'd like to confirm
> an entry in sysctl.conf by changing the value if necessary or appending
> the key/value if it doesn't exist in the file. This seems like a common
> scenario. However, the following example does not add
> net.ipv4.tcp_max_syn_backlog if it doesn't already exist in sysctl.conf.
>
Thank you. I have applied this patch. Please let me know if it works for
you.
http://git.et.redhat.com/?p=ace.git;a=commit;h=8c4420ba7c732d039ce6a37fd347437b0a0492a0
-- bk
Joel Nimety
Bryan Kearney wrote:
> Joel Nimety wrote:
>
>
> Thank you. I have applied this patch. Please let me know if it works for
> you.
>
> http://git.et.redhat.com/?p=ace.git;a=commit;h=8c4420ba7c732d039ce6a37fd347437b0a0492a0
>
> -- bk
hmmm. looks like a patch from Marc Fournier attempts to address the same
thing and I'm not sure both are necessary (and they conflict in some
cases). I suppose it depends on what behavior is appropriate.
Marc's patch will not perform the onlyif get/match if the node doesn't
exist (when result.nil?). My patch will still perform the get/match; my
thinking was that this would allow to test for the entry not being
present (onlyif => "Key =~ ''").
I'm not sure which approach results in a more intuitive behavior but
only one should be used. Thoughts?
Bryan Kearney
>
>
> Bryan Kearney wrote:
>> Joel Nimety wrote:
>>
>>
>> Thank you. I have applied this patch. Please let me know if it works for
>> you.
>>
>> http://git.et.redhat.com/?p=ace.git;a=commit;h=8c4420ba7c732d039ce6a37fd347437b0a0492a0
>>
>> -- bk
>
> hmmm. looks like a patch from Marc Fournier attempts to address the same
> thing and I'm not sure both are necessary (and they conflict in some
> cases). I suppose it depends on what behavior is appropriate.
>
> Marc's patch will not perform the onlyif get/match if the node doesn't
> exist (when result.nil?). My patch will still perform the get/match; my
> thinking was that this would allow to test for the entry not being
> present (onlyif => "Key =~ ''").
>
> I'm not sure which approach results in a more intuitive behavior but
> only one should be used. Thoughts?
I put a test in there where, assuming no star wars characters exist in
the file this should run
augeas{"test_missing_node_should_run":
require => Augeas[test_regex_2_should_not_run],
context => "/files/etc/sysconfig/firstboot",
changes => "set Boss Nass",
onlyif => "get Boss != Nass ",
}
And this should not
augeas{"test_missing_node2_should_not_run":
require => Augeas[test_regex_2_should_not_run],
context => "/files/etc/sysconfig/firstboot",
changes => "set Jango Fett",
onlyif => "get Jango == Fett ",
}
So.. we basically say run if nil != Nass and do not run if nil == Fett.
This appears to be true. This seems logical to me. What it does not
allow for is the setting of value X if node Y is absent. But this can be
done with the following (again, first runs second will not)
augeas{"test_missing_node3_should_run":
require => Augeas[test_regex_2_should_not_run],
context => "/files/etc/sysconfig/firstboot",
changes => "set Boba Fett",
onlyif => "match Anakin size == 0",
}
augeas{"test_missing_node4_should_not_run":
require => Augeas[test_regex_2_should_not_run],
context => "/files/etc/sysconfig/firstboot",
changes => "set Anakin Skywalker",
onlyif => "match Boba size == 0",
}
-- bk
Bryan Kearney
I just noticed that the extra patch got in. I reverted it. The above
still holds. Marc.. does the above solve your use cases?
-- bk
Marc Fournier
>>> thing and I'm not sure both are necessary (and they conflict in some
>>> cases). I suppose it depends on what behavior is appropriate.
>>>
>>> Marc's patch will not perform the onlyif get/match if the node doesn't
>>> exist (when result.nil?). My patch will still perform the get/match; my
>>> thinking was that this would allow to test for the entry not being
>>> present (onlyif => "Key =~ ''").
>>>
>>> I'm not sure which approach results in a more intuitive behavior but
>>> only one should be used. Thoughts?
>>
>>
>> I put a test in there where, assuming no star wars characters exist in
>> the file this should run
>>
>
> I just noticed that the extra patch got in. I reverted it. The above
> still holds. Marc.. does the above solve your use cases?
In fact my usual use case is
changes => "set Boss Nass",
onlyif => "get Boss != Nass ",
as a workaround for the issue discussed in this thread:
http://thread.gmane.org/gmane.comp.sysutils.augeas.devel/985/focus=9753
The patch I sent indeed focused on the need for this workaround. The
behaviour of Joel's patch is definitely better.
Thanks !
Marc
Bryan Kearney
So.. to verify... you are good?
-- bk
Marc Fournier
>> behaviour of Joel's patch is definitely better.
>
>
> So.. to verify... you are good?
Sorry, I wasn't very clear. Yes Joel's patch works fine for me.
Marc
Bryan Kearney
Great.. thank you for using it and sending along the patch!
-- bk
David Lutterkort
> In fact my usual use case is
> changes => "set Boss Nass",
> onlyif => "get Boss != Nass ",
> as a workaround for the issue discussed in this thread:
> http://thread.gmane.org/gmane.comp.sysutils.augeas.devel/985/focus=9753
>
> The patch I sent indeed focused on the need for this workaround. The
> behaviour of Joel's patch is definitely better.
I just released augeas-0.3.2, which does not need this workaround
anymore: the behavior is now that files are only touched if their actual
contents have changed, i.e. Augeas is now idempotent.
The list of files that was actually modified is now also available
at /augeas/events/saved ... that should make it easy to generate log
messages about what was changed, either at the level of tree nodes or
actual files.
David