I've just pushed a round of updates to the syslog-ng 3.2 repository, featuring some interesting stuff, such as:
Error parsing plugin unix-stream, syntax error in etc/syslog-ng-null.conf at line 3, column 34:
source s_log { unix-stream("log" default-facilitz(syslog)); };
^^^^^^^^^^^^^^^^
Neat, eh?
One more thing I need to think about is how to configure module loading. I guess it'd be less than user friendly if I'd rely on the user to load the modules that so far were the core functionality of syslog-ng.
E.g. right now if you want udp() support, you'd need something like this in the syslog-ng.conf header:
@module: afsocket
Having to remember all the module names is cumbersome and irritating. On the other hand I'd like to make it possible to run a bare-bones syslog-ng without socket support, so autoloading modules without any configurability is also out of the question.
In the current implementation syslog-ng automatically loads core modules, if the configuration version is below 3.2, and does nothing if it is 3.2 (e.g. you need an explicit @module directive for the current configuration format).
If you have an idea about how you think configuring modules should look like, just drop me an email/comment.
- SQL reorganization: Patrick Hemmer sent in a patch to implement explicit transaction support instead of the previous auto-commit mode used by syslog-ng. I threw in some fixes and refactored the code somewhat.
- Configuration parser changes: the syntax errors produced by syslog-ng became much more user-friendly: not only the column is displayed, but also the erroneous line is printed and the error location is also highlighted.
- Additional plugin modules were created: afsql for the SQL destination, and afstreams for Solaris STREAMS devices. Creating a new plugin from core code takes about 15 minutes. I'm quite satisfied. With the addition of these two modules, it is now possible to use syslog-ng without any kind of runtime dependency except libc.
- The already existing afsocket module (providing tcp/udp sources & destinations) is compiled twice: once with and once without SSL support, so it is now possible to choose which one to use at runtime.
Error parsing plugin unix-stream, syntax error in etc/syslog-ng-null.conf at line 3, column 34:
source s_log { unix-stream("log" default-facilitz(syslog)); };
^^^^^^^^^^^^^^^^
Neat, eh?
One more thing I need to think about is how to configure module loading. I guess it'd be less than user friendly if I'd rely on the user to load the modules that so far were the core functionality of syslog-ng.
E.g. right now if you want udp() support, you'd need something like this in the syslog-ng.conf header:
@module: afsocket
Having to remember all the module names is cumbersome and irritating. On the other hand I'd like to make it possible to run a bare-bones syslog-ng without socket support, so autoloading modules without any configurability is also out of the question.
In the current implementation syslog-ng automatically loads core modules, if the configuration version is below 3.2, and does nothing if it is 3.2 (e.g. you need an explicit @module directive for the current configuration format).
If you have an idea about how you think configuring modules should look like, just drop me an email/comment.
Comments
@module: afsocket
way.
One possible way is to introduce versions for the config settings
allowing some tricks with default values.
Another possibility would be to make it possible that e.g. udp()
triggers module loading, but this makes the parser step complex
I think.
There are global options hat have to be at the begin of the config
anyway. It would be also possible to add an "autoload on/off" flag
causing to load all available modules or not (and a "compatibility"
flag specifying the version to be compatible with).
syslog-ng-3.x could change to use syslog-ng.conf with a default of
autoload=off in version 3.x and when the (compatibility version) is
not set, it assumes to run in compatibility mode to the oldest
supported version where autoload=on is used by default.
Les complex, would be to just assume:
autoload not specified => autoload=on + warning [compat mode]
Default "dist" config makes use of autoload=off.
More important here is IMO, that there are (optionally) two paths,
where the modules can be installed:
/lib[64]/syslog-ng and /usr/lib[64]/syslog-ng
The second is required to make it possible to run syslog-ng on
systems with iscsi/nfs-root. It is not possible to install any
binary or library in /lib when it has link dependencies to libs
in /usr (e.g. database drivers).
At early boot time, syslo-ng is started with syslog-ng-early.conf;
When /usr is available, syslog-ng can be reloaded or even restarted
(using a different config path) to use the full blown config.
The early version could log into some persistent store, where the
full blown one pickups the logs later at start time.
I'm still making a couple of changes to the configuration parser to make it easier to use and after that I'm going to work on the plugin loading functionality again.
So, for example, you might have something like:
@module: CORE
That would load a set of core modules matching what most people would expect (probably based on feature availability from previous releases of Syslog-NG).
1) if the autoload-compiled-modules global variable is "1" (the default), then all compile-time-enabled modules will be loaded automatically.
2) I've added default configuration files, which ships a "modules.conf" file included into the main config, which explicitly loads modules. This config file can then be customized.
I have a lot of changes in the git tree, but didn't get to blog about it yet. However there are really important changes there.