Skip to content

feat(roles/redis, roles/valkey): listen on a Unix socket that the service group may use - #421

Open
NavidSassan wants to merge 6 commits into
mainfrom
feat/redis-valkey-unixsocket
Open

NavidSassan wants to merge 6 commits into
mainfrom
feat/redis-valkey-unixsocket

Conversation

@NavidSassan

Copy link
Copy Markdown
Member

Extracted from #396, which builds on it: Nextcloud connects to Redis / Valkey through this socket.

Changes

  • role:valkey, role:redis: listen on a Unix socket in addition to TCP. On RHEL the path is the one the package ships (/run/valkey/valkey.sock, /run/redis/redis.sock), on Debian and Ubuntu, whose packages ship the socket off, /run/valkey/valkey-server.sock and /run/redis/redis-server.sock. *__conf_unixsocketperm defaults to 770, so the members of the service group may connect; without it the mode follows the service's umask (0755) and only the daemon itself could. Redis has no unixsocketgroup (Valkey added it in 8.0), so access goes through the group on both. *__conf_unixsocket stays out of argument_specs, since its default comes from vars/<os>.yml, which is loaded after the role-entry validation.
  • role:valkey, role:redis: keep the ownership of the config file that the package sets. The RHEL packages ship Z /etc/valkey ~0750 valkey root (and the same for Redis from Remi) in tmpfiles.d, which systemd-tmpfiles applies at every boot, so the root:valkey the role set flipped back and the next run reported a change. Debian and Ubuntu keep root:valkey.
  • role:redis: meta/argument_specs.yml, derived from the valkey role, whose variables and static defaults are the same; checked with validate_argument_spec against every static default.
  • molecule valkey: asserts that valkey answers on the socket, that the socket is open to its group only, and that the config file has the package's ownership and is not world-readable.

Tests

… use

The RHEL package enables /run/valkey/valkey.sock, the templates commented it
out. valkey__conf_unixsocket follows the package path on RHEL and uses
/run/valkey/valkey-server.sock on Debian and Ubuntu, whose package ships the
socket off. valkey__conf_unixsocketperm defaults to 770: without it the mode
follows the umask of the service (0755), so only valkey itself could connect.
valkey__conf_unixsocket stays out of argument_specs, since its default comes
from vars/<os>.yml, which is loaded after the role-entry validation.
Same as for Valkey. The Remi package for EL9 (redis 8.8) enables
/run/redis/redis.sock with the mode left to the umask. Redis has no
unixsocketgroup (Valkey added it in 8.0), so access goes through the redis
group on both.
Derived from the valkey role, whose variables and static defaults are the
same; checked with validate_argument_spec against every static default of
the role.
… sets

The RHEL package ships `Z /etc/valkey ~0750 valkey root` in tmpfiles.d, which
systemd-tmpfiles applies at every boot and on every RPM tmpfiles trigger, so
the root:valkey the role set flipped back to valkey:root and the next run
reported a change (verified on Rocky 10). Debian and Ubuntu keep root:valkey.
With this, a second run of setup_nextcloud on a fresh Rocky 10 reports
changed=0.
Same as for Valkey: the Remi package ships `Z /etc/redis ~0750 redis root` in
tmpfiles.d (redis 8.8 for EL9).
@NavidSassan

Copy link
Copy Markdown
Member Author

Molecule valkey is green on Debian 13, Rocky 10 and Ubuntu 26.04 (converge, verify, idempotence, verify), ansible-core 2.16. The redis role has no scenario of its own; it is only exercised through setup_nextcloud on Rocky 8/9 in #396.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants