[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110829004157.GB9671@openwall.com>
Date: Mon, 29 Aug 2011 04:41:57 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: Owl 4.0 priorities
Vasiliy,
On Sun, Aug 28, 2011 at 12:42:12PM +0400, Vasiliy Kulikov wrote:
> This is my very rough Owl 4.0 plan ordered by the significance:
>
> * GCC update. Look at the work done by Georgi, probably continue it or
> start from scratch.
Right.
This is needed for and allows for not only kernel update, but also glibc
update, although we'll also need to update binutils first (but this
should be easy). So maybe the next steps after gcc update are: binutils
update, glibc update. I think having fresh glibc is highly desirable
for work on and updates of other userland packages. Updating/testing
them on older glibc, which is to be updated before the release anyway,
is a less productive use of our time.
> * SYSLINUX packetizing. Make installer use it instead of LILO.
I think we should start by moving to ISOLINUX for our ISOs. We have
immediate need for this (avoiding kernel size limit). Moving to
SYSLINUX for installed systems is not as important, and is arguably only
desirable after we start using ISOLINUX for CDs (because a reason to
move to SYSLINUX would be to have only one upstream for bootloaders
instead of two different upstreams).
> * Big Kernel Update to RHEL6/OpenVZ. Identify which new CONFIG_* are
> needed for Owl, which are OK to skip, which are needed for modern
> distro run as containers (like cgroups stuff) which need prior code
> review, etc. etc.
Yes. I think the approach may be:
1. Diff our current kernel config vs. OpenVZ's for their RHEL5 kernels.
2. Apply similar changes against OpenVZ's default kernel config for
their RHEL6 branch kernels.
> * Solve CD space issue. Decide to either switch to DVD, or use
> compressed fs for Live CD, or remove (part of) sources from CD.
I think that we'll temporarily exceed CD size during development (will
require DVD), then introduce a compressed fs or exclude sources from CD
(maybe keep kernel sources only, to allow for optional custom kernel
builds when installing new systems).
> * Backport hardening kernel stuff from upstream Linux and from
> NACK'ed/pendind RFCs.
Right. Also submit to OpenVZ and to Red Hat for their consideration.
> * Identify what userspace hardening can be achieved from the updated
> toolchain. Likely enable everything for networking programs.
Right. I think we'll support different build settings, but indeed we'll
need to pick a default.
> * IPv6. Identify which kernel features are mandatory for userspace IPv6,
> which are desirable/optional. Enable IPv6 support in init scripts.
> Identify which packages need a simple passing --with-ipv6 to
> ./configure, which don't support it. Packetize IPv6 related stuff
> (radvd?). Identify sane sysctl defaults.
Right. Also add support to setup and settle.
Of all these sub-tasks, I think support in startup scripts is the most
essential requirement to starting to use Owl with IPv6.
Oh, also I don't know whether our older version of vzctl is able to
configure IPv6 addresses in containers... and indeed it's not aware of
future support for those in Owl's startup scripts. This is an essential
thing to have, too.
> * Packetize new stuff / update existing. ppp*, network sniffing tools,
> LAMP, parted, etc.
Yes. Some of these might be a higher priority than some of the tasks
above, so some of this work should proceed in parallel.
> * Repository setup (apt?).
As discussed, the choice of repository type in part depends on what
libraries we end up packaging anyway, such as for LAMP components.
At this time, all of zypper, apt, and yum are within consideration.
> These are likely to be mixed during the process. However there are some
> rather strong dependencies:
>
> - Kernel update, IPv6, new tools, repository need MUCH space on CD.
I think IPv6 support doesn't need much extra CD space. Other things you
mentioned do.
> - Kernel update, new tools likely need new gcc as some new software
> doesn't compile by our gcc 3.4.5.
Yes, and also because our and our users' time spent testing stuff is
made better use of if such testing is applied to builds that are more
similar to those we'll have in the next release. Updating gcc and glibc
early will result in fewer bugs remaining in the release.
> - Kernel update, IPv6 need syslinux as our lilo's pseudy floppy is
> almost full.
Yes, except that you mean ISOLINUX, not (the rest of) SYSLINUX.
> So, I expect to make big changes in the list during the process :)
Sure.
Thanks,
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.
