When telegraf is installed by the monitor_client role, two files are created in the /etc/telegraf/ directory:

• telegraf.conf
• telegraf.conf.sample

Immediately after the install, these files are identical. We take the presence of telegraf.conf.sample as an indicator of whether we have configured the service or not. To configure the service, we customise telegraf.conf to our needs and remove telegraf.conf.sample.

Unfortunately this causes a slight issue when an APT upgrade includes the telegraf package. We run up against a report that the telegraf.conf.sample file in the package is not a match for what is now present on the host.

If you inadvertently omit a host from the host_to_roles_map variable then that will cause playbook failure; for example when templating out the bacula-dir.conf file. The failures are easy enough diagnose but it would be better still if we executed a task right at the start of playbooks that validated the host_to_roles_map and gave a nice, clear "You're missing entries" message instead.

The dns_external role uses an outdated version of the API provided by my chosen hosting provider. I need to modify it to use the current version of the API.

The current bootstrap logic only writes one version, which is the latest full backup and subsequent differentials. It ought to be possible to maintain multiple versions with each complete build that's available in the backup history.

When the WP-CLI tool is run, it is as root, which means that I always have to provide the --allow-root option. Since the tasks that it is used for are tested and automated and I'm the only one with sudo privilege, this isn't a major concern, so a low priority to do anything about this.

We have an occasional error whereby I receive an email notification that fetchmail has failed to authenticate successfully when trying to fetch our home domain emails. Subsequent to that, it then seems to go into a period of never being able to authenticate successfully when fetching the home domain email while continuing to work fine for other emails. The "fix" is to restart the fetchmail daemon, which causes the backlog to come through.

This seems to be associated with specific emails appearing multiple times in our inboxes, possibly in the run up to the problem occurring, certainly for a period after the "fix" above it actioned.

The script that the dns_external role deploys is scheduled using crontab. Investigate whether there are sufficient benefits to changing it to be scheduled by systemctl instead.

The dynamic DNS integration with Linode is raising a record changed report every time, so currently once every fifteen minutes for every DNS record configured. Try to make this only report on actual IP address change.

The dns role sets resolv-file in the dnsmasq configuration to /et/upstream-resolv.conf. I've lost track of the original reason why we needed to use a separate resolve file for this role. Check and confirm.

Because of the absence of Apache rewrite functionality, enabling permalinks other than plain for a WordPress site using the wordpress_nginx role doesn't work. I may try to fix this or perhaps just abandon the use of this role altogether and just use the wordpress_apache role throughout.

I use synchronisation with Dropbox to ensure that there are off-site copies of both bootstrap files and backup media files. Prior to writing new files, I temporarily disable Dropbox synchronisation to ensure that it is not happening while we're writing new files. The backup media files can be quite large.

The Bacula RunBeforeJob and RunAfterJob directives provide a means to temporarily stop and resume the Dropbox synchronisation on the Bacula Director server before and after backup jobs. However, I haven't yet worked out a way to do so on the Bacula Storage Daemon server if this is separate from the Bacula Director server. Consequently, as things stand the Bacula Director and Bacula Storage Daemon services must be co-hosted.

See if a way can be found to remove this deployment restriction.

The initial deploy-host-roles.yml playbook is parsed in a couple of places in this roles library to determine the roles assigned to each host. The backup_director role uses this to determine what to backup on each host. The dns role uses it to determine service lookups to provide for each host.

This is neat. However, it is a layer of complexity and imposes a couple of restrictions on the deploy-host-roles.yml playbook; it hard codes that playbook's name and it dictates that the classic (original) way of using roles in that playbook must be used.

If we need to enable HTTPS for a site then we're going to need a two stage approach to configuring Nginx for that site. It's not possible to bring Nginx up if the site configuration contains references to certificates that don't yet exist on the host. So, we need to do the following:

1. Configure the site for HTTP only
2. Obtain the certificate (okay, maybe three stage!)
3. Reconfigure the site for HTTPS

Currently the wordpress_nginx role forces the co-hosting of the nginx and php-fpm services. It ought to be possible to run them on separate hosts.

The task "Register a certbot account on this host" will run again if it is asked to with an account already in place. It gets around this by not treating a return code of 1 from the register command as failure. This could be improved upon; for example by making the tasks dependent on the previous "Instal certbot APT package" making a change or perhaps using the show_account command that becomes available with certbot version 1.23.0 or maybe I can look into some certbot file to see the account?

The backup_dropbox role installs the Python helper script provided by Dropbox. For some reason when it tries to fetch this script it occasionally receives a 404 response and so the task fails. If you wait a little while and rerun the task, then it works with a 200 response.

Is there a way to deal with this scenario more gracefully; for example some sort of retry until success loop?

When a client is targeted for removal it can be put in the backup_exceptions group but I want to be able to take it out of the schedule while it is still known to Bacula as an interim step.

I hit a memory issue at one point and had to do this for the affected WordPress site so build it into the relevant role(s) here.