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 node, which you reach with ssh -p 2222 ubuntu@<cluster-ip> (see How users log in).

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¶

Port 22 on the cluster's public IP leads straight into the Slurm login pod (seamless SSH). Every user, including ubuntu, lands there as themselves (their own UID), with the full Slurm CLI, and their jobs run under their own identity:

ssh alice@<cluster-ip>
ssh ubuntu@<cluster-ip>

The login pod has no sudo, and anything installed outside /home is lost when the pod restarts. For admin work (sudo, kubectl, slinky-user-add), use the login node's own shell on port 2222:

ssh -p 2222 ubuntu@<cluster-ip>

Members of the kanidm cluster_users group (everyone added with slinky-user-add) cannot open a shell on the login node; they only get the login pod.

The Slurm commands on the login node are admin wrappers that run inside the login pod through kubectl, as the pod's root user. Jobs submitted that way are owned and accounted as root, so submit regular work from the login pod instead; srun id shows which identity a shell submits as.

Changing the port layout¶

The layout is set in /etc/default/verda_seamless_ssh on the login node:

Apply a change with sudo systemctl restart slinky-login-dnat.service. Only 22 or 2222 are valid ports.

Access control¶

When users submit from the login pod, 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