CVE-2016-6213 was reported three years ago by OpenVZ developer(bugzilla.redhat.com) |
CVE-2016-6213 was reported three years ago by OpenVZ developer(bugzilla.redhat.com) |
I feel OpenVZ gets a bad rap simply because of the "pop up" VPS providers who oversell and under-provision. It is a mature, maintained containerisation system. Yes it still requires kernel patches (created before Linux had namespaces/cgroups etc) but the team is actively working on merging missing functionality upstream and adapting OpenVZ tools to support things like namespaces and cgroups.
LXC and Docker, especially when combined with a virtualisation layer and SELinux are modern, stable, well maintained options that are not only easy to configure and manage but do not require custom kernel patches etc...
They're only just moving from their 2009 Kernel fork to a fork of Kernel 3.10 which was released in 2013...
Edit: In fact, on second inspection, a lot of the items in that table are either wrong or straight out lies (although I'm assuming the former). I'd hate to think what the community around the product is like but I can only assume they live in a bubble similar to those in the Drupal community that thinks for whatever reason that the product they're using is the one and only / best solution rather than truly evaluating the best tool for the job, as far as I can see it unless that page you linked to truly isn't maintained thats the only way you could end up with that quality of information / misinformation available.
Edit2: Formatting
Edit: I clearly can't read. Upvoted you both, thanks.
Sad to see you spreading FUD without knowing much. Let me describe how it's really working.
OpenVZ kernels are based on RHEL (Red Hat Enterprise Linux) kernels. Yesterday we have released OpenVZ 7 which is based on RHEL7 kernel, which is loosely based on 3.10 (I hear you say "old kernel!" -- more on that below).
OpenVZ kernel developers are doing two things: 1. merge our patches upstream; 2. port our patches to a newer RHEL kernels.
As for merging our patches upstream, it's usually happens by rewriting pieces from scratch, and therefore the process is slower than we'd like. So far we have succeeded in having PID and network namespaces, some cgroup controllers, and CRIU (checkpoint/restore, a prereq to live migration -- it's mostly in userspace but there are about 170 kernel patches). I estimate this makes us (Virtuozzo/OpenVZ team) the biggest contributor to the containers in the Linux kernel. This contribution of ours enables technologies such as Docker, LXC etc. In other words, we made Docker and LXC possible.
As for porting our kernels, yes, we use RHEL kernels as a base for ours, as we believe that Red Hat is doing great work keeping their kernels stable and secure. What they do is fork a kernel (2.6.9 for RHEL4, 2.6.18 for RHEL5, 2.6.32 for RHEL6, 3.10 for RHEL7) about a year or so before a RHEL x.0 release, and then they maintain that fork, fixing bugs and improving stability, and sometimes porting new features, but [almost] not introducing new bugs. We value this work, and we use it as a base. So, yes, the latest and greatest RHEL7, and the latest and greatest OpenVZ 7 are based on somewhat rusty 3.10 kernel. Having said that, 3.10 is just a version number of the kernel that was used, a few years back, as a base for the RHEL kernel. It's been heavily patched since that time, but still bears this 3.10 number.
Hope that makes it more clear. Please spread the truth.
> modern, stable, well maintained options
See, we do OpenVZ kernel releases on an almost weekly basis. But since it's 2.6.32, or 3.10, it makes us unmodern, unstable, and not well maintained, right? Wrong.