Ubuntu Wiki

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

• Created: 2005/10/25 by FabioMassimoDiNitto

• Contributors: FabioMassimoDiNitto

• Packages affected: unknown

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 forensinc.
• 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 achive 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 UbuntuCluster)

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