And see NavajosBogMigrationGuide for actually using this stuff.
= 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
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
Migrate web services from deleuze
Migrate and upgrade hcoop wiki
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
restart ferm after installation
install user rules conffiles so firewall works before install fwtool
2. Packages Config
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.
forward all mail for UID < 1000 to logs
Masquerade as hcoop.net
- Newfangled pam-config framework for a fresh squeeze install looks quite promising... (enabled kerberos + unix + afs session)
3. Major Open issues
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)