New certbot setup #23

2019-03-14T20:24:44Z

greg commented

2019-03-14 20:24:44 +00:00

I have also switched back to the nginx cookbook, we were still using the deprecated chef_nginx fork, the official cookbook is nginx again

Let's merge this one, then I can add the Let's Encrypt setup to the ejabberd PR. I have already executed this on andromeda, and created the initial cert for the kosmos.org cert manually with it. On the automated renewal (done by the systemd timer set up by the package) the cert will be concatenated and the permissions set, and the ejabberd service will be reloaded using the ejabberdctl reload_config command after a successful deploy (/etc/letsencrypt/renewal-hooks/deploy/ejabberd on andromeda, coming up in the ejabberd PR once this is merged)

For an example of a nginx vhost, see site-cookbooks/kosmos-ipfs/recipes/letsencrypt.rb

Refs #1

I have also switched back to the nginx cookbook, we were still using the deprecated chef_nginx fork, the official cookbook is nginx again Let's merge this one, then I can add the Let's Encrypt setup to the ejabberd PR. I have already executed this on andromeda, and created the initial cert for the kosmos.org cert manually with it. On the automated renewal (done by the systemd timer set up by the package) the cert will be concatenated and the permissions set, and the ejabberd service will be reloaded using the `ejabberdctl reload_config` command after a successful deploy (`/etc/letsencrypt/renewal-hooks/deploy/ejabberd` on andromeda, coming up in the ejabberd PR once this is merged) For an example of a nginx vhost, see `site-cookbooks/kosmos-ipfs/recipes/letsencrypt.rb` Refs #1

❤️ 1

raucao commented

2019-03-15 05:47:35 +00:00

I found a few issues with this:

Resolved:

The domain was hardcoded 12 times in the recipe for no apparent reason. I pushed a commit that moves it to a node attribute.
The email address used for LE was a 5apps one. I changed it to a kosmos one (but not sure if we have ops@ created).

Open:

A lot of the LE stuff would be exactly the same in any cookbook needing a cert. These resources should be defined in a provider/lib, merely handing over the domain name and having it create ACME directories, execute certs etc.
Similarly to 1, the ACME config is using webroot, but the port 80 config is mixed in with the custom nginx template. Why not move this to a seperate vhost for only the ACME calls. Any nginx site would want to re-use that and also redirect to HTTPS.
The "api_port" variable is defined for nginx specifically, but that should be/come from ipfs general config.
I'm pretty sure "external API port" 5444 should not be open in production, and I couldn't find documentation that says anything but the swarm p2p port (4001) should be open. In any case, it shouldn't be hardcoded for an nginx template, but also come from normal ipfs config/attributes imo.

I found a few issues with this: Resolved: * The domain was hardcoded 12 times in the recipe for no apparent reason. I pushed a commit that moves it to a node attribute. * The email address used for LE was a 5apps one. I changed it to a kosmos one (but not sure if we have ops@ created). Open: 1. A lot of the LE stuff would be exactly the same in any cookbook needing a cert. These resources should be defined in a provider/lib, merely handing over the domain name and having it create ACME directories, execute certs etc. 2. Similarly to 1, the ACME config is using webroot, but the port 80 config is mixed in with the custom nginx template. Why not move this to a seperate vhost for only the ACME calls. Any nginx site would want to re-use that and also redirect to HTTPS. 3. The "api_port" variable is defined for nginx specifically, but that should be/come from ipfs general config. 4. I'm pretty sure "external API port" 5444 should not be open in production, and I couldn't find documentation that says anything but the swarm p2p port (4001) should be open. In any case, it shouldn't be hardcoded for an nginx template, but also come from normal ipfs config/attributes imo.

greg marked the pull request as work in progress 2019-03-15 08:21:59 +00:00

greg commented

2019-03-15 08:23:50 +00:00

Thanks for the review, I'm going to create a resource to remove the duplication and take care of the questions about ports too

👍 1

greg commented

2019-03-15 11:19:45 +00:00

Re: opening up port 5444 for IPFS, it's what Kredits is using to connect to ipfs-cluster

raucao commented

2019-03-15 11:38:16 +00:00

Kredits is not supposed to connect to ipfs-cluster. It is supposed to
only connect to ipfs via the nginx proxy site, and only via the
methods/URLs exposed in that.

Kredits is not supposed to connect to ipfs-cluster. It is supposed to only connect to ipfs via the nginx proxy site, and only via the methods/URLs exposed in that.

greg commented

2019-03-15 12:25:21 +00:00

Yes, that's exactly what this is, through the nginx vhost that exposes only selected URLs to port 5444. It's connecting to ipfs-cluster instead of ipfs so the pins are done on the cluster

raucao commented

2019-03-15 12:57:14 +00:00

Ah, I see. That makes sense then. But it's not clear from the code really, as proven by my confusion.

raucao commented

2019-03-16 07:16:23 +00:00

17f1b2a20a is very cool! So much cleaner now. 👏

What's the WIP task that's left?

17f1b2a20ae667e9f93b06e8139fc72b202a31c7 is very cool! So much cleaner now. :clap: What's the WIP task that's left?

greg marked the pull request as ready for review 2019-03-16 09:47:30 +00:00

greg commented

2019-03-16 09:47:55 +00:00

I think this is good to go, I forgot to remove the WIP tag

raucao commented

2019-03-18 08:13:09 +00:00

Did you run this against one or more servers already? Code lgtm.

greg commented

2019-03-18 09:09:06 +00:00

I successfully ran it against andromeda, but it only had one vhost. dev is where all the vhosts are right now, once I run it there I think we can merge this

raucao marked the pull request as work in progress 2019-03-18 09:50:50 +00:00

raucao commented

2019-03-18 09:51:11 +00:00

If it's not safe to merge right now, then it's still WIP. I added the tag back to the title.

greg marked the pull request as ready for review 2019-03-18 16:22:32 +00:00

greg commented

2019-03-18 16:23:49 +00:00

I ran it successfully on dev. I edited /etc/letsencrypt/renewal/wiki.kosmos.org.conf, /etc/letsencrypt/renewal/sockethub.kosmos.org.conf, and /etc/letsencrypt/renewal/kosmos.social.conf manually to change the root directory to the new one (now standardized to /var/www/#{domain.ltd})

I ran it successfully on dev. I edited `/etc/letsencrypt/renewal/wiki.kosmos.org.conf`, `/etc/letsencrypt/renewal/sockethub.kosmos.org.conf`, and `/etc/letsencrypt/renewal/kosmos.social.conf` manually to change the root directory to the new one (now standardized to `/var/www/#{domain.ltd}`)

greg closed this pull request

2019-03-18 16:24:00 +00:00

greg deleted branch feature/1-lets_encrypt

2019-03-18 16:24:22 +00:00

greg commented

2019-03-18 16:25:17 +00:00

I also had to install certbot without using the PPA on 15.04 (5fa0fa6)

I also had to install certbot without using the PPA on 15.04 (5fa0fa6)

raucao commented

2019-03-18 16:45:17 +00:00

Good. Please don't forget to add kredits labels before merging pull requests.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#23