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

Merged

navigator merged 3 commits from fix/anubis-key-from-the-pair-common56 into main 2026-10-16 10:41:30 -03:00

Conversation 0 Commits 3 Files changed 12 +488 -9

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

Owner

Copy link

Fixes Keel-Linux/common#56. Based on main after #185.

On a pair, keel-overlay-anubis-key.service makes no key on the database replica: the key is shared and comes from the primary (decision 0041, shared: true). Nothing copied it, so anubis@keel did not start on the replica, and the apply failed the anubis overlay. The LNMP and LNPP pair tests copied the key by hand.

What changes:

• The secret message of the members' channel gives a second name, anubis/signing_key. It is answered with /etc/anubis/keel.key, only to the other member of the pair record, as the replication credential is (keel.mesh.vipserve.shared).
• keel.system.anubiskey: on the live system, in a run that may change the machine, a node whose spec makes it a database replica, with Anubis enabled, no key file and no secrets.anubis_signing_key, asks the other member of its pair. The plan writes the key with mode 0600 before the overlay's units start. The key unit then finds the key and leaves it. The key is not in the plan's output.
• Before the pair record exists, the apply starts nothing for Anubis and says why. So the first boot of a replica does not fail the overlay.
• A key that is there is never replaced. While the primary has no key yet or does not answer, the apply starts nothing for Anubis, says why, and a later apply asks again. An answer that is no key refuses the step. A link whose target is gone is removed before the write.
• docs/replication.md says it, for both engines.

Tests: tests/test_system_anubiskey.py (the channel: the other member gets the key, a member outside the pair does not, a holder with no key, an answer that is no key, a key through a link; the observation: asks, waits, refuses, asks nothing in a dry run) and tests/test_system_appliance.py (the write comes before the start, a waiting replica starts nothing, a problem refuses). The real-node proof is the cross-site test of LNMP and LNPP 19.0-3.

keel 0.23.34.

Fixes Keel-Linux/common#56. Based on main after #185. On a pair, `keel-overlay-anubis-key.service` makes no key on the database replica: the key is shared and comes from the primary (decision 0041, `shared: true`). Nothing copied it, so `anubis@keel` did not start on the replica, and the apply failed the anubis overlay. The LNMP and LNPP pair tests copied the key by hand. What changes: - The `secret` message of the members' channel gives a second name, `anubis/signing_key`. It is answered with `/etc/anubis/keel.key`, only to the other member of the pair record, as the replication credential is (`keel.mesh.vipserve.shared`). - `keel.system.anubiskey`: on the live system, in a run that may change the machine, a node whose spec makes it a database replica, with Anubis enabled, no key file and no `secrets.anubis_signing_key`, asks the other member of its pair. The plan writes the key with mode 0600 before the overlay's units start. The key unit then finds the key and leaves it. The key is not in the plan's output. - Before the pair record exists, the apply starts nothing for Anubis and says why. So the first boot of a replica does not fail the overlay. - A key that is there is never replaced. While the primary has no key yet or does not answer, the apply starts nothing for Anubis, says why, and a later apply asks again. An answer that is no key refuses the step. A link whose target is gone is removed before the write. - `docs/replication.md` says it, for both engines. Tests: `tests/test_system_anubiskey.py` (the channel: the other member gets the key, a member outside the pair does not, a holder with no key, an answer that is no key, a key through a link; the observation: asks, waits, refuses, asks nothing in a dry run) and `tests/test_system_appliance.py` (the write comes before the start, a waiting replica starts nothing, a problem refuses). The real-node proof is the cross-site test of LNMP and LNPP 19.0-3. keel 0.23.34.

navigator added 6 commits 2026-10-16 07:04:22 -03:00

