ipng/ipng.ch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Replace all post_url with Hugo ref blocks

Browse Source
This commit is contained in:
Pim van Pelt
2024-08-05 01:43:55 +02:00
parent c1f1775c91
commit a2f10236a3
56 changed files with 221 additions and 241 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
content/articles/2023-08-27-ansible-nginx.md
View File

@ -39,7 +39,7 @@ pim@squanchy:~/src/paphosting/scripts$ wc -l *push.sh funcs
1468 total
```
In a [[previous article]({% post_url 2023-03-17-ipng-frontends %})], I talked about having not one but a cluster of NGINX servers that would
In a [[previous article]({{< ref "2023-03-17-ipng-frontends" >}})], I talked about having not one but a cluster of NGINX servers that would
each share a set of SSL certificates and pose as a reversed proxy for a bunch of websites. At the bottom of that article, I wrote:
> The main thing that's next is to automate a bit more of this. IPng Networks has an Ansible controller, which I'd like to add ...
@ -83,7 +83,7 @@ I'm not going to go into all the details here for the **debian** playbook, thoug
all servers (bare metal or virtual). The one thing I'll mention though, is that the **debian** playbook will see to it that the correct
users are created, with their SSH pubkey, and I'm going to first use this feature by creating two users:
1. `lego`: As I described in a [[post on DNS-01]({% post_url 2023-03-24-lego-dns01 %})], IPng has a certificate machine that answers Let's
1. `lego`: As I described in a [[post on DNS-01]({{< ref "2023-03-24-lego-dns01" >}})], IPng has a certificate machine that answers Let's
Encrypt DNS-01 challenges, and its job is to regularly prove ownership of my domains, and then request a (wildcard!) certificate.
Once that renews, copy the certificate to all NGINX machines. To do that copy, `lego` needs an account on these machines, it needs
to be able to write the certs and issue a reload to the NGINX server.
@ -196,8 +196,7 @@ In order:
* `conf.d/options-ssl-nginx.inc` and `conf.d/ssl-dhparams.inc` are files borrowed from Certbot's NGINX configuration, and ensure the best
TLS and SSL session parameters are used.
* `sites-available/*.conf` are the configuration blocks for the port-80 (HTTP) and port-443 (SSL certificate) websites. In the interest of
brevity I won't copy them here, but if you're curious I showed a bunch of these in a [[previous article]({% post_url
2023-03-17-ipng-frontends %})]. These per-website config files sensibly include the SSL defaults, custom IPng headers and `upstream` log
brevity I won't copy them here, but if you're curious I showed a bunch of these in a [[previous article]({{< ref "2023-03-17-ipng-frontends" >}})]. These per-website config files sensibly include the SSL defaults, custom IPng headers and `upstream` log
format.
### NGINX Cluster: Let's Encrypt
@ -208,9 +207,9 @@ Name Indication_ or SNI. Let's first take a look at building these two of these
one for [[FrysIX](https://frys-ix.net/)], the internet exchange with Frysian roots, which incidentally offers free 1G, 10G, 40G and 100G
ports all over the Amsterdam metro. My buddy Arend and I are running that exchange, so please do join it!
I described the usual `HTTP-01` certificate challenge a while ago in [[this article]({% post_url 2023-03-17-ipng-frontends %})], but I
I described the usual `HTTP-01` certificate challenge a while ago in [[this article]({{< ref "2023-03-17-ipng-frontends" >}})], but I
rarely use it because I've found that once installed, `DNS-01` is vastly superior. I wrote about the ability to request a single certificate
with multiple _wildcard_ entries in a [[DNS-01 article]({% post_url 2023-03-24-lego-dns01 %})], so I'm going to save you the repetition, and
with multiple _wildcard_ entries in a [[DNS-01 article]({{< ref "2023-03-24-lego-dns01" >}})], so I'm going to save you the repetition, and
simply use `certbot`, `acme-dns` and the `DNS-01` challenge type, to request the following _two_ certificates:
```bash