= General Specifications = == All Machines == === Hardware === * RAID1 * Dual Socket * Initially install one four-core processor in each (six-core processors are dramatically more expensive) * Remote reboot and console ability * Most of the servers I have quickly speced out appear to have minimal remote reboot and console ability built in with fancier addon cards for web interfaces and other things; we should be ok with just the baseline module. === Software Choices === ==== Virtualization ==== Virtualization would allow us to avoid having to dedicate an entire physical machine to the KDC/AFS server. It would also allow us to snapshot and migrate VM instances between machines in the future if needed. OpenVZ at least allows VM images to be suspended, migrated to another physical machine, and resumed with no apparant interuption to userspace (aside from network connections and such potentially timing out). This kind of flexibility would make future expansion a lot less painful. == Core Services Machine == === Hardware === * 2U * 8GB RAM (initially) * We should probably use 2G or 4G modules to ensure we can upgrade to 16/32G without having to replace memory * Dual RAID1 Arrays (ideally room for 6 drives; 2 hot spares?) * Large (750G - 1TB?) array for AFS and only AFS * Smaller (250G?) array for OS images / databases * Redundant power supplies === Software === * Base operating system should just be Debian setup either as a Xen or OpenVZ server * Things which logically belong in separate machines go into VM images * KDC/AFS (and nothing else except perhaps LDAP) * Core Network Services * Domtool * Portal * Bugzilla * HCoop MoinMoin * DNS * SFTP (if we want to continue supporting it) * Mail delivery * Still into AFS space? At the very least users should be permitted to directly access their Maildir somehow * '''Note''': if we continue to use procmail users can run program on this machine; procmail should run in a restricted shell with access to a few external programs useful for mail filtering but nothing else * Databases * Dedicated partition on the smaller array for database storage (potentially with its on RAID1 in the far off future?) == User Services Machine == === Hardware === * 1U * 8G RAM * Mostly allocated to user daemon image * Single RAID1 Array * Not too large (250G? Any smaller does not seem cost effective) * Local VM image disk space * Some amount of space for users (80G?) * Users who need fast local disk could request a portion of this (enforced using quotas etc.) === Software === * Also a Xen/OpenVZ server * VM Images * Secondary KDC * Do we need to have a secondary AFS server with ro copies of user volumes? Or at least some core volumes all machines need? * Web serving * Should we continue to use Apache? I know it would involve rewriting the domtool Apache modules, but it doesn't seem like we use Apache more than for static file serving, url rewriting, and proxying. All of which can be done with a smaller server that will probably be easier to maintain (e.g. see our current mysterious issues that have defied all debugging) * Should users have direct access to this image? Perhaps we could either write a small config utility or extend domtool to enable running programs automatically in the image; users could then configure their daemons on the general user image. I can see a few issues with controlling the remote daemons, but maybe we can work this out (perhaps using runit) * General user access * Users ssh here and run whatever * Either just a general use shell server or combined with the web serving image * IMAP/Jabber * If we choose to not deliver mail into AFS space at least IMAP will need to go onto the core machine; Jabber is lightweight and does not present a security risk so it can just go wherever IMAP does