Mailing List Archive

Hello Michael,
at first, thank you for your work done.

Propose rsyslog-ossl (OpenSSL driver for TLS encryption) being built and
put into non-free if possible. Just to let people test or use it if they
want.
The libssl-dev is listed in BuildDepends list. Are there other parts of
rsyslog which are dependent on OpenSSL libraries? These are not
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930816

Maybe backporting of some bugfixes for rsyslog in stable release should be
made.
At the moment the 8.24.0-1 in current stable means there were no changes
from original source. Due to rsyslog release policies bugfixes are
primarily included in new releases only. At least some important bug might
be backported in my opinion.
Just list from 8.25 release:
- bugfix imtcp: fix very small (cosmetic) memory leak
- bugfix rainerscript: set/unset statement do not check variable name
validity
- bugfix core: str2num mishandling empty strings
- bugfix queue subsystem: queue corrupted if certain msg props are used
- core: fix potential message loss in old-style transactional interface

The bug "queue corrupted if certain msg props are used" caused DA queues
not being dequeued when some variables used in message processing (most
semi-advanced setups do).
At least this and some of others might be backported to Debian stable
release package.

The use of package from backports is not always the best option as those
versions also come with new bugs and regressions.
For example in 8.1905 release there was important regression in core
- core bugfix: segfault on startup depending on queue file names
rsyslog will segfault on startup when a main queue file name has
been set and at least on other queue contains a file name. This
was cased by too-early freeing config error-detection data
structures. It is a regression caused by commit e22fb205a3.
Thanks to Wade Simmons for reporting this issue and providing
detailled analysis. That greatly helps fixing it quickly.
closes https://github.com/rsyslog/rsyslog/issues/3681

Maybe, with help of community, Debian would be able to provide "real
stable" rsyslog release.

--
Peter

On Tue, Jul 2, 2019 at 9:13 PM Michael Biebl via rsyslog <
rsyslog@lists.adiscon.com> wrote:

> Hi everyone,
>
> in case you don't know me, I'm the (official) maintainer of rsyslog in
> Debian.
> I put the official in parenthesis as I know there are deb packages as
> well provided by Adiscon directly.
> While I appreciate the service that is done by Rainer and his folks, I
> wonder if there is something we can improve on the Debian side. I try
> to keep the Debian packages up-to-date [1] as well as I can given the
> constraints that a distro like Debian has.
> Is there anything else that you are missing?
> Any recommendations how the Debian packages can be improved?
>
> I'm happy to receive feedback here. Just keep in mind, that I have to
> balance here, that rsyslog is installed on basically everyone's
> (Debian) system.
>
> Regards,
> Michael
>
> [1] https://tracker.debian.org/pkg/rsyslog
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

Hijacking the thread just slightly...

El jue., 4 jul. 2019 a las 9:51, Peter Viskup via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>

> The use of package from backports is not always the best option as those
> versions also come with new bugs and regressions.
> For example in 8.1905 release there was important regression in core
> - core bugfix: segfault on startup depending on queue file names
> rsyslog will segfault on startup when a main queue file name has
> been set and at least on other queue contains a file name. This
> was cased by too-early freeing config error-detection data
> structures. It is a regression caused by commit e22fb205a3.
> Thanks to Wade Simmons for reporting this issue and providing
> detailled analysis. That greatly helps fixing it quickly.
> closes https://github.com/rsyslog/rsyslog/issues/3681
>
> Maybe, with help of community, Debian would be able to provide "real
> stable" rsyslog release.

A main problem from our PoV is that almost nobody uses the daily
stable releases. If at least a couple of folks would do, we could
usually iron out regressions like the above very quickly. As this does
not happen, it propagates to the 6-week stable, is deteced rather
quickly, and folks need to wait another 6 weeks to get the patch
(daily stable users have it immediately).

I think the same applies to at least some degree to the debian offical
packages Michael maintains.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

El mar., 2 jul. 2019 a las 21:13, Michael Biebl via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>
> Hi everyone,
>
> in case you don't know me, I'm the (official) maintainer of rsyslog in Debian.
> I put the official in parenthesis as I know there are deb packages as
> well provided by Adiscon directly.

Michael, I always consider the Debian packages to be the official ones.

We just have "rsyslog official packages". But as I have said more than
once, we are not good at packaging and the quality of these packages
is in general lower than the ones you maintain. As yours are kept
pretty current, we for a long time did not even do rsyslog packages
for Debian at all. We just recently started (via OBS) because folks
requested the most current versions. I guess that's the prime driver.
Still, our OBS packages are definitely not as mature as the Debian
official ones. This is why I also constantly ask for volunteers in
this regard for the rsyslog project packages.

That said, I would be very happy if we could identify spots that make
the Debian official packages (not ours) more appealing to the user
base.

Rainer


