Missing argument (--list) at command apt?

[e36Alex]

Hi,

i am new to Icinga2 and have a question about the external command apt.

The command in general is already running fine so far on my hosts: Avaiable updates are reported correctly to icinga.
Now i would like to get the upgradeable packages listed, too.

Therefore i created a data field “apt_list”:

And added this field to the external command:

At the service template i added the data field, too, and set the value “true” (even tried with “1” and with a boolean field):

But the plugin output doesnt show the upgradeable packages:

I checked the executed command and the is no additional argument shown:

• Icinga Web 2 version: 2.9.3

• Used modules and their versions (System - About):
  

• Web browser used: Firefox 92

• Icinga 2 version used (icinga2 --version): r2.13.1-1

• PHP version used (php --version): PHP 7.3.29-1

• Server operating system and version: debian 10

Thanks for your help!

Alex

[steaksauce (Ben)]

Assuming that check_apt takes arguments, you may want to add to your argument field, not the “fields”

[e36Alex]

Thanks for your reply. This was my first thought, but i dont know how to add it in this case:

1. There is no arguments tab for this command
2. In field selection i cant choose the list-argument:
   
   

[log1c]

Adding it to the “fields” tab of the command or the service template is both fine.

But you need to define the datafield as type “boolean”. Then you will get a “Yes”/“No” drop down in the variable. Setting the value to “Yes” will add the argument to the check execution

@e36Alex

In field selection i cant choose the list-argument:

The drop down in the field section of a command only shows variables the populate a value (like at the --critical argument for example). Variables for set_if have to be created manually beforehand and can then be added via the field drop down (but they are still not shown under “suggested fields”)

[e36Alex]

Thanks for your reply, too.

I already tried it with field type boolean an now tried it again, but without success - i still get the same result and have really no idea, what i am doing wrong.

[log1c]

Let’s start fresh.
Delete the apt_list data field and create it again. Be sure there is to trailing white space.

Add the apt_list field to the command.

Then create a service template that uses the apt command.

zones.d/director-global/service_templates.conf
template Service "apt" {
    import "generic-service"

    check_command = "apt"
    command_endpoint = host_name
    vars.apt_list = true
}

Then create a service (e.g. via apply rule) that imports the service template

zones.d/director-global/service_apply.conf
apply Service "updates" {
    import "apt"

    assign where host.address == "127.0.0.1"

    import DirectorOverrideTemplate
}

Then you will have a check with the parameter

[e36Alex]

Thanks for your detailed explanation. I followed your suggestion and removed all apt related data fields, service templates and services and did a fresh start - but there is still no change:

1. New data field:
   

   

2. Added new data field to command:
   

   

3. Created a new service template:
   

   

4. Created service apply rule:
   
   

5. But i still get the same result:
   

[log1c]

Well, wtf xD That is strange.

Does the apt_list parameter show up under the custom vars section of the service?

Can you please also show the config preview of the host you are applying the service as well? Maybe there is something fishy in there.

[e36Alex]

Yes, the parameter is shown up:

And here the preview of the host:

[e36Alex]

Could it be possible, that something is wrong with my external commands?

I am not sure, yet, but i think i maybe got an issue with the by_ssh command, too.

I am missing the argument by_ssh_command here:

object CheckCommand "by_ssh" {
    import "plugin-check-command"
    command = [ PluginDir + "/check_by_ssh" ]
    timeout = 1m
    arguments += {
        "-4" = {
            description = "Use IPv4 only"
            set_if = "$by_ssh_ipv4$"
        }
        "-6" = {
            description = "Use IPv6 only"
            set_if = "$by_ssh_ipv6$"
        }
        "-C" = {{
            /* Unable to fetch function body through API */
        }}
        "-E" = {
            description = "Ignore all or (if specified) first n lines on STDERR [optional]"
            value = "$by_ssh_skip_stderr$"
        }
        "-H" = {
            description = "Host name, IP Address, or unix socket (must be an absolute path)"
            value = "$by_ssh_address$"
        }
        "-c" = {
            description = "Response time to result in critical status (seconds)"
            value = "$by_ssh_crit$"
        }
        "-i" = {
            description = "identity of an authorized key [optional]"
            value = "$by_ssh_identity$"
        }
        "-l" = {
            description = "SSH user name on remote host [optional]"
            value = "$by_ssh_logname$"
        }
        "-o" = {
            description = "Provide ssh options (may be repeated)"
            value = "$by_ssh_options$"
        }
        "-p" = {
            description = "Port number (default: none)"
            value = "$by_ssh_port$"
        }
        "-q" = {
            description = "Tell ssh to suppress warning and diagnostic messages [optional]"
            set_if = "$by_ssh_quiet$"
        }
        "-t" = {
            description = "Seconds before connection times out (default: 10)"
            value = "$by_ssh_timeout$"
        }
        "-w" = {
            description = "Response time to result in warning status (seconds)"
            value = "$by_ssh_warn$"
        }
    }
    vars.by_ssh_address = "$check_address$"
    vars.by_ssh_quiet = false
    vars.check_address = {
        arguments = [  ]
        deprecated = false
        name = "<anonymous>"
        side_effect_free = false
        type = "Function"
    }
    vars.check_ipv4 = "$by_ssh_ipv4$"
    vars.check_ipv6 = "$by_ssh_ipv6$"
}

