• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/server-candy

• Created: 2005/10/25 by FabioMassimoDiNitto

• Contributors: FabioMassimoDiNitto

• Packages affected: unknown

DO NOT EDIT THE SPEC! ADD YOUR COMMENTS *ONLY* AT THE BOTTOM

Summary

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 certifactes 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.

Implementation

Documentation of security/updates policies

• We need to documentat the differences between -security and -updates, hilighting
  • 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.

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 (pkgsum.ubuntu.com) 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

Outstanding Issues, Wishlist Items, and Related Specs

• We would love a working Xen implementation (discussed in https://wiki.ubuntu.com/Xen)

• 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)

bzr requirements

(We should probably create a separate spec for the bzr implications)

I'd like to clarify a bit more just what the use cases for this are. Is it just to keep a record of previous configurations and to allow admins to manually diff and roll back?

I think the bzr side of this is practical for dapper -- indeed I might start tracking my /etc in bzr just to see how it goes.

bzr 0.6.2 handles versioning of files, directories and symlinks. On my breezy machine there are no other file types in /etc; if we wanted to handle sockets or similar things in there that would need to be fixed. (But it is rather unclear to me how we could usefully version them; presumably the program that owns them would recreate them and anyhow they should probably be in /var or /dev.)

The main thing that would need to be fixed is to track permissions and ownership. This should not be too hard to do but will require some new code.

At the moment bzr assumes that working copy files are writable - if you try to update a file that's readonly you will get an error. This is probably a feature in typical use but one *might* want to overwrite it for versioning of /etc. This is probably OK if the admin is going to make any reversions manually.

Hardlinked working files would probably also cause confusion but I don't see any of them in /etc either.

Decision to choose bzr

What was the reason to choose bzr above other source control systems?

Was the main reason that bzr has the nice feature that there's only a single .bzr in the top level directory?

I suggest that the Svk project be considered, as it has the same feature. However, svk sits above Subversion, which has proved itself as a reliable source control system and many server admins are familair with it.

It seems a little odd to trust a relatively brand new source control system on an OS that's going to be supported for 5 years. I would rather see something that people are familiar with, even if it doesn't have all of bzr's sexy features.

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. http://openvz.org/

• linux vserver : Classic. http://linux-vserver.org/

• usermode Linux : with recommended skas for extra security http://user-mode-linux.sourceforge.net

• 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.

Other comments in /etc under RCS

Does this advance also include other improvements over Debian's conffile handling? Right now, it only guarantees two versions (the old installed version and and the new package version) are available to examine, and leaves many openings for screw-ups in configuration. A better way would seem to be a three-way merge from the packaged version that the running version in /etc descended from. Basically, I see some nice ideas about keeping better track of /etc, that a lot of sysadmins do on their own, but nothing about integration with the package management system, which is where the real opportunity for advance lies.