[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2018 13:57:30 +0200
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Owl update
On Fri, Jul 06, 2018 at 05:28:22PM +0300, croco@...nwall.com wrote:
> On Tue, Jul 03, 2018 at 01:51:08PM +0200, Solar Designer wrote:
> > On Fri, Jun 08, 2018 at 08:02:15AM +0300, gremlin@...mlin.ru wrote:
> > > On 2018-05-30 15:01:08 +0200, Solar Designer wrote:
> > > > Given what Owl already is and our own primary use cases for it,
> > > > the currently possible migration path is to OpenVZ/Virtuozzo 7
> > > > kernels, which are based on RHEL7's "3.10" kernels.
> > >
> > > After the drop of vzquota (simfs) in favour of ploop, the OpenVZ
> > > had become almost useless.
> >
> > I have to agree. With ploop, it's neither here (containers) nor there
> > (VMs). While ploop might be better for security, no support for simfs
> > breaks straightforward upgrades for systems that currently use simfs and
> > it brings usability drawbacks much like VMs would, yet without switching
> > to VMs. So the point of spending effort on migrating from simfs to
> > ploop is moot - that effort could as well be spent on migration to VMs.
>
> Actually speaking, in many environments simfs was the only possible option.
> When your hosting mashine doesn't have an infinite disk space (and it never
> does), and you offer your users a limit of, say, 100 Gb per VPS, you can
> have no more that 100 containers on a 10Tb disk, while with simfs you could
> have 150-200 of them, or even more, as most of customers never reach their
> limits. Further, when you backup and migrate a stopped container, with
> simfs you had only to transfer actually existing files, but with that damn
> loopback you have to transfer the whole huge file.
It's not that bad. You certainly can overcommit disk space with ploop.
An issue is needing to compact those images once in a while, and those
tools being tied to other ex-commercial-Virtuozzo-only prl* components.
Now this is free software, but that doesn't make it less of a monster.
So we might have a hard time retaining/regaining the ploop compacting
feature if we want to keep only vz* but not prl* tools in future Owl.
For example, for a test container I had created on a test Vz7 install in
2016 and made a little bit use of, the filesystem size is 10 GB, actual
usage is currently 2.6 GB (these are per "df" inside the container),
disk space usage on host prior to compact was 4 GB, after compact it's
down to 3 GB (per "du -s" on the /vz/private directory containing the
ploop image and more).
> Well, may be I'm crazy, but isn't there any chance to fork OpenVZ to get
> simfs back? I strongly believe there are thousands (if not millions) of
> people who would appreciate this. I think this can even attract more
> developers to Owl.
Yes. Actually, simfs without quotas just works (albeit again we'd need
to untie everything from prl* userspace components). Re-adding
first-level quotas for containers (as ext4 "project quotas") looks
realistic. Re-adding second-level quotas (for users inside containers)
looks too complicated, so no more shared hosting inside containers.
https://lists.openvz.org/pipermail/users/2018-July/007492.html
> Well, first of all, the people whose opinion would really be interesting
> for me in this respect, are hardly found on Twitter.
I think you would be interested in their reasoning of you met them
elsewhere, not knowing they have Twitter accounts. ;-) Unfortunately, a
poll like this doesn't let us see who voted nor what their reasoning was
(except for the few replies I received).
> If my opinion is interesting for you, I'd say that:
>
> 1) fork of RHEL has no sense at all, this monster must be buried, not
> forked (and it applies to CentOS, too);
OK, that's your opinion. To me, it's unclear where to draw the line.
Why bury RHEL, etc. and not bury Linux (kernel), which is also a monster
in many ways. When we chose to go with Linux for Owl, we accepted some
monstrosity and inconsistency compared to *BSDs and microkernels. We
did this for a variety of reasons, including meeting demand for Linux.
Maybe the same applies to a RHEL fork (or rather, a fork of RHEL core
only), which could enable us to reuse the security enhancements we've
developed and make them reasonably available to more people.
I also find RHEL clones (CentOS, Scientific Linux) useful for projects
such as our HPC Village.
> 2) fork of Alpine makes more sense, but for me (personally) it will be
> useless; if I choose Owl for my servers, it is NOT for the absence of suid
> binaries nor for using of tcb, but only for its minimalism and strong unix
> tradition compliance, so in case there will be 'hardened' fork of Alpine,
> perhaps I will not bother and either install Alpine as such, or pick
> another distro (well, may be even Slackware)
It sounds like there are already distros suitable for you - as you say,
Alpine and Slackware. Lucky you.
> 3) discontinuation of the project would not make me glad, but, honestly
> speaking, if you prefer to turn it into a fork of some bloatware out there,
> this makes not much of difference for me;
>
> so, I would vote for revitalization of the project as it is the only option
> that keeps Owl useful for me.
Why focus on keeping Owl useful for you when you readily have other
distros you could happily use instead?
> Well, I'm still sure you continue to ignore the thing which I personally
> consider to be the main feature of Owl: its minimalism (and conservatism as
> a kind of consequence). For me, it is more important that Owl uses LILO
> and sysVinit than that it is a bit harder to break in if compared with
> other distros.
Continuing with Owl for its minimalism when there's already comparably
(or more) minimalist Alpine may be unreasonable. Would we be doing it
out of habit, NIH, PR?
> Actually, the whole Linux world seems for me to be going wrong way now, I
> even started to think about switching to FreeBSD;
Same here.
If we can't easily have secure containers on a minimalistic Linux distro
anymore/yet (ironically, in part due to effort of upstreaming
containers, which has resulted in lots of things but not what we had
with OpenVZ), we can as well switch to FreeBSD jails and bhyve.
> as of today, Owl it the
> only Linux distro I know which is not on that way to hell, and that's why I
> do use it.
Is Alpine "on that way to hell"?
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
