ServerCandy

Revision 20 as of 2005-11-04 00:06:53

Clear message

Reviewer Comments

  • MarkShuttleworth:

    • WHAT seed changes? Make some concrete proposals please, don't just push it off.

In general, this spec is too hand-wavy and incomplete to be approved.

Response to Comments

  • I clarified everything I can, and wrote out more detailed descriptions of the data that needs to be gathered before we can finalize the seed list. I hope it makes more sense now.

    FabioMassimoDiNitto:

  • I did clean up and reorganize the spec. Added also more stuff that we can do out of the box or on sysadmin request. I am also considering splitting the spec into smaller specs for readability, but the implementation bits should be the same afaict.

Summary

The "server edition" of Dapper will be supported for 5 years. We need to make sure that we have thought of things that will be attractive for system administrators, to raise interest in Ubuntu as a server OS. This specification lists ideas for the server edition.

Rationale

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

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

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:

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

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)

Third part 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.

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

(talk with James about implementation)

Outstanding Issues

Bling is not really something system administrators value on the server. They want stability, they like things that just work, and sane defaults.

random input

RE-DRAFT NOTES OF DESTINY

Me, and mine's personal wishlist:

  • Xen (https://wiki.ubuntu.com/Xen)

  • HA (UbuntuCluster)

  • Documentation of -security and -updates policy, and the fact
    • that they are separate. And that stuff in -updates is approved, unlike e.g. Debian.

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

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

  • Sane NetworkWideUpdates implemetation

  • AutomaticPackageUpdates too, for fun and profit

  • As easy as possible out of the box monitoring of multiple machines
  • dtrace port or use/investigate/integrate/package system tap
  • Useful meta packages, e.g. 'system-investigation' or something
  • Easy integration of log analysis, particularly with apache