Commit graph

7 commits

Author SHA1 Message Date
Slavi Pantaleev b1c77f9bf2 Add comment to matrix-backup-borg.service
Related to 8005557061
2022-12-05 15:45:33 +02:00
Slavi Pantaleev 8005557061 Give backup-borg container more permissions to perform the backup
Running with a user (like `matrix:matrix`) fails if Etherpad is enabled,
because `/matrix/etherpad` is owned by `matrix_etherpad_user_uid`/`matrix_etherpad_user_gid` (`5001:5001`).

The `matrix` user can't acccess the Etherpad directory for this reason
and Borgmatic fails when trying to make a backup.

There may be other things under `/matrix` which similarly use
non-`matrix:matrix` permissions.

Another workaround might have been to add `/matrix/etherpad` (and
potentially other things) to `matrix_backup_borg_location_exclude_patterns`, but:

- that means Etherpad won't be backed up - not great
- only excluding Etherpad may not be enough. There may be other files we
  need to exclude as well

---

Running with `root` is still not enough though.

We need at least the `CAP_DAC_OVERRIDE` capability, or we won't be able to read the
`/etc/borgmatic.d/config.yaml` configuration file (owned by
`matrix:matrix` with `0640` permissions).

---

Additionally, it seems like the backup process tries to write to at least a few directories:
- `/root/.borgmatic`
- `/root/.ssh`
- `/root/.config`

> [Errno 30] Read-only file system: '/root/.borgmatic'
> Error while creating a backup.
> /etc/borgmatic.d/config.yaml: Error running configuration file

We either need to stop mounting the container filesystem as readonly
(remove `--read-only`) or to allow writing via a `tmpfs`.

I've gone the `tmpfs` route which seems to work.

In any case, the mounted source directories (`matrix_backup_borg_location_source_directories`)
are read-only regardless, so our actual source files are protected from unintentional changes.
2022-12-05 15:42:57 +02:00
Slavi Pantaleev 64b03c2dfd Fix backup-borg repository initialization for borgmatic 1.7+ (or borg 2.0) 2022-12-05 15:00:11 +02:00
Slavi Pantaleev 7086c0ebe3 matrix_host_command_sh -> devture_systemd_docker_base_host_command_sh (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:40:25 +02:00
Slavi Pantaleev a9a81460ec matrix_host_command_docker -> devture_systemd_docker_base_host_command_docker (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:39:35 +02:00
Slavi Pantaleev f03f716989 matrix_systemd_unit_home_path -> devture_systemd_docker_base_systemd_unit_home_path (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:37:47 +02:00
Slavi Pantaleev 410a915a8a Move roles/matrix* to roles/custom/matrix*
This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.
2022-11-03 09:11:29 +02:00