[syslog-ng] Redhat repo
Evan Rempel
erempel at uvic.ca
Mon Apr 1 01:09:41 UTC 2019
The Oracle release cycle is also a problem. For any new feature released
in the 3 years following a LTS release, the only way to get the feature
is to install a product with a life cycle of 6 months, because after 6
months there are no bug fixes. A six month upgrade cycle is far too fast
for any shop with more than a handful of applications to support.
Running without bug/security fixes is unacceptable as well.
The other issue is that a new deploy that takes place 1 month prior to
the release of the LTS will need to undergo and upgrade in 1 month
because the LTS version and the current release both come off the
support path at the same time.
The Oracle release cycle is one of the reasons that we are abandoning
the Oracle packaged JDK and going with a support vendor that will
provide 3-5 years of support on their packaged JDK releases.
In my opinion, any product that wants to be accepted into an enterprise
environment needs to address this issue. I acknowledge that it is more
work for developers and that the developers need to minimize the
likelihood of significant code differences for the same features across
the supported releases so that patches can more easily be applied across
the different releases. I also acknowledge that this can't be done in
all cases, that every case is unique.
As it stands now, syslog-ng is in danger of being pushed to the fringe.
Other syslog products in combination with message pipelines and glue
products can be used to replace syslog-ng. If these combinations provide
easier (less costly) maintenance with ensured security patches, company
policies will force syslog-ng to be dropped.
On 3/30/19 10:19 PM, Nik Ambrosch wrote:
> 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
> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <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
>
>
> N�n�r����)em�h�yhiם�w^���
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20190331/6e354c5e/attachment-0001.html>
More information about the syslog-ng
mailing list