Bastian de BylandClaude Opus 5
62c4015410
`@bot restart` saves, sends RCON quit, and relies on the unit's Restart=always to bring the server back. It never came back. The container sat at exited(0) while the unit reported active/running with NRestarts=0, so the bot waited for a startup that was never going to happen and the server stayed down until someone noticed. podman generate systemd emits Type=forking with ExecStart=podman start and a PIDFile pointing at conmon. podman start returns immediately, so the process systemd was told to supervise was never its child -- it warns about exactly this in the journal, once per poll, and then does not notice the exit: zomboid.service: Supervising process 2431312 which is not our child. We'll most likely not notice when it exits. That PIDFile is also stale by design: it embeds the container ID, so every deploy that recreates the container leaves it pointing at nothing. Type=simple with `podman start -a` keeps podman in the foreground as systemd's own child, so the exit is seen and Restart=always does what it always claimed to. stdout and stderr are discarded deliberately -- attaching re-emits the container's output for systemd to capture straight back into the journal, which is the flood the k8s-file driver exists to prevent. podman logs still has it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
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 |