Just a bunch of little things, mostly, except for the decision to remove the hot-standby server (because the
newer postgresql configuration is completely different, and I don't think it was ever necessary for performance
or fault-tolerance).

I've run this on a new server installed with Ubuntu Noble, and transferred the data from 1.shaman.ceph.com with pg_dumpall -> pg_restore -> psql:

1.shaman:
pg_dumpall -c --quote-all-identifiers -f dumpall.sql
(copy dumpall.sql to new server)
1.new:
dropdb shaman
pg_restore -c -C -f restore.sql dumpall.sql
psql < restore.sql

The new server provides a working web UI, and I validated the newest fix from #147 as follows:

1. create a project 'dmick'

2. create 1.json:

{
  "url": "url1",
  "status": "ready",
  "distro": "distro1",
  "distrover": "distrover1",
  "distro_arch": "distroarch1",
  "ref": "ref1",
  "sha1": "sha1_1",
  "flavor": "default",
  "extra": {
    "version": "ver1",
    "job_name": "dmick-synthetic"
  }
}

curl -v -X POST -H "Content-Type: application/json" -d @1.json -u "admin:****" 'https://1.shaman.new.ceph.com/api/builds/dmick/'

4. change distro_arch to 'distroarch2' and post again as above:

$ diff 1.json 2.json
6c6
<   "distro_arch": "distroarch1",
---
>   "distro_arch": "distroarch2",

5. verify with psql that both build records exist, differing only in distro_arch value

I should be able to schedule some downtime, bring 1.shaman and 2.shaman's service down, take a last dumpall of the DB and load it into the new server, then twiddle the server IPs to have the new server take over at 1.shaman (to avoid DNS-TTL-timeout delays for all consumers) in fairly short order.