i installed the icinga2 agent on a windows box.
Certificate is signed and the menu shows the hostname in the following format:
HOSTNAME.DOMAIN.local.
This works so far.
Now i wanted to add an snmp trap alerting, using snmptrapd and /var/run/icinga2/cmd/icinga2.cmd.
Sadly it resolves the hostname to hostname.domain.local thus it isn’t matching the hostname configured in icinga correctly and the state will not update.
Of course i could parse the name in a script but i would prefer handling each hostname case insensitive. Is there a way to do this?
the host is configured through icinga director -> Hostname: HOSTNAME.DOMAIN.local
Just changing it to lower case results in an error message for all agent based services: "Remote Icinga instance ‘hostname.domain.local’ is not connected to ‘icinga’.
Ah ok, auto-discovered within the Director, I see. Then you’d need to pick one of the two, if possible:
Ensure that the Windows hostname is lowercase (dunno if that’s working)
Add a rule to snmptrapd to try uppercasing the host name
Since you’re using a script for the command pipe, you can do so anyways.
Besides, I can highly recommend using the REST API instead which gives a direct error feedback instead of making you grep the master logs. The command pipe is deprecated btw.
I had rerun the Icinga 2 Setup Wizard on the windows box.
It defaults to a mixed FQDN, using upper case and lower case.
Changing it to lower case case solves the issue. Maybe in further versions this could be made the default?
maybe you can look into the SNMP bits and EXEC things yourself and contribute with an updated guide for the docs. The REST API is documented here. Or you’ll write an howto here as well. I don’t have such a setup at hand and will take me a while to get such - currently my schedule is full with 2.11 and ongoing projects
Anyhow, for the Windows parts this is just what the operating system returns. For some reason, Windows prefers to print short host names in upper case, likely coming from the netbios naming schema. In my dev VM, I’ve explicitly added it to a domain which resulted in a lower case host name. Might help with your setup as well.
i was able to use the API to update the status of the service. Sadly it also works case sensitive and there i couldn’t find an option to tell the filter beeing apllied case insensitive.
I’m using the command:
curl -k -s -u root:$myPW$ -H ‘Accept: application/json’ -X POST ‘https://localhost:5665/v1/actions/process-check-result’ -d ‘{ “type”: “Service”, “filter”: “host.name==“HOST.DOMAIN.tld” && service.name==“SNMP_TRAP””, “exit_status”: 2, “plugin_output”: “CRITICAL 123456789”, “pretty”: true }’
As said, its doable if you remember to change the host to lower case during Windows Setup Wizard.
Case insensitive handling would be kind of insane. Each object name is case sensitive and therefore unique. Icinga1 and Nagios used to ignore that and you could name our objects like PING, ping, PiNg and they all where the same. No-one can determine that from a problem’s list that they are all the same service checks.
I’m not sure about the impact of changing the setup wizard to only show lower case names. Please discuss that on GitHub with a feature request.
It is the Windows C# API which returns this in upper case, so that’s a more generic question. We could lowercase that anyways, but I’d like get the idea why the caller needs to do that explicitly.
In terms of the repo - https://github.com/icinga/icinga2 being the core which also provides the agent setup wizard. The code for the wizard is located here and with following the development guides you can also edit and test this in Visual Studio 2017.
