SCIENTIFIC-LINUX-USERS Archives

June 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Hans Kristian Rosbach <[log in to unmask]>
Reply To:
Hans Kristian Rosbach <[log in to unmask]>
Date:
Mon, 20 Jun 2016 10:54:10 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
On 06/18/2016 08:33 PM, Nico Kadel-Garcia wrote:

> I'm extremely leery of any system that tries to "bundle all the system
> tools" to run packages. It might be usable for containers, but it
> presents real library and package management problems for deployed
> such working environments. The approach is very familiar: it used to
> be done with chroot a lot, it's more recently been done with docker
> and Vagrant, and I don't see any compelling need for more such tools.

I just love maintaining servers running software that bundles its own
libraries, often using libraries or java several years old, with no
security patches since then. The application works, so the developer
does not want to spend the time updating the libraries. When prompted
to do so, citing security vulnerabilities, I have often heard they have
it on their todo-list for the next 6 months, yet a year later nothing
has been done.

Unfortunately this is the sad case with several expensive commercial
programs, whether running from /opt, in docker or in a VM.

So, from a developers point of view it is great, but from a sysadmin
pov it is often hated and can result in a need for more strict security
measures on and around that server.

I know well the complications of updating system libraries, and we
have to maintain a repo with quite a few nonstandard rpms to achieve
features not otherwise available in SL.

What would be nice is a better separation of libraries in packages,
take mysql-libs for example. It contains more than just the libs, and
thus installation of mariadb-libs will conflict even though the libraries
themselves do not conflict. That means workarounds is needed to solve
something that should not even be a problem.
A worse problem is openssl, since EL7 still does not support ALPN and
google recently stopped supporting NPN for HTTP2 in Chrome.
We maintained a modified openssl rpm for SL6 for similar reasons,
but for SL7 we'd really like to avoid that. So we are currently looking
at BoringSSL as an alternative.

-- 
   Hans Kristian Rosbach
   Raske Sider AS

ATOM RSS1 RSS2