anubis: a database replica gets no signing key, so Anubis does not start on a pair

navigator commented

2026-10-16 05:42:53 -03:00

Owner

Found by the LNMP and LNPP pair tests on hw12-br1, 2026-10-16 (handbook docs/evidence/2026-10-16-lnmp-lnpp-images.md).

On a cloud simple pair, keel-overlay-anubis-key.service makes no key on the database replica:

anubis: this node is a database replica: the key is shared and comes from the primary (decision 0041); none is made on this node

Nothing copies the key to the replica. Thus anubis@keel does not start there, and keel spec apply --system-only fails the anubis overlay: "A dependency job for anubis@keel.service failed".

The tests used this workaround: copy /etc/anubis/keel.key of the primary to /etc/keel/secrets/anubis_signing_key (mode 0600) on the replica, declare secrets.anubis_signing_key: {file: ...}, restart the key unit, then apply again.

What is needed, one of:

Copy the key from the primary over the members' channel, as keel asks the database certificate of the holder (a keel change).
At the least, write the manual step in the pair procedure and say it in the unit's message.

Found by the LNMP and LNPP pair tests on hw12-br1, 2026-10-16 (handbook docs/evidence/2026-10-16-lnmp-lnpp-images.md). On a cloud simple pair, `keel-overlay-anubis-key.service` makes no key on the database replica: ``` anubis: this node is a database replica: the key is shared and comes from the primary (decision 0041); none is made on this node ``` Nothing copies the key to the replica. Thus `anubis@keel` does not start there, and `keel spec apply --system-only` fails the anubis overlay: "A dependency job for anubis@keel.service failed". The tests used this workaround: copy `/etc/anubis/keel.key` of the primary to `/etc/keel/secrets/anubis_signing_key` (mode 0600) on the replica, declare `secrets.anubis_signing_key: {file: ...}`, restart the key unit, then apply again. What is needed, one of: 1. Copy the key from the primary over the members' channel, as keel asks the database certificate of the holder (a keel change). 2. At the least, write the manual step in the pair procedure and say it in the unit's message.

navigator referenced this issue from a commit

2026-10-16 07:04:13 -03:00

test: the other member of a pair gets the primary's Anubis key (common#56)

navigator referenced this issue from a pull request from Keel-Linux/keel that will close it,

2026-10-16 07:04:22 -03:00

fix: a paired replica asks the other member for Anubis's key (common#56) #187

navigator referenced this issue from a commit

2026-10-16 07:16:00 -03:00

test: the other member of a pair gets the primary's Anubis key (common#56)

navigator referenced this issue from a commit

2026-10-16 07:54:58 -03:00

test: the other member of a pair gets the primary's Anubis key (common#56)

navigator referenced this issue from a commit

2026-10-16 10:04:19 -03:00

test: the other member of a pair gets the primary's Anubis key (common#56)

keel-bridge commented

2026-10-16 10:12:35 -03:00

Member

The bridge mirrored this item to GitHub: https://github.com/Keel-Linux/common/issues/53
Comments, labels and the open or closed state sync both ways.

The bridge mirrored this item to GitHub: https://github.com/Keel-Linux/common/issues/53 Comments, labels and the open or closed state sync both ways.

navigator closed this issue

2026-10-16 10:41:31 -03:00

navigator commented

2026-10-16 10:42:29 -03:00

Author

Owner

Fixed in keel by Keel-Linux/keel#187 (merged, keel 0.23.34): a paired replica asks the other member of the pair for the key over the members' channel and writes it before Anubis starts. The cross-site rehearsals of 2026-10-16 showed the key on the replica with no hand copy. The release test of LNMP and LNPP 19.0-3 checks it again.

Rows
Columns

anubis: a database replica gets no signing key, so Anubis does not start on a pair #56