can not set up wrapper for module: nimclient

[Xander Cage]

Hi,

after upgrading masterfiles to 3.21.5 cf-agent spills this error...

Q: ".../cf-agent" --de":    error: Unsupported package module wrapper API version: -1
Q: ".../cf-agent" --de":    error: Can not set up wrapper for module: nimclient

agent is still on 3.21.4...maybe this is the root cause of this...

chris

[Xander Cage]

upgrade binaries to 3.21.5...error persists

[Xander Cage]

fun fact...i noticed on some clients the error changed to this after upgrading binaries...

cat: cannot open ../../tests/unit/mock_lslpp_Lc

[Xander Cage]

seems this part in the nimclient script is not working, hence the " cat: cannot open ../../tests/unit/mock_lslpp_Lc " error...

# Set up mock environment if necessary
# This is not well developed as I don't have continuous access to aix and nim
# nor am I an expert
CFENGINE_TEST_NIMCLIENT_MOCK=false
if [ -n "$CFENGINE_TEST_NIMCLIENT_MOCK"  = "true" ]; then
    list_installed_packages() {
        cat ../../tests/unit/mock_lslpp_Lc
     }
    nimclient_showres() {
        # This lists the AVAILABLE packages in the nim repo
        cat ../../tests/unit/mock_nimclient_showres
    }
    nimclient_install_package() {
        # Ugh, not sure what this should do to mock. I think that nimclient
        # return codes kind of suck, might need to parse the output?
        echo nimclient -o cust -a lpp_source=${lpp_source} -a filesets=\"${Name}\" >&2
    }
    remove_package() {
        echo installp -u "${Name}" >&2
    }
else
    list_installed_packages() {
        lslpp -Lc
    }
    nimclient_showres() {
        /usr/sbin/nimclient -o showres -a resource=${lpp_source} -a installp_flags=L
    }
    nimclient_install_package() {
        /usr/sbin/nimclient -o cust -a lpp_source=${lpp_source} -a filesets=\"${Name}\" 1>&2
    }
    remove_package() {
        installp -u "${Name}" 1>&2
    }
fi

no idea why CFENGINE_TEST_NIMCLIENT_MOCK=false is not evaluated correctly...

same for this part...

supports_api_version () {
    echo 1
}

should work, but fails...strange

[Xander Cage]

changing the mock part to this fixes the related error...successfully stolen from the pksrc module...

if [ -n "$CFENGINE_TEST_NIMCLIENT_MOCK" ]; then

still no idea concerning the api check...

[Xander Cage]

i took a look at cf-agent/package_module.c...

static int NegotiateSupportedAPIVersion(PackageModuleWrapper *wrapper)
{
    assert(wrapper);

    Log(LOG_LEVEL_DEBUG, "Getting supported API version.");

    int api_version = -1;

    Rlist *response = NULL;
    if (PackageWrapperCommunicate(wrapper, "supports-api-version", "",
                                  &response) != 0)
    {
        Log(LOG_LEVEL_INFO,
            "Error occurred while getting supported API version.");
        return -1;
    }

    if (response)
    {
        if (RlistLen(response) == 1)
        {
            api_version = atoi(RlistScalarValue(response));
            Log(LOG_LEVEL_DEBUG, "package wrapper API version: %d", api_version);
        }
        RlistDestroy(response);
    }
    return api_version;
}

this looks somewhat "weird" to me...

if (PackageWrapperCommunicate(wrapper, "supports-api-version", "",
                                  &response) != 0)

isnt the returned "1" from the module also not "0", so its always an error  except the module returns "0"?

[craig.c...@northern.tech]

Hello,

The C code you found is correct as far as I can tell. The "!= 0" condition that comes first is checking that the communication worked, not checking the actual response code which is set in the response variable which is an Rlist and we get the api_version from the first entry in that list.

I will look more at this now and get back with more ideas/suggestions.

-Craig

[craig.c...@northern.tech]

The pertinent code, I think, is here in cf-agent/package_module.c, line 125:

    wrapper->supported_api_version = NegotiateSupportedAPIVersion(wrapper);
    if (wrapper->supported_api_version != 1)
    {
        Log(LOG_LEVEL_ERR,
            "Unsupported package module wrapper API version: %d",
            wrapper->supported_api_version);
        DeletePackageModuleWrapper(wrapper);
        return NULL;
    }

Which indeed, if your package module script is erroring out like you indicated will result in returning a -1 from NegotiateSupportedAPIVersion().

Looking at the module script I think something went wrong in this line:

if [ -n "$CFENGINE_TEST_NIMCLIENT_MOCK"  = "true" ]; then

There is a -n test but also an = test so I would expect that expression to give shell errors and exit with an error there.

Looks like a bug on our side in MPF for this nimclient module.

I have logged a ticket and will see if I can make a fix that you can try:

https://northerntech.atlassian.net/browse/CFE-4415

-Craig

[Xander Cage]

the nimclient script returns exactly what the agent requires...

root@nimvie: /root # /var/cfengine/modules/packages/nimclient supports-api-version < /dev/null
1

[craig.c...@northern.tech]

Please see https://github.com/cfengine/masterfiles/pull/2921 and try the fix.

I just removed the -n test since it is not needed. A simple test to see if the variable is equal to "true" should suffice just fine and allow the script to proceed.

if [ "$CFENGINE_TEST_NIMCLIENT_MOCK" = "true" ]; then

I suppose on AIX or your system that your "sh" is more lenient possibly and allows more args to "[" so that is why the code path is getting into the mock branch instead of the non-mock branch and failing to cat out that file you don't have laying around.

-Craig

[craig.c...@northern.tech]

Thanks for testing and commenting on the PR. I have merged that PR and will work on the cherry pick to 3.21.x.

Cheers,

Craig

[Xander Cage]

i  looked deeper at the shell at /bin/sh in aix....seems this is "Korn Shell 88"...about 40 years old...was a  good laugh ;-)

[Vratislav Podzimek]

On Mon, 2024-07-08 at 08:49 -0700, Xander Cage wrote:
> i  looked deeper at the shell at /bin/sh in aix....seems this is "Korn Shell 88"...about 40 years old...was a  good laugh ;-)

A rare case of something being older than CFEngine. 😄️

--
Vratislav

[Craig Comstock]

I checked on an AIX 7.1 instance we use for test/build/dev and see that ksh/aix has different behavior than bash built-in `[` on linux/etc.

# MOCK=false

# [ -n "$MOCK" = "true" ]
# echo $?
0
# [ -n "$MOCK" ]
# echo $?
0
# [ "$MOCK" = "true" ]
# echo $?
1

Versions I am dealing with on this instance:

# lslpp -L | grep -i ksh
  bos.rte.shell             7.1.5.16    C     F    Shells (bsh, ksh, csh)
# oslevel -r
7100-05

And is it a built-in for ksh? For mine it is:

# whence -v [
[ is a shell builtin

A quick scan of POSIX test (https://pubs.opengroup.org/onlinepubs/9699919799/) seems to lean towards "unspecified results" ;)

4 arguments:

If $1 is '!', negate the three-argument test of $2, $3, and $4.
^{[OB XSI]}  If $1 is '(' and $4 is ')', perform the two-argument test of $2 and $3.   On systems that do not support the XSI option, the results are unspecified if $1 is '(' and $4 is ')'.
Otherwise, the results are unspecified.

Have fun!

Craig

--
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 help-cfengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/85f01bba74a2d2559af7060ed670b652298dc23d.camel%40northern.tech.

--

Craig Comstock (he/him)
CFEngineer/Digger | CFEngine
Kansas, USA
Northern.tech | Securing the world's connected devices