The playbook is meant to be usable on its own, on any host, the way every other one here is: the first run creates the container, and every run after that converges it. It had picked up a migration shape instead -- a readme that assumed a webroot copied in from monoco, a warning that nagged when config.php was missing, and, worse, readiness gates that only passed for an instance that was already installed. That last one was a real bug for the intended use. On a host with no webroot, the image initialises the code, writes no config.php because it has no admin credentials to install with, and serves the setup wizard -- so `occ status` never reports installed: true, and the play would have spent its whole retry budget and then failed on a first run that was going exactly as designed. What replaces it: - The readiness gate is Apache answering status.php inside the container, which is Nextcloud's own endpoint and reports `installed` either way. It is the one thing `is-active` cannot tell us, and it passes for a wizard that has not been completed. - config.php's presence then decides the report: wait for maintenance mode to clear and print `occ status` for an instance, or say what is left for a human to do for a fresh one -- and succeed. The two optional credentials in vars/default.yml install unattended instead, in which case the same endpoints come back installed and the wizard note never appears. - The app creates its own database. Postgres is a shared unit with one default database and nothing else in this repo knows this app's database name, so a fresh cluster previously reached the installer and failed on "database nextcloud does not exist". It is a lookup and a `createdb`, a no-op afterwards, and it fails with the instruction to run postgres/playbook.yml if the cluster is not there rather than with a bare psql error. - Updates. An update in a Quadlet deployment is "pull, then recreate": the unit names a tag, `podman run` reuses the local image, and nothing fetches a newer one. The role pulls on every run and compares the image ID either side, so an unchanged tag is not a change and a running site is not restarted for nothing. - Handlers are flushed before verification, so a queued recreate -- new image, changed unit, changed environment -- happens before the checks rather than after them, and the checks describe what will keep running. Removed: the entire monoco migration section and its copy commands, the config.php warning that existed only to serve it, the host-specific notes, and the narrative comments about this play's first runs. References to the audit and migration planning docs go with them; the ownership reasoning is stated inline, since it does not depend on where an instance came from. `hosts:` is now the only host-specific thing in the directory. The readme is rewritten around the two paths it now has -- "First run" and "Updates" -- with the deploy order, the session-file trap and the debugging commands kept.
25 lines
1002 B
YAML
25 lines
1002 B
YAML
---
|
|
# Append this site's block to the shared Caddyfile.
|
|
#
|
|
# The Caddyfile is a bind mount into the Caddy container, so Caddy sees the
|
|
# change as soon as the file is written; the handler only asks Caddy to re-read
|
|
# it. That is a reload, not a restart, so the other hosted sites are untouched.
|
|
#
|
|
# blockinfile is idempotent on its own via the marker, so there is no need to
|
|
# slurp the file and compare first — which also matters because slurp *fails*
|
|
# when the Caddyfile does not exist yet, on a host where the Caddy playbook has
|
|
# not run.
|
|
#
|
|
# The marker is stable, so re-runs replace this site's block in place rather than
|
|
# appending a second copy of it.
|
|
- name: "Add the {{ host }} site block to the Caddyfile"
|
|
ansible.builtin.blockinfile:
|
|
path: "{{ caddyfile_path }}"
|
|
marker: "# {mark} Ansible managed Caddy snippet for {{ host }}"
|
|
block: "{{ snippet_block }}"
|
|
create: yes
|
|
owner: "{{ podman_user }}"
|
|
group: "{{ podman_user }}"
|
|
mode: '0644'
|
|
notify: Reload Caddy
|