Pin the component at 1.0.2, and check the two things that broke the boot #5

Merged

marcos-mendez merged 1 commit from fix/one-account-declaration into master

2026-09-27 23:28:45 -03:00

marcos-mendez commented

2026-09-27 23:24:30 -03:00

(Migrated from github.com)

unit-redis#3 fixes two defects that the first booted layer found and no build could have, because a build runs everything as root and both were about what that leaves behind.

Redis refuses a user declared twice across configuration files, so the component no longer publishes an administrative account for the first boot to turn on. It is declared once, at the first boot, or not at all. The old shape left redis-server.service in a restart loop and 35redispass failing.
Redis opens every value its logfile setting is ever given, so running the server as root during a build leaves /var/log/redis/redis-server.log owned by root in a directory the redis user owns, and the service then fails to start with Can't open the log file: Permission denied on every machine built from the layer.

conf.d/main checks both on the built tree, because this recipe checks the component rather than trusting it: exactly one account declared in the whole of /etc/redis and not the administrative one, and no log file the service would not be able to write.

Test plan

Both fixes proved by hand in the booted container of the failing layer: service active, admin authenticates over IPv6 with the declared secret, a key written and read back, a wrong secret refused, GET without a secret refused, and keel inspect reporting role: standalone
tests / coverage green here
The layer rebuilt at this pin and the boot test green end to end

unit-redis#3 fixes two defects that the first booted layer found and no build could have, because a build runs everything as root and both were about what that leaves behind. - **Redis refuses a user declared twice** across configuration files, so the component no longer publishes an administrative account for the first boot to turn on. It is declared once, at the first boot, or not at all. The old shape left `redis-server.service` in a restart loop and `35redispass` failing. - **Redis opens every value its `logfile` setting is ever given**, so running the server as root during a build leaves `/var/log/redis/redis-server.log` owned by root in a directory the redis user owns, and the service then fails to start with `Can't open the log file: Permission denied` on every machine built from the layer. `conf.d/main` checks both on the built tree, because this recipe checks the component rather than trusting it: exactly one account declared in the whole of `/etc/redis` and not the administrative one, and no log file the service would not be able to write. ## Test plan - [x] Both fixes proved by hand in the booted container of the failing layer: service active, `admin` authenticates over IPv6 with the declared secret, a key written and read back, a wrong secret refused, `GET` without a secret refused, and `keel inspect` reporting `role: standalone` - [ ] `tests / coverage` green here - [ ] The layer rebuilt at this pin and the boot test green end to end