We could manage the users in various LDAP groups (mainly sudo) through Ansible.
This would be convenient, since it reduces the number of places where the list of admins must be kept in sync.

This is safe, because admins do not need their in-LDAP credentials to login to ldap.hashbang.sh (this is done through a public key) and re-establish their access, should something go terribly wrong.

As @AlissaSquared pointed out in #2, we need to document how to regain access to the various services we use.

That includes:

• Atlantic.net:
  • the Atlantic account itself;
  • the shell boxes;
• DigitalOcean:
  • account;
  • service boxes;
• Github organisation;
• GlobalSign account.

This is good for stuff like rebooting all servers at once, which should be done right now but honestly I have no idea how to go about it.

we have wildcards for {da,sf,to,ny}1 but not de1 even though they're all pointing to the right place. could finally get shell-server#105 sorted

Can use postfix pgsql module. Should replace the current admin-tools/files/postfix/ldap-aliases.cf and line in main.cf

represents changes live on de1

If it's possible, adding something in doc/ would be nice for providing instructions to break out of the /tmp sandbox. @daurnimator @KellerFuchs

• @RyanSquared, key expired 2017-10-29
• @drGrove, key revoked 2017-10-08
• @KellerFuchs, subkeys expired 2017-10-22
• @DeviaVir, key revoked 2017-10-25

Same problem as hashbang/password-store#5, same solution.

Currently, Github is ultimately trusted, since we pull configuration from it, build containers based on repo's contents, ... As a first step away from this (not from using Github, but from trusting it), I suggest we use OpenPGP signatures to protect the authenticity of the git tree.

This is (mostly) straightforward:

• Create a GnuPG homedir in /etc/gpg/, used only for signature checking.
  This allows us to keep the keyring and the GnuPG config (in particular, trust-model direct) in shell-etc.
• Agree to only merge PRs in shell-etc using signed merge commits, as can be created with git merge --no-ff -S.
  When switching to this practice, create an empty, signed commit at the head of shell-etc (if needed).
• Replace etckeeper vcs pull --ff-only in sync.yml with etckeeper vcs pull --ff-only --verify-signatures, with the GNUPG_HOME environment variable set to /etc/gpg/.

There are 2 main issues:

• It doesn't currently seem possible, on Github, to enforce that only signed commits get pushed.
  I've been in touch with Github's support regarding that.
• How do we deal cleanly with commits created by apt(8)?

This requires two things:

• actually writing the config template;
• setting up an encrypted Ansible Vault to store the oper's password hashes in.

Encrypting that is a very good idea, given that some of the oper passwords might be not-so-strong, and we will likely need to store secrets here in the long run (API keys, ...).

This would be much cleaner than parsing with grep and awk.

NOTE: This is a note to myself, I will work on it ;)

http://www.postfix.org/postconf.5.html compatibility_level should be set to 2 to avoid being yote into a chroot

var = "${whatever.var2}" can now be var = whatever.var2

It would be much easier to improve the playbooks and roles if we know which version of Ansible we are targetting.

Currently, we use some v1.9 features (v1.9 is in jessie-backports), but cleaning up on error (in #12 for instance) is much easier using blocks ... which are a v2.0 feature.
Ansible 2.0 is available in Debian Stretch, and it looks like the pin shouldn't be problematic (unlike the weechat one, which ran into ABI breakages).

Admins in agreement:

• @ChickenNuggers
• @daurnimator
• @drGrove
• @KellerFuchs
• @lrvick

We don't have any agreed-upon policy about how we handle users wanting to recover their account.

I would like to propose a way to setup IPSec in transport mode between all our machines, because:

• we can ;)
• it makes sure that communication between our boxes is authenticated and encrypted (I haven't reviewed the TLS settings for everything, and that would be a daunting task...)
• it hides some communication metadata (protocol & port).

However, managing a full mesh by hand is not going to be fun, so we should have a playbook that:

• fetches the IPSec pubkeys, and make the server generate keys if needed;
• sends the pubkeys to all servers (or as a hash in the config?);
• generate the StrongSwan config from a template;
• reloads.

• we can generate mynetworks from shell-servers in the hosts file
• pull userdb connectionstring into a config file

All the other admins should add themselves and their SSH keys here.

Then, we can make ansible remove all the SSH keys that aren't listed here, and the state of the repo will faithfully describe what is on the servers.

• daurnimator
• lrvick
• dgrove
• KellerFuchs
• Alissa

(Expand onto this list when needed)

The documentation (at least README and doc/Installing_packages.md) need to be updated, as they document an obsolete situation.

It would be really convenient to have a playbook for fetching the SSH hostkeys, signing them locally, and uploading the result back as a a HostCertificate.

No compatible private key for etckeeper was found; no packages are installable by any user using two factor authentication until this is fixed or a user adds in a key of their own. Currently I'm setting one up on my own account but I'm unsure of how to set it for the whole organization.

We currently have an outage where lon1.irc.hashbang.sh fails all TLS handshakes.
All users in Europe are only sent a record for lon1.

• The health check should actually perform a TLS handshake and validate the cert, if AWS can even do that.
• We should, longer-term, make sure that all users get at least 2 IRCds in any request.