ServerCandy

Differences between revisions 15 and 16
Revision 15 as of 2005-11-02 17:06:03
Size: 6185
Editor: 209
Comment: Temporary save
Revision 16 as of 2005-11-02 17:13:00
Size: 6029
Editor: 209
Comment:
Deletions are marked like this. Additions are marked like this.
Line 24: Line 24:
 * I did clean up and reorganize the spec. Added also more cool 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.  * 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.
Line 89: Line 89:
 * Provide  * 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.
  * Provide option to crontab the tool.
Line 91: Line 96:
This has two parts: 1) creating a public server such as pkgsums.ubuntu.com that has known-good md5sums of everything in the archive 2) the creation of a tool that can be run from Ubuntu Installer Recovery mode   * 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.
Line 93: Line 98:

 * The client side program needs to have an interface to check specific files to make sure they match the web archive.
 * The client side program needs to have an interface to check all installed files for a particular deb against the server.
 * The client side program should have an interface to check all installd debs against the MD5 archive.
    --- (fabbione ~ 2/3 weeks)
  (fabbione ~ 2/3 weeks)

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 (debsums.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.
    • Provide option to crontab the tool.
    • 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)

Thirdy 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 (in one pkg) that will easily place /etc (by default, and possibly other dirs on request) under bzr.

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.

BoF agenda and discussion

random input

  • Please add a requeste tracker (request-tracker3.4).

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