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! :)
- 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.
- 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