Re: [debian enterprise] sub-project planning
On Tue, 2003-12-02 at 05:12, Andres Salomon wrote:
> 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.
Great to hear. I started a web page at http://debian-enterprise.org/.
> Initial preparation for Debian Enterprise will take place within Debian
> itself, with the following short-term goals being:
I guess if you're a DD (I'm in the NM-process myself), you can creake
"official" Debian wiki, etc?
> 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.
Good place to start.
> 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.
I'd put security a top priority - hopefully "suggestion C" or something
similar will get implemented soon - see related thread "revival of
signed debs".
> 3. Debian Installer enhancements, and work on getting packages moved
> into testing. Obviously, these things are useful for all Debian users,
...
> thread brought up things like debix and fai, which would be very
> interesting for this sub-project as well.
agreed
> 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).
This is an excellent idea. I haven't previously heard of something that
could as easily get around the release timetable problems. Choosing a
(limited) set of architectures will definitely provide a greater
likelihood of meeting release timetables.
> 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).
Awesome stuff. The great thing about Free Software is that anyone, from
the competant individual to the multinationals, can get involved
providing service where service is wanted, and in the process contribute
back to the community.
> I would like to stress that while Voxel does have commercial motivations
> for getting involved,
And as I put on the web page, a goal of debian-enterprise ("should be",
IMHO) to explicitly support *for-profit* organisations. Let's make no
bones about it - the goal is to make as much profit as possible, such
that we might Do Good Things (TM).
> 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
agreed - seems like we are thinking very similarly here
> 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.
:)
regards
zen
--
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.
Reply to: