Calling it fix in double quotes since that's still quite hand-crafted,
but at least you can now specify options with `@` inside them (e.g.
`ProxyJump`) and have it work properly.
Moreover this fixes the syntax for GET-like variables in the networking
clanCore module. Only the fixed syntax is supported since that's what
was tested, and actually parsed in the code.
Quick follow up to PR #2781, this commit does the same kind of logic but
for machines instead of users and groups.
Note that this only affects the `clan secrets machines remove`
sub-command, and that `clan machines delete` still leaves unusable
secrets & vars behind. This can be addressed in a different change.
Change `prompt.persist` default to false.
We want a consistent default that is not conditionally dependent on
other values.
This makes communication on how the functionality is used more
consistent and easier understood.
We need to remove all keys that were in the group from affected secrets.
With this change we now take `group_name` as an argument in
`{add,remove}_member`, which is a little bit more readable than
`group_folder.parent.name`, and helps DRY the code a bit.
When users or groups are updated :
- Check that keys are properly updated on sops secrets;
- Check that no dangling symlinks are left behind in sops secrets.
And when an user is removed from the clan, check that it is removed from
the groups it belonged to.
This doesn't check this works for vars explicitly, since they share the
same logic, see `secret_paths.extend(list_vars_secrets(flake_dir))` in
commit f2856cb773.
Those improvements allow us to validate that #2659 is indeed fixed, and
tell us that we need to make the same kind of fixes for machines and
groups. For groups this is straightforward, and for machines, when one
is deleted, I wanna discuss first whether we want to delete all its
secrets as well.