test: a reseed works when repl has no CONNECT on a database (keel#183) ... ecad9eaa5a

The reseed probe sums pg_database_size() over every database as the
role repl. That function needs CONNECT on the database. The keel-lnpp
check database revoked CONNECT from PUBLIC, and every reseed of the
LNPP pair refused: "permission denied for database keel_check".

The netns test of the pair now revokes CONNECT on the shop database
from PUBLIC before case (d), as the check database did. The unit tests
ask that the probe measures only the databases repl may connect to,
and that a refusal for lack of space names the databases it left out.

fix: the reseed probe measures only the databases repl may connect to (keel#183) ... e33d7f3a5b

pg_database_size() needs CONNECT on the database or the role
pg_read_all_stats. An application database with REVOKE CONNECT FROM
PUBLIC stopped every reseed with "permission denied".

The probe now sums the size with a FILTER on
has_database_privilege(oid, 'CONNECT') and counts the databases it
leaves out. The free space check uses the size it has. When the check
refuses, the message says how many databases the need leaves out. The
base backup itself is not changed: it copies the whole cluster.

pg_read_all_stats is not granted to repl: it gives more read access
than the reseed needs.

chore: keel 0.23.33 (keel#183) a6271bbc9b

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

On a pair, keel-overlay-anubis-key.service makes no key on the database
replica: the key is shared and comes from the primary (decision 0041).
Nothing copied it, so anubis@keel did not start there, and the apply
failed the anubis overlay. The LNMP and LNPP pair tests copied the key
by hand (Keel-Linux/common#56).

The tests ask that the other member of the pair record, and no other
member, gets the key over the members' channel; that a paired replica
with no key asks for it in a run that may change the machine, and
writes it with mode 0600 before Anubis starts; that a replica in no
pair yet starts nothing and says why; and that an unreachable primary
refuses the step.

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

The secret message of the members' channel gives a second name,
anubis/signing_key, answered with /etc/anubis/keel.key only to the
other member of the pair record, as the replication credential is.

keel.system.anubiskey observes, on the live system and only in a run
that may change the machine, a node whose spec makes it a database
replica, with Anubis enabled, no key file and no
secrets.anubis_signing_key declared. It asks the other member of its
pair, and the plan writes the key (mode 0600) before the overlay's
units start. The key unit then finds the key and leaves it.

Before the pair record exists, the apply starts nothing for Anubis and
says why, so the first boot of a replica no longer fails the overlay. A
key that is there is never replaced.

chore: keel 0.23.34 (common#56) 240512d44c

navigator referenced this pull request 2026-10-16 07:12:21 -03:00

fix: the VIP overlay waits for etcd's cluster, as etcd does (keel#106) #189

navigator referenced this pull request 2026-10-16 07:12:49 -03:00

fix: the fence of an old MariaDB primary ends its connections (keel#186, keel#193) #190

navigator force-pushed fix/anubis-key-from-the-pair-common56 from 240512d44c to 8fc10142ee 2026-10-16 07:16:00 -03:00 Compare

navigator referenced this pull request 2026-10-16 07:24:18 -03:00

fix: an apply that starts etcd records it, and the start enables wireguard (keel#188) #191

navigator referenced this pull request 2026-10-16 07:51:36 -03:00

fix: the VIP fence of a caught-up MariaDB replica is cleared (keel#192) #194

navigator force-pushed fix/anubis-key-from-the-pair-common56 from 8fc10142ee to e1beb9c4cf 2026-10-16 07:54:58 -03:00 Compare

navigator force-pushed fix/anubis-key-from-the-pair-common56 from e1beb9c4cf to 5adbb9dc61 2026-10-16 10:04:19 -03:00 Compare

navigator referenced this pull request 2026-10-16 10:04:38 -03:00

fix: a MariaDB holder whose lease is in doubt acknowledges no write (keel#195) #197

navigator merged commit 502751e6d5 into main 2026-10-16 10:41:30 -03:00

navigator referenced this pull request from a commit 2026-10-16 10:41:32 -03:00

Merge pull request 'fix: a paired replica asks the other member for Anubis's key (common#56)' (#187) from fix/anubis-key-from-the-pair-common56 into main

navigator referenced this pull request from Keel-Linux/common 2026-10-16 10:42:29 -03:00

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

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

accessibility

Barrier affecting people with disabilities

  

bug

Something isn't working

  

documentation

Improvements or additions to documentation

  

duplicate

This issue or pull request already exists

  

enhancement

New feature or request

  

good first issue

Good for newcomers

  

help wanted

Extra attention is needed

  

invalid

This doesn't seem right

  

question

Further information is requested

  

wontfix

This will not be worked on

No labels

accessibility

bug

documentation

duplicate

enhancement

good first issue

help wanted

invalid

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Keel-Linux/keel!187

No description provided.