That's just an attribute. If your address should be the FQDN instead, then
put it there. Or tell your service object, that address should be
overridden with the host.name or any other custom setting resolved at
runtime.
apply Service "blub" {
vars.address = $host.name$
...
The reason why we removed the hack provided by Nagios/Icinga 1.x is simple
- $HOSTADDRESS$ should resolve into the host attribut 'address'. If there
is no address attribute defined, the old core automagically uses the
HOSTNAME.
This leads to funny debug sessions if the hostname is *not* an FQDN. Users
won't see the workaround hack and will question the address macro.
Trust me, i've seen that too many times doing Icinga support for 5+ years
now.
Therefore there's a clear strategy with Icinga2 - use the proper macros,
and stay safe. You'll get a context including warning on the logs if your
macros do not resolve upon check execution.
And you can define default values in your checkcommand, if you put the fqdn
in a custom attribute for instance.
object CheckCommand {
import ...
vars.address = $host.vars.fqdn$ //from host
//vars.address = $fqdn$ //service or host custom attr
...
Afterall, you could also define your own commands passing the $host.name$
macro being an fqdn. But it's not the recommended way for users and
beginners.
I for myself don't trust the dns system, caching and possible resolval
issues which will hide/influence the real problem. I have had too much
trouble in my previous job in Vienna, also managing the cctld for .at ...
Kind regards,
Michael
Am 14.07.2014 23:14 schrieb "Alan Bunch" <ala...@swifttrip.com>:
> First of all Thank You to all who have created and contributed to Icinga.
> I'm just getting here and hope to be helpful in the future.
>
> I have used Nagios for many years in smaller deployments and in the past I
> have never had to set the address property in a host definition. I have
> always
> depended on DNS to resolve the address. I have found that all of the
> command
> definitions in Icinga2 use the address rather then the hostname.
>
> I was wondering if someone was aware of the thinking behind this decision.
> Please note that I am NOT QUESTIONING the decision. I am just interested
> in the rationale behind it. I do my best not to hard code ip addresses
> anywhere but in DNS zone files and was wondering if I was missing some
> requirement of Icinga to have the addresses in the config files.
>
> TIA
> Alan
>
> _______________________________________________
> icinga-users mailing list
> icinga-users@lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users
>
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
