Onboard redis as a Keel appliance #1

New issue

Closed

opened 2026-09-27 06:05:38 -03:00 by marcos-mendez · 1 comment

marcos-mendez commented

2026-09-27 06:05:38 -03:00

(Migrated from github.com)

Closes when the recipe builds as a Keel layer carrying a redis unit, the project
packages are installed and asserted against the archive rather than a literal
version, bind takes literal addresses, and a boot test proves a client
authenticates over IPv6 with the declared secret and that Webmin answers.

Note for later, not for this issue: Debian 13 also ships valkey-server, the
fork made after the licence change. The same unit should be able to serve both.

This repository is still an untouched fork of the upstream recipe. Redis is one of the three engines the maintainer chose, and it is the one where the modes are cheapest: replication is `replicaof` with `masterauth`, failover has `redis-sentinel` packaged with the server, and sharding is native in Cluster with no extra package, where PostgreSQL has none packaged and MariaDB needs Spider. Closes when the recipe builds as a Keel layer carrying a redis unit, the project packages are installed and asserted against the archive rather than a literal version, `bind` takes literal addresses, and a boot test proves a client authenticates over IPv6 with the declared secret and that Webmin answers. Note for later, not for this issue: Debian 13 also ships `valkey-server`, the fork made after the licence change. The same unit should be able to serve both.

marcos-mendez commented

2026-09-27 23:50:22 -03:00

(Migrated from github.com)

Where this stands, and the one thing that is not done.

Done and merged

keel-linux/unit-redis, a new repository: the component as a fab unit, plan, overlay/, conf, version. PRs 1, 2 and 3, tags v1.0.0, v1.0.1 and v1.0.2. 100 percent on all three measured files, 129 lines, 70 bats tests.
This repository: the recipe rebuilt as a layer on core carrying unit.d/redis, the project packages asserted against the archive rather than a literal version, the archive verified with gpgv rather than trusted, bind ::1 127.0.0.1 as two literal addresses. PRs 2, 3, 4 and 5. 100 percent on all three files it writes, 270 lines, 92 bats tests. tests / coverage and package / changelog are required on master.
keel-linux/apt PR 12: redis core in conf/appliances. Four tests of tests/release.bats had been failing on its main since the web layer and the two stacks were added; the harness reads conf/appliances now instead of a second list, and they pass.

The layer

Built, staged and signed on the build host: redis, delta on core 7acf2c53, first build sha256 14b11627, 46,950,426 bytes, manifest recording units redis@1.0.1.

What booting it proved, and what it found

Every claim this issue asks for was proved on the booted container, on lxcbr0: admin authenticates over IPv6 on [::1]:6379 with the declared secret and answers PONG, writes and reads a key, a wrong secret is refused, a client with no secret is refused every key with NOPERM, and keel inspect reports database.server.role: standalone with engine: redis and listen: 127.0.0.1, ::1.

Getting there cost three defects, all in this work and all now fixed with tests and written into docs/traps.md:

Redis speaks CRLF. Every line of an INFO reply ends \r\n, so a grep anchored on $ never matches. Killed the first build with a message that said no Redis answered while the server was up on both families.
A Redis ACL user may be declared only once in all the configuration there is. Publishing user admin off at build time and declaring it again at first boot is what the SQL engines do, and Redis refuses it outright; the account is declared once, at first boot, or not at all.
Redis opens every value its logfile setting is ever given, so the build time check, running as root, left /var/log/redis/redis-server.log owned by root in a directory the redis user owns, and the service could not start on any machine built from the layer.

Not done

Webmin answering over IPv6 has not been proved on a booted machine, because the run failed before that step, and the layer has not been rebuilt at v1.0.2 to run the boot test end to end. The layer is not published, for two reasons:

