That is how I handle it now - ext script runs every 5m checking to see if change in database -- If change in database, write out alerts.cfg, analysis.cfg, hosts.cfg
--
Sean Clark Sr. Engineer, Software ATG Network Operations & Planning Integrated Regional OSS <http://www.twcable.com/DepartmentOverview/AdvancedTechnologyGroup/ATG/NOP/ OSS/Network.aspx> sean.clark at twcable.com <mailto:sean.clark at twcable.com> devaudio <aim://devaudio> <mailto:sean.clark at twcable.com> Cell: (315) 415-2816
On 6/14/12 2:22 AM, "Vernon Everett" <everett.vernon at gmail.com> wrote:
I hate to sound greedy, but is there a way to have the best of both worlds?
Assume a text config file that could be imported into a database table. This table could be re-exported from the table to text file.
Changes to the table, (edited via the GUI) trigger an export to text file. Changes detected in the text file are either automagically imported into the table, or will need to be manually imported into the database with an import tool. Haven't decided which is better yet, but I am leaning towards a manual import. Edit files, run cfg-import.
How to ensure simultanious edits are not occurring is left as an exercise for the reader :-) Right now, unless you use some form of version control, concurrent edits are possible anyway, so we would be no worse off.
The advantage of this system is that the configs done using the GUI will automatically be sanity checked. (I hope) In theory the GUI shouldn't allow a config change that is completely wrong. But, by importing the text file, into a database, the text file will need to be sanity checked, probably using the same routine, and will be rejected if it is obviously wrong too. And it satisfies the grey-beards and the click-monkeys. Two ways to edit. The best of both worlds.
Regards Vernon
On 14/06/2012, Henrik Størner <henrik at hswn.dk> wrote:
Hi,
in another mail thread, another monitoring tool (Zenoss) was mentioned which had the advantage of ³no hand editing of config files².
Text based config files have their ups and downs - they are infinitely flexible and can adapt to all sorts of weird ways of defining your setup, but it is also easier to "get it wrong" and put something in there which doesn't work. Even happens to me occasionally.
It's the age-old debate over whether something is "powerful" or "dangerous".
I am currently working on the next Xymon version (except I've been swamped with for-pay work the past couple of months ... and a hefty round of lay-offs in other departments than mine). This involves a complete rewrite of the network testing tool, and for this rewrite I've started using an SQLite database for storing some intermediate data used by the network tester, instead of keeping it in a bunch of temporary text-files.
And it has made me consider the idea of using a database for storing at least some of the configuration - first of all the hosts.cfg configuration of hosts, IP-adresses and network tests. This would make some things simpler, others a bit more complex - "xymongrep", for instance - but would also make it a lot easier to provide a GUI for managing what hosts are being monitored.
This is not going to happen anytime soon, but since the subject was up in the air - what do you think about it ? Is it a major problem that Xymon has all configuration in text files ? How many of you auto-generate the Xymon config by extracting the information from a database already ?
Just looking for some feedback...
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- "While it is futile to try to eliminate risk, and questionable to try to minimize it, it is essential that the risks taken be the right risks. "
- Peter F. Drucker
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.