ServerCandy

Differences between revisions 16 and 17
Revision 16 as of 2005-11-02 17:13:00
Size: 6029
Editor: 209
Comment:
Revision 17 as of 2005-11-02 17:32:17
Size: 6226
Editor: 209
Comment: More cleanup
Deletions are marked like this. Additions are marked like this.
Line 84: Line 84:
  * 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.
  * 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.
Line 94: Line 93:
  * Provide option to crontab the tool.
Line 115: Line 113:
 * Implement a simple set of scripts (in one pkg) that will easily place /etc (by default, and possibly other dirs on request) under bzr.  * 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

(talk with James about implementation)
Line 119: Line 121:
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 ==
Bling is not really something system administrators value on the server.
They want stability, they like things that just work, and sane defaults.
Line 125: Line 126:
 * Please add a requeste tracker (request-tracker3.4).  * Please add a requeste tracker (request-tracker3.4)
 * http://www
.linux.com/article.pl?sid=05/10/26/215206

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

(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

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