Hi,
Actually i have an icinga master and an icinga client, they are working no problem with that.
But now i have to add a satellite in the same network of my client and connect this client to the new satellite. But i don’t know how to do that because when i use “icinga2 node wizard” on the futur satellite he add this host as a client and he don’t care about satellite.
On my master i created 2 zones : master and SMAX(satellite + client)
thanks for your help
You need 3 zones, one for master, satellite and client each.
i did it but all configuration zones must be in the Master server ??
And to configure the satellite i have to do icinga2 node wizard and configure it like an “agents” ?
Anoter question, after that in case everything works, to use check command from satellite to a client target how can i do that, i must configure everything on the satellite or i have to do somethings on master too ?
thanks,
Icinga’s concept is very powerfull but somewhat challenging to get used to it. It’s crucial to understand the concept.
The master needs to know about all zones, in your case the satellite as well and the client it’s own zone and the satellite.
Best practice for command objects is to create global zones e.g. windows-commands and linux-commands and add them to master, all satellites and according clients.
Yeah i read it,
And for check command on client ? how it works, we must configure it on the satelitte thats logical for me but its not clear on icinga doc.
Hi,
since you already have a working master and client, including an Icinga CA, keep it this way.
Your first step is to install the new satellite and connect it to the master, just like the client before. Do this by running the node wizard after installation, point it to the parent zone being your master, and the endpoints when asked.
Ensure that TLS certificates are signed and the configuration works properly. This includes editing the master’s zones.conf and adding the satellite zone and endpoint as shown in the three level cluster scenario in the docs.
The base concepts are needed to understand that this doesn’t matter on the second level this being a client or a satellite zone.
One the satellite works, start simple and create a zone directory called satellite (or whatever name you’ve chosen in zones.conf) and put a host object there. Restart the master and let this being synced to the satellite. Wait up until a check result is retrieved and you can view it in Icinga Web 2.
One you’re sure cluster communication including config sync works. you’ll go the second step with connecting the client to the satellite instead of the master.
This is fairly simple, since the TLS certificates are already signed, and the satellite’s public certificate is signed with the same CA as the client’s public certificate.
The main point is to navigate into the client’s zones.conf and edit the parent zone (which previously is the master zone) and also modify the endpoint details.
-object Endpoint "master.FQDN" {
-
-}
+object Endpoint "satellite.FQDN" {
+
+}
-object Zone "master" {
- endpoints [ "master.FQDN" ]
-}
+object Zone "satellite" {
+ endpoints = [ "satellite.FQDN" ]
+}
object Zone "client.FQDN" {
endpoints = [ "client.FQDN" ]
- parent = "master"
+ parent = "satellite"
}
Depending on your configuration and connection direction, you’ll need to set the host attribute for the Endpoint again.
On the satellite’s end, you’ll need to do it vice versa, add the client endpoint and zone to the satellite’s zones.conf
Next up, restart the client and then the satellite and verify that they connect.
The last important step is to move the Host object for the client from the master zone into the satellite zone.
This also influences the way how Endpoint and Zone objects for clients are distributed, a little trick allows you to just add them into the hosts.conf file on the master, and sync them to the satellite (followed by a restart).
First off, remove the client’s Zone and Endpoint from your satellite’s zones.conf.
Next, edit zones.d/satellite/hosts.conf.
object Host "client.FQDN" {
address = "..."
vars.client_endpoint = name //convention that host name == endpoint name
}
object Zone "client.FQDN" {
endpoints = [ "client.FQDN" ]
}
object Endpoint "client.FQDN" {}
Now pick a service apply rule which uses command-endpoint, and put it into the satellite’s directory in zones.d as well.
Run a config validation, and then restart the master. Wait up until the first check is executed and inspect the check source.
Cheers,
Michael
Ok thanks this is more understandable, I had already done some things, can you tell me if for the moment I’m right ?
My /icinga2/zones.conf file :
object Endpoint “BASTION” {
host = “BASTION”
}object Zone “satellite” {
endpoints = [ “BASTION” ]
parent = “master”
}
//------------------------------------------------------------------------------------------------//
object Endpoint “CLIENT” {
host = “CLIENT”
}object Zone “client” {
endpoints = [ “CLIENT” ]
parent = “satellite”
}
//--------------------------------------------------------------------------------------------------//object Endpoint “MASTER” {
host = “MASTER”
}object Zone “master” {
endpoints = [ “MASTER” ]
}
//---------------------------------------------------------------------------------------------------//object Zone “global-templates” {
global = true
}object Zone “director-global” {
global = true
}//----------------------------------------------------------------------------------------------------//
My structure :
MASTER >>>>> SATELLITE >>>>> CLIENT
On my master /icinga2/zones.d/satellite/SATELLITE.conf :
// Host Objects
object Host “BASTION” {
check_command = “hostalive”
address = “@IP”
vars.client_endpoint = “BASTION” //follows the convention that host name == endpoint name// Custom Optional check - START
vars.local_disks[“/app Filesystem”] = {
disk_partitions = “/app”
}
vars.local_http_vhosts[“http”] = {
http_uri = “/”
}
vars.local_tcp_port[“tcp”] ={
tcp_port = “23”
service_name = “Telnet Check”
port_number = “Port 23”
}
// Custom Optional Check - END
}
I have the same for the client file client.conf in zones.d/client/CLIENT.conf :
// Host Objects
object Host “CLIENT” {
check_command = “hostalive”
address = “@IP”
vars.client_endpoint = “CLIENT” //follows the convention that host name == endpoint name// Custom Optional check - START
vars.local_disks[“/app Filesystem”] = {
disk_partitions = “/app”
}
vars.local_http_vhosts[“http”] = {
http_uri = “/”
}
vars.local_tcp_port[“tcp”] ={
tcp_port = “23”
service_name = “Telnet Check”
port_number = “Port 23”
}
// Custom Optional Check - END
}
At which step in my post are you?
This isn’t what I’ve told you, the client configuration needs to be put into the satellite’s zone name in zones.d/satellite e.g.
Im at the end of step 2 i try to edit the zones.conf in the satellite’s end but i have an error with this file.
Hi,
I did all your steps but when I watch the ping’s check source it’s not ok.
I followed your protocol but, sometime, I was not sure of myself. I watch my satellite and my client on icingaweb2 but the checksource is wrong.
My zones.conf in the satellite :
object Endpoint “MASTER” {
host = “MASTERIP”
port = “5665”
}
object Zone “master” {
endpoints = [ " MASTER " ]
}
object Endpoint “SATELLITE” {
}
object Zone " SATELLITE " {
endpoints = [ " SATELLITE " ]
parent = “master”
}
//-----------------------------------//
//There is an error with this part, that why she is in commentary
/*
object Endpoint “CLIENT” {
host = " CLIENT "
}
object Zone “client” {
endpoints = [ " CLIENT " ]
// parent = “satellite”
}
*/
//-------------------------------//
object Zone “global-templates” {
global = true
}
object Zone “director-global” {
global = true
}
My zones.conf Client’s :
object Endpoint “SATELLITE” {
}
object Zone “satellite” {
endpoints = [ "SATELLITE " ]
}
object Endpoint "CLIENT " {
}object Zone " CLIENT " {
endpoints = [ " CLIENT " ]
parent = “satellite”
}
object Zone “global-templates” {
global = true
}
object Zone “director-global” {
global = true
}
And now my master’s zones.conf, there are things you didn’t ask me but it was a previous config, maybe it could be a problem ?
object Endpoint " SATELLITE " {
host = " SATELLITE "
}
object Zone “satellite” {
endpoints = [ " SATELLITE " ]
parent = “master”
}
//------------------------------------------------------------------------------------------------//
object Endpoint " CLIENT " {
host = "CLIENT "
}
/*
object Zone “client” {
endpoints = [ “CLIENT” ]
parent = “satellite”
}
*/
//--------------------------------------------------------------------------------------------------//
object Endpoint " MASTER " {
host = " MASTER "
}
object Zone “master” {
endpoints = [ " MASTER " ]
}
//---------------------------------------------------------------------------------------------------//
object Zone “global-templates” {
global = true
}
object Zone “director-global” {
global = true
}
And this is my /etc/icinga2/zones.d/host.conf :
object Host “CLIENTl” {
check_command = “hostalive”
address = “IPCLIENT”
vars.client_endpoint = “CLIENT” //convention that host name == endpoint name
}
object Zone “CLIENT” {
endpoints = [ “CLIENT” ]
}
Thanks
Can you share a screenshot and explain this more in detail. “not ok” can mean anything, and “is wrong” as well - what expected values would you see there?
Without the error from config validation, we cannot really tell you what to do - please provide its output for further analyses.
Also, please use the three backticks wrapped around code blocks, as suggested in this guide: Create topics and master Markdown formatting
Cheers,
Michael
The check command hostalive return a down state :
But it’s normal because the check source is my master and they aren’t in the same network, we need checksource = satellite to have an up state.
Without the error from config validation, we cannot really tell you what to do - please provide its output for further analyses.
My bad i got no error on this part.
And for information my master got a public IP, my satellite too and he have also a prive IP in the same network of my client. (client doesn’t have a public ip).
Thanks,
Louis
Hi,
I modified my conf files, but when i edit the zones.conf on the master (for the first step) my check commands no longer executes. (like a ping, they are no longer executes).
icinga2/zones.conf :
object Endpoint “master.FQDN” {
}object Zone “master” {
endpoints = [ “master.FQDN” ]
}
//-----------------------------------------------------------------------------//
object Endpoint “satellite.FQDN” {
}object Zone “satellite” {
endpoints = [ “satellite.FQDN” ]
parent = “master”
}
And can you develloped :
One you’re sure cluster communication including config sync works.
Which file exactly must be sync ? zones.conf ?
I understood now that there is no need for a client zones but only master/satellite.
Cheers,
Louis
No, the host object with its content. The object must be available on the satellite, check that with icinga2 object list --type Host --name ....
Right now, it seems that the master executes this object, which likely happens that its host object is located in zones.d/master and not zones.d/satellite.
Cheers,
Michael
When I try your command i get lot of informations like IP, parents, and the zone definition (“satellite”).
Furthermore my host.conf is in /zones.d/satellite, so its strange.
I continuous to search a solution.
Cheers,
Louis
when i try the command with the master’s host i got nothing in “zones”.
Posting the output within code blocks will help, I have really a hard time following your thoughts without your screen.
Also, when you trigger a forced check now from the web interface, enable the debug log and trace its way on the master to the satellite to the client. Grep for the object name for example, and add this here.
Cheers,
Michael
I understand that it is not easy to follow without proper screen, I did not find how to activate the debug log, more I have almost nothing in syslog. Can you tell me quickly how to enable it ?
Moreover on this screen you can see a satellite ping but we notice that the “checksource” is not good, it is itself. This is probably why he refuses to update the ping for 3 days. The satellite verifies itself while logically it is the master. He is supposed to check only the client but not itself.
Cheers,
Louis
Hi,
just execute the command on the shell:
icinga2 feature enable debuglog
and restart icinga2. The debug.log can be found at /var/log/icinga2/debug.log.
https://icinga.com/docs/icinga2/latest/doc/15-troubleshooting/#enable-debug-output-on-linuxunix
Greetz
ok thank you, my bad i read this doc but i searched for “icingaweb2” not icinga but you right icinga2 is the backend of web interface that was stupid ^^.
thanks,
Louis
