Certificate Monitoring - x509 no such module

Service Monitoring
1

Hello everyone!

I have followed all the steps at About - Icinga Certificate Monitoring and the subsequent guide pages. Everything went well (after I broke my Icinga QA 10 times, lol). However, now that I tried to create an apply rule for multiple certificates to show, this is what I see in monitoring:

Also want to clarify, I can run icingacli x509 commands.

image
image1115×258 36.2 KB

Any assistance would be greatly appreciated!

Thanks!

2

Some basic troubleshooting that I can think of off hand:

  • What’s the executed command? You can grab this from the icinga2 logs (can’t recall if debug logs need to be on), or if you have the director module installed, you can grab it from the web ui by clicking the inspect link. What’s the output when you manually run the executed command on the cli?
  • Is the command executed from the master or another node? In a distributed environment, you could have this command executing on the wrong box (I am assuming single master though)
3

This is the executed command:

'/usr/bin/icingacli' 'x509' 'check' 'host' '--allow-self-signed' '--host' 'host.domain.com' '--ip' '10.120.0.8' '--port' '5665'

I am using a director installation. When running the command from the CLI, this is the output

[root@myicingahost ~]# '/usr/bin/icingacli' 'x509' 'check' 'host' '--allow-self-signed' '--host' 'adfs01-mis.misqa.com' '--ip' '10.120.0.8' '--port' '5665'
OK - host.domain.com expires in 5473 days|'host.domain.com'=472951195s;118281600;47347200;0;473040000

I am running a single master. This is not a distributed environment.

Thanks!!

4

If it works manually as root the user which is used by Icinga does not have access to the configuration. So assigning the user to the group which has access should solve this, if SELinux is not enforcing as this would be another problem.

5

I’m going to try to fix that and then post if I run into any more problems. Thank you!

EDIT: These are the changes I made and it’s still not working. Did I do this correctly?

[root@icinga02-mis ~]# cat /etc/passwd | grep icinga
icinga:x:996:990:icinga:/var/spool/icinga2:/sbin/nologin
icingadirector:x:994:994::/var/lib/icingadirector:/bin/false
[root@icinga02-mis ~]# id icinga
uid=996(icinga) gid=990(icinga) groups=990(icinga),991(icingacmd)
[root@icinga02-mis ~]# id icingadirector
uid=994(icingadirector) gid=994(icingaweb2) groups=994(icingaweb2),990(icinga)
[root@icinga02-mis ~]# ll /usr/bin/icingacli
-rwxr-xr-x. 1 root icinga 239 Aug 18  2020 /usr/bin/icingacli
6

Ok, so it is a rpm based system.

So this should do the trick:
usermod -a -G icingaweb2 icinga && systemctl restart icinga2.service

This will add the additional group icingaweb2 to the user icinga and then restart the service to take effect.

7

To @dgoetz 's point, I’m kind of interested if selinux is enabled or disabled – what’s the output of getenforce

If the output is Enabled, can you try setenforce 0 (this does not disable selinux, but instead puts it in permissive mode) and then try having Icinga run the check again.

To test commands as the Icinga user, you can run sudo -u icinga <command>

Edit: looks like @dgoetz beat me to a different approach :sweat_smile:

8

Thanks! That worked. Would you mind explaining what happened there so I can know? Why did adding the Icinga account to the Icingaweb2 group work?

9

I have SELinux set to Enabled. Normally I disable it but hadn’t just yet on this box I guess. Still works after I made that change.

Thanks!!

1 Like
10

Why did adding the Icinga account to the Icingaweb2 group work?

We discussed this in slack, but for everyone else:

[root@icinga02 enabledModules]# pwd
/etc/icingaweb2/enabledModules
[root@icinga02 enabledModules]# ls -l x509
lrwxrwxrwx 1 apache icingaweb2 34 Jan 10  2020 x509 -> /usr/share/icingaweb2/modules/x509
11

icingacli is executable by every user, but to function properly it requires the configuration. The configuration is stored in /etc/icingaweb2 which is by default readable for the icingaweb2 group but not the icinga user. By adding it to the group access is granted. The running instance will not change its user’s groupmembership, so if the service is not restarted it will have no effect, because of this the service gets restarted in the second command.