TS - Is there a DB frontend for Xymon maintenance?
list Tom Schmitt
Team,
Has anyone created a Database (MySQL) front-end to handle the HOSTS and
ALERTS information?
Thus, when finished, you extract all of the data from the tables in the
DB and re-create the HOSTS and/or ALERTS files.
And then you restart Xymon?
I have a need for multiple Admins to do ADD, CHANGE, DELETE requests to
the system but they cannot work on the files at the same time.
I have had to create a LOCK and UNLOCK (exclusive) while someone is
working on the files.
The NOTES files are individual files and are no problem as you probably
would not be working on someone else's NOTES files.
Thanks,
Tom Schmitt
Senior IT Staff - R&D
L-3 Communication Systems West
640 North 2200 West P.O. Box 16850
Salt Lake City, UT XXXXX
Phone (XXX) XXX-XXXX
Cell (XXX) XXX-XXXX
eFax (XXX) XXX-XXXX
\\\\||////
\ ~ ~ /
| @ @ |
--oOo---(_)---oOo--
Have A Nice Day !
list Henrik Størner
▸
On 31-01-2012 20:05, user-9c1ae820b621@xymon.invalid wrote:
Has anyone created a Database (MySQL) front-end to handle the HOSTS and ALERTS information? Thus, when finished, you extract all of the data from the tables in the DB and re-create the HOSTS and/or ALERTS files.
It would probably be a simple thing to do, but I haven't heard of any.
And then you restart Xymon?
Usually not required, and certainly not for changes to {hosts,alerts}.cfg
▸
I have a need for multiple Admins to do ADD, CHANGE, DELETE requests to the system but they cannot work on the files at the same time. I have had to create a LOCK and UNLOCK (exclusive) while someone is working on the files.
Isn't it possible to spread your configuration over multiple files ? In my experience, most admins only handle a limited number of hosts - in my setup hosts for a specific client - so by splitting up the hosts.cfg / alerts.cfg files into customer-specific "bits" you avoid the problem of multiple simultaneous updates. Apart from that, consider putting your configuration files under some sort of revision control system (CVS, Subversion, git, even plain old RCS if you must). The newer ones are quite good at managing multiple updates to a shared set of files. I am not saying that using a DB backend for - at least - the hosts.cfg information is a bad idea; in fact, I am considering this for the next version. I just want to point out that there may be less "fancy" - but usable - solutions to this specific problem. Regards, Henrik
list Paul Root
We just use RCS on the files. Paul Root - Senior Engineer Managed Services Systems - CenturyLink
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Tuesday, January 31, 2012 3:02 PM To: xymon at xymon.com Subject: Re: [Xymon] TS - Is there a DB frontend for Xymon maintenance?
▸
On 31-01-2012 20:05, user-9c1ae820b621@xymon.invalid wrote:Has anyone created a Database (MySQL) front-end to handle the HOSTS and ALERTS information? Thus, when finished, you extract all of the data from the tables in the DB and re-create the HOSTS and/or ALERTS files.It would probably be a simple thing to do, but I haven't heard of any.And then you restart Xymon?Usually not required, and certainly not for changes to {hosts,alerts}.cfgI have a need for multiple Admins to do ADD, CHANGE, DELETE requests to the system but they cannot work on the files at the same time. I have had to create a LOCK and UNLOCK (exclusive) while someone is working on the files.Isn't it possible to spread your configuration over multiple files ? In my experience, most admins only handle a limited number of hosts - in my setup hosts for a specific client - so by splitting up the hosts.cfg / alerts.cfg files into customer-specific "bits" you avoid the problem of multiple simultaneous updates. Apart from that, consider putting your configuration files under some sort of revision control system (CVS, Subversion, git, even plain old RCS if you must). The newer ones are quite good at managing multiple updates to a shared set of files. I am not saying that using a DB backend for - at least - the hosts.cfg information is a bad idea; in fact, I am considering this for the next version. I just want to point out that there may be less "fancy" - but usable - solutions to this specific problem. Regards, Henrik
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
list Erik
In our enviornment, we use SVN. We committed the servers/etcdirectory to an SVN repository. Admins check out the files, make their edits, then commit them back to the repository. They then go to the Xymon server to do an "svn update". It makes the process a bit more cumbersome, to be sure, but has done a great job of keeping us from clobbering each others edits. SVN makes merging changes much easier.