[syslog-ng] Redhat repo

Thu Mar 28 13:43:32 UTC 2019

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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.balabit.hu_mailman_listinfo_syslog-2Dng&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=zMyZvtxRXMBKZZYKVMke9zplWK320p3d51BzuU4jwWo&m=GdLkKgI_K4XLKuI61LZLTrdOwlI2Hikxtn-pM0wKfhI&s=sL8zjABb_crnYwDEgbmaEiULVckvTJqcklAnYLRqNKs&e=
Documentation: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.balabit.com_support_documentation_-3Fproduct-3Dsyslog-2Dng&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=zMyZvtxRXMBKZZYKVMke9zplWK320p3d51BzuU4jwWo&m=GdLkKgI_K4XLKuI61LZLTrdOwlI2Hikxtn-pM0wKfhI&s=823-vvWMgkw_m5R52nc3q7B3u-0HbJ8TeaXjCP0OHaI&e=
FAQ: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.balabit.com_wiki_syslog-2Dng-2Dfaq&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=zMyZvtxRXMBKZZYKVMke9zplWK320p3d51BzuU4jwWo&m=GdLkKgI_K4XLKuI61LZLTrdOwlI2Hikxtn-pM0wKfhI&s=6B0Um7N9KEORW2cvMvQ_epi13Wy9Z_mL41ZkcZq58NQ&e=