"msgs" alerts, sending 10240 bytes and line-buffering 🔗 link

I'm having an issue on my Solaris clients running an older Xymon 4.3.12.
(I have a test build of 4.3.21 waiting in the wings.)

We constantly get scanned by our IT Security people, resulting in
"/var/adm/messages" entries like

Aug 24 09:23:39 myorgsun6 nrpe[15035]: [ID 808958 daemon.warning] refused \
connect from itsecurity-scanner.my.do.main (access denied)

I put an IGNORE entry into "analysis.cfg" to ignore any lines with
"itsecurity-scanner.my.do.main" but I keep getting them - they often look
like this:

--
red Mon Aug 24 09:55:37 PDT 2015 - Log files NOT ok

&red Critical entries in <a href="/xymon-cgi/svcstatus.sh?CLIENT=myorgsun6&amp;SECTION=msgs:/var/adm/messages">/var/adm/messages</a>
&red ess denied)
--

As you can see the "messages" entry has been clipped off leading to the
raw "denied" string which triggered the alert.  It's random - sometimes
it's clipped down to "do.main access denied", for example.

I'm using a bog-standard

[sunos]
log:/var/adm/messages:10240

entry in client-local.cfg.

My theory is that by sending 10240 bytes of the "messages" file across,
it leaves things open to the possibility of sending "clipped" lines -
leading to partial lines that avoid my IGNORE string as a result.

Am I correct?

Is there anything in the newer releases that addresses this?

	- Greg

Greg

You might be right that the message is being clipped.  If so, you should
see Xymon log messages to that effect.

Perhaps add the IGNORE clause to the client-local.cfg message instead.
This will cause the messages to be dropped at the client side.  Not only
can you forget about these messages on the Xymon server, but also you're
less likely to have a clipped message.  Like so:

[sunos]
log:/var/adm/messages:10240
ignore refused connect from itsecurity-scanner.my.do.main

You could also increase the maximum from 10240.

Cheers
Jeremy

On 25 August 2015 at 08:11, Greg Earle <user-8f45ae7a27f3@xymon.invalid> wrote:

Thanks Jeremy, where in the logs exactly?  Do I grep for "clipped"?  :-)

Excellent idea - hadn't thought of th... wait, hang on.  The only place I
have a "client-local.cfg" file is on my *server*, not on any of my clients.

Ummm, actually this file is only supposed to exist on the server, and
when the client connects to report the status, it will also download a
copy of it's (section) of the file and apply that for future status updates.

Note: I forget the details, but it can take 15 minutes (3 cycles) before
you will see the changes applied/working.

Thanks for clarifying that, Adam.  I removed the client-side "client-local.cfg"
file and made the suggested changes on the server-side.  The incidents of
"clipped" messages file text causing red alert triggers have lessened, but I'm
not sure they've stopped entirely.

Do I need to restart all of my Solaris clients to pick up this (server-side)
change?  (viz. "it will also download a copy of it's (section) of the file
and apply that for future status updates")

	- Greg

On 28/08/15 10:00, Greg Earle wrote:

No need to restart the client, but you will need to ensure the section 
you added it to will apply to all the clients you are expecting. Since 
the server only returns the relevant section to the client, who might be 
using a different section compared to what you expected..... It should 
take between 10 minutes and 30 minutes for the change to be applied, if 
it is taking longer, then something is wrong with the config.

Regards,
Adam

-- 
Adam Goryachev Website Managers www.websitemanagers.com.au

On 28 August 2015 at 10:00, Greg Earle <user-8f45ae7a27f3@xymon.invalid> wrote:

No restart required.  Each time a client connects to the Xymon server and
sends its client data, the server then sends the relevant section in
client-local.cfg, and this gets stored on the client in XYMONTMP (typically
~xymon/client/tmp/) in a file called logfetch.$MACHINEDOTS.cfg.  Have a
look for this file, check its contents, and see if it's what you configured
in client-local.cfg.  In particular, look for the 10240 value for the
"log:" line having being changed, and also any "ignore" qualifier lines
you've configured.

As you probably know, the Xymon client runs every 5 minutes.  Because the
logfetch.*.cfg file is fetched during the client data reporting run, it can
take up to 5 minutes for this file to reflect the relevant section in
client-local.cfg on the server.  This newly fetched file will be actioned
on the next client data reporting run, which is 5 minutes later.  So
changes on the server will be made manifest from 5 to 10 minutes later.

Cheers
Jeremy