[dev.icinga.com #2411] address/address6 are not required

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2411

Created by calestyo on 2012-03-07 00:53:39 +00:00

Assignee: Wolfgang
Status: Resolved (closed on 2012-05-05 10:12:00 +00:00)
Target Version: 1.7
Last Update: 2012-05-05 10:12:00 +00:00 (in Redmine)

---

Hi.

In http://docs.icinga.org/1.6/en/objectdefinitions.html#objectdefinitions-host the "address" directive is marked red as being required.

However, as mentioned later in the text it is not required.
Even if address6 isn't specified, then the value of "host_name" is simply taken as default.

So I guess, the red colour should be removed. :)

Cheers,
Chris.

[icinga-migration]

Updated by calestyo on 2012-03-07 00:58:43 +00:00

Oh and I just noted, that the BOTH of "contacts" and "contact_groups" may be undefined, too.
At least my Icinga started and I just got no notifications.

[icinga-migration]

Updated by Wolfgang on 2012-03-07 07:17:20 +00:00

• Status changed from New to Feedback
• Assigned to set to calestyo

Well, we can argue about this. Technically seen you are right, but:
It is highly recommended to add an address directive for the reason mentioned in the note. Additionally most examples calling plugins use the macro $HOSTADDRESS$ and there would a lot of work to change the definitions. I am not sure about configuration tools but I think they require a value as well.

[icinga-migration]

Updated by mfriedrich on 2012-03-07 09:16:08 +00:00

the core has a safety hook not to work with NULL values. nevertheless, the user must be made aware that not setting the address will trigger a gehthostbyname which requires DNS resolution and can be an unwanted dependency in case of failure. with my dns admin hat on, i would leave the address attribute mandatory.

[icinga-migration]

Updated by calestyo on 2012-03-07 20:18:36 +00:00

Well that this uses DNS then is explained already in the text, right? As well as the implications.

I guess there are many setups where it's just "useless" to set the address[6] field.
Well useless is a bit harsh perhaps,.. what I mean is rather there are setups where you don't have severe drawbacks if you use DNS to reach your hosts (and then it saves you work, IMHO, as you don't have to manually enter all IP addresses)

At the local institute for example, we run our own authoritative DNS servers.
If those are gone, nearly everything breaks, potentially even nagios... maybe not fully, but at least it would no longer be able to send out emails (it could not resolve the MTAs FQDN).

So I'd suggest... remove the red colour, keep the big fat warning, that DNS is then used and that this has implications.

As it is now at least the text conflicts itself. The red colour says it's required, the text below says it's not.

Cheers,
Chris.

[icinga-migration]

Updated by mfriedrich on 2012-03-07 20:31:07 +00:00

sure, we run our own dns resolvers as well. but that does not imply that we want to query the local resolver => recursive resolver each time a check runs, and the cache cannot answer.

the default examples on the most commands use $HOSTADDRESS$ as their macros, and not something like $HOSTNAME$ as your config need not be bound to use FQDNs as hostname which would be fully resolvable when being but onto a command as macro being fetched.

if the core would have a bug, and not setting the address field to the hostname (which could be something else than an fqdn btw), this will lead into faulty condition some might not be able to debug.
even further, when someone is not using fqdns, the core inherits that as actual address (!) the command using the $HOSTADDRESS$ will fail completely.

the past did show that is the most common mistake

1. use whatever hostname, but not fqdn
2. don't define host address
3. use $HOSTADRESS$ in your check / notification / eventhandler command definition
4. FAIL
5. cannot explain the error, unless someone sees that the address attribute is entirely missing

you actually can NOT enfore the users to just use fqdn then.

for my personal understanding, the address attribute is a must and i would make it happen in the core as well, if that would not break compatibility.

so my vote is for leaving it to mandatory RED, and adding a note to the users, what could happen if they don't set it.

and to add an addon which enforces the usage of the address attribute - checkmk. and that is good how it is, as it prevents live on execution dns resolve errors, warning your already on config creation if such an automated lookup will fail on generate, doing a rollback transaction.

@wolfgang
how many users can you count in your long lasting support on the portal having that exact mistakenly error?

[icinga-migration]

Updated by Wolfgang on 2012-03-08 20:33:54 +00:00

• Assigned to changed from calestyo to Wolfgang
• Target Version set to 1.6.2
• Done % changed from 0 to 50

changed in master and r1.7

[icinga-migration]

Updated by mfriedrich on 2012-03-16 14:21:29 +00:00

• Target Version changed from 1.6.2 to 1.7

[icinga-migration]

Updated by mfriedrich on 2012-05-05 10:12:00 +00:00

• Status changed from Feedback to Resolved
• Done % changed from 50 to 100

well if you insist on the change ... i would not do it.