Findout if I'm on a master or not?

icinga2

(Danny H.) #1

Hey there,

right now I’m building a playbook to install icingaweb2 & icinga2 with all configurations.
Therefore I’m using the icinga2_feature module…

My playbook:
1.) install icinga2
2.) configure by placing all config files
3.) running icinga2_feature module to enable
- api
- checker
- command
- ido-mysql
- influxdb
- mainlog
- notification
- perfdata
4.) running the shell command: icinga2 node setup --master

4.) seam to override /etc/icinga2/constants.conf
from:

object ApiListener "api" {

  ticket_salt = salt1234567xyz
}

to

object ApiListener "api" {

  ticket_salt = TicketSalt
}

Therefore I would like to write a handler which will run these commands only if necessary.
I would like to know if there is a way, file or command which can provide me any information if a Master is already setup?

Best regards

Danny H.


(Michael Friedrich) #2

It is best practice to not define the ticket_salt in the api.conf feature directly, but to use a global constant and define the value of TicketSalt in the constants.conf file.

Instead of checking if everything is applied already, the descriptive configuration in your playbook should always produce the same result, shouldn’t it?


(Danny H.) #3

Instead of checking if everything is applied already, the descriptive configuration in your playbook should always produce the same result, shouldn’t it?

It should of course.
Therefore icinga2 node setup --master should be a handler which will run under specific conditions.
For example if there is no Master set-up.
I might have just config changes which should not result in setting up the Master again…

It is best practice to not define the ticket_salt in the api.conf feature directly, but to use a global constant and define the value of TicketSalt in the constants.conf file.

ticket_salt into constand.conf… check

Is there a command, file or something which I can get for a conditional check if master, client or satellite?


(Michael Friedrich) #4

Imho you should create a role for that and specifically assign that role to the FQDNs. That’s how I am used to with Puppet. I think Ansible works quite the same way.


(Danny H.) #5

I did not get your approach I think.

What I get: (My Icinga servers fqdn is icingaserver.domain.example)

If my fqdn == icingaserver.domain.example than it should run the icinga2 node setup --master.

If my fqdn != icingaserver.domain.example it should not run icinga2 node setup --master.

Is that correct?


(Michael Friedrich) #6

No, the entire role and configuration should only be applied for e.g. a master. This one holds the instructions for setting things up. A different role is then created for satellites which slightly differs, next to the one for clients.

Isn’t that a thing with Ansible? I think that’s the best approach with Puppet. I’m not an Ansible user though.


(Danny H.) #7

I maybe not explained properly what my problem is.
But in generell you are right. That is not a problem at all to setup a client, master or satellites at all.

My only question was:
Where can I get the information if a server is set-up as master, client or satellites.

I might just found an answer.
My assumption:
If /var/lib/icinga2/ca exists than my server is already set-up as master.

Is that correct?


(Michael Friedrich) #8

That would be one location, yes. You could also go for checking for content in zones.d if your role deploys configuration already.