I'm logging off for the night but the first pass of the deploy is now
available at https://git.sr.ht/~tekk/arbor-infra
The basic workflow:
You make your changes in setup.go
If you need to copy config files, those will go in deploy/files

To test your changes or run a deploy, invoke the deploy.sh shell script
with the IP you want to set up.

The deploy script is more or less trivial. It does the following:
Has mage compile the magefile
Tars up the deploy directory
scps it to the remote server's root home
sshes into the server as root, untars, executes the magefile.

At the moment the magefile itself has a handful of targets. I've
parallelized where possible; they're basically split into two sets:
setting up the ssh config and everything else.
It's split that way so that worst case if there's a failure you can ssh
in as root and clean things up/retry.

The targets are:
Users (creates the "user" user we'll all use)
Sudoers (copies the sudoers file from the deploy files)
Apt (installs go with apt)
Firewall (enables ufw blocking all outbound traffic except ntp and https)
and SshConfig (copies our ssh config in place and restarts ssh.)

Firewall rules will need tweaking once we have services running, but
this is what we need now.

Definitely rough but it ought to be a start. Let me know any
questions/comments/flames.

On Sat, Feb 6, 2021 at 12:16 AM Daniel Wilkins <tekk@linuxmail.org> wrote:
>
> I'm logging off for the night but the first pass of the deploy is now
> available at https://git.sr.ht/~tekk/arbor-infra
> The basic workflow:
> You make your changes in setup.go
> If you need to copy config files, those will go in deploy/files
>
> To test your changes or run a deploy, invoke the deploy.sh shell script
> with the IP you want to set up.
>
> The deploy script is more or less trivial. It does the following:
> Has mage compile the magefile
> Tars up the deploy directory
> scps it to the remote server's root home
> sshes into the server as root, untars, executes the magefile.
>
> At the moment the magefile itself has a handful of targets. I've
> parallelized where possible; they're basically split into two sets:
> setting up the ssh config and everything else.
> It's split that way so that worst case if there's a failure you can ssh
> in as root and clean things up/retry.
>
> The targets are:
> Users (creates the "user" user we'll all use)
> Sudoers (copies the sudoers file from the deploy files)
> Apt (installs go with apt)
> Firewall (enables ufw blocking all outbound traffic except ntp and https)
> and SshConfig (copies our ssh config in place and restarts ssh.)
>
> Firewall rules will need tweaking once we have services running, but
> this is what we need now.
>
> Definitely rough but it ought to be a start. Let me know any
> questions/comments/flames.

I just took a look through it, and I think it's looking great! I have
two requests in the short term:

- Can we put a list of URLs to scrape for ssh keys into the config?
Then we could just grab and apply those keys to authorized keys on
deploy.
- Can we go ahead an allow inbound TCP traffic on ports 7117 and 7777?
I'd also like to enable the relays to talk to one another (via
sprout), but I'm not exactly sure what that firewall rule looks like.
Something like `ufw allow out 7117`?

Anyway, this is great progress! Do you already have instances to test
against? I assume that you must, given that you were complaining about
DO the other day. You can definitely create a test instance in our
arbor DO team to test this out with.

For everyone else, I should mention this:
https://git.sr.ht/~whereswaldon/arbor-infra/tree/main/item/droplet/systemd/arbor-relay.service

This is a config repo I created a long ways back to partially manage
the config for our current (messy) infra. This repo (and in particular
the service file linked) may prove useful.

Cheers,
Chris