User management¶

On a Slinky cluster you do not drive Kanidm by hand. A single tool, slinky-user-add, provisions everything a user needs in one step:

• a Kanidm person (the identity + their SSH public key),
• a POSIX account (UID/GID) and cluster_users group membership,
• the per-user subuid/subgid mapping that containers need,
• a Slurm account association (default_acct by default) so the user can submit jobs.

Run it as an admin (root) on the login/bastion node.

Add a user¶

sudo slinky-user-add alice \
  --display-name "Alice Example" \
  --ssh-key "ssh-ed25519 AAAA... alice@laptop"

Useful options:

--test is worth using the first time: it confirms the new user resolves on the workers and can launch a Slurm step (it prints the step's uid/user).

Remove a user¶

sudo slinky-user-remove alice --yes

• --archive-home moves /home/alice under /home/.verda/removed-users/ instead of leaving it in place.
• --keep-kanidm keeps the Kanidm person but drops cluster_users membership (revokes cluster access without deleting the identity).

How users log in¶

The path for provisioned users is seamless SSH: it drops the user straight into the Slurm login pod over port 2222, where they are themselves (their own UID) and the full Slurm CLI is available:

sudo slinky-user-add alice --enable-seamless --ssh-key "ssh-ed25519 AAAA..."

This flips SEAMLESS_SSH_ENABLED=1 in /etc/default/verda_seamless_ssh and restarts slinky-login-dnat.service, after which the user connects with:

ssh alice@<cluster-ip> -p 2222

Once enabled, the :22 admin bastion shell (ubuntu@<cluster-ip>) keeps working as before, while members of the kanidm cluster_users group are restricted to the seamless port — they can no longer open a plain bastion shell on :22. SEAMLESS_SSH_PORT (default 2222) selects which port is the redirect; set it to 22 to flip the roles, so seamless uses the cleaner :22 and the admin bastion shell moves to :2222. Only 22 or 2222 are valid.

Without seamless SSH a provisioned user can still SSH to the login node on port 22, but the wrapped Slurm CLI there is effectively admin-only: the wrappers exec into the login pod with kubectl credentials, which only the ubuntu admin and root have by default, and they run as the login pod's root user rather than as the invoking account. Enable seamless SSH for anyone who should submit their own jobs; srun id confirms which identity a shell submits as.

Access control¶

When users submit as themselves (seamless SSH), each user is a distinct POSIX/Slurm identity and normal Slurm and filesystem boundaries apply: a user cannot scancel another user's job, and /home/<user> is private. Jobs submitted through the admin wrappers all run as root and bypass these per-user boundaries. Per-user limits and QoS are set with sacctmgr, see the workshop use case for a worked multi-user example.

Identity across cluster re-provisioning (replay and reconcile)¶

File ownership on a shared filesystem is stored as numeric UIDs. If you delete a cluster and create a new one with the same filesystem attached, the new cluster starts with an empty identity store, and naively re-created users would get different UIDs and lose access to their own files.

Slinky clusters solve this with an identity ledger: a small record of every user (username, UID, display name, SSH keys) kept on the filesystem itself.

• slinky-user-add and slinky-user-remove maintain the ledger automatically. By default it lives at /home/.verda/slinky-users/; pass --path <mount> to keep it on a filesystem you retain between clusters instead.

• slinky-users-replay re-creates every user in the ledger, pinned to the original UID/GID and with the stored SSH keys. It runs automatically at boot and is idempotent, so it is safe to run by hand, for example after attaching a kept filesystem at /main:

  sudo slinky-users-replay --path /main
  

• If the attached filesystem holds user data but no ledger yet (a volume from before this feature), replay first auto-seeds the ledger from directory ownership. It only considers regular user UIDs and refuses to guess if two directories share a UID.

• slinky-users-reconcile audits the ledger against actual directory ownership and reports mismatches without changing anything; --write-ledger writes the inferred entries:

  sudo slinky-users-reconcile --path /main