Why does my satelite node not show up on the Iicingaweb page?

To make myself a little clearer, I have uploaded a screenshot of the network setup.

I have a master server standing in our own network and trying to connect to a satelite node that is on a remote siter that is supposed to monitor the agents there.

When I install the satelite node using the Icinga manual ─ icinga2 node wizard command.

I connect to the Master server using a public IP address forwarded on port 5665 TCP to the Master server’s internal address. This connection works because I see the certificates popping up from the server during the Satelite node installation, so the connection to the Master has clearly succeeded.

After the Satelite installation, I look at the icingaweb2 page, but I don’t see the Satelite node there? It clearly connected to the server, but no trace of the satelite to be found.

Then I can add the satelite with the director module where I refer to the public IP of the remote firewall that the Satelite is behind ─ this is forwarded to the internal IP address of the Satelite node. Then it does show up in the web page of Icinga, but I see that the “ping4” check is done from the Matser server to the satelite node. The IP address used by the ping4 check is the public address of the remote firewall, so it is the firewall that responds to the ping4 check, but not the satelite node. Other checks where the Satlite node is the source and not the Master also come in fine, but the ping4 check is deceptive because it is in fact the remote firewall that answers and not the Satelite node.

Two things:

1: How come the Satelite node does not come online in Icinga’s web page and I have to add it manually with the director module?

2: How can I run the ping4 check on the Satelite itself and then forward that data to the master server and not the other way around, so that I don’t get an answer from the public address, but from the Satelite’s internal address?

If I am asking stupid questions here, forgive me, I am just starting to set up and explore Icinga, I am here to learn.

If there is certain configuration you want to see to get more clarity, just ask :).

PS: port number in the screenshot is wrong, but is only for illustration.

You need to the zones.conf on the master as well as on the satellite updated with the new relationship between them. And you need a host object that represents the satellite.

icinga doesnt take care of your hosts or services.

you already figured out that director is something to manage host and service configs. You should to create every host and service that shall be monitored in icinga director.

It is a little bit misleading because icinga2’s default config creates a host for you master-node in plain config files.

Recommendation: I would secure the connection one more time using a vpn.

Hi Roland,

First of all thanks for replying so quickly. So, during the installation of the Satelite node and during the connection to the Master, I indeed noticed that the zone file of the Satelite was modified with the information I provided during the Satelite installation.

I was under the belief that when the Satelite connects to the Master ─ during the installation I also provided the PKI ticket that was generated on the Master ─ that oo, the Master’s zone file was automatically modified, but by the looks of it, it was not.

I modified it and the Satelite node comes online. But, I see that the ping4 check is done with Master as the source to the Satelite to see if it is online. The IP is obviously the public IP of the remote firewall the satelite is behind. Isn’t it the firewall answering instead of the satelite?

I am attaching a screenshot for clarification.

For example, when I do a check through the director module (mem check), I see that the source of the check is the Satelite node. That in turn then forwards the data to the Master. So, from Satelite to Master, but not like the ping4 check from Master to Satelite.

If the source of the ping4 check were the Satelite I could pass its internal IP to ping. If the Master does the check I obviously give the Public address as an argument, but then I fear the firewall will answer instead of the Satelite.

How do I solve this?

still recommend the vpn, but you can use check_tcp on port 5665 as you host check command, If executed from master it will look for the open port on your satellite and decide if the satellite is up or down

2 Likes

Yes, I plan to set up a wireguard VPN and then I won’t need the portforward (5665), but imagine if I didn’t. Is it not possible then to do the ping4 check on the Satelite and remove the default ping4 check from the dashboard ─ which shows if the Satelite is online, but whose source is the Master? I did see if I do the hostalive4 check and set it through the director module, that the source is the Satelite itself and I can give the internal IP as an argument.

Sometimes one needs to replace the default host check (ping) with some thing like icinga-zone or check_tcp on port 5665.

Also, what is the diffirence between an agent and a Satelite. While installing it i see no diffirence.

A agent is a satellite that targets only it self and has no other agents attached underneath in the pyramid structure.

The agent is the single node in the zone and there are no sub zones.

2 Likes

Ok, but when i add the Satelite node with the director module, its default check is the ping4 check. How do i change that?

Clone your host template and there you can choose a check_command.
Now import your new template on your satellite host.

Ok Dominik,

I will check it out right now, i will come back to you in a few minutes to give some feedback!

Dominik,

It works if I modify the host template!

All the checks below in the screenshot were added using a service set I created in the director module.

What I notice is that all the checks have as source the Satelite, but not the ping4, which takes the Master as source. Based on what is decided whether the check comand should be started on the remote Satelite or on the Maste server?

Well, the host can’t check it self if it’s up the upstream cluster needs to determine this.

Ok, but the hostalive check runs the exact same script and command, but it does it from on the Satelite and not from the Master as the source.

It has a different command_endpoint in the cluster. If I understand correctly the host check is always run in the zone above the node in the cluster.

I see that this can be changed, but i will leave it as it is.

I became wiser today, thank u for all the help, Dominik!

Have a great day!