[syslog-ng] Redhat repo

Nik Ambrosch nik at ambrosch.com
Sun Mar 31 05:19:09 UTC 2019 

Not all projects get back-ported bug fixes.  Right now the copy of
syslog-ng in epel gets back-ported bug fixes, I don't know very much about
who maintains that though.

I think a good example of what you have in mind is what Oracle just did
with the Java JDK - a new LTS release (currently JDK 11) will become
available every three years but is supported for eight(ish?) years.  A new
feature release will become available every six months, I don't believe
fixes are back-ported.


On Fri, Mar 29, 2019 at 11:13 AM Evan Rempel <erempel at uvic.ca> wrote:

> I don't have a versioning issue with versioned repos. After all, that is
> what all of the
> OS repos are: Redhat 6, Sientific Linux 7, Centos 8, Debian 9, Ubunto 16
> etc.
>
> The issue I have with syslog-ng in specific is that once a new version
> comes out,
> the previous version is abandoned. No bug fixes. No security fixes etc.
> This is NOT the same as the OS versions repos where bug fixes and security
> fixes
> are continued within the repo.
>
> What is being suggested in this thread is for major version repo to be
> created and
> maintained in the long term support (LTS) role. Given the history of
> version numbers for
> syslog-ng there is no clear major version transition. Syslog-ng3 (3.0
> thorught 3.19)
> has been changing, breaking and adding new features for nearly 6 years.
> That's
> about 3 releases per year. Without some automated update process this is
> impossible to
> keep up with for anything more that a handful of systems.
>
> Some thought as to designing a policy around when a new major version
> should be created
> and supported the long term support and then automatic updates (not
> upgrades) would be possible
> within that major version and its associated repo. A balance needs to be
> found between frequency
> of releases and how many versions need to be supported. I would recommend
> only 1 release per
> year that is supported. That would limit the number of supported versions
> to no more than 5.
> Possibly include an unsupported head for folks that absolutely need a
> latest feature before the
> year it is released. That group can transition to the released version
> once it is released as a
> supported version.
>
> With regards to the duration of the long term support, I think that 3
> years is a little short.
> With a 3 year LTS cycle organizations that use syslog-ng would have to
> start the planning, testing
> and approval process perhaps as frequently as every 2 years. Redhat basic
> support is 5 years
> with extended support pushiing that out to 7 years. That cycle might be a
> little long and costly for the
> vendor/community to support that long.
>
> I would propose nothing shorter than 4 years, so that customers can do the
> planning, testing, approval
> and upgrade process every 3 years at a minimum.
>
>
>
> On 3/29/19 6:23 AM, Nik Ambrosch wrote:
>
> Having a syslog-ng-latest repo to compliment the existing syslog-ng-317
> versioned repos might be a good idea for people who use these builds for
> desktops and non-mission-critical applications.
>
> I don't like surprises so I use the versioned repos and only change when
> there's a *need* to upgrade (new feature/fix listed in the changelog).
>
>
> On Fri, Mar 29, 2019 at 4:24 AM Czanik, Péter <peter.czanik at balabit.com>
> wrote:
>
>> Hi,
>>
>> Here I offer my personal opinion about rolling releases, which differs
>> from the official Balabit opinion...
>>
>> When I first started my unofficial syslog-ng rpm packages a long time
>> ago in the galaxy, I had a single repository. When a new release came
>> out I packaged it into this repo. The feedback I received -- and I
>> fully agreed as a practicing sysadmin -- that "don't do automagic
>> version updates for us, as it might break things". That's how
>> versioned repositories started. From the admin point of view an
>> automatic update is a risk, as even with thousands of automatic tests,
>> configurations can break. I recall quite a few breaking changes, some
>> intentional, some accidental. From this point of view things got just
>> worse when from yearly releases we changed to two months. Quite a few
>> places test new releases for more than two months before adding to
>> production...
>>
>> Here I fully agree with Evan, and this was also a feedback I often
>> received in private (unfortunately not on a public mailing list, blog
>> post or whatever), that continuous rolling is a major pain. To best
>> accommodate such users, there could be an LTS releases next to the
>> rolling, which receives fixes for critical problems. To avoid having
>> many parallel supported versions, we could align this with a major
>> release of Redhat, and keep that version supported for ~3 years.
>>
>> In this case there could be a versioned repo for LTS releases:
>> syslog-ng4
>> syslog-ng5
>> etc.
>> And for those needing the latest features:
>> syslog-ng-rolling
>> Where people receive new feature releases automatically as they appear.
>>
>> Bye,
>>
>> Peter Czanik (CzP) <peter.czanik at balabit.com>
>> Balabit (a OneIdentity company) / syslog-ng upstream
>> https://syslog-ng.com/community/
>> https://twitter.com/PCzanik
>>
>> On Thu, Mar 28, 2019 at 3:57 PM Evan Rempel <erempel at uvic.ca> wrote:
>> >
>> > The syslog-ng package maintainers and those deciding on version
>> numbering need to decide on when backwards compatibility breaking occurs.
>> IMO there is no reason to not upgrade to newer versions automatically
>> (whatever schedule the client performs yum updates), with the one exception
>> being updates that no longer work with a configuration file. Having an
>> exact version number in the configuration file (@version 3.17) is not
>> useful if the configuration works with multiple releases. I would think
>> > that having a configuration version that remains the same for the same
>> configuration syntax and semantcs would be more meaningful. Just thinking
>> in public/out loud, perhaps all syslog-ng version 3.x use the same
>> configuration syntax, then the @version would be 3, and when the config
>> syntax is no longer backwards compatible, a new package name and @version
>> is produced. This means that package NAMES would need to contain the major
>> version number "syslog-ng-3" so that you do NOT get automatic
>> > updates to "syslog-ng-4".
>> >
>> > The down side for this is that syslog-ng-3 would need to be security
>> fixed along side the syslog-ng-4 package for some support period and then
>> finally deprecated in favour of the newer syslog-ng-4 package.
>> >
>> > I find that the postgresql community has done this very well. They make
>> a major version release once per year which is how they introduce new
>> features. They provide security fixes (and most bug fixes) for a period of
>> 5 years. That means that at any given time they are supporting 5 major
>> releases. Because this is a published schedule, installations are
>> guaranteed to be supported/patched for 5 years, which falls into line with
>> vendor OS support models quite well and provides the postgresql
>> > community the ability to make backwards breaking changes every year.
>> >
>> > For enterprise environments similar to what Mark describes below, it is
>> critical that installed packages don't become abandoned with regards to
>> patches. New features are not required to be added automatically, but
>> security and bug fixes are. Some way to get security and bug fixes
>> automatically without breaking compatibility over a long time preriod (3-5
>> years) is what is needed to ensure stability, security and maintainability
>> in an enterprise environment.
>> >
>> > Our company suffers from these requirements which are made that much
>> more difficult by packaging decisions like what syslog-ng has decided on.
>> Don't think  I am picking on syslog-ng. elasticsearch and oracle java
>> suffer from this too. I am just trying to make the syslog-ng package as
>> awesome as the syslong-ng program!
>> >
>> > I am free for further discussing if the package maintainers want to
>> reach out.
>> >
>> > Evan Rempel
>> >
>> > On 3/28/19 6:43 AM, Faine, Mark R. (MSFC-IS40)[NICS] wrote:
>> > > You can easily version lock a package in Redhat (don’t know about
>> SUSE, but I’d imagine so)  There is no need for a separate repository.  It
>> makes more sense for the default to be the latest release and for locking
>> to a specific release to be the exception.  It would probably even be
>> easier for him to manage.
>> > >
>> > > The Redhat version is very old (3.2.5), so I’d rather not use it but
>> not having a repo that tracks with the latest release breaks my
>> installation process and means that I need a few separate tasks just for
>> syslog-ng.
>> > >
>> > > If there is an update, I’ll have to remove the repo, add the new
>> repo, then upgrade.  Instead of just doing a yum update.  I usually patch
>> secondary servers first and then a few weeks later the primary or
>> production servers, I think that would be enough warning if there were any
>> breaking changes.
>> > >
>> > > Hopefully, if he is going to choose not to provide a repo with the
>> latest release, I hope he is at least standardizing the naming convention
>> and URLs so that I can automate the process, even so my problem is that it
>> would still be a manual process, at least partially, since I’ll have to
>> keep track of when a new version is released and update my configuration
>> accordingly.  Manual processes such as this increase the potential for
>> oversight which could allow a security vulnerability to slip through.
>> > >
>> > > I don’t know how many security vulnerabilities typically occur with
>> syslog-ng but I know that it’s a big deal here and we are constantly pushed
>> to keep systems up-to-date.  If there is some random high profile security
>> vulnerability found on my system, I don’t want to be called out for having
>> out-of-date software from a third-party repo.  I know it’s not fair but
>> that’s the way they’ll frame it.
>> > >
>> > > In the end, I might be forced to use the Redhat version in the
>> optional rpms repo, though since I’ve been working with 3.18, it’s possible
>> that there may be things in my configuration that aren’t even compatible
>> with that version. The thing is, they’d rather I use the old version that
>> is, at least allegedly, supported by Redhat, than a newer, arguably more
>> secure, and more performant version. Their reasoning breaks down to nothing
>> more than CYA.
>> > >
>> > > I guess my point is that I’d hoped to argue for getting to use the
>> czanik packages for the reasons I’ve mentioned and knowing already it would
>> be an uphill battle but if they get a whiff of how the repos are structured
>> it will make it even harder to justify, perhaps impossible.
>> > >
>> > > Thanks,
>> > > -Mark
>> > >
>> > > From: syslog-ng <syslog-ng-bounces at lists.balabit.hu> On Behalf Of
>> Péter, Kókai
>> > > Sent: Thursday, March 28, 2019 4:16 AM
>> > > To: Syslog-ng users' and developers' mailing list <
>> syslog-ng at lists.balabit.hu>
>> > > Subject: Re: [syslog-ng] Redhat repo
>> > >
>> > > Hello,
>> > >
>> > > I've just spoke with Czanik Peter - the maintainer of those
>> repositories.
>> > >
>> > > He said that initially there was one repo having the latest released,
>> but majority of the user want to control when to upgrade to a newer version
>> from both RHEL and SUSE side.
>> > > (I guess it is an *easy* way to prevent accidental updates.)
>> > > Also he said that there was not much demand for such structured
>> repository since the shift (only 1-2 person).
>> > >
>> > >
>> > >
>> > > --
>> > > Kokan
>> > >
>> > > On Wed, Mar 27, 2019 at 3:40 PM Faine, Mark R. (MSFC-IS40)[NICS]
>> <mailto:mark.faine at nasa.gov> wrote:
>> > > I have a question about the Redhat repo for the unofficial OSE
>> builds.  It seems as though they are tied to a specific version.  For
>> example, I'm currently using czanik-syslog-ng318epel6, however, I see that
>> 3.19 has a different repo specifically for that version.  This seems to be
>> counter to the point of yum repositories and it imposes an additional
>> maintenance burden.  Am I maybe not properly understanding how it works,
>> and if not, is there a repo that tracks with the latest stable version?
>> > >
>> > > -Mark
>> > >
>
>
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20190331/acc03d2c/attachment-0001.html>

More information about the syslog-ng mailing list