The *certbot* role now supports copying the data for an existing Let's
Encrypt account to the managed node using an archive. If an archive
named for the inventory hostname (typically the FQDN) of the managed
node is found in the `accounts` directory under the `files` directory of
the *certbot* role, it will be copied to the managed node and extracted
at `/var/lib/letsencrypt/accounts`. This takes the place of running
`certbot register` to sign up for a new account.
The *install* tag is applied to any task that installs a package.
The *user* tag is applied to any task that creates an OS user or group.
The *group* tag is applied to any task that creates an OS user group.
Since the host *gw0* is not a member of the *pyrocufflink.blue* domain,
GSSAPI authentication does not work. As such, the SSH private key has to
be made available to the `ansible-playbook` process for authentication
to that host.
The `zabbix.yml` playbook applies to hosts that are not members of the
*pyrocufflink.blue* domain, and thus have different passwords for
`sudo`. Using the `-e` argument to `ansible-playbook` and specifying a
single Vault-encrypted file that defines the `ansible_become_password`
variable effectively forces Ansible to try to use that password on every
host. This is because variables defined on the command line, or read
from a file specified on the command line, have the highest precedence.
To use different passwords on different hosts, the normal variable
scoping rules have to be used. To that end, one `sudo-pass` file is
created in the `group_vars/pyrocufflink` directory, so it will apply to
all machines that are members of the *pyrocufflink.blue* domain.
Additionally, another `sudo-pass` file is created in the `host_vars/gw0`
directory; it will only apply to the gateway device.
Converting the *pyrocufflink* group variables definition from a file to
a directory will allow Jenkins jobs to place a Vault-envrypted file
within it that defines the `ansible_become_password` variable. In this
way, a different password can be used for machines that are members of
the *pyrocufflink.blue* domain than for other hosts. The existing
mechanism of specifying the path to the Vault-encrypted file that
defines the variable allows only a single password to be defined, so it
does not work when multiple machines in the same play have different
passwords.
The gateway device is now monitored by Zabbix. Adding it to the *zabbix*
group ensures that the Zabbix agent is installed and configured
correctly.
Because the *zabbix-agent* role has a task to configure FirewallD, the
`host_uses_firewalld` variable needs to be set to `false` for *gw0*,
since it does not use FirewallD.
For machines that do not use firewalld, the *zabbix-agent* role will now
skip attempting to open the Zabbix agent port using the `firewalld`
module. The `host_uses_firewalld` variable controls this behavior.
The `gitea_root_url` variable is used to configure the root URL for
Gitea, which is in turn used to generate HTTP/HTTPS "clone" links for
Git repositories. If this value is not set, the default is used, which
does not work since the application is behind a reverse proxy.
The *certbot* role installs and configures the `certbot` ACME client. It
adjusts the default configuration to allow the tool to run as an
unprivileged user, and then configures Apache to work with the *webroot*
plugin. It registers for an account and requests a certificate for the
domains specified by the `certbot_domains` Ansible variable. Finally, it
enables the *certbot-renew.timer* systemd unit to schedule automatic
renewal of all Let's Encrypt certificates.
The *dch-proxy* role sets up HAProxy to provide a revers proxy for all
public-facing web services on the Pyrocufflink network. It uses the TLS
Server Name Indication (SNI) extension to determine the proper backend
server based on the name requested by the client.
For now, only Gitea is configured; the name *git.pyrocufflink.blue* is
proxied to *git0.pyrocufflink.blue*. All other names are proxied to
Myala.
The *haproxy* installs HAproxy and sets up basic configuration for it.
It configures the systemd unit to launch the service with the `-f
/etc/haproxy` arguments, which will cause it to load all files from the
`/etc/haproxy` directory, instead of just `/etc/haproxy/haproxy.cfg`.
This will allow other roles to add frontend and backend configuration by
adding additional files to this directory.
Since Gitea servers may be exposed directly to the Internet, it is
important to prevent SSH tunneling, lest the server become an ingress
point into the network.
Additionally, the *gitea* user should not be allowed to use password
authentication, as this would only work if the user actually has a
password (which it does not) and would result in shell access instead of
Gitea.
The *sshd* role can be used to configure the OpenSSH daemon. It supports
configuring a few options globally, as well as a limited set of options
in `Match` blocks (e.g. per-user/group configuration).
The `trustca` role can be used to add CA certificates to the system
trust store. It requires a variable, `ca`, to be defined, referring to
the name of a file containing a CA certificate to install.
The `gitea_ssh_domain` and `gitea_http_domain` variables can be used to
configure the host portion of the URLs for cloning Git repositories over
SSH and HTTPS, respectively. By default, both values are the FQDN of the
machine hosting Gitea.
The *gitea* role installs Gitea using the system package manager and
configures Apache as a reverse proxy for it.
The configuration file requires a number of "secret" values that need to
be unique. These must be specified as Ansible variables:
* `gitea_internal_token`
* `gitea_secret_key`
* `gitea_lfs_jwt_secret`
The `gitea generate` command can be used to create these values.
Normally, Gitea expects to run its own setup tool to generate the
configuration file and create the administrative user. Since the
configuration file is generated from the template instead, no
administrative user is created automatically. Luckily, the `gitea`
command includes a tool to create users, so the administrator can be
created manually, e.g.:
sudo -u gitea gitea admin create-user -c /etc/gitea/app.ini \
--admin
--name giteadmin \
--password giteadmin \
--email giteadmin@example.org
In order to enable LDAPS/STARTTLS support in Samba, the `tls enabled`
option must be set to `yes` and the `tls keyfile` and `tls certfile`
options must be set to the path of the private key and certificate
files, respectively, that Samba will use. The `samba_tls_enabled`,
`samba_tls_keyfile`, and `samb_tls_certfile` Ansible variables can be
used to control these values.
The `socket options` directive does not need to be specified in
`smb.conf`. I think I copied it from an example many years ago, and
never bothered to remove it. It is definitely not required, most likely
not helping performance at all, and most likely hindering it.
This commit adjusts the firewall and networking configuration on dc0 to
host the Pyrocufflink remote access IPsec VPN locally instead of
forwarding it to the internal VPN server.
The *dch-vpn-server* role configures strongSwan to act as an IPsec
responder for `vpn.pyrocufflink.net` and provide an IKEv2/IPsec VPN for
remote access clients, as well as the reverse VPN to FireMon.
The *strongwan* role is intended to be used as a dependency of other
roles that use strongSwan for IPsec configuration. It deploys some basic
configuration and configures the *strongswan* service, but does not
configure any connections, secrets, etc.
Newer versions of ansible no longer require a single top-level temporary
directory per user, as each run creates its own. Combined with the weird
random failures on *dc0.pyrocufflink.blue* that prevent Jenkins from
using Ansible occasionally, it's better to just let Ansible create its
own temporary directory directly in `/var/tmp` and clean up after itself
when it finishes.
Dustin