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.
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.
-- 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.
#check the value in augeas aug = open_augeas() - result = aug.get(path) + result = aug.get(path) || '' unless result.nil? case comparator when "!=": @@ -208,7 +208,7 @@
#Get the values from augeas aug = open_augeas() - result = aug.match(path) + result = aug.match(path) || ''
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.
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.
-- 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.
#check the value in augeas aug = open_augeas() - result = aug.get(path) + result = aug.get(path) || '' unless result.nil? case comparator when "!=": @@ -208,7 +208,7 @@
#Get the values from augeas aug = open_augeas() - result = aug.match(path) + result = aug.match(path) || ''
> 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.
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?
-- 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.
> 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 ",
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)
>> 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
> 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)
>>> 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
>> [...]
> I just noticed that the extra patch got in. I reverted it. The above > still holds. Marc.. does the above solve your use cases?
Marc Fournier wrote: >>>> 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
>>> [...] >> I just noticed that the extra patch got in. I reverted it. The above >> still holds. Marc.. does the above solve your use cases?
> 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.
