[syslog-ng] Redhat repo

Fri Mar 29 13:23:09 UTC 2019

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
> >
>
> ______________________________________________________________________________
> 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/20190329/0705d8bd/attachment.html>