I have discussed the idea of a Debian Enterprise sub-project with
various people, and have concluded that it's a worthy goal. I have
listed the technical reasons/goals for this sub-project below.
Initial preparation for Debian Enterprise will take place within Debian
itself, with the following short-term goals being:
1. Discussion and work on an "enterprise" kernel. This will be one of
the first things I tackle, hopefully w/ input on the requested
debian-enterprise mailing list (#222359). The goals for this kernel
will be inclusion of non-experimental features needed by
enterprise-level users utilizing Debian in a server environment. Others
have suggested simply using a Red Hat kernel; however, Red Hat tends to
include experimental features, which are a bit too bleeding edge. I
would like to see things like:
A. Clustering (eg, LVS)
B. Resizable filesystems (device-mapper, ext3online, etc)
C. Security (pax or exec-shield; pax is preferable, but will
require modifications)
D. UML's skas host patch, and so on.
Obviously, suggestions are encouraged, but please hold off until the
debian-enterprise list is created. If the list cannot be created in a
timely manner (w/ developer accounts currently locked, this may be an
issue), I'll host it on a Voxel machine.
2. Given last week's security issues, attention needs to be paid to
package signatures, as well as authentication methods. For packages, we
may want to focus on apt-secure (http://monk.debian.net/apt-secure/);
I'm not sure the status of it, but it will be something that can be
discussed. Of course, this has much interest outside of this
sub-project; the sub-project will merely help it (and its integration)
along. As far as authentication methods, we may want to focus on
ways to allow out-of-the-box OPIE, SRP, or other ways of PAM
authentication. This might be handled w/ a meta-package, for example.
Again, this needs more discussion.
3. Debian Installer enhancements, and work on getting packages moved
into testing. Obviously, these things are useful for all Debian users,
so development on these may or may not be focused on debian-enterprise.
d-i enhancements might include installation types (similar to redhat's
installer; select server, workstation, etc, and have packages selected
for you), support for enterprise features directly in the installer
(choosing certain features may automatically pull in the
debian-enterprise kernel), and so on. The previous debian-enterprise
thread brought up things like debix and fai, which would be very
interesting for this sub-project as well.
These are shorter term goals. Longer term goals include possible
creation of another branch, security updates on this branch, etc. I'm
leaning towards testing snapshots, utilitizing snapshot.debian.net for
package storage (along w/ security updates for these packages). The
goal of this branch will be shorter release cycles (a new release every
2-3 months), longer security updates (end-of-life after 2 years, for
example; 6-8 releases), and focus on only server architectures (m68k
bugs won't, for example, keep a package out of the distribution;
enterprise users don't really care about m68k).
I have discussed this sub-project extensively at Voxel, and we are
willing to commit to seeing this idea through - in a manner that allows
the Debian community to benefit from resources that we put into it. We
are willing to provide developmental resources (Voxel is more than
willing to pay me to head up this sub-project), hardware, legal
resources, bandwidth, and hosting, with development happening under the
Debian moniker. We are also researching the possibility of 24/7
commercial support for enterprise clients, as that is a large part of
what companies want (both for technical support, as well as someone to
blame when something goes wrong).
I would like to stress that while Voxel does have commercial motivations
for getting involved, the entire sub-project will comply fully with the
Debian Social Contract, and will not stray far from the Debian's
official distribution; switching to normal Debian should be a simple
process of using $APT_FRONTEND to download a group of different
packages. I believe this is the cleanest way to accomplish this (as
opposed to forking).
Comments and suggestions are welcome, but I'm not really interested in
another "Debian already is a server distro" flamewar.
Attachment:
signature.asc
Description: This is a digitally signed message part