The "server edition" of Dapper will be supported for 5 years. This specification lists ideas for the server edition. We would like to improve the profile of Ubuntu as a server platform, and help system administrators to get things done quickly and efficently.

Use cases

Company foo wants to replace their servers and they want a simple install/long time supported platform. They must be able to choose Ubuntu without any fear.

  • They want to test if their hardware is compatible with Ubuntu.
  • They want to stress test the hardware to ensure that Ubuntu will not let them down.
  • They want a single CD install with the best selection of server software with great flexibility.
  • They want a method to verify that their server have not been compromised at any give time or if they suspect that the server has been compromised, be able to perform basic forensics.
  • They want a centralized SSL management system for all their services, without overhead in managing certificates in N different places.
  • They want to be able to use vendor proprietary monitoring/configuration tools without having to download and install manually many small bits of software.
  • They would love to see a "Vendor foo Ubuntu certified hw".
  • They want to be able to use a RCS to handle their config files, specially during deployment to verify local changes and be able (if required) to redistribute them with just a push/pull.


Documentation of security/updates policies

  • We need to document the differences between -security and -updates, highlighting
    • the facts that they are separate and that stuff in -updates requires explicit approval.

Ship a Server Test Suite on the CD

  • The test suite is defined in TestingServerHardware.

  • The test suite will be integrated in the Ubuntu Installer mode
  • The test suite will need to produce reasonable short run results, along with it's full burn-in test results (all this is in the spec on TestingServerHardware).

Third party software inclusion

  • Collect and analize as many proprietary monitoring/configuration tools from vendors (HP, IBM, Sun, Dell, others?).
  • Prepare installation wrappers for them.
  • Test packaging in coordination with elmo/znarl that have hw access at the datacenter.
  • Seed Depends into main and ship them on the cd.
  • Ship tools required by 3rd part vendors to certify hw directly on CD.
  • List is unknown at this time. (See ServerExtApps)

Make adjustments to the seed list

  • In order to provide the best to our server admins we must have feedback from what they need and achieve this by creating a vibrant server community (irc channel, mailing list, wiki docs, more if required).
    • (fabbione to collect info from the community ~ always in progress)
  • Some useful metapackages, e.g. 'system-investigation' would be nice, if we get enough feedback from the users to know what they'd like to see in them.

We need to implement a central snakeoil SSL setup This would be one package that provids SSL/TLS setup for:

  • postfix
  • apache2
  • slapd
  • exim4
  • imap/pop
  • others....

These packages will also need to be modified to look to this new central SSL cert package by default.

  • (infinity/lamont ~ 4 weeks)

Create an MD5 checker for the Ubuntu Installer rescue mode

Target is to provide the possibility to perform basic forensic analisys on offline disks/server.

The implementation requires a client and a server side and needs to be as simple as possible given the limited amount of tools we have in Rescue mode.

