[Xymon] OS version tags

[Johan Karlsson]

>> Hi!
>>
>> We have an issue with RHEL7 and xymon-client 4.3.26
>>
>> In client-local.cfg on our xymon server we have these log rules:
>>
>> [linux]
>> log:/var/log/daemon.log:102400
>> log:/var/log/kern.log:102400
>> log:/var/log/syslog:102400
>> log:/var/log/messages:102400
>> ignore MARK
>>
>> [rhel3]
>> log:/var/log/messages:102400
>> ignore MARK
>>
>> We have an old RHEL5 server which reports the following to Xymon and 
>> thus get matched against [rhel3] in client-local.cfg:
>>
>> [collector:]
>> client oldserver,xxx,com.rhel3 rhel3
>>
>> However, unconfigured the RHEL7 server reports:
>>
>> [collector:]
>> client newserver,xxx,com.linux linux
>>
>> Setting CLIENTOS="rhel3" in /etc/sysconfig/xymon-client only changes 
>> the
>> first:
>>
>> [collector:]
>> client newserver,xxx,com.rhel3 linux
>>
>> We need it to report:
>>
>> [collector:]
>> client newserver,xxx,com. rhel3 rhel3
>>
>> Any idea where to change the setting for that?
>>
>> The issue is that RHEL doesn't have daemon.log, kern.log etc, so these 
>> turn up as warnings in the msgs test
>>
>> Regards,
>>
>> Johan
>
>Hmm,
>
>Leaving aside the issue of the old 'rhel3' label there (this also affects how vmstat output is parsed, so it may be causing an unwanted side effect), there's actually a bit more of a >fundamental logical problem
>here: a CLASS=linux will match before OS=<whatever>, and by default we're sending both OSTYPE and CLASS.
>
>The precise bug is in a change in the RPM (which has been there for a while, I think), as this line in xymonclient.cfg:
>
>CONFIGCLASS="$SERVEROSTYPE"     # Default configuration class for logfiles
>
>... is parsed before the CLIENTOS variable in /etc/sysconfig/xymon-client is converted to SERVEROSTYPE in /usr/libexec/xymon-client/xymonclient.sh.
>
>As an immediate work-around, edit that variable in xymonclient.cfg.
>
>If you're feeling more adventurous, changing [linux] to [os=linux] in client-local.cfg *should* cause the (CLASS=)[rhel3] line to take priority here, while still letting >the default linux clients work OK. 
>
>
>I'm not quite sure on the right solution here is (other than consolidating variable names in 4.x going forward); there might be good causes for both linux as a class and linux as an OS type remaining separately tweakable according to local needs. OTOH, the status quo is definitely somewhat confusing. Likewise, it's possible that client-local.cfg's default settings should be hard-coded to the lowest-precedence category (os=) so that overrides are more likely to work. 
>
>All that aside, I'd advise making a new class type for different categorizations like this (or just using the hostname, if it's a one-off) rather than the 'rhel3' tag. >That's definitely intended for legacy support.
>
>
>Regards,
>-jc

Hi!

Ah, I see. Thanks for your input!

Regards,

Johan