[syslog-ng] syslog-ng-stable RPM repo

[Evan Rempel]

The stable repository is a great addition to the syslog-ng community, 
however, it introduces a new challenge with staying up to date.

I'm wondering if anyone else has experienced the same challenges, and 
how they have addressed them.
Also, if anyone has anything else to add to this I would like to hear it.

The issue is that the configuration file /etc/syslog-ng/syslog-ng.conf  
contains an exact version statement "@version:3.22"
If I have a system that is using the stable repo, it will get the next 
release automatically, but the configuration file will not get
updated automatically, and the @version number in the configuration file 
will no longer match the version of syslog-ng that is being used.

To overcome this I think that the file /etc/syslog-ng/syslog-ng.conf 
should NOT be marked as a configuration file in the RPM. This way it will
always be replaced with the new one when the package is upgraded. This 
introduces the challenge of how does a customer create custom 
configurations.

I propose that the /etc/syslog-ng/syslog-ng.conf file should only be of 
the form

@version:3.22
@include "scl.conf"
@include "/etc/syslog-ng/conf.d/*.conf"

and that the contents of the current /etc/syslog-ng/syslog-ng.conf file 
be moved to /etc/syslog-ng/conf.d/default.conf
and that this file be marked in the RPM as a configuration file so that 
it is NOT replaced by the RPM upgrade process.

At a minimum I think this is required to create a sustainable upgrade 
process. In the event that there is a backwards incompatibility in the
configuration, you would have to bump the name of the syslog-ng package 
to syslog-ng4 to stop the automatic upgrades, and bump the version to 4.0.

I think that the above is absolutely needed, but I would also like you 
to consider a change to the include order. I have come across situations
where I need to define all of the templates first, then define the 
destinations etc. To allow a conf.d style inclusion of this order dependent
configurations I have added the following include list to my top level 
syslog-ng configuration.

@include 'conf.d/*.option'
@include 'conf.d/*.template'
@include 'conf.d/*.source'
@include 'conf.d/*.destination'
@include 'conf.d/*.filter'
@include 'conf.d/*.rewrite'
@include 'conf.d/*.log.final'
@include 'conf.d/*.log'
@include "conf.d/*.conf"

The last one is for backwards compatibility.

This way I can define all of the global options first, then the 
templates, then the sources, then the destinations ... etc.
This allows for automated deploy tools such as puppet or ansible to drop 
appropriate snippets into the conf.d and get them loaded in the correct 
order.