keel-linux/tracker#11: publishing a release of one appliance replaces the public Proxmox index with an index of that one appliance. Staging it as it is would take releases.keellinux.org/pve/aplinfo.dat from eleven appliances to one.
The rebuild at v1.0.2 was started as keel-release --resume --rebuild redis, and --rebuild is not scoped to the appliance named: it began rebuilding core. Stopping it left the build host's own /mnt/builds/layers/core.tar.zst disowned by its manifest (1a4df079 on disk, 7acf2c53 required). Nothing published is affected and the repair is two writes and no build, both written down in the handbook's STATUS.

So this issue stays open until core is restored on the build host, the layer is rebuilt at units redis@1.0.2, and tests/boot-test.sh runs green end to end.

Where this stands, and the one thing that is not done. ## Done and merged - **`keel-linux/unit-redis`**, a new repository: the component as a fab unit, `plan`, `overlay/`, `conf`, `version`. PRs 1, 2 and 3, tags v1.0.0, v1.0.1 and **v1.0.2**. 100 percent on all three measured files, 129 lines, 70 bats tests. - **This repository**: the recipe rebuilt as a layer on `core` carrying `unit.d/redis`, the project packages asserted against the archive rather than a literal version, the archive verified with gpgv rather than trusted, `bind ::1 127.0.0.1` as two literal addresses. PRs 2, 3, 4 and 5. 100 percent on all three files it writes, 270 lines, 92 bats tests. `tests / coverage` and `package / changelog` are required on `master`. - **`keel-linux/apt`** PR 12: `redis core` in `conf/appliances`. Four tests of `tests/release.bats` had been failing on its `main` since the web layer and the two stacks were added; the harness reads `conf/appliances` now instead of a second list, and they pass. ## The layer Built, staged and **signed** on the build host: `redis`, delta on `core` `7acf2c53`, first build sha256 `14b11627`, 46,950,426 bytes, manifest recording `units redis@1.0.1`. ## What booting it proved, and what it found Every claim this issue asks for was proved on the booted container, on `lxcbr0`: `admin` authenticates over IPv6 on `[::1]:6379` with the declared secret and answers `PONG`, writes and reads a key, a wrong secret is refused, a client with no secret is refused every key with `NOPERM`, and **`keel inspect` reports `database.server.role: standalone`** with `engine: redis` and `listen: 127.0.0.1, ::1`. Getting there cost three defects, all in this work and all now fixed with tests and written into `docs/traps.md`: 1. **Redis speaks CRLF.** Every line of an `INFO` reply ends `\r\n`, so a grep anchored on `$` never matches. Killed the first build with a message that said no Redis answered while the server was up on both families. 2. **A Redis ACL user may be declared only once** in all the configuration there is. Publishing `user admin off` at build time and declaring it again at first boot is what the SQL engines do, and Redis refuses it outright; the account is declared once, at first boot, or not at all. 3. **Redis opens every value its `logfile` setting is ever given**, so the build time check, running as root, left `/var/log/redis/redis-server.log` owned by root in a directory the redis user owns, and the service could not start on any machine built from the layer. ## Not done **Webmin answering over IPv6 has not been proved on a booted machine**, because the run failed before that step, and the layer has not been rebuilt at v1.0.2 to run the boot test end to end. **The layer is not published**, for two reasons: - `keel-linux/tracker#11`: publishing a release of one appliance replaces the public Proxmox index with an index of that one appliance. Staging it as it is would take `releases.keellinux.org/pve/aplinfo.dat` from eleven appliances to one. - The rebuild at v1.0.2 was started as `keel-release --resume --rebuild redis`, and `--rebuild` is not scoped to the appliance named: it began rebuilding `core`. Stopping it left the build host's own `/mnt/builds/layers/core.tar.zst` disowned by its manifest (`1a4df079` on disk, `7acf2c53` required). Nothing published is affected and the repair is two writes and no build, both written down in the handbook's STATUS. So this issue stays open until `core` is restored on the build host, the layer is rebuilt at `units redis@1.0.2`, and `tests/boot-test.sh` runs green end to end.