changing the default syslog daemon for lenny?
Holger Levsen
Debian Edu will be switching its syslog for Lenny and as we want to differ the
least possible from Debian, we are wondering, what the default syslog will be
in Lenny.
The main reason is that we need/want to configure syslogd via debconf (or any
other policy complient way) for remote logging and the sysklogd maintainer
doesn't want to provide it. See #370339 for details.
So we decided to switch to syslog-ng for now.
On the #debian-release channel some people claimed, that syslog-ng is not a
drop-in replacement, while other said so. I don't know :) Please explain
here. Other options would be rsyslog (which Fedora is using, see
http://fedoraproject.org/wiki/Releases/FeatureRsyslog) or msyslog.
Obviously Debian could also continue to use sysklogd.
Oh, and btw, I suggest to change the default for new installations and to keep
whatever is installed on upgrades to Lenny.
regards,
Holger
Joerg Jaspert
> So we decided to switch to syslog-ng for now.
> On the #debian-release channel some people claimed, that syslog-ng is not a
> drop-in replacement, while other said so. I don't know :) Please explain
> here. Other options would be rsyslog (which Fedora is using, see
> http://fedoraproject.org/wiki/Releases/FeatureRsyslog) or msyslog.
It is a dropin replacement with the config that the package delivers in
Debian.
Of course using syslog-ng means you can take some more advantages
compared to the old sysklogd - like automated logrotating.
http://ganneff.de/syslog-ng.conf is an (old) config from me for that,
which simply keeps logs in a host/year/month/day structure.
It also has a nice set of filters and stuff, can do tcp and not only
udp, and lots more.
It is to be preferred over the sysklogd thing for a long time already.
*IMO*
JFTR - i dont care if the future default is rsyslog or syslog-ng or yet
another one, as long as its better than sysklogd... (I install my
favorite anyways, so......)
--
bye Joerg
<snooze02> sind jabber und icq 2 unterschiedliche netzwerke ?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
> On 11278 March 1977, Holger Levsen wrote:
>
>> So we decided to switch to syslog-ng for now.
>
>> On the #debian-release channel some people claimed, that syslog-ng is not a
>> drop-in replacement, while other said so. I don't know :) Please explain
>> here. Other options would be rsyslog (which Fedora is using, see
>> http://fedoraproject.org/wiki/Releases/FeatureRsyslog) or msyslog.
>
> It is a dropin replacement with the config that the package delivers in
> Debian.
rsyslog is also a drop in replacement, even more so, as it can
understand the syntax of sysklogd. The default rsyslog config file
/etc/rsyslog.conf is basically a copy of /etc/syslog.conf.
So if you have a custom syslog.conf, you could either copy it to
/etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf.
rsyslog also allows to include other config files. The default
/etc/rsyslog.conf is setup to include all files in /etc/rsyslog.d/*.conf.
This easily allows for other packages to add custom configuration very
easily.
> Of course using syslog-ng means you can take some more advantages
> compared to the old sysklogd - like automated logrotating.
> http://ganneff.de/syslog-ng.conf is an (old) config from me for that,
> which simply keeps logs in a host/year/month/day structure.
> It also has a nice set of filters and stuff, can do tcp and not only
> udp, and lots more.
rsyslog has all these features, too (and many more). It even offers
support for logging into MySQL and PostgreSQL databases, which only the
commercial syslog-ng branch has.
Support for these is in two separate packages rsyslog-mysql and
rsyslog-pgsql. These two packages use the dbconfig-common framework to
setup the database and automatically create config files for
/etc/rsyslog.d/, so you can get up and running really quick and hassle free.
A real plus is also upstream, who is very responsive and active and it's
a pleasure to work with him.
As maintainer of rsyslog, I'd really like to see rsyslog become the
default for lenny and I think it would be a very good choice.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
William Pitcock
I agree with this. Additionally, Balasz Schielder (Balabit) makes people
who contribute to syslog-ng sign a contributory license agreement [1],
so that they can be included in syslog-ng premium, which is in my view
against the whole purpose of open source. If you disagree with signing
the CLA, your patch is rejected. As such, I feel that syslog-ng is not a
good choice for the default syslogd in Debian.
rsyslog upstream have a fairly good reputation of being cooperative and
generally good to work with, at least from what i have observed.
William
Francesco P. Lovergine
>
> I agree with this. Additionally, Balasz Schielder (Balabit) makes people
> who contribute to syslog-ng sign a contributory license agreement [1],
> so that they can be included in syslog-ng premium, which is in my view
> against the whole purpose of open source. If you disagree with signing
> the CLA, your patch is rejected. As such, I feel that syslog-ng is not a
> good choice for the default syslogd in Debian.
>
> rsyslog upstream have a fairly good reputation of being cooperative and
> generally good to work with, at least from what i have observed.
>
What about first hand experiences with them in heavy-load production
environments? Stability, etc.
--
Francesco P. Lovergine
Javier Fernandez-Sanguino
> The main reason is that we need/want to configure syslogd via debconf (or any
> other policy complient way) for remote logging and the sysklogd maintainer
> doesn't want to provide it. See #370339 for details.
I find it surprising that the maintainer himself has not pronounced
his standing on the issue. The only reference to the maintainer is a
cut & paste note from an IRC log which might or might not be true.
The maintainer hasn't even tagged this issue (which is open for almost
2 years) as 'wontfix'. (!)
Regards
Javier
Holger Levsen
On Monday 28 January 2008 10:51, Javier Fernandez-Sanguino wrote:
> 2008/1/28, Holger Levsen <hol...@layer-acht.org>:
> > The main reason is that we need/want to configure syslogd via debconf (or
> > any other policy complient way) for remote logging and the sysklogd
> > maintainer doesn't want to provide it. See #370339 for details.
> I find it surprising that the maintainer himself has not pronounced
> his standing on the issue. The only reference to the maintainer is a
> cut & paste note from an IRC log which might or might not be true.
>
> The maintainer hasn't even tagged this issue (which is open for almost
> 2 years) as 'wontfix'. (!)
I agree that this bug should be tagged "wontfix", but I leave it to the
maintainer to do it.
But I have no reason not to believe the maintainer handles this bug
as "wontfix", no (self-written) reply to the bug by him states this pretty
well.
CC:ed Joey, so he can comment.
regards,
Holger
Patrick Winnertz
> rsyslog is also a drop in replacement, even more so, as it can
> understand the syntax of sysklogd. The default rsyslog config file
> /etc/rsyslog.conf is basically a copy of /etc/syslog.conf.
> So if you have a custom syslog.conf, you could either copy it to
> /etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf.
>
> rsyslog also allows to include other config files. The default
> /etc/rsyslog.conf is setup to include all files in
> /etc/rsyslog.d/*.conf.
rsyslog without touching configuration files in postinst scripts of other
packages is really important for some other Debian releated Groups (e.g.
Debian Edu).
Greetings
Patrick Winnertz
--
.''`. Patrick Winnertz <win...@debian.org>
: :' : GNU/Linux Debian Developer
`. `'` http://www.der-winnie.de http://d.skolelinux.org/~winnie
`- Debian - when you have better things to do than fixing systems
Russ Allbery
> Debian Edu will be switching its syslog for Lenny and as we want to
> differ the least possible from Debian, we are wondering, what the
> default syslog will be in Lenny.
>
> The main reason is that we need/want to configure syslogd via debconf
> (or any other policy complient way) for remote logging and the sysklogd
> maintainer doesn't want to provide it. See #370339 for details.
>
> So we decided to switch to syslog-ng for now.
It sounds like there are other reasons to switch to syslog-ng or rsyslog
for Debian as well (and I certainly understand why Debian Edu switched).
I just wanted to note somewhere in this thread that if the problem were
just this single packaging feature (which I know is not actually the
case), that by itself isn't a reason to switch default syslog daemons.
Another possible course of action would be to appeal the maintainer's
decision to the Technical Committee.
Of course, since other syslog implementations are potentially better in
larger ways, there may still be good reason to switch the default syslog
to another implementation. We're using syslog-ng for some hosts at
Stanford because the configuration language just lets you do more stuff
that sysklogd doesn't.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Michael Biebl
> Am Montag, 28. Januar 2008 01:55:23 schrieb Michael Biebl:
>> rsyslog is also a drop in replacement, even more so, as it can
>> understand the syntax of sysklogd. The default rsyslog config file
>> /etc/rsyslog.conf is basically a copy of /etc/syslog.conf.
>> So if you have a custom syslog.conf, you could either copy it to
>> /etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf.
>>
>> rsyslog also allows to include other config files. The default
>> /etc/rsyslog.conf is setup to include all files in
>> /etc/rsyslog.d/*.conf.
> I would go also for rsyslog. The feature to add configuration files to
> rsyslog without touching configuration files in postinst scripts of other
> packages is really important for some other Debian releated Groups (e.g.
> Debian Edu).
>
As a (simple) example:
If you want to filter out the messages of e.g. NetworkManager into a
separate logfile, just drop a file networkmanager.conf into
/etc/rsyslog.d, containing the line
:programname, contains, "NetworkManager" -/var/log/NetworkManager.log
Packages could ship such files themselves, which would allow for more
fine-grained logging. rsyslog allows to filter based on a lot more
properties (and also regexps) [1][2].
Cheers,
Michael
[1] http://www.rsyslog.com/module-Static_Docs-view-f-rsyslog_conf.html.phtml
[2]
http://www.rsyslog.com/module-Static_Docs-view-f-property_replacer.html.phtml
Holger Levsen
On Tuesday 29 January 2008 00:55, Russ Allbery wrote:
> Of course, since other syslog implementations are potentially better in
> larger ways, there may still be good reason to switch the default syslog
> to another implementation.
It seems to me that everybody replied in favor to this idea and nobody replied
suggesting to keep sysklogd the default. Which leads me to believe it should
be done :-)
I just wonder how... anyone?
regards,
Holger, who also agrees with http://blog.technologeek.org/2008/01/29/92
Raphael Hertzog
> Hi,
>
> On Tuesday 29 January 2008 00:55, Russ Allbery wrote:
> > Of course, since other syslog implementations are potentially better in
> > larger ways, there may still be good reason to switch the default syslog
> > to another implementation.
>
> It seems to me that everybody replied in favor to this idea and nobody replied
> suggesting to keep sysklogd the default. Which leads me to believe it should
> be done :-)
>
> I just wonder how... anyone?
- Check the consequences of the change (what about tools that rely on
/usr/sbin/syslog-facility or /usr/sbin/syslogd-listfiles ?), file bug on
packages that depend on sysklogd because of that
- Involve the rsyslog maintainer in the work
- Document the change by preparing a patch for the release notes
- Get the priorities fixed by a ftpmaster (assistant)
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Marc Haber
<hol...@layer-acht.org> wrote:
>It seems to me that everybody replied in favor to this idea and nobody replied
>suggesting to keep sysklogd the default. Which leads me to believe it should
>be done :-)
Please, do change away from sysklogd. sysklogd in itself is not bad,
but the package has been nearly fully unmaintained for years.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Michael Biebl
> On Wed, 30 Jan 2008, Holger Levsen wrote:
>> Hi,
>>
>> On Tuesday 29 January 2008 00:55, Russ Allbery wrote:
>>> Of course, since other syslog implementations are potentially better in
>>> larger ways, there may still be good reason to switch the default syslog
>>> to another implementation.
>> It seems to me that everybody replied in favor to this idea and nobody replied
>> suggesting to keep sysklogd the default. Which leads me to believe it should
>> be done :-)
>>
>> I just wonder how... anyone?
>
> - Check the consequences of the change (what about tools that rely on
> /usr/sbin/syslog-facility or /usr/sbin/syslogd-listfiles ?), file bug on
> packages that depend on sysklogd because of that
Ok, here we go...
rsylogd provides linux-kernel-log-daemon and system-log-daemon, so it
replaces both klogd and sysklogd. The only package depending on klogd is
sysklogd, so there is no problem here. For system-log-daemon I analyzed
the packages depending on it:
Suggests:
1.) xwatch: sysklogd
Besides a small example config file, there is nothing syklogd
specific in this package.
Should be changed to $default_syslog | system-log-daemon
2.) jffnms: syslog-ng
Nothing syslog-ng specific in this package. Should be changed to
$preferred_syslog | system-log-daemon
Recommends:
3.) anacron: sysklogd | system-log-daemon
4.) fcron: sysklogd | system-log-daemon
5.) heartbeat: sysklogd | syslog-ng | system-log-daemon
6.) ldirectord: sysklogd | syslog-ng
Should be changed to $preferred_syslog | system-log-daemon
7.) nullmailer: sysklogd | system-log-daemon
8.) rlinetd: sysklogd | system-log-daemon
9.) xinetd: sysklogd | system-log-daemon
Depends:
10.) alamin-client: sysklogd | system-log-daemon
11.) alamin-mysql: sysklogd | system-log-daemon
12.) alamin-server: sysklogd | system-log-daemon
Uses syslog-facility in postinst/prerm. install will not fail if
syslog-facility is not present.
Easy to use a fixed syslog-facility or even better provide a
rsyslog.d snippet.
13.) alamin-smpp: sysklogd | system-log-daemon
14.) fwlogwatch: sysklogd | system-log-daemon
15.) inetutils-ftpd: inetutils-syslogd | system-log-daemon
16.) inetutils-inetd: inetutils-syslogd | system-log-daemon
17.) inetutils-talkd: inetutils-syslogd | system-log-daemon
18.) inetutils-telnetd: inetutils-syslogd | system-log-daemon
19.) klogd: sysklogd | system-log-daemon
20.) logcheck: sysklogd | system-log-daemon | syslog-ng
Has used syslogd-listfiles in postinst, was removed again 2002
21.) psad: syslogd | syslog-ng | metalog
Should be changed to $preferred_syslog | system-log-daemon
22.) request-tracker3.6: sysklogd | system-log-daemon
23.) snort: sysklogd | system-log-daemon
Has used syslogd-listfiles years again, was removed again
24.) snort-common: sysklogd | system-log-daemon
25.) snort-mysql: sysklogd | system-log-daemon
26.) snort-pgsql: sysklogd | system-log-daemon
27.) snort-rules-default: sysklogd | system-log-daemon
28.) sympa: sysklogd (>= 1.3-27) | system-log-daemon
Uses syslog-facility in postrm/postinst to setup a custom facility
to log to /var/log/sympa.log. Doesn't fail to install if
syslog-facility is not found, will log to /var/log/messages
instead. Could easily ship a rsyslog.d snippet.
So, the only real showstopper is 21.), not having system-log-daemon as
alternative, which makes it uninstallable with rsyslog.
If there is consensus, I'd go on filing bugs (priority important)
against 1.), 2.), 6.) and 21.), asking for changing the dependency to
rsyslog | system-log-daemon (or if they don't agree with the rsyslog
choice, their preferred system-log-daemon).
For 12.) and 28.), I'd file a wishlist bug providing a config file
snippet for /etc/rsyslog.d/
And finally, if it is approved that rsyslog should be become the default
system-log-daemon, I'd file wishlist bugs against the remaining packages
to change the dependency to rsylog | system-log-daemon, where appropriate.
> - Involve the rsyslog maintainer in the work
I'm here and all ears. I'm willing to work on the necessary steps.
> - Document the change by preparing a patch for the release notes
> - Get the priorities fixed by a ftpmaster (assistant)
Should, I file a lenny release goal first and wait for it's approval, or
can I take this thread as consensus that I can pursue changing the
default system-log-daemon to rsyslog?
Cheers,
Michael
Ben Finney
> Ok, here we go...
>
> [investigation and analysis of dependencies on 'sysklogd']
Good work, thankyou.
> Should, I file a lenny release goal first and wait for it's
> approval, or can I take this thread as consensus that I can pursue
> changing the default system-log-daemon to rsyslog?
It doesn't need to be a release goal to proceed with the work. File
the release goal if you like, but I'd say go ahead with the change
whether the release goal is accepted or not.
--
\ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
`\ rm * halt LART LART LART!" —The Swedish BOFH, |
_o__) alt.sysadmin.recovery |
Ben Finney
Guillem Jover
On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> For 12.) and 28.), I'd file a wishlist bug providing a config file
> snippet for /etc/rsyslog.d/
Can we please use /etc/syslog.d/ instead? this way we don't get locked
in any specific implementation. I'm preparing a patch for
inetutils-syslogd to support that, and it might also make sense to
require all system-log-daemon providers to support that dir as well.
> And finally, if it is approved that rsyslog should be become the default
> system-log-daemon, I'd file wishlist bugs against the remaining packages
> to change the dependency to rsylog | system-log-daemon, where
> appropriate.
rsyslogd seems to have a lot of features, and it's a bit big compared
to other implementations, do normal users need all that stuff?
Sysadmins can easily change it, and I bet most of the users do not
care much what syslogd is installed as long as it's just logging.
The list of syslogd sorted by Installed-Size:
Package: socklog-run
Installed-Size: 148
Package: sysklogd
Installed-Size: 212
Package: inetutils-syslogd
Installed-Size: 216
Package: syslog-ng
Installed-Size: 552
Package: rsyslog
Installed-Size: 672
regards,
guillem
Michael Biebl
> Hi,
>
> On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
>> For 12.) and 28.), I'd file a wishlist bug providing a config file
>> snippet for /etc/rsyslog.d/
>
> Can we please use /etc/syslog.d/ instead? this way we don't get locked
> in any specific implementation. I'm preparing a patch for
> inetutils-syslogd to support that, and it might also make sense to
> require all system-log-daemon providers to support that dir as well.
I'd rather not do that. There is no common config file format, that all
sylog daemons understand. E.g. you can't mix syslog-ng configuration
with metalog or rsyslog. The additional functionality of rsyslog is
implemented via special directives, which other syslog daemons won't
understand. So, I don't think this is a good idea.
>> And finally, if it is approved that rsyslog should be become the default
>> system-log-daemon, I'd file wishlist bugs against the remaining packages
>> to change the dependency to rsylog | system-log-daemon, where
>> appropriate.
>
> rsyslogd seems to have a lot of features, and it's a bit big compared
> to other implementations, do normal users need all that stuff?
> Sysadmins can easily change it, and I bet most of the users do not
> care much what syslogd is installed as long as it's just logging.
Regarding memory usage, the next major release of rsyslog will allow to
load only required functionality via shared modules. So you can
fine-tune rsyslog to your needs. The default rsyslog installation could
be setup to only support local logging, advanced features like remote
logging via udp or tcp could be enabled on demand.
> The list of syslogd sorted by Installed-Size:
>
> Package: socklog-run
> Installed-Size: 148
>
> Package: sysklogd
> Installed-Size: 212
>
> Package: inetutils-syslogd
> Installed-Size: 216
>
> Package: syslog-ng
> Installed-Size: 552
>
> Package: rsyslog
> Installed-Size: 672
That's mostly because of lots of documentation in
/usr/share/doc/rsyslog. If you think that's an issue, I could split out
the doc into a separate package.
Michael Biebl
>> The list of syslogd sorted by Installed-Size:
>>
>> Package: socklog-run
>> Installed-Size: 148
This one requires runit (430k) and socklog (291k) for operation
>> Package: sysklogd
>> Installed-Size: 212
This one requires klogd (139k) for kernel logging.
>>
>> Package: inetutils-syslogd
>> Installed-Size: 216
>>
>> Package: syslog-ng
>> Installed-Size: 552
>>
>> Package: rsyslog
>> Installed-Size: 672
>
> That's mostly because of lots of documentation in
> /usr/share/doc/rsyslog. If you think that's an issue, I could split out
> the doc into a separate package.
The documentation in /usr/share/doc is around 400k
Christian Perrier
> On Wed, 30 Jan 2008 15:01:58 +0100, Holger Levsen
> <hol...@layer-acht.org> wrote:
> >It seems to me that everybody replied in favor to this idea and nobody replied
> >suggesting to keep sysklogd the default. Which leads me to believe it should
> >be done :-)
>
> Please, do change away from sysklogd. sysklogd in itself is not bad,
> but the package has been nearly fully unmaintained for years.
Seconded as well. While I have no technical advice on this, all good
arguments have been given and it is obvious that Michael did a great
job studying the consequence of the change and is prepared to deal
with it.
Petter Reinholdtsen
[Michael Biebl]
> That's mostly because of lots of documentation in
> /usr/share/doc/rsyslog. If you think that's an issue, I could split
> out the doc into a separate package.
This is probably a good idea, for those that need a very small disk
footprint. Please split it into a -doc package.
Happy hacking,
--
Petter Reinholdtsen
Michael Biebl
>
> [Michael Biebl]
>> That's mostly because of lots of documentation in
>> /usr/share/doc/rsyslog. If you think that's an issue, I could split
>> out the doc into a separate package.
>
> This is probably a good idea, for those that need a very small disk
> footprint. Please split it into a -doc package.
>
Ok, will do. Thanks for the feedback!
Cheers,
Michael
------------------------------------------------------------
This mail was sent through TecO-Webmail: http://www.teco.edu
Raphael Hertzog
> Should, I file a lenny release goal first and wait for it's approval, or
> can I take this thread as consensus that I can pursue changing the
> default system-log-daemon to rsyslog?
Go ahead and keep up the good work!
Guillem Jover
> Guillem Jover wrote:
> > On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> > > For 12.) and 28.), I'd file a wishlist bug providing a config file
> > > snippet for /etc/rsyslog.d/
> >
> > Can we please use /etc/syslog.d/ instead? this way we don't get locked
> > in any specific implementation. I'm preparing a patch for
> > inetutils-syslogd to support that, and it might also make sense to
> > require all system-log-daemon providers to support that dir as well.
>
> I'd rather not do that. There is no common config file format, that all
> sylog daemons understand. E.g. you can't mix syslog-ng configuration
> with metalog or rsyslog. The additional functionality of rsyslog is
> implemented via special directives, which other syslog daemons won't
> understand. So, I don't think this is a good idea.
I've just checked a bit and sysklogd, inetutils-syslogd and rsyslog
understand the standard syslog.conf format. rsyslog has additional
directives, but IMO those should not be used by third party packages
that would drop config snippets under /etc/syslog.d/. rsyslog could of
course read configs from syslog.d and rsyslog.d, and admins could
install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
use of those additional features.
The only daemons not understanding the standard format are syslog-ng,
socklog, and metalog (which is not even on the distro).
My concern is making packages explicitely dependant on rsyslog, when
they could be generic, making it difficult for admins to switch
syslogd and also any future transition to another syslogd.
Holger Levsen
On Thursday 31 January 2008 00:11, Michael Biebl wrote:
> > - Involve the rsyslog maintainer in the work
> I'm here and all ears. I'm willing to work on the necessary steps.
> Ok, here we go...
I just wish to say a big thanks to you for all the work you've already done on
this. You rock!
> > - Document the change by preparing a patch for the release notes
I guess I c+should at least take over this one ;-)
regards,
Holger
Michael Biebl
> Quoting Petter Reinholdtsen <pe...@hungry.com>:
>
>> [Michael Biebl]
>>> That's mostly because of lots of documentation in
>>> /usr/share/doc/rsyslog. If you think that's an issue, I could split
>>> out the doc into a separate package.
>> This is probably a good idea, for those that need a very small disk
>> footprint. Please split it into a -doc package.
>>
>
> Ok, will do. Thanks for the feedback!
Done. I've split out the html documentation and now rsyslog weighs
258kb. It's currently waiting in NEW.
Tollef Fog Heen
| I agree with this. Additionally, Balasz Schielder (Balabit) makes people
| who contribute to syslog-ng sign a contributory license agreement [1],
| so that they can be included in syslog-ng premium, which is in my view
| against the whole purpose of open source. If you disagree with signing
| the CLA, your patch is rejected. As such, I feel that syslog-ng is not a
| good choice for the default syslogd in Debian.
FWIW, if you want your patch to end up in any Apache project, you have
to sign their contributor licence agreement. Similarly, for GNU
software, you have to assign copyright to FSF.
The syslog-ng author putting the changes into a closed-source version
(if I understand the paragraph quoted correctly), which is fine as
long as the licence allows it. You might not think it's in the spirit
of free software, but it's certainly something one of the arguments
some people are using to get people to use the BSD licence in favour
of the GPL.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Bernd Zeimetz
> course read configs from syslog.d and rsyslog.d, and admins could
> install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
> use of those additional features.
This would also be a way to solve #311812.
Cheers,
Bernd
--
Bernd Zeimetz
<be...@bzed.de> <http://bzed.de/>
Holger Levsen
(sorry for the bad quoting ratio, but I figured it's nice to bring back the
context...)
On Thursday 31 January 2008 00:11, Michael Biebl wrote:
Did you file those bugs? Is there a usertag for them?
> For 12.) and 28.), I'd file a wishlist bug providing a config file
> snippet for /etc/rsyslog.d/
>
> And finally, if it is approved that rsyslog should be become the default
> system-log-daemon, I'd file wishlist bugs against the remaining packages
> to change the dependency to rsylog | system-log-daemon, where appropriate.
>
> > - Involve the rsyslog maintainer in the work
>
> I'm here and all ears. I'm willing to work on the necessary steps.
I'm still willing to help... :) (But as its obvious now, I have lost the
status on this..)
> > - Document the change by preparing a patch for the release notes
> > - Get the priorities fixed by a ftpmaster (assistant)
>
> Should, I file a lenny release goal first and wait for it's approval, or
> can I take this thread as consensus that I can pursue changing the
> default system-log-daemon to rsyslog?
Or was it already too late for this?
regards,
Holger
Michael Biebl
>
> Did you file those bugs? Is there a usertag for them?
>
I tried to collect the information at http://wiki.debian.org/Rsyslog and
started filing the important bugs [1]. The real showstopper bug, which
made rsyslog uninstallable, in the psad package, has been fixed already.
For the remaining ones (changing sysklogd | system-log-daemon -> rsyslog
| system-log-daemon), I wanted to wait until rsyslog is actually
accepted as default syslog daemon
> I'm still willing to help... :) (But as its obvious now, I have lost the
> status on this..)
If the wiki page is missing information, please let me know.
>
>>> - Document the change by preparing a patch for the release notes
>>> - Get the priorities fixed by a ftpmaster (assistant)
>> Should, I file a lenny release goal first and wait for it's approval, or
>> can I take this thread as consensus that I can pursue changing the
>> default system-log-daemon to rsyslog?
>
> Or was it already too late for this?
Dunno. We should bring this topic up on debian-release I think to get
more input there. If you want to kick of the discussion, please go ahead.
Cheers,
Michael
[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-rsyslog;users=bi...@debian.org
Holger Levsen
(Please don't cc: me, I'm subscribed.)
On Wednesday 02 April 2008 01:20, Michael Biebl wrote:
> Holger Levsen schrieb:
> > Did you file those bugs? Is there a usertag for them?
>
> I tried to collect the information at http://wiki.debian.org/Rsyslog and
> started filing the important bugs [1].
Only one bug is open in the usertag list, but most from the wiki are not filed
yet.
> The real showstopper bug, which
> made rsyslog uninstallable, in the psad package, has been fixed already.
> For the remaining ones (changing sysklogd | system-log-daemon -> rsyslog
> | system-log-daemon), I wanted to wait until rsyslog is actually
> accepted as default syslog daemon
Makes sense, but also makes this goal a bit look like its stalled.
> > I'm still willing to help... :) (But as its obvious now, I have lost the
> > status on this..)
> If the wiki page is missing information, please let me know.
Looks good to me, thanks.
> >>> - Document the change by preparing a patch for the release notes
> >>> - Get the priorities fixed by a ftpmaster (assistant)
> >> Should, I file a lenny release goal first and wait for it's approval, or
> >> can I take this thread as consensus that I can pursue changing the
> >> default system-log-daemon to rsyslog?
> > Or was it already too late for this?
> Dunno. We should bring this topic up on debian-release I think to get
> more input there. If you want to kick of the discussion, please go ahead.
So, hi, debian-release, what is your opinion on this? Do you think we still
have the time to do this change for Lenny or is it too late already?
regards,
Holger
> [1]
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-rsyslog;users=biebl@d
>ebian.org