<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/30/19 10:19 PM, Nik Ambrosch
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFZHMGM+bVgkLR8PKuLo3nZynU9aTjCAPgo2DXBDstxXqStkFw@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div> </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 11:13
AM Evan Rempel <<a href="mailto:erempel@uvic.ca"
moz-do-not-send="true">erempel@uvic.ca</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_7093337168929300605moz-cite-prefix">I
don't have a versioning issue with versioned repos. After
all, that is what all of the</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">OS
repos are: Redhat 6, Sientific Linux 7, Centos 8, Debian
9, Ubunto 16 etc.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">The
issue I have with syslog-ng in specific is that once a new
version comes out,</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">the
previous version is abandoned. No bug fixes. No security
fixes etc.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">This
is NOT the same as the OS versions repos where bug fixes
and security fixes</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">are
continued within the repo.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">What
is being suggested in this thread is for major version
repo to be created and</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">maintained
in the long term support (LTS) role. Given the history of
version numbers for</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">syslog-ng
there is no clear major version transition. Syslog-ng3
(3.0 thorught 3.19)</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">has
been changing, breaking and adding new features for nearly
6 years. That's</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">about
3 releases per year. Without some automated update process
this is impossible to</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">keep
up with for anything more that a handful of systems.<br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">Some
thought as to designing a policy around when a new major
version should be created</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">and
supported the long term support and then automatic updates
(not upgrades) would be possible</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">within
that major version and its associated repo. A balance
needs to be found between frequency</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">of
releases and how many versions need to be supported. I
would recommend only 1 release per</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">year
that is supported. That would limit the number of
supported versions to no more than 5.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">Possibly
include an unsupported head for folks that absolutely need
a latest feature before the</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">year
it is released. That group can transition to the released
version once it is released as a</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">supported
version.</div>
<br>
<div class="gmail-m_7093337168929300605moz-cite-prefix">With
regards to the duration of the long term support, I think
that 3 years is a little short.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">With
a 3 year LTS cycle organizations that use syslog-ng would
have to start the planning, testing</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">and
approval process perhaps as frequently as every 2 years.
Redhat basic support is 5 years</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">with
extended support pushiing that out to 7 years. That cycle
might be a little long and costly for the</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">vendor/community
to support that long.</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">I
would propose nothing shorter than 4 years, so that
customers can do the planning, testing, approval</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">and
upgrade process every 3 years at a minimum.<br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
</div>
<div class="gmail-m_7093337168929300605moz-cite-prefix">On
3/29/19 6:23 AM, Nik Ambrosch wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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.<br>
</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019
at 4:24 AM Czanik, Péter <<a
href="mailto:peter.czanik@balabit.com"
target="_blank" moz-do-not-send="true">peter.czanik@balabit.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Here I offer my personal opinion about rolling
releases, which differs<br>
from the official Balabit opinion...<br>
<br>
When I first started my unofficial syslog-ng rpm
packages a long time<br>
ago in the galaxy, I had a single repository. When a
new release came<br>
out I packaged it into this repo. The feedback I
received -- and I<br>
fully agreed as a practicing sysadmin -- that "don't
do automagic<br>
version updates for us, as it might break things".
That's how<br>
versioned repositories started. From the admin point
of view an<br>
automatic update is a risk, as even with thousands of
automatic tests,<br>
configurations can break. I recall quite a few
breaking changes, some<br>
intentional, some accidental. From this point of view
things got just<br>
worse when from yearly releases we changed to two
months. Quite a few<br>
places test new releases for more than two months
before adding to<br>
production...<br>
<br>
Here I fully agree with Evan, and this was also a
feedback I often<br>
received in private (unfortunately not on a public
mailing list, blog<br>
post or whatever), that continuous rolling is a major
pain. To best<br>
accommodate such users, there could be an LTS releases
next to the<br>
rolling, which receives fixes for critical problems.
To avoid having<br>
many parallel supported versions, we could align this
with a major<br>
release of Redhat, and keep that version supported for
~3 years.<br>
<br>
In this case there could be a versioned repo for LTS
releases:<br>
syslog-ng4<br>
syslog-ng5<br>
etc.<br>
And for those needing the latest features:<br>
syslog-ng-rolling<br>
Where people receive new feature releases
automatically as they appear.<br>
<br>
Bye,<br>
<br>
Peter Czanik (CzP) <<a
href="mailto:peter.czanik@balabit.com"
target="_blank" moz-do-not-send="true">peter.czanik@balabit.com</a>><br>
Balabit (a OneIdentity company) / syslog-ng upstream<br>
<a href="https://syslog-ng.com/community/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://syslog-ng.com/community/</a><br>
<a href="https://twitter.com/PCzanik" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://twitter.com/PCzanik</a><br>
<br>
On Thu, Mar 28, 2019 at 3:57 PM Evan Rempel <<a
href="mailto:erempel@uvic.ca" target="_blank"
moz-do-not-send="true">erempel@uvic.ca</a>>
wrote:<br>
><br>
> 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<br>
> 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<br>
> updates to "syslog-ng-4".<br>
><br>
> 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.<br>
><br>
> 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<br>
> community the ability to make backwards breaking
changes every year.<br>
><br>
> 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.<br>
><br>
> 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!<br>
><br>
> I am free for further discussing if the package
maintainers want to reach out.<br>
><br>
> Evan Rempel<br>
><br>
> On 3/28/19 6:43 AM, Faine, Mark R.
(MSFC-IS40)[NICS] wrote:<br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > Thanks,<br>
> > -Mark<br>
> ><br>
> > From: syslog-ng <<a
href="mailto:syslog-ng-bounces@lists.balabit.hu"
target="_blank" moz-do-not-send="true">syslog-ng-bounces@lists.balabit.hu</a>>
On Behalf Of Péter, Kókai<br>
> > Sent: Thursday, March 28, 2019 4:16 AM<br>
> > To: Syslog-ng users' and developers' mailing
list <<a href="mailto:syslog-ng@lists.balabit.hu"
target="_blank" moz-do-not-send="true">syslog-ng@lists.balabit.hu</a>><br>
> > Subject: Re: [syslog-ng] Redhat repo<br>
> ><br>
> > Hello,<br>
> ><br>
> > I've just spoke with Czanik Peter - the
maintainer of those repositories.<br>
> ><br>
> > 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.<br>
> > (I guess it is an *easy* way to prevent
accidental updates.)<br>
> > Also he said that there was not much demand
for such structured repository since the shift (only
1-2 person).<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Kokan<br>
> ><br>
> > On Wed, Mar 27, 2019 at 3:40 PM Faine, Mark
R. (MSFC-IS40)[NICS] <mailto:<a
href="mailto:mark.faine@nasa.gov" target="_blank"
moz-do-not-send="true">mark.faine@nasa.gov</a>>
wrote:<br>
> > 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?<br>
> ><br>
> > -Mark<br>
> ></blockquote>
</div>
</blockquote>
<br>
</div>
______________________________________________________________________________<br>
Member info: <a
href="https://lists.balabit.hu/mailman/listinfo/syslog-ng"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a
href="http://www.balabit.com/support/documentation/?product=syslog-ng"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">N�n�r����)em�h�yhiם�w^���</pre>
</blockquote>
<p><br>
</p>
</body>
</html>