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

  • 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

    • Ideally into afs space, owned by the hcoop account.
    • Or not? One reason for it being on local fs space is to remain accessible in case kerberos/afs are gone. This is less of an issue now (and will be even less so once we have multiple volservers and ensure the hcoop volume is on all of them), so might not be worth it. Alternative: set up automatic moin mirroring to outpost using a trivial lighttpd setup.

  • Migrate Portal

    • Move all data storage into afs

    • Hack needed 32-bit libraries

    • Update SMLSQL for libpq5

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