| Age | Commit message (Collapse) | Author |
|---|
|
This is used to determine the letsencrypt endpoint to hit.
I used to have a single variable for the endpoint, and I would uncomment the
prod or nonprod endpoint depending on the circumstances.
The two endpoints are given in separate variables in the config file:
acme_server_nonprod and acme_server_prod. Likewise, the renew_script variable
has been split into renew_script_nonprod and renew_script_prod. Choose between
them using the argument.
|
|
We now have different domains managed by different DNS providers. Select the
provider per-domain based on the config file.
|
|
mercuric.uk is now using Mythic Beasts instead of deSEC for DNS, and I'll be
moving the other domains shortly. As a result, I would like to be able to
select between providers them in the config file.
As a first step towards supporting Mythic Beasts, pass the API key ID and
secret to lego.
We can do this in all circumstances: it will be unused if we don't specify
mythicbeasts when the command is invoked.
|
|
I use letsencrypt's nonprod server when testing renewals - especially when
setting up new domains.
I used to have two lines in the config file - one for prod and one for nonprod,
only one of which would be uncommented at any given time.
However, especially since I started running the script via a cron job, there
was a risk that I would forget to change it back.
The end goal is to control the environment via a flag to the renew-all script.
As a first step towards this, hardcode the environment as prod here.
|
|
When I still had a domain for motoristic, I had separate emails and tokens for
it, the idea being that I could hand it over to someone else more easily.
However, I deleted the motoristic server some time ago, and since then, all
servers have used the same email and token. Therefore, retrieve this info from
the common config section instead of the domain-specific section.
|
|
The config file gets installed to here in reality. I could introduce some
config, for example overwriting this during the build process, I think that
would be overkill.
|
|
The web services on fennell-hosted run behind a reverse proxy which I do not
control, and only forwards HTTP/HTTPS traffic. No DNS entries point to the
underlying server. Therefore, the standard approach of using any DNS name that
points to that server does not work here.
I already have an entry in my ssh config for the underlying server under an
alias. So, if I do ssh ${alias}, then it picks up the IP address from that
config file. I want to use the same approach here, without duplicating the IP
address. This means I must use the config file.
This should allow me to use more flexible naming for other servers in the
config file too, matching how I ssh to those servers normally.
|
|
I run a prosody transport server, to interact with legacy networks. Since
invites are disabled on this server, nginx doesn't run and so there's no need
to restart it in this case.
|
|
I no longer host forgejo, so there is no need for a dedicated command to update
the certs.
|
|
This is used for some of the services on fennell.dev, like munin, cgit and
snac.
|
|
It will only get out of date, especially the config section.
I can't see this project being useful for anyone but me, but if someone
contacts me saying they use this repo, I'll recreate the README to match what
questions they have. I don't think that's a likely scenario, though.
|
|
This gives a brief introduction to the goals of the project, and outlines the
config file format.
|
|
Different domains are managed by different identities both in deSEC and
letsencrypt. Therefore, we should store these per domain, instead of globally.
|
|
This project's initial purpose was to automatically renew certiricates across
multiple prosody servers. However, over time, it has been used with more
services, each with their own ad-hoc and custom installation scripts.
This commit replaces the install-for-prosody script with a more general script
that can handle multiple different kinds of services in the future.
|
|
This commit adds the initial structure / scaffolding on which the rest of the
project can be built.
The idea is to have an entry point written in python, which parses a toml file
which contains information about each domain, and general configuration of the
lego tool which will actually renew the certificates. Each domain has an
additional post-renew script, the path to which is given in the config file,
which is used to install the new certificates onto the remote hosts if
necessary.
|
