please submit patches along with a description of the problemn and
solution to feedb...@check-mk.org.
2018-02-03 1:59 GMT+01:00 Christopher Cox <chris...@endlessnow.com>:
> So, came up with a fix... best way to submit a patch?
> On 02/02/2018 06:04 PM, Paul wrote:
>> I think the quickest way would be to copy the existing check script into
>> your "~/local/" structure. Then make the required edits.
>> This should leave any existing configuration options for this check type
>> (WATO etc) in tact.
>> On Fri, Feb 2, 2018 at 3:58 PM, Christopher Cox <chris...@endlessnow.com
>> <mailto:chris...@endlessnow.com>> wrote:
>> The dell_om_disks uses the snmp (bridged from OpenManage) value of
>> arrayDiskName as the key of uniqueness for "Physcial disks"...
>> however that name is not unique across all controllers, thus each
>> controller could have "Physical Disk 0:0:0" for example. The
>> arrayDiskNexusID seems to have the unique values, for example one
>> being '0\\0\\0\\0' vs '1\\0\\0\\0', the first element identifying
>> the "nexus" or in my opinion, controller. Regardless, it's a better
>> "name" for uniqueness, though it probably needs massaging because of
>> the backslashes.
>> Anyhow, I'd like to change dell_om_disks to use my own instead of
>> the supplied one to test. Then I might submit a fix, and might
>> rename things to match calling it Disk Nexus ID 0:0:0:0, or
>> something like that rather than Physical Disk 0:0:0 (noting that
>> string is actually contained in the MIB returned value) when using
>> the bad arrayDiskName.
>> So what's the prescribed best way to override with my own check?
>> btw, I didn't actually check to see if the latest dell_om_disks does
>> the right thing, but pretty sure it doesn't.
>> checkmk-en mailing list
> checkmk-en mailing list
checkmk-en mailing list