Hello,
Syslog-ng 3.2 beta1 was released over the weekend. It has many interesting new features:
- modularized, so /usr is no more a problem - patternize - automatic pattern generation from logs - correlation - for more info see blogs - SCL - a config library to ease configuration generation
For a complete list of changes, see the lead developers blog: http://bazsi.blogs.balabit.com/2010/10/syslog-ng-ose-3-2beta1-released/ The final version of 3.2 will be released before openSUSE 11.4 feature freeze, so I'd like to update syslog-ng to 3.2.
Questions / problems:
- it is not yet a final version. Can I push it to factory (once some problems are solved), or I need to wait for the final release coming end of November?
- for database support, libdbi is needed. Currently it is available only in Contrib. Could it be imported to factory so database support could be enabled?
- I get one error and some warning messages regarding libraries. Could someone take a closer look at them and help me out?
- AppArmor: there are some new files and directories, which is an easy fix (see below). The problem is SCL, but also affects syslog-ng.conf, if someone wants to call an external application as log source or destination. I got some advice previously, but that did not help, calling external apps still does not work, only when disabling AppArmor completly. For now I don't use the new features from SCL to avoid this problem, but would be nice, if we could demo some easy steps to modify /etc/apparmor.d/sbin.syslog-ng than saying that if one needs to call external apps, then should disable AppArmor...
A working but not yet perfect version of syslog-ng 3.2 beta1 is available in the oBS: https://build.opensuse.org/package/show?package=syslog-ng32&project=home...
- it has glib fixes for factory (thanks go to cristian.rodriguez@opensuse.org) - ssl is enabled - no database support yet (libdbi is in contrib) - system() from SCL is not yet used due to AppArmor troubles - AppArmor needs some manual editing: --- sbin.syslog-ng.orig 2010-07-05 13:21:25.000000000 +0200 +++ sbin.syslog-ng 2010-09-29 10:09:51.001748203 +0200 @@ -36,9 +36,10 @@ /etc/hosts.deny r, /etc/hosts.allow r, /sbin/syslog-ng mr, + /usr/share/syslog-ng/** r, # chrooted applications @{CHROOT_BASE}/var/lib/*/dev/log w, - @{CHROOT_BASE}/var/lib/syslog-ng/syslog-ng.persist rw, + @{CHROOT_BASE}/var/lib/syslog-ng/syslog-ng.persist* rw, @{CHROOT_BASE}/var/log/** w, @{CHROOT_BASE}/var/run/syslog-ng.pid krw, @{CHROOT_BASE}/var/run/syslog-ng.ctl rw,
Please give it a try, let me know if you have any problems or fixes (sr :-) )! Bye,
On Wednesday 20 October 2010 11:55:24 Peter Czanik wrote:
- it is not yet a final version. Can I push it to factory (once some
problems are solved), or I need to wait for the final release coming end of November?
Hi,
You can push betas to factory, if: - you're certain you get a stable release before Milestone6 - the betas allow testing of both syslog-ng and the remaining system.
Greetings, Stephan
On 10/20/2010 08:43 PM, Stephan Kulow wrote:
On Wednesday 20 October 2010 11:55:24 Peter Czanik wrote:
- it is not yet a final version. Can I push it to factory (once some
problems are solved), or I need to wait for the final release coming end of November?
Hi,
You can push betas to factory, if:
- you're certain you get a stable release before Milestone6
It will be released right after Milestone4.
- the betas allow testing of both syslog-ng and the remaining system.
There is one thing holding me back: AppArmor. I did not get useful help on how to be able to run external apps from syslog-ng. But I'll most likely add a few minor fixes to /etc/apparmor.d/sbin.syslog-ng, and a README.SuSE explaining, that "to use program() data sources and/or destinations, or to use some features of SCL, one needs to disable AppArmor for syslog-ng". Default syslog-ng.conf can easily live without SCL, and program() is not used in the default config either. Bye,
On 2010-10-26 14:40:54 +0200, Peter Czanik wrote:
There is one thing holding me back: AppArmor. I did not get useful help on how to be able to run external apps from syslog-ng. But I'll most likely add a few minor fixes to /etc/apparmor.d/sbin.syslog-ng, and a README.SuSE explaining, that "to use program() data sources and/or destinations, or to use some features of SCL, one needs to disable AppArmor for syslog-ng". Default syslog-ng.conf can easily live without SCL, and program() is not used in the default config either.
IRC would give us a better roundtrip to fix the issue.
darix
Hello,
On 10/26/2010 06:17 PM, Marcus Rueckert wrote:
On 2010-10-26 14:40:54 +0200, Peter Czanik wrote:
There is one thing holding me back: AppArmor. I did not get useful help on how to be able to run external apps from syslog-ng. But I'll most likely add a few minor fixes to /etc/apparmor.d/sbin.syslog-ng, and a README.SuSE explaining, that "to use program() data sources and/or destinations, or to use some features of SCL, one needs to disable AppArmor for syslog-ng". Default syslog-ng.conf can easily live without SCL, and program() is not used in the default config either.
IRC would give us a better roundtrip to fix the issue.
OK. I prefere e-mail, but then I'll try to reach you on IRC tomorrow. Bye, CzP
Hello,
on Dienstag, 26. Oktober 2010, Peter Czanik wrote:
There is one thing holding me back: AppArmor. I did not get useful help on how to be able to run external apps from syslog-ng.
Did you test with the apparmor 2.5.1 packages from security:apparmor? (not sure if Jeff has submitted them to Factory already)
Assuming AppArmor works, you simply have to run aa-logprof and allow the additional permissions.
The hardcore method ;-) is to manually add the rules in /etc/apparmor.d/* (in case of executing an external application, you'll need *x (ix, Px etc.) rules) - that's doable, but nothing you should recommend to every user *g*
and a README.SuSE explaining, that "to use program() data sources and/or destinations, or to use some features of SCL, one needs to disable AppArmor for syslog-ng".
If you really do this, then please add a (temporary) BuildRequires: apparmor-utils = 2.3.1 so that you get an automatic reminder when the updated AppArmor packages are in Factory ;-)
Or just be optimistic and recommend to run "aa-logprof" to update the profile if someone wants to use program(). I'd say you should recommend to use child profiles (Cx) or external profiles (Px) so that the external programs get their own profile. Which of them is better depends if the program will/can be run standalone, and if it should be confined then. For example, a custom perl script to process the log entries is a candidate for Px, but you'll get very grey hair if you use Px for something like bash or sed - those are candidates for Cx.
Inherit (ix) isn't the best idea from the security point of view because then the called program has all permissions syslog-ng has. Also unconfined (Ux) is a bad idea because the program will not be restricted then.
Oh, and please recommend to always clean the environment... (that's Cx and Px, never use cx or px).
Hmm, that said - should we have some "AppArmor in 5 minutes" guide? The most important part would be "understanding the aa-logprof questions"... I know there's a full AppArmor manual (now part of the security manual), but that's probably too long to read for "just" updating a single profile.
Regards,
Christian Boltz
-
Christian Boltz -
Marcus Rueckert -
Peter Czanik -
Stephan Kulow