GitLab

This runs a simple webserver to be called as a project hook from
gitlab. It will eventually (doesn't yet) call gitmail and pull
much of the configuration it needs from the gitlab APIs.

This provides better backward compatibility: it avoids the accidental
dependency on Python 2.7, which is not available under (e.g.) FreeBSD 8.2.

make more sense.

as little of that as possible, so that our images work everywhere.

1. kpartx does not do its own locking, so must protect it from
   concurrent runs during setup.

2. Allow mulitple XEN hosts (up to 4) to set up concurrently via new
   TBScriptLock() shared lock, but revert to exclusive lock if an
   image needs to created or modified.

3. Convert root disk (XEN-STD) to a plain NDZ file from raw LVM bits,
   so that we get some benefit from the buffer cache.

a different error code.

path and since it takes too long, causes the node to get rebooted
when libreboot thinks it has failed.

the same field in the users table, so that clients know to update
users.

locks in addition to the default exclusive mode locks, which is
handy for allowing multiple containers to set up in parallel
since in general they won't be changing anything, just reading.

What a mess.  Conflicts, syntax errors, the works conspired to keep this
from going in.

are the details, so they are recorded someplace.

The Racks do not have a real 172 router for the "jail" network.
This is a mild pain, and one possibility would be to make the
router be the physical node, so that each set of VMs is using its own
router thus spreading the load.

Well, that does not work because we use bridge mode on the physical
host, and so the packets leave the node before they have a chance to
go through the routing code. Yes, iptables does have something called
a brouter via etables, but I could not make that work after a lot of
trying and tearing my hair out

So the next not so best thing is to make the control node be the
router by sticking an alias on xenbr0 for 172.16.0.1. Fine, that works
although performance could suffer.

But what about NFS traffic to ops? It would be really silly to send
that through the routing code on the control node, just to end up
bridging into into the ops VM. So figured I would optimize that by
changing domounts to return mounts that reference ops address on the
jail network. And in fact this worked fine, but only for shared
nodes.

But it failed for exclusive VMs! In this case, we add a SNAT rule on
the physical host that changes the source IP to be that of the
physical host so that users cannot spoof a VM on a shared node and
mount an NFS filesystem they should not have access to. In fact, it
failed for UDP mounts but not for TCP mounts. When I looked at the
traffic with tcpdump, it appeared that return TCP traffic from ops was
using its jail IP, but return UDP traffic was using the public IP.
This confuses SNAT and so the packets never get back into the VM.

So, this change basically looks at the sharing mode of the node, and
if its shared we use the jailip in the mounts, and if it is exclusive
we use the public IP (and thus, that traffic gets routed through the
control node). This sucks, but I am worn down on this.

This is essentially a port of tmcc to Python, without any caching (yet)
and an interface tailored to retrieving GENI information.