[Xymon] Two basic questions

[Michael Short]

Thanks Phil, I can try that.  Question -- do you find after patching a server that the syslog-ng config needs to be updated again?  I've found that if sendmail gets updated on my machines, the *.cf files get replaced with the generic. I have to make backups first.  Just wondering if the same is necessary for syslog-ng/

thanks!


-----Original Message-----
From: Phil Crooker [mailto:Phil.Crooker at orix.com.au] 
Sent: Thursday, July 16, 2015 4:59 PM
To: Michael Short
Cc: xymon at xymon.com
Subject: RE: [Xymon] Two basic questions

Yes, welcome. I moved from BB some years ago, xymon not only fills in many gaps BB hadn't covered, it is organised much better and a lot quicker. No more MPEs (massive purple explosions).

On your second point on reading log files, I normally chgrp the files of interest to the xymon group (if nothing else needs to read it) and keep it read-only of course. I found it was syslog-ng in my flavour of linux (suse) that maintains file ownership, so I add (for example):

    destination messages { file("/var/log/messages" group(xymon)); };

for when the log files are rotated.

cheers, Phil

________________________________________
From: Xymon <xymon-bounces at xymon.com> on behalf of J.C. Cleaver <cleaver at terabithia.org>
Sent: Friday, 17 July 2015 8:50 AM
To: Michael Short
Cc: xymon at xymon.com
Subject: Re: [Xymon] Two basic questions

On Thu, July 16, 2015 2:56 pm, Michael Short wrote:
> Hello All,
>
> I'm a new subscriber, moving from an old BB setup to Xymon. I had two
> questions that I hadn't been able to find the answer to.

Welcome! :)


>
> 1)  How do you setup an external script to run only on certain hosts?  I
> didn't see anything like the bb-bbexttab file.  It seems if a script isn't
> present in the $XYMHOME/ext/ directory, it can't run.  But that's not as
> clean a solution; makes it had to have one set of files to push to all
> clients.  So what's the preferred method?

On the client side, you'll want to modify the clientlaunch.cfg file.
Depending on your distribution/package, this may also automatically
include a directory like /etc/xymon-client/client.d/

Those files (similar to the tasks.cfg file server-side) can contain
'ONHOST' directives within given stanzas (which can be regexes) to control
task running on a per-server basis.

One note is that a non-matching 'onhost' line simply disables the tasks.
xymonlaunch will still need all [tasks] it sees to be unique, even the
disabled ones.

If you have puppet or some other sort of config management, it may be
simplest just to deploy client.d/* files on the servers you want to run
the code on and not on the others.

There's nothing special or automatic about the 'ext' directory itself;
it's simply a useful place to put things.

>
> 2) How do you read system logfiles on Linux hosts, when the files are
> root-only and the monitoring runs as user xymon?  This is for Red Hat
> systems, where things like /var/log/messages are perm 700. I could set the
> perms to 744, but that's likely to get changed back when the logs rotate
> or the systems is patched.  Do you run Xymon as root user on Linux
> systems? I didn't think so, or the install instructions wouldn't have you
> create a xymon user and group. So is there a better way?


xymon runs as an unprivileged user, so log file monitoring should be
considered in that regards. Depending on your OS and release, adding a
read facl for the xymon user might survive a rotation (RHEL6 does this,
EL5 doesn't). You could also chmod it 640, give it a group of 'adm', and
add the xymon user to that group, or provide another means of reading it.

One thing you'll definitely not want to do is make the logfetch program
itself setuid. Its config of what files to look at is returned from the
server, so you don't want to elevate it beyond the normal user account.


HTH,

-jc


_______________________________________________
Xymon mailing list
Xymon at xymon.com
http://lists.xymon.com/mailman/listinfo/xymon
-- 

This message from ORIX Australia might contain confidential and/or
privileged information. If you are not the intended recipient, any use,
disclosure or copying of this message (or of any attachments to it) is
not authorised.

If you have received this message in error, please notify the sender
immediately and delete the message and any attachments from your
system. Please inform the sender if you do not wish to receive future
communications by email.

The ORIX Australia Privacy Policy outlines what kinds of personal 
information we collect and hold, how we collect and handle it and your 
rights in regards to your personal information. Our Privacy Policy is 
available on our website: http://www.orix.com.au .

We do not accept liability for any loss or damage caused by any computer 
viruses or defects that may be transmitted with this message. We 
recommend you carry out your own checks for viruses or defects.

****************************************************************************************** 
This message may contain confidential or proprietary information intended only for the use of the 
addressee(s) named above or may contain information that is legally privileged. If you are 
not the intended addressee, or the person responsible for delivering it to the intended addressee, 
you are hereby notified that reading, disseminating, distributing or copying this message is strictly 
prohibited. If you have received this message by mistake, please immediately notify us by  
replying to the message and delete the original message and any copies immediately thereafter. 

Thank you. 
****************************************************************************************** 
CLLD