Closed icinga-migration closed 12 years ago
Updated by mfriedrich on 2012-11-05 14:43:00 +00:00
no. such exceptions would lead into severe dependency problems inside the core, as well as for all external addons, plugins, scripts, notification modules, etc.
hostname and servicedescription are case sensitive, and will stay like that for remarked reasons. if you do not trust that, patch it yourself and throw in a full featured environment with all valuable addons installed (idoutils is case sensitive, pnp is, nagvis is, etc).
This issue has been migrated from Redmine: https://dev.icinga.com/issues/3422
Created by mzac on 2012-11-05 14:31:05 +00:00
Assignee: (none) Status: Rejected (closed on 2012-11-05 14:43:00 +00:00) Target Version: (none) Last Update: 2012-11-05 14:43:00 +00:00 (in Redmine)
One thing that has bugged me for a while is the fact that Icinga (and even nagios) makes a distinction between hosts with different cases, ie, ROUTER, Router and router are different.
Could it be possible to perhaps have an option in the icinga.cfg to be able to say if a hostname is processed with uppercase but it is found in the config as lowercase to treat it the same? I suggest it as optional because maybe some people do like to have it the way it currently is.
My case in this point is we are integrating our SCOM server with our Icinga server to send NSCA messages to Icinga, however a lot of the hostnames on the SCOM server are in many different cases (UPPER, lower, Combinations etc)
When I try to submit with different cases, this is what I get, the hostname I'm testing against is 'spare2950-48-sw1':
Submitting with NSCA with SPARE2950-48-sw1: [11-05-2012 09:20:32] Warning: Passive check result was received for service 'SNMP Trap' on host 'SPARE2950-48-sw1', but the host could not be found!
Submitting with NSCA with spare2950-48-sw1: [11-05-2012 09:20:55] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;spare2950-48-sw1;SNMP Trap;2;Testing