Working notes on getting kvm working on fritz. This will need to be integrated into SetupNewMachines and AdminArea after everything is working. See http://wiki.hcoop.net/Migration2009/SoftwareSetup for the gist of what ClintonEbadi is trying to do here, but `s/OpenVZ/KVM via libvirt/g`. And see NavajosBogMigrationGuide for actually using this stuff. === Tasks === (./) = done, {o} = not done, = possibly done, awaiting verification, {X} = gave up or died trying * Apply advanced wine making techniques to carefully blend the Apache configurations on `fritz` and `mire` * {o} Per machine NameVirtualHost config * It turns out that '''both''' the `NameVirtualHost` and `VirtualHost` directive must use `*` or an explicit IP. For the sake of correctness, keeping the IP in `VirtualHost` directives seems like a Good Idea (tm), so we need to have domtool install `/etc/apache2/conf.d/hcoop-namevhost-$machine` for every web serving node. * '''However''': Apache 2.4 removed the `NameVirtualHost` directive so wheezy+1 (or, backports?) won't need this. * {o} Per-machine apache default vhost * {o} Change defaultPhpVersion to 5 * {X} Check all user `domtool` configs and explicitly set `phpVersion = 4` if needed * We'll be supporting php4 for such a short time anyway... * Domtool `mod_proxy` support to machines other than `localhost` * (./) Check DomTool for all used modules and sure they are enabled * (./) Spin up the fancy new Apache KVM and pray that it works * (./) Reinstall using preseed + postinst * (./) Make openafs start earlier in boot process * Things like apache need to resolve pts users; it's easier to divert/transform the openafs script than to divert every script that needs access to afs uids. * {i} This was really hard. insserv in squeeze has weird problems. * (./) Move `gitweb` and `git` hosting over * (./) Set up `rcube` * Install squirrelmail at `squirrelmail.hcoop.net` temporarily (sort of, still on deleuze) * (./) Turn off `fritz`'s Apache (it's the KVM host and KDC ... change of plans, eh) * (./) Move http://debian.hcoop.net to navajos * (./) Move mire web services * (./) phpmyadmin * {X} ajaxterm * (./) Move `unknownlamer.org` onto navajos (what better a guinea pig) * {X} Point `hcoop.net` at the new machine (also a huge reconfiguration PITA) * {o} Harrass any users who refuse to leave mire * {o} Remove php4 support from domtool * {o} Turn mire off, remove from rack, set on fire * {X} Kill ns3 * {o} Migrate web services from deleuze * (./) Migrate and upgrade hcoop wiki * {o} Migrate Portal * {o} Move all data storage into afs * {o} Hack needed 32-bit libraries * Update SMLSQL for libpq5 (it builds at least) Other tasks, lower priority: * {o} Configuration package nits * {o} ssh: restart sshd after installation * Actually easy: just setup a trivial postinst/prerm ala `hcoop-apache2-config` * {o} firewall * {o} restart ferm after installation * {o} install user rules conffiles so firewall works before install fwtool === Packages Config === {{{#!wiki note This, and other information, should be merged into a general description of our infrastructure and how it differs from a stock Debian installation. }}} Things not mentioned on SetupNewMachines that had to have their default debconf values changed. * `ssmtp` * forward all mail for UID < 1000 to logs * Masquerade as `hcoop.net` * PAM * Newfangled pam-config framework for a fresh squeeze install looks quite promising... (enabled kerberos + unix + afs session) === Major Open issues === {{{#!wiki note This, and other things, should be merged into a "Undecided Infrastructure Issues" document, so that folks don't make the mistake that "the path of least resistance" is how we wanted to do things. }}} * Exim setup (have to add to forwardable domains on deleuze) * Figuring out what to do wrt local users for system services that need to access afs * e.g. Apache, Exim, debarchiver, domtool, impad, spamd, ... * AFAICT, it makes more sense to just have afs users -- if the ptdb is gone, the services will not operate in a correct way anyway * Removes issues with keeping UIDs in sync * How does this interact with Debian automatically creating system users for packages? * A few system users were created using `create-user` -- mail is routed to them and they are subscribed to mailing lists and whatnot which is ... probably bad. i.e. We probably want to split `create-user` into the portions to just create an afs/kerberos user and then to do the fancy stuff an actual factual human user needs. * Integration with package requests * Preseeding means we can kill/respin web node images with ease -- but not restore packages users have requested to support their cgi programs * If the portal stores this info, we need a package to reinstall user packages * Is the keytab situation messy? Having the domtool keytab at the toplevel seems out of place * Reading old -sysadmin posts revealed that only having $user.daemon keys was supposed to be temporary -- we really should have a few standard principles for hcoop services to access data (e.g. $user.mail for mail delivery), and have a portal interface (and domtool integration) allowing users to request additional principles if they want (e.g. $user.$webapp-they-run ... or just $user.cgi in the default Just Works (tm) configuration) ---- CategorySystemAdministration CategoryWorkInProgress