[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180608050215.GA14327@gremlin.ru>
Date: Fri, 8 Jun 2018 08:02:15 +0300
From: gremlin@...mlin.ru
To: owl-users@...ts.openwall.com
Subject: Re: Owl update
On 2018-05-30 15:01:08 +0200, Solar Designer wrote:
Sorry for a late reply...
>> You said you started the Openwall project because every time you
>> set a new server, you had to spend a lot of time to secure it.
> With Owl, time had to be spent on installing use case specific
> software on top of it. This was no different compared to our uses
> of distros of late 1990s, where such software was also either
> not packaged or at least not in the way we wanted it anyway.
Alas, this software became almost useless very quickly.
> Then other distros progressively got more functionality built-in.
However, most of those (I can't tell surely for all) are unusable
out-of-the-box because the developers have no idea on who are their
users and what they really need.
> Owl without even a web server in it started looking especially
> weird to many prospective users. We had our own set of packages
> for use on top of Owl, eventually called OwlX, but we never
> brought it to a state where we'd be comfortable releasing and
> maintaining it for the general public.
The same mistake here: s/general public/system administrators/
These people just want the system to perform a relatively small set
of tasks and be convenient with setting it up to do that.
> After my security audit of OpenVZ in 2006, we also started using
> Owl along with OpenVZ kernels
> With this, Owl made more sense for use by others: yes, its package
> set was still very limited, but that was actually good for use on
> "hardware nodes", where other distros could also be run in VEs aka
> containers.
And with that we've stucked on 2.6 kernels... well, I've successfully
moved to 2.6.32-vz which was still supported even by a quite recent
glibc-2.26, and that allows me to continue using my own Owl derivatives
on my servers.
>> Regarding to Owl's future. Currently, thanks to your cooperation
>> with Salvatore Mesoraca[1], more and more solutions developed
>> for the Owl's kernel begin to go to linux.
> That's not how I see it. As you correctly noted above, Owl was/is
> primarily about the hardened userland. Some of the things we tried
> out in Owl got into a few other distros (especially ALT Linux's,
> so it's also where we might take forward-ported patches from
> if we revitalize Owl)
ALT was started as (and still is) a desktop system. After many years
of development it become "dirty", having many redundant dependencies
(when I recently tried to install LibreOffice on my workstation, it
attempted to pull gcc-fortran as a chained dependency). That could
be tolerated on a desktop, but will definitely be inacceptable for
servers.
That means, even just taking patches would likely take much time.
>> I wonder if it would be sensible to use Owl userland also on
>> other kernels. This would allow better use of the new hardware
>> (eg. CPU's, amr64).
> Sure, but who would be the users and why would they prefer Owl?
1. servers
2. embedded systems, including network hardware
> Also, what other kernels?
I'd guess: recent 4.*
> 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.
On 2018-04-24 I tried asking the people from OpenVZ team whether
there would be UBC and simfs support in the newer 4.* (4.14-based)
kernels, but got no answer - not even a single fuqoff.
> This also makes sense from a security standpoint: newer kernels
> tend to contain new vulnerabilities, whereas RHEL7 is already
> mature.
Newer kernels do support newer hardware. Without that, the kernel
is useless.
> I see little point, other than "marketing", in introducing any of
> that to Owl at this time. We need containers anyway, they're most
> mature in OpenVZ/Virtuozzo, and upgrading within the same container
> technology is most straightforward. Containers are easier to
> use and reason about than policies with a single larger system.
That applies to both virtualization techniques, VPS and VDS.
> We could possibly develop a semi-stable branch with OpenVZ 7
> kernels and a current branch with latest mainline kernels, but then
> the current branch would lack support for OpenVZ containers and
> wouldn't be able to build vz* packages (unless we build it/them
> with OpenVZ kernel headers). This would have some advantages -
> "marketing" ("yes, we have a branch with latest kernels"), a
> playground for submitting kernel patches upstream, and making our
> userland ready for newer OpenVZ kernels as well (perhaps based
> on RHEL8 and on). However, it would also be hackish and it'd
> interfere with our usual approach of turning a matured current
> branch into a stable branch.
That's normal: even being "hackish", that would decrease the TCO
and, therefore, could attract more customers (not just users).
--
Alexey V. Vissarionov aka Gremlin from Kremlin
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8
Content of type "application/pgp-signature" skipped
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.
