On 11/09/2011 12:38 PM, Balazs Scheidler wrote:
Does this patch break the behavior described in the documentation for 3.3.1?
If an object is defined twice (for example the original syslog-ng configuration file and the file imported into this configuration file both define the same option, source, or other object), then the object that is defined later in the configuration file will be effective. For example, if you set a global option at the beginning of the configuration file, and later include a file that defines the same option with a different value, then the option defined in the imported file will be used.
If you cannot overload previously defined objects then the ability to include config files becomes FAR less useful imho.
uhm, uhm. Yes it does. I didn't know this was a documented feature :)
This could be controlled (possibly by a configuration variable), but before I do that could you explain your usecase, which makes include files to be less useful?
Well, the standard case for having includes would be for use in distribution packaging. Where syslog-ng would ship with a default configuration and would then do an include against a directory of files, a "conf.d" style setup. Later other packages could drop bits of configuration into conf.d. Lets say you install some theoretical log collection and parsing application via a distribution provided package. Previously when overloading was supported that new package could drop a config chunk which overloads a "log object" from the default config so that now instead of outputting to a file it outputs to a destination object defined in this new config. Actually I was assuming that not only would this behavior persist into future versions of syslog-ng but I had also hoped that it would be enhanced to allow for things like partial overloads or concatenation of existing object definitions such as is available in software such as nagios. Since there is no function by which later defined objects can interrogate the state of earlier objects nor is there any capability for conditional object definition (afaik) there is some inherint limitation to the complexity of the configs which could be generated still, but this would be a huge step forward in config flexibility. ------Separate but related thought ;) Speaking of which, it would be nice if there was some method of bundling objects together. So that for instance you could define:
source s_local { internal(); unix-dgram("/dev/log"); file("/proc/kmsg" program-override("kernel") flags(kernel)); }; source s_remote { syslog( transport("udp") so_rcvbuf(16777216) ); }; source s_everything { source(s_local) source(s_remote) ); };
I might be missing something, but afaict there is no easy method to do such a definition in the documentation. -Dave Rawks