Xymon script for linux

It might be a little tricky with the way the code path works right now, as
we don't really scan back and forth when processing a client message. But
as long as the locations within the text area are the same we can probably
do a sequential case check around it.

I do agree on 'sar' being generally more available now -- although I've
run into EL boxes where it mysteriously isn't present, so I suspect the
race to prune minimal sizes for containers may have resulted in its
exclusion in some groupings. One of the original use-cases for the
compression (and binary safety that it entails) was being able to take raw
sar output as a client section. There are a number of ways that could be
parsed, although I'm not certain whether there were large output-stability
changes in recent versions.

-jc


On Thu, September 19, 2019 7:53 pm, Jeremy Laidman wrote:

Would it be difficult to have the server-side linux parser look for
[ports]
and if not found, then look for [ss]; and similarly, [ifconfig] has
[ip-addr] as its fallback (assuming "ip addr show" gives similar output -
probably doesn't, but you get the idea)?

Minorly tangential, I think sar is more universally available these days
than when the client scripts were first created. So I'm wondering if we
should make better use of sar, perhaps even have a [sar] section of the
client message, that is the first place that xymond goes when looking for
statistics.

On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <user-87556346d4af@xymon.invalid>
wrote:

On 9/18/2019 8:05 AM, Zden??k Tlust?? wrote:

Hello,

the script xymonclient-linux.sh is using commands like ifconfig,
netstat, etc. These commands are marked as depreciated and some of the
Linux distributions have removed them already. For example SuSE Linux
Enterprise Server 15 has no support for netstat and ifconfig.
The replacement are commands from iproute2 package like ip, ss,
routel, etc.
Are there any plan to replace depreciated commands with new ones?

Especially with SS and IP, it's something that's on the road map.
Unfortunately, doing that in a backwards-compatible way will still
keeping the 'linux' OStype/class 'linux' might prove difficult without a
lot more text processing. (This flag is split on the receiving side for
parsing out what client evaluations to run and how, since the output of
SunOS, Linux, BSDs, and other *nixes can vary widely.)

One could either move current OS's to something like "linux-old", or
have upgraded scripts under "linux-new", or do a lot of 'awk' calls in
xymonclient-linux.sh to try to duplicate previous output more precisely.
I'm not sure which is better there.

Regards,
-jc