Server side:

  • Create a public server of good and trusted md5sum and/or sha1 checksums:
    • Layout a vhost ( that will expose the same directory layout of a normal archive and that will expose $path/$package.deb.{md5,sha1}.
    • Write a script that will run on trusted mirror inside the Datacenter to populate the archive.
    • The $package.deb.{md5,sha1} will contain a simple uncompressed output of md5sum/sha1 calculation of dpkg -e and dpkg -x output of the .deb. The last line of the file will contain the md5/sha1 of the file itself. This will allow the client to verify that the download of the $package.deb.{md5,sha1} is correct.

Client side:

  • Implement set of simple scripts to be able to perform the following checks using the information provided by the server:
    • Single file check.
    • Single deb check.
    • Full deb installation check.
    • Provide full report of the scan.
    • We don't want to reimplement an IDS. Only a simple "warning" tool. An IDS replacement would be too expensive and out of scope from this spec. (fabbione ~ 2/3 weeks)

Provide a RCS /etc out of the box

  • Implement a simple set of scripts that can easily put /etc (by default, and possibly other dirs on request) under bzr control.
  • Implement crontab script that will take care of committing monitored directories on a configurable base (1 hour by default).
  • Implement option to mail admins if there are changes
  • Make it not do backups of sensitive files unless a config option is turned on

  • We would love a working Xen implementation (discussed in

  • We need more and more work on HA (discussed in UbuntuClusters)

  • Some centralized user management system that is not NIS. (discussed in NetworkAuthentication - client is ok, server will be aimed at Dapper+1)

  • Easy way to determine (e.g. look up on a web site) if Dapper will work with a prospective server (discussed in TestingServerHardware)

  • We would really love sane NetworkWideUpdates and AutomaticPackageUpdates implemetations.

  • Simple out of the box monitoring of multiple machines would be a plus.
  • A dtrace port or use/investigate/integrate/package system tap (apparently a dtrace-alike for Linux)
  • Easy integration of log analysis tools, particularly with apache and multiple vhosts.

Reviewer comments

MarkShuttleworth: approved 05 Nov 2005. Very much improved, thank you! I liked the clear separation of the proposed items, and the "future / wishlist" suggestions distinct from the Dapper commitments.

Other comments

XXX: Provide information inside /etc config files about each option, possible choices, etc. to make configuration easier

XXX: Server-oriented drivers, such as lpfcdd from emulex (comes with Suse linux enterprise server)

XXX: Fully automated installations should just work; no interruptions from buggy packages with debconf problems. Use a tool (system-config-kickstart?) to create a configuration which includes debconf preseeding prompts for all packages selected for installation. This includes the ability to choose packages for installation including dependency resolution. The tool could also be used to create a local mirror of the Ubuntu distribution archive. The tool could initiate an installation into a disk image if desired. This would help in debugging packages with debconf priority problems and I imagine could be useful for those who create images suitable for copying directly onto disks. Bonus points if the tool could also manage the pxeboot/tftp configuration.

Configuration in revision control

There is a specification for the implementation of revision controlled /etc: VersionControlledEtc

Integration of directory service

Would be nice to see if fedora directory server would be integrated. Solves the question for centralized identity management, could be a base for a company local trust center and also a base for a directory based configuration management (default configurations).

About Xen and/or virtualization

Someone mentioned Xen as a nice thing to have. I would like to add the following : Whatever virtualization method will be included it will be nice to be available "out of the box" without requiring kernel recompilation. Xen should be the the best approach in terms of security and future support (think of virtualization technology that is being developed at intel with xen in mind) However these alternatives are also good

  • openvz : Works great on centos/fedora and seems to be quite an elegant approach while being very flexible.

  • linux vserver : Classic.

  • usermode Linux : with recommended skas for extra security

  • qemu but it's slow without the commercial kernel module. A GPL-ed effort for a qemu kernel module exists but it does not look to be mature (yet).

Extra Security

Grsecurity or selinux or rsbac or something similar for hardened environments + userland tools to manage the thing. Two kernels could be provided if merging virtualization with grsecurity/selinux/rsbac creates too much problems.However Xen should accept other patches easier. If hardware support for virtualization will be available then xen should work fine with any kernel and set of patches.

Kerberized Apps

Enable Kerberos for use with LDAP (OpenLDAP, Fedora Directory Server, whatever), SAMBA, SSH, PostgreSQL, etc. so that users/admins only need a single sign-on to get some serious work done. Would also support Windows clients nicely, too.

SSH and SSL Certificates

AndrewYeomans: In addition to having unified certificates for postfix, apache2, slapd, exim4, imap/pop it would be great if ssh were included. One issue has been certificate formats: there are several variations in use, both in fundamental structure (X.509, PGP, ssh) and in encoding format (DER, BER). If X.509v3 /PKCS format certificates could be additionally supported by ssh, it would make management easier, for example the certificates could be stored in a common LDAP directory.

This also implies that the client software which uses those servers (Firefox, Thunderbird, Evolution, ssh) should also support the same formats. Which also makes it easier to use client certificate authentication, for a much nicer user experience.

All in one package

There're plans to include Asterisk Open Source PBX ( ) and/or SugarCRM CRM ( ) as deafult Ubuntu's features?

Storage Area Networks

What are the plans for supporting Storage Area Network devices, such as IBM ESS or FAStT, Hitachi and EMC devices and most importantly multipathing software? SAN is extremely important in Enterprises implementing clusters due to its scalability, performance and reliability vs local-attached disk (SCSI, internal IDE).

There is some more information about /etc under revision control at VersionControlledEtc

Centralized client-installation & thin-client-server

JanneOjaniemi: Ubuntu-server should support centralized installation of clients. The server-admins could create bunch of preconfigured client-images on the server. When client with no OS is booted up, it could try netbooting. The Ubuntu-server intercepts the netboot, and presents the user with a boot-image not that different from current LiveCD boot-image. It would contain entries like "Install developement-workstation", "Install secretary-workstation" and "Install thin-client workstsation" (for example. the actual names could be determined by the admins). When user select "Install developement-workstation", a preconfigured image would be dumbed and installed to the client from the server, with no user-intervention. If the user select to install thin-client workstation, that client-machine is confired for thin-client use, after which it would reboot as thin-client machine. The whole process would take just few seconds.

Such a setup could work since workstations are usually standardized in enterprise-environments. This kind of setup would make installation of new clients a snap.


ServerCandy (last edited 2008-08-06 16:18:50 by localhost)