> While I appreciate the service that is done by Rainer and his folks, I
> wonder if there is something we can improve on the Debian side. I try
> to keep the Debian packages up-to-date [1] as well as I can given the
> constraints that a distro like Debian has.
> Is there anything else that you are missing?
> Any recommendations how the Debian packages can be improved?
>
> I'm happy to receive feedback here. Just keep in mind, that I have to
> balance here, that rsyslog is installed on basically everyone's
> (Debian) system.
>
> Regards,
> Michael
>
> [1] https://tracker.debian.org/pkg/rsyslog
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

Am Do., 4. Juli 2019 um 09:50 Uhr schrieb Peter Viskup <skupko.sk@gmail.com>:
>
> Hello Michael,
> at first, thank you for your work done.
>
> Propose rsyslog-ossl (OpenSSL driver for TLS encryption) being built and put into non-free if possible. Just to let people test or use it if they want.
> The libssl-dev is listed in BuildDepends list. Are there other parts of rsyslog which are dependent on OpenSSL libraries? These are not
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930816

I'm not sure, if using non-free for rsyslog-openssl is the solution
here. Combining GPL and OpenSSL is a bit of an icky topic especially
when dlopen comes into play.
I'll need to get some help on this. Rest assured I have not forgotten
about this.

> Maybe backporting of some bugfixes for rsyslog in stable release should be made.
> At the moment the 8.24.0-1 in current stable means there were no changes from original source. Due to rsyslog release policies bugfixes are primarily included in new releases only. At least some important bug might be backported in my opinion.

I do provide backports for $stable-backports. See
https://packages.debian.org/source/stretch-backports/rsyslog
What's currently in testing I usually also upload to $stable-backports.

You are indeed correct that I'm somewhat limited what I can upload to
$stable by the stable release policies.

Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

On Thu, Jul 4, 2019 at 11:51 AM Rainer Gerhards <rgerhards@hq.adiscon.com>
wrote:

> Hijacking the thread just slightly...
>
> El jue., 4 jul. 2019 a las 9:51, Peter Viskup via rsyslog
> (<rsyslog@lists.adiscon.com>) escribió:
> >
>
> > The use of package from backports is not always the best option as those
> > versions also come with new bugs and regressions.
> > For example in 8.1905 release there was important regression in core
> > - core bugfix: segfault on startup depending on queue file names
> > rsyslog will segfault on startup when a main queue file name has
> > been set and at least on other queue contains a file name. This
> > was cased by too-early freeing config error-detection data
> > structures. It is a regression caused by commit e22fb205a3.
> > Thanks to Wade Simmons for reporting this issue and providing
> > detailled analysis. That greatly helps fixing it quickly.
> > closes https://github.com/rsyslog/rsyslog/issues/3681
> >
> > Maybe, with help of community, Debian would be able to provide "real
> > stable" rsyslog release.
>
> A main problem from our PoV is that almost nobody uses the daily
> stable releases. If at least a couple of folks would do, we could
> usually iron out regressions like the above very quickly. As this does
> not happen, it propagates to the 6-week stable, is deteced rather
> quickly, and folks need to wait another 6 weeks to get the patch
> (daily stable users have it immediately).
>

The syslog infra is something which most of admins do not want to update on
daily basis.
I think this is not something we should expect from admins - and as you
see, it was just proven. Also some bugs might occur after a while.
Find it not appropriate to follow agile development principles on such
crucial subsystem as syslog still is. This is user's point of view.

Similar situation is with systemd. Was just trying to create chrooted
systemd rsyslog services and fall down on knees searching why this and that
super-duper feature does not work. In some cases it was bug in version
available in Debian, in others this or that feature was not available in
the Debian version, or it was architectural issue in vanilla where those
features just does not work together.
On the end the services were built upon systemd features available since
the very beginning, with calling Start/StopExecPre/Post commands.

--
Peter
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

Am Do., 4. Juli 2019 um 13:30 Uhr schrieb Peter Viskup via rsyslog
<rsyslog@lists.adiscon.com>:
> The syslog infra is something which most of admins do not want to update on
> daily basis.
> I think this is not something we should expect from admins - and as you
> see, it was just proven. Also some bugs might occur after a while.
> Find it not appropriate to follow agile development principles on such
> crucial subsystem as syslog still is. This is user's point of view.


So if I understand you correctly you don't want the latest and
greatest but you would actually prefer the version that is shipped in
$stable and only apply targetted fixes?





--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

