Re: "returnszero" not working as expected

Hi Chris,

I am wondering if I could ask about your original question. I don't see a
problem with the following. Given the promise:

"EN_NEEDS_CHANGE_SENDSPACE_$(device)"   expression => returnszero
("/usr/sbin/lsattr -El $(device) -a tcp_sendspace -F value | /usr/bin/grep
-q 1048576", "useshell");

Where device is en1 and the verbose output:

 verbose: returnszero ran '/usr/sbin/lsattr -El en1 -a tcp_sendspace -F
value | /usr/bin/grep -q 1048576' successfully and it returned zero
 verbose: Caching result for function 'returnszero("/usr/sbin/lsattr -El
$(device) -a tcp_sendspace -F value | /usr/bin/grep -q 1048576","useshell")'
 verbose: C:     +  Private class: EN_NEEDS_CHANGE_SENDSPACE_en1

hmm...scratching my head...but i dont get it...it says the command returned
zero but the class is set.


So it would seem all is well. The command returns zero and so the value
given to the expression attribute is true aka "any" and should cause the
class to be defined.

Also, when you ran Nick's example it seemed to act correctly.

It's a bit hard to comment on the islessthan example since the value of
current_send_space_value is not given.

What version of AIX are you running? And what is the default shell aka what
does `ls -l /bin/sh` give?

Thanks!
-Craig

On Wed, Sep 4, 2024 at 6:53 AM Xander Cage <[email protected]> wrote:

> i tried to use islessthan instead of returnszero...same
> problem...something is fishy
>
> "EN_NEEDS_CHANGE_SENDSPACE_$(device)"  expression =>
> islessthan($(current_send_space_value), "1048576");
>
> On Wednesday, September 4, 2024 at 7:54:23 AM UTC+2 Xander Cage wrote:
>
>> i am just guessing...the cached result contains the unresolved instance
>> of the "$(device)" variable and this command
>> is ran for every ethernet interface, might be that something is
>> overwritten here.
>>
>> verbose: C: BEGIN classes / conditions (pass 1)
>>  verbose: returnszero ran '/usr/sbin/lsattr -El en0 -a tcp_sendspace -F
>> value | /usr/bin/grep -q 1048576' successfully and it returned zero
>>
>>  verbose: Caching result for function 'returnszero("/usr/sbin/lsattr -El
>> $(device) -a tcp_sendspace -F value | /usr/bin/grep -q
>> 1048576","useshell")'
>>  verbose: C:     +  Private class: EN_NEEDS_CHANGE_SENDSPACE_en0
>>
>> On Wednesday, September 4, 2024 at 7:28:41 AM UTC+2 Xander Cage wrote:
>>
>>> hmm...your example works without any problems...
>>>
>>> root@aixtest01: /root/cfe_testbed # /var/cfengine/bin/cf-agent -KI -f ./
>>> returnszero_issue.cf
>>> R: CFEngine 3.21.5 on aixtest01
>>>
>>> R: The first returnszero() function evaluated true
>>> R: The second returnszero() function did not evaluate true
>>>
>>> adding the action immediate also changes nothing...
>>>
>>> i tried the commands in shell without cfengine...correct returncodes ...
>>>
>>> root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/lsattr -El en1 -a
>>> tcp_sendspace -F value | /usr/bin/grep -q 1048576; echo $?
>>> 0
>>>
>>> root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/chdev -a
>>> tcp_sendspace=16256 -l en1
>>> en1 changed
>>> root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/lsattr -El en1 -a
>>> tcp_sendspace -F value | /usr/bin/grep -q 1048576; echo $?
>>> 1
>>>
>>>
>>>
>>> On Tuesday, September 3, 2024 at 6:06:15 PM UTC+2 [email protected]
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> came across another weird thing…
>>>>
>>>> i am running a command and setting a class on the return code…nothing
>>>> special
>>>>
>>>> EN_NEEDS_CHANGE_SENDSPACE_$(device)" expression => returnszero
>>>> ("/usr/sbin/lsattr -El $(device) -a tcp_sendspace -F value | /usr/bin/grep
>>>> -q 1048576", "useshell");
>>>>
>>>> until now, i was sure the class is set wenn return is 0…unfortunatly
>>>> not in this case.
>>>>
>>>> verbose output:
>>>>
>>>> verbose: returnszero ran '/usr/sbin/lsattr -El en1 -a tcp_sendspace -F
>>>> value | /usr/bin/grep -q 1048576' successfully and it returned zero
>>>> verbose: Caching result for function 'returnszero("/usr/sbin/lsattr -El
>>>> $(device) -a tcp_sendspace -F value | /usr/bin/grep -q
>>>> 1048576","useshell")' verbose: C: + Private class:
>>>> EN_NEEDS_CHANGE_SENDSPACE_en1
>>>>
>>>> hmm…scratching my head…but i dont get it…it says the command returned
>>>> zero but the class is set.
>>>>
>>>> if i do this it works as expected…
>>>>
>>>> "EN_NEEDS_CHANGE_SENDSPACE_$(device)" not => returnszero
>>>> ("/usr/sbin/lsattr -El $(device) -a tcp_sendspace -F value | /usr/bin/grep
>>>> -q 1048576", "useshell");
>>>>
>>>> i mean, i have no problem with setting it to "not", but an explaination
>>>> of this reversed behaviour would be nice.
>>>>
>>>> cfe version is 3.21.5, platform is aix
>>>>
>>>> Hi Chris,
>>>>
>>>> Can you create some simple standalone policy to demonstrate the
>>>> differing behavior on different client versions on the same host?
>>>>
>>>> For example, here is a very simple policy that is similar in nature to
>>>> your snippet.
>>>>
>>>> bundle agent __main__{
>>>>   classes:
>>>>     "RETURNSZERO_ECHO_PIPE_GREP_TRUE"
>>>>       expression => returnszero("/bin/echo hello | /usr/bin/grep -q el", "useshell" );
>>>>     "RETURNSZERO_ECHO_PIPE_GREP_FALSE"
>>>>       expression => returnszero("/bin/echo hello | /usr/bin/grep -q NOPE", "useshell" );
>>>>
>>>>   reports:
>>>>      "CFEngine $(sys.cf_version) on $(sys.fqhost)";
>>>>     RETURNSZERO_ECHO_PIPE_GREP_TRUE::
>>>>      "The first returnszero() function evaluated true";
>>>>     !RETURNSZERO_ECHO_PIPE_GREP_FALSE::
>>>>      "The second returnszero() function did not evaluate true";}
>>>>
>>>> R: CFEngine 3.24.0a.fc037ae3b on precision-5570
>>>> R: The first returnszero() function evaluated true
>>>> R: The second returnszero() function did not evaluate true
>>>>
>>>> Since there is a pipe in play in your example, I wonder if that is
>>>> involved, perhaps a difference in which command is returning zero or not.
>>>> Also, returnszero is a cached function, so your probe could be stale from
>>>> start of the agent run, adding action => immediate to the promise
>>>> should override caching for that promise.
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/help-cfengine/92c08ea5-6369-41eb-bc59-93ee76b64d30n%40googlegroups.com
> <https://groups.google.com/d/msgid/help-cfengine/92c08ea5-6369-41eb-bc59-93ee76b64d30n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

*Craig Comstock* (he/him)
CFEngineer/Digger | CFEngine <https://cfengine.com/>
Kansas, USA
 <https://www.linkedin.com/company/northern.tech>
<https://twitter.com/northerntechhq> <https://northern.tech>
Northern.tech <https://northern.tech> | Securing the world's connected
devices

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/CAMDw%3DqFX_qCoZy%3Dv_6zidXVdxT54Rv1wuWBMKx71Fcq6S_Ti7Q%40mail.gmail.com.