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