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.
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
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”)
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.
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:
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.
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)?
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
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).
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?
Yeah, you can do that. But the files will get replace when there are updates coming in via apt.
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?
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.