[syslog-ng]include file feature?

Ardo van Rangelrooij avrangelrooij@lucent.com
Thu, 14 Mar 2002 13:07:10 -0600


Ed Ravin wrote:
> Ardo van Rangelrooij writes:
> 
>>I've taken a different more flexible approach (based on what's become common 
>>practice in the Debian GNU/Linux distribution: I've created a directory called 
>>'syslog-ng.d' [...]
>>
>>Each sniplet has a name of '<digit><digit><sniplet nmae>' [...]
>>   cat syslog-ng.d/* >syslog-ng.conf
>>upon a start and reload.
>>
> 
> It's nice to be flexible, but I think the init.d paradigm, which
> relies on tricks of alphabetical filename sorting to enforce order
> at the expense of readability and managability, should be retired,
> not expanded.

If you're talking about managability the method I presented is favourable above 
changing a file just to add an #include statement.  I prefer not to have tools 
changing configuration files during package install/removal, unless there's a 
wrapper available that does that on behave of the package (like using `adduser` 
instead of accessing /etc/passwd directly).

> The joy of syslog-ng is that it has a clean, readable, and predictable
> configuration file.  An extension for reading in include files would
> hopefully preserve those attributes.

You've lost me.  If you use #include statetements your syslog-ng.conf could look 
  like this:

#include header
#include global_options
#include syslog-ng_internal
#include source_localhost
#include app_A_logging
#include app_B_logging

Wow, I'm impressed with the readability we just achieved.  If I do an `ls' in my 
syslog-ng.d directory I see more or less the same.

No matter which partitioning scheme we want to use, it all comes down to a 
proper organization of the configuration and keeping things together that 
belongs together.

I'm also in favour of adding functionality to syslog-ng which is already 
available in cpp, m4 and other similar tools.  I'm in favour of the UNIX style 
of small tools working together each doing it's own dedicated task.

And how far do you want to go?  Nested include's?  Why then not simply use cpp 
as a preprocessor?

Thanks,
Ardo