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.
Description: This is a digitally signed message part