24ee0990a2
`user add` refuses on an existing name, so the `--group` flag it takes at creation time could not be added afterwards at all: repairing an account meant hand-editing both users.json and the rendered users.yml as root. mara, on #3167: "i will not edit those files by hand, we will have the same issues elsewhere". The merge rules live in users.rs as a pure function over a UserUpdate, so they are testable without a command line, a container or a running authelia — main.rs's arm only loads, applies, publishes and prints. Removals are strict and everything else is idempotent, which is the one asymmetry here and is deliberate: a --remove-group naming a group the user does not have fails, because a revocation that reports success without revoking is the outcome nobody re-checks; while refusing an already-satisfied set would make the multi-attribute call this verb exists for break whenever one of the values was already right. A command that changes nothing at all still fails — it would otherwise rewrite both files and restart the SSO provider to no effect. Passwords are out of scope: regenerating a credential is a different intent from editing an attribute, and folded together an attribute edit can invalidate a login by accident. Extracts publish() from user_add so both verbs share the render -> store -> users.yml -> restart ordering and the comment that explains why that order, rather than the second verb copying it.
2.6 KiB
2.6 KiB
Command-Line Help for swarmctl
This document contains the help content for the swarmctl command-line program.
Command Overview:
swarmctl
swarm-level operator CLI
Usage: swarmctl [OPTIONS] <COMMAND>
Subcommands:
user— Manage subjects in the swarm's SSO provider
Options:
--authelia-bin <PATH>— authelia binary used to hash passwords. The argon2 parameters must match the verifier's, so this has to be the configured package rather than whatever is onPATH--users-file <PATH>— Host-side path of authelia's users database — i.e. the path inside the container, prefixed with the container's root--machine <NAME>— Machine name of the authelia container, forsystemctl -M--unit <UNIT>— authelia's systemd unit inside that container--store <PATH>— Canonical user store
swarmctl user
Manage subjects in the swarm's SSO provider
Usage: swarmctl user <COMMAND>
Subcommands:
add— Add a user, generating a password for themupdate— Change an existing user's attributes
swarmctl user add
Add a user, generating a password for them
Usage: swarmctl user add [OPTIONS] <USERNAME>
Arguments:
<USERNAME>— Login name. Conservative ASCII only — it is a YAML map key and reaches access-control rules and logs
Options:
--display-name <TEXT>— Name shown in the SSO UI. Defaults to the username--email <ADDRESS>--group <GROUP>— Repeatable
swarmctl user update
Change an existing user's attributes.
Every flag is optional and they compose, so one call can set several things at once. Deliberately does not touch the password: regenerating a credential is a different intent from editing an attribute, and folded together an attribute edit can invalidate a login by accident.
Usage: swarmctl user update [OPTIONS] <USERNAME>
Arguments:
<USERNAME>— Login name of an existing user
Options:
--display-name <TEXT>— Name shown in the SSO UI--email <ADDRESS>--add-group <GROUP>— Repeatable. Adding a group the user is already in is not an error--remove-group <GROUP>— Repeatable. Fails if the user is not in the group — a revocation that reports success without revoking is the failure nobody re-checks
This document was generated automatically by
clap-markdown.