El jue., 4 jul. 2019 a las 13:30, Peter Viskup (<skupko.sk@gmail.com>) escribió:
>
> On Thu, Jul 4, 2019 at 11:51 AM Rainer Gerhards <rgerhards@hq.adiscon.com> wrote:
>>
>> Hijacking the thread just slightly...
>>
>> El jue., 4 jul. 2019 a las 9:51, Peter Viskup via rsyslog
>> (<rsyslog@lists.adiscon.com>) escribió:
>> >
>>
>> > The use of package from backports is not always the best option as those
>> > versions also come with new bugs and regressions.
>> > For example in 8.1905 release there was important regression in core
>> > - core bugfix: segfault on startup depending on queue file names
>> > rsyslog will segfault on startup when a main queue file name has
>> > been set and at least on other queue contains a file name. This
>> > was cased by too-early freeing config error-detection data
>> > structures. It is a regression caused by commit e22fb205a3.
>> > Thanks to Wade Simmons for reporting this issue and providing
>> > detailled analysis. That greatly helps fixing it quickly.
>> > closes https://github.com/rsyslog/rsyslog/issues/3681
>> >
>> > Maybe, with help of community, Debian would be able to provide "real
>> > stable" rsyslog release.
>>
>> A main problem from our PoV is that almost nobody uses the daily
>> stable releases. If at least a couple of folks would do, we could
>> usually iron out regressions like the above very quickly. As this does
>> not happen, it propagates to the 6-week stable, is deteced rather
>> quickly, and folks need to wait another 6 weeks to get the patch
>> (daily stable users have it immediately).
>
>
> The syslog infra is something which most of admins do not want to update on daily basis.
> I think this is not something we should expect from admins - and as you see, it was just proven. Also some bugs might occur after a while.
> Find it not appropriate to follow agile development principles on such crucial subsystem as syslog still is. This is user's point of view.

We have been there. We have maintained long term released for quite a
while. Bottom line: it created quite some effort but the end result
was more or less the same. But worse, because the delta between stable
and devel was month at that time. So when we moved forward to crafting
a new stable, we got many bug reports - and did not even remember
sufficiently well what was done to fix it quickly. Sometimes the delta
was 2 or 3 years, e.g. when folks used v5-stable while we were at
v7-stable. Everyone used the old version and when finally a larger
migration wave came in, things tended to fail miserably.

Open source is a community effort. Some of the testing *needs* to be
done by the community - we cannot reproduce every esoteric conf. And
if that testing does not happen, we will roll regressions into new
stable builds. If so, it is far better to see them quickly and
one-after-another instead of everything at once when an obviously
never used in practice codebase out of the sudden receives much
attention.

The current approach has proven to be much better than maintaining
v5-m v7- and v8-stable builds. If we have regressions, we can iron
them out much more quickly and with far less effort. Also, regressions
happen less frequently if I am not mistaken (that's also thanks to
major CI improvements).

>
> Similar situation is with systemd. Was just trying to create chrooted systemd rsyslog services and fall down on knees searching why this and that super-duper feature does not work. In some cases it was bug in version available in Debian, in others this or that feature was not available in the Debian version, or it was architectural issue in vanilla where those features just does not work together.
> On the end the services were built upon systemd features available since the very beginning, with calling Start/StopExecPre/Post commands.

In contrast to systemd, we never break existing feature set. So you
can always upgrade with a very low risk (program bug remains as risk,
of course).

see also; https://rainer.gerhards.net/2019/06/rsyslogs-daily-stable.html

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

On Thu, 4 Jul 2019, Rainer Gerhards via rsyslog wrote:

> El mar., 2 jul. 2019 a las 21:13, Michael Biebl via rsyslog
> (<rsyslog@lists.adiscon.com>) escribió:
>>
>> Hi everyone,
>>
>> in case you don't know me, I'm the (official) maintainer of rsyslog in Debian.
>> I put the official in parenthesis as I know there are deb packages as
>> well provided by Adiscon directly.
>
> Michael, I always consider the Debian packages to be the official ones.
>
> We just have "rsyslog official packages". But as I have said more than
> once, we are not good at packaging and the quality of these packages
> is in general lower than the ones you maintain. As yours are kept
> pretty current, we for a long time did not even do rsyslog packages
> for Debian at all. We just recently started (via OBS) because folks
> requested the most current versions. I guess that's the prime driver.
> Still, our OBS packages are definitely not as mature as the Debian
> official ones. This is why I also constantly ask for volunteers in
> this regard for the rsyslog project packages.
>
> That said, I would be very happy if we could identify spots that make
> the Debian official packages (not ours) more appealing to the user
> base.

We would also welcome any assistance in improving the quality of the packages we
provide, if there are things that are different in our packages than in the
official Debian packages, help us understand what the difference is and how to
make our packages work as drop-in replacements for people who need newer
features.

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.

On Thu, Jul 4, 2019 at 1:35 PM Michael Biebl <mbiebl@gmail.com> wrote:

> Am Do., 4. Juli 2019 um 13:30 Uhr schrieb Peter Viskup via rsyslog
> <rsyslog@lists.adiscon.com>:
> > The syslog infra is something which most of admins do not want to update
> on
> > daily basis.
> > I think this is not something we should expect from admins - and as you
> > see, it was just proven. Also some bugs might occur after a while.
> > Find it not appropriate to follow agile development principles on such
> > crucial subsystem as syslog still is. This is user's point of view.
>
>
> So if I understand you correctly you don't want the latest and
> greatest but you would actually prefer the version that is shipped in
> $stable and only apply targetted fixes?
>

Yes, Michael, that would make sense. Not all bug fixes, but at least those,
which will be considered critical, making the software not work as expected
or failing.
E.g. that one in 8.24 version causing DA queues not being processed.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.