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.

1. Tasks

= done, = not done, = possibly done, awaiting verification, = gave up or died trying

• Apply advanced wine making techniques to carefully blend the Apache configurations on fritz and mire

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

  • Per-machine apache default vhost

  • Change defaultPhpVersion to 5

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

    • 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

    • ajaxterm

  • Move unknownlamer.org onto navajos (what better a guinea pig)

  • Point hcoop.net at the new machine (also a huge reconfiguration PITA)

• Harrass any users who refuse to leave mire

  • Remove php4 support from domtool

• Turn mire off, remove from rack, set on fire

  • Kill ns3

• Migrate web services from deleuze

  • Migrate and upgrade hcoop wiki

  • Migrate Portal

    • Move all data storage into afs

    • Hack needed 32-bit libraries

    • Update SMLSQL for libpq5 (it builds at least)

Other tasks, lower priority:

• Configuration package nits

  • ssh: restart sshd after installation

    • Actually easy: just setup a trivial postinst/prerm ala hcoop-apache2-config

  • firewall

    • restart ferm after installation

    • install user rules conffiles so firewall works before install fwtool

2. Packages Config

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)

3. Major Open issues

• 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