Hi, I'm looking in to using syslog-ng as a syslog-sink for a number of nodes, but am concerned that the configuration file may become somewhat cluttered and unwieldy. Is there any way to have syslog-ng read it's configuration information in the increasingly popular "everything in this directory is a configuration file to be read" manner? The examples I'm thinking of include xinetd and logrotate... It would be useful to have all of the host-specific filters, destinations and sources all in one file, but only for that host in question, rather than having to build what could eventually be a very large single file. Thanks. Scott
Scott A. McIntyre on Fri, Jan 05, 2001 at 09:13:37AM +0100: Hi,
Is there any way to have syslog-ng read it's configuration information in the increasingly popular "everything in this directory is a configuration file to be read" manner? The examples I'm thinking of include xinetd and logrotate...
I didn't realize this was increasingly popular ;)
It would be useful to have all of the host-specific filters, destinations and sources all in one file, but only for that host in question, rather than having to build what could eventually be a very large single file.
I would prefer "include" directives as opposed to the directory thing. What if you edit a file in this directory and restart syslog-ng while the editor keeps a backup-copy in the same place? How do you handle backup copies of configuration that you change? I usually create "configfile.YYYYMMDD" in the same directory. :) What I usually do when I work with software that doesn't support including and yet has a huge configuration, is to write a little Make- file with a default target that does whatever needs to be done to concatenate my set of config files. For some things, I even abuse the gcc C preprocessor. If the application supports it, you could also have a "test" target that starts the app with a config check option. In particular, if you have a seperate directory for each of your daemons, you can put Makefile, includes, maybe some README and the actual config file (plus above mentioned backup copies) in the same place. Real includes would be slightly better, but this works very well for many applications. Regards, Gregor. -- Gregor Binder <gbinder@sysfive.com> http://www.sysfive.com/~gbinder/ sysfive.com GmbH UNIX. Networking. Security. Applications. Gaertnerstrasse 125b, 20253 Hamburg, Germany TEL +49-40-63647482
Also sprach Gregor Binder (gbinder@sysfive.com):
configuration file to be read" manner? The examples I'm thinking of include xinetd and logrotate...
I didn't realize this was increasingly popular ;)
Ah, well, not necessarily with users so much as Certain Operating Systems and Developers Of Packages For Them. ;-)
I would prefer "include" directives as opposed to the directory thing.
That would certainly work just as well, if not better. The accomplished goal is essentially the same. My frustration at using syslog-ng for this in the past is that I had a very large and complicated series of filters and destinations and I found that it was difficult to automate the addition of new datasources as the order-dependence of things could cause problems.
What I usually do when I work with software that doesn't support including and yet has a huge configuration, is to write a little Make- file with a default target that does whatever needs to be done to
Yes, that is what I've been doing in certain circumstances as well. The downside is that you begin to have a lot of multi-tool dependence and if one of those tools breaks, or gets tweaked/modified, well, a much more important (and potentially complicated) system fails behind it. I generally try to avoid the band-aid upon band-aid upon perl-script upon band-aid solution for this reason. Having said that, my *real* preference here is that the config file be in XML. :-) That would sort out a lot of problems from my point of view. I may end up just doing this anyway and using some XSLT to create the syslog-ng.conf. Thanks for the ideas! Scott
participants (2)
-
Gregor Binder
-
Scott A. McIntyre