Bastian de BylandClaude Opus 5 eea55def6c retire Graylog behind a flag, fix Caddy reloads, reap awsddns zombies
Graylog was the worst cost/benefit tenant on this 4-core box: two JVMs plus
MongoDB holding ~1.6 GB resident and ~3% CPU around the clock to store ~3k
messages a day -- about 28 MB across its four live indices. journald already
retains ~25 days of the same logs at its 500M cap, so this costs searchability,
not the logs.

The switch is `graylog_enabled` in inventory rather than a role default,
because three roles read it (common, podman, graylog-config). The disabled
path is an active teardown, not a skipped create: the containers already on
the host keep running and their systemd user units keep restarting them at
boot unless something stops and removes them. fluent-bit follows the same
flag -- with the GELF sink down it would spin retrying a dead 127.0.0.1:12202
and fill the journal it exists to drain -- but only the service state follows,
so re-enabling is a restart rather than a reinstall.

Caddy reloads were silently no-ops. The handler read /etc/caddy/Caddyfile,
which is a single-file bind mount, and podman binds those by inode; the
template module writes a temp file and renames it into place, so every deploy
gave the host file a new inode while the container kept seeing the one it was
created with. Config changes only ever landed when something recreated the
container. {{ caddy_path }}/config is also mounted, as a *directory*, and
directory mounts resolve names at open() time -- so /config/Caddyfile is
always the file Ansible just wrote.

awsddns and its four siblings had accumulated 12 zombies over 30 days of
uptime. The image's PID 1 is busybox crond, which only waitpid()s the job PIDs
it tracks and does no generic orphan reaping, so whenever the run-parts/sh
layer exited before the script it left a permanent <defunct>. init: true puts
catatonit at PID 1 to reap them, and the recreation clears the existing ones.

Also bumps fulfillr and greg-time-bot images.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-25 23:40:10 -04:00
2020-09-24 21:06:56 -04:00
2022-04-04 20:26:45 -04:00
2020-09-25 14:22:54 -04:00
2020-09-24 21:06:56 -04:00
2023-05-03 12:30:14 -04:00
2020-09-25 12:04:21 -04:00
2023-07-24 15:25:47 -04:00

Deploy Home

There's no place like home!

Just as Dorothy managed the simple task of clicking her heels together, the desire for an equally simple one-button push deployment was in my heart. Thus, this repository was made.

Build Status

Ansible

Ansible, along with double encrypted secrets, deploys the necessary configurations to make the home fit for certain needs and desires. Namely, having access to my home from anywhere, securely, and a self-hosted CI server that easily ties into existing workflows.

Makefile

The makefile is primarily used as a wrapper script to ensure that necessary files, such as the secret vault password file, are provisioned as part of this. One such addition to the task is utilizing dependency pinning through the utilization of Python's virtualenv to lock down the specific dependency versions within the requirements.txt file. This, ideally, prevents any deployment issues with dependency version woes (e.g. version conflicts, major updates in newest versions, etc.)

Target Name Description
lint (default) Runs yamllint and ansible-lint on all YAML files in ansible/
deploy Deploys everything, or only tasks specified in TAGS= environment variable
check Runs deploy in a "dry-run", showing diff-style outputs on tasks indicating changes
vault Opens the Ansible vault file for editing
S
Description
No description provided
Readme MIT
2.5 MiB
Languages
YAML 49%
Jinja 24.6%
Lua 14.6%
PHP 8%
Python 2.4%
Other 1.4%