The only downside I see is spam harvesting and frankly I've got a nice
procmail filter that keeps spam from making it to my buildds (buildd
mail only knows six messages, everything else must be spam). If I was
really clever, I could probably drop such messages earlier. Hmmmm.
If we route all buildd mail via debian (or other) mail servers, that kind
of procmail fitering could happen there.
As I'm already collecting some buildd mails on buildd.net and put those into
IMAP folders, it should be no big deal to receive some additional mails.
There's a spamassassin running as well, of course.
Just an offer...
I'd classify information like ssh connection info and backup admins as
sensitive, and would suggest to keep them out of public view. As the wiki
will need some sort of account management, that should not be too hard to
do.
As I've converted Buildd.Net to use a CMS, it could be suited as well for
that purpose as it gives the possibility to use ACLs based on group
membership and/or particular users.
Just again an offer.
While we're on the topic of renewing buildd.d.o ssh keys - is there any
way to tell the SSH server to accept dynamic DNS addresses, in the sense
that they may not resolve to the dyndns host name on a reverse query?
Otherwise, the buildd.d.o admins would have to accept a rather broad
wildcarding on my part (*.jetstream....), or set up a system to securely
register the current buildd IP address (like dyndns update).
I've thought about setting up my own dynamic DNS service and provide some
kind of VPN (IPsec roadwarrior or OpenVPN) for my buildds, maybe even with
static IP (IPv4 & IPv6) addresses.
Alas, when we would use our own w-b again, all buildds could be hooked up
together by a VPN. That would make some things easier on one hand, but OTOH
it would have some implications as well.