Add Remote Server using FQDN instead of IP ?

[UrBnW]

Hi,

I'm trying to configure a remote server.
Both my central and my (ready to be configured) remote server are reachable through HTTPS only, with a valid SSL certificate.
So both can be reached through their https://FQDN/ URL.
They can't be reached using their IP (https://IP/), which will return an HTTP 403 Forbidden error.

I'm a little bit confused by the Centreon documentation where the process to add a remote server only talks about the IP address of the central and remote servers.
I tried to add the remote server using the FQDN of the central and remote servers where the process asks for an IP address, this to be sure both use the FQDN and not the IP of the other server, so that they will properly connect through HTTPS, reach and validate the proper SSL certificate etc...
There are 3 places where an IP address is asked :
https://documentation.centreon.com/docs/centreon/en/latest/administration_guide/poller/install_remote_server_packages.html

• @IP_CENTREON_CENTRAL, when running centreon -a enableRemote... ;
• Server IP address, in the wizard ;
• Centreon central IP address, in the wizard.

Unfortunately this does not seem to work.

I tried to investigate and found that the FQDN does not fit into the ip field of the remote_servers MySQL table, which is too small. Perhaps this is the issue.

Did I miss something ?

Thank you for your help 👍

Edit : issue still present in 19.04.2.

[UrBnW]

Of course, after having allowed both my instances to be reached using their IP (https://IP/), configuring the remote server using IPs works.

I then don't understand the goal of the "Do not check SSL certificate validation" user option, as we can't validate a SSL certificate using an IP, but using a FQDN only (valid SSL certificate only contain FQDN). As per my understanding this option then can't be unchecked : we will be presented a self-signed certificate, or a CA-signed certificate but which will not validate the IP address...

Thank you 👍

[adr-mo]

Hi @cpbn

Thanks for the feedback 💯

I'll check with @lpinsivy and get his opinion on this.

Regards,

[lpinsivy]

Hi @cpbn I made a PR, can you test ?

[UrBnW]

Hi @lpinsivy, sure, many thanks, let me test this and report 👍

[UrBnW]

So @lpinsivy, #7637 really helps, thank you 👍

One thing though.
Running the following command from the Remote Server...
centreon -a enableRemote... -v 'https://nicefqdn.com;0;HTTPS;443;0;0'
... will still put the Remote Server IP into the remote_servers table of the Central Server.
Then, adding the Remote Server using the Select a Remote Server option from the Central Server wizard will fail (as the IP address will be used).

The workaround I found for now is to choose the Manual input solution, using FQDN instead of IPs in both places of the wizard form.

Thank you 👍

[lpinsivy]

We prefer to store received IP from Remote Server instead of FQDN.
So yes the best way is to create manually the configuration through the wizard.

So the PR works?

Regards,

[UrBnW]

Perfect then 👍
Yes the PR works, I am now able to interact with a Remote Server through its FQDN.
Thank you again !

[UrBnW]

One last question Laurent (which will perhaps lead to a documentation update).
In the documentation, we have :

# /usr/share/centreon/bin/centreon -u admin -p centreon -a enableRemote -o CentreonRemoteServer -v '@IP_CENTREON_CENTRAL;<not check SSL CA on Central>;<HTTP method>;<TCP port>;<not check SSL CA on Remote>;<no proxy to call Central>'

How to simply enable Remote Server mode without specifying Central info ?
As if we create manually the Remote Server configuration through the Central wizard, we do not need to pre-fill the remote_servers table.
Even more if we use FQDN, as it will not match the pre-filled IP...

Thank you again 👍

[lpinsivy]

@cpbn unfortunately you can't.

The workaround is to set an invalide IP to get the "Ping Master" failed and enable the Remote Server ;)
However, you need to add the real IP addresses in the centreon.informations table for "authorizedMaster" field.

[cgagnaire]

Just to be clear, the ip column of the remote_servers table is not meant to store the FQDN of the Central, but the IP address from which the enableRemote process did come from, so the Remote Server IP.

So when you call the enableRemote action, you have to specify the IP address and/or FQDN of your Central to report back to it, and add it locally as a "Authorize" host for future createRemoteTask action coming from the Central.

[UrBnW]

the ip column of the remote_servers table is not meant to store the FQDN of the Central, but the IP address from which the enableRemote process did come from

Sure :)

so the Remote Server IP

Or its FQDN then, right ? (this was the purpose of this ticket and its related PR @lpinsivy wrote).