[log1c]

Last thing to try (as I missed it before). Please don’t use the master branch of the Icinga Director. Check out a specific version (newest is v1.8.1)
https://icinga.com/docs/icinga-director/latest/doc/02-Installation/#installation-from-git-repository

@e36Alex

I am missing the argument by_ssh_command here:

If you mean the /* Unable to fetch function body through API */. This is “normal”.
At least it is the same in my setups.

Not sure if this still is a (displaying) bug in the Director, but the commands will work nonetheless
According to this the issue should be fixed, but that does not seem to be the case:
https://github.com/Icinga/icingaweb2-module-director/pull/1416

[e36Alex]

Thanks, i really have been on the master branch of the director.
Now i changed to 1.8.1 but i am still a bit confused:

at my grafana host still the upgradeable package isnt shown:

but on another host the upgradeable packages are listed now:

unfortunately i changed the version first and then saw that there is another upgradeable host so i cant specifiy i the version change has been the reason.

also the director now shows a warning:

can i ignore this or do i have one more to do to solve it?

[log1c]

@e36Alex

at my grafana host still the upgradeable package isnt shown:

@e36Alex

but on another host the upgradeable packages are listed now:

Ah, interesting^^
Please check the check_apt script on both of those servers with check_apt -V to print the version of the plugin. The --list parameter was added with v2.3. Anything lower does not have the parameter.
If they both are at least v2.3 then check:

Both checks come via the same service template?
Did you wait for a re-check after the config deploy (or did it manually)?

@e36Alex

also the director now shows a warning:

That’s what I “feared”. I don’t think it is a big deal, but it could be (as the message says).

You could try making a dump of the Director DB and backup all the Director config via a Basket snapshot. Then delete the Director DB and create a new one that then can get poplated with the schema by the correct Director version. After this you can load the basket snapshot into the Director and should have all you configs (apart for services via an apply rule).

But I would test this in a dev environment first and not do it in production

[e36Alex]

Please check the check_apt script on both of those servers with check_apt -V to print the version of the plugin. The --list parameter was added with v2.3. Anything lower does not have the parameter.
If they both are at least v2.3 then check:

On both hosts the same version is installed, but they are just on v2.2

I installed the monitoring plugins by apt as described in the docs, but it seems like there is no v2.3 avaible.
Can i download the checks manually from https://www.monitoring-plugins.org/download.html and replace the current plugin files?

Both checks come via the same service template?
Did you wait for a re-check after the config deploy (or did it manually)?

Yes, they come from the same service template.
I did both: After changes i triggered the check manually from icingaweb, but the check is also running regularly.

That’s what I “feared”. I don’t think it is a big deal, but it could be (as the message says).

Ok, then i will ignore it for the moment

[log1c]

@e36Alex

On both hosts the same version is installed, but they are just on v2.2

Now I’m totally confused
How can one check work and not the other when they both shouldn’t have the parameter xD
The check source for both checks is their respective agent?

@e36Alex

Can i download the checks manually from Monitoring Plugins - Download and replace the current plugin files?

Yeah, you can do that. But the files will get replace when there are updates coming in via apt.

[e36Alex]

I really have no idea whats happening there, too.

Today i tried to copy the check_apt-file from the working agent to the not working agent but same result.

Furthermore i have been notificated for other avaible package updates on other hosts: on these host the list parameter doesnt work, too.
I dont know if it could make a difference, but all hosts where list does not work are lxc containers on a proxmox host. The only agent with working list-parameter is the proxmox host itself. Could this be the reason?

[e36Alex]

Had a deeper look at it again:
on most hosts i see this inspecting the command:

on the proxmox-machine i see this:

But the command comes by the same template / apply rule to all agents.

[log1c]

Please check if all the hosts (containers and container host) have the same config.
Maybe something is wrong with the config deployment to the containers.

Check under /var/lib/icinga2/api/zones/... if the config s are the same, especially the on for the service apply rule.

[e36Alex]

I checked the files at the path but they are all identical (number of files, filesize…).

I dont know if this brings us closer, but also a bit strange: when i run the command in a ssh-session, the upgradeable package is in the output:

[log1c]

What happens when you run the command as the icinga user with sudo -u icinga check_apt --list?
Is the output of the packages still there?