People and roles
Use the cluster's People tab to add people, change SSH keys, change roles and remove people. A change takes a few seconds. The console can take up to 3 minutes if a VM is slow to answer.
Anyone with access to the console account can use this tab. Slurm's roles do not apply in the console.
Who can do what
| Action | User | Admin |
|---|---|---|
sbatch, srun, salloc, squeue, sinfo, sacct | Yes | Yes |
| Cancel or hold your own jobs | Yes | Yes |
| Cancel other people's jobs | No | Yes |
Change compute nodes and partitions with scontrol | No | Yes |
sacctmgr changes (limits, accounts) | No | Yes |
sudo on the login VM and compute nodes | No | Yes |
ssh to a compute node | Only with a job there | Yes |
| Log in to the scheduler VM | No | No |
A user sees these answers when they try an admin command:
| Command | Answer |
|---|---|
sudo | sudo: a password is required, or a password prompt. |
scontrol reboot | Permission denied |
sacctmgr changes | Your user doesn't have privilege to perform this action |
scancel -u <someone else> | Nothing. It exits with 0 and cancels nothing. |
Jobs cannot run as root. So an admin who runs sudo srun or sudo sbatch gets Invalid user id.
All people can see all jobs in squeue and in the console. To hide jobs from squeue, refer to PrivateData in Slurm settings.
Add a person
- Open the cluster's People tab.
- Click Add person.
- Enter the Login name.
- Select the Role: User or Admin (sudo).
- Under SSH public keys, select Add a saved key, or click Paste a key.
- Click Add person.
- Read the result at the top of the tab.
Done on every VM.means that the person can log in.
The login name follows the same rules as at create. Refer to Create a cluster. A cluster can have 50 people.
The new person can log in and submit jobs with no other steps. They get a home folder at /home/jl_fs/<login-name>.
Add people on the People tab, not with adduser. Someone added by hand can log in, but Slurm refuses all their jobs with Invalid account or account/partition combination specified. You cannot correct that from inside the cluster.
If you then add the same name on the People tab, that person is not set up on those VMs. Other people's changes still arrive, but each change says that it is not on every VM until you remove the account made by hand, or the person on this tab. A hand-made account can also take the ID that the console gives next. The console then shows a message with already exists.
Do not change people while you add compute nodes. A new compute node can end up with the old list. If you must, click Retry when the compute node is up.
Change SSH keys
- On the person's row, click Edit keys.
- To remove a key, click the X on its row.
- To add a key, select Add a saved key, or click Paste a key.
- Click Save keys.
The person's old key no longer works after the change. A person must keep at least one key:
Keep or add at least one key. Without a key, this person can’t log in.
This change does not touch the person's own ~/.ssh/authorized_keys. A key that they added there themselves still works until they delete it, or until you remove the person.
Change a role
- On the person's row, click Change role.
- Select User or Admin (sudo).
- Click Change role.
Admins get sudo on the login VM and compute nodes, and they are Slurm admins. Set the admin role here only. Admin rights that someone gives by hand, with AdminLevel in sacctmgr or with the slurm-admins group, go away at the next people change.
At least one admin must stay on the cluster:
At least one admin must stay on the cluster. Make someone else an admin first.
An admin who becomes a user keeps sudo in any SSH session that is already open, until they log out. New sessions are correct.
Remove a person
- On the person's row, click Remove.
- Type the login name.
- Click Remove.
The removal has these results:
- The person can no longer log in. The account stays on the VMs, locked.
- Slurm cancels their jobs that run and their jobs that wait.
- Their files stay in
/home/jl_fs/<login-name>. - Slurm removes them from all accounts, so they lose their team and limits.
If you add the same login name later, the person gets their home folder and files back. An admin must set up their team and limits again.
While the scheduler VM is down, the console refuses all people changes, because it reaches all VMs through the scheduler VM.
Messages on the People tab
| Message | Meaning | What to do |
|---|---|---|
Done on every VM. | The change is complete. | Nothing. |
The change is saved, but some VMs don't have it yet. Press Retry to try them again. | A VM is down or not ready. The notice names it and gives a reason. | Click Retry when the VM is up. |
A saved change to this cluster’s people hasn’t reached every VM yet. We keep trying. Press Retry to try now. | An older change did not reach all VMs. | Click Retry. |
Still being built. Press Retry once it is up. | This VM is not ready. | Click Retry when it is up. |
not set up, their name or home folder belongs to someone else: user1 | /home/jl_fs/user1 belongs to someone else, or an account with this name was made by hand on that VM. | Retry does not help. Correct the folder or remove the account made by hand, or remove the person on this tab. |
user1’s ~/.ssh folder can’t be updated, so SSH between VMs may not work for them. | Refer to SSH to compute nodes. | The person corrects their folder. |
Another change to this cluster's people is being applied. Try again in a moment. | Two changes at the same time. | Try again. |
user1 is already on this cluster. | The name is there. | Use another name. |
We couldn’t confirm this. Check the people list. | The connection stopped. The console can have saved the change. | Read the list before you try again. |
A person with a folder clash can log in, but they cannot write to their home folder, and SSH between VMs fails for them. Other people's changes still arrive. Every later change says that it is not on every VM until you correct the folder.
The console does not warn about this clash at create. So check your login names against the folders on the filesystem.
Size limit
The people and their SSH keys together have a size limit. Long keys, such as RSA 4096, reach it sooner. The console refuses the change with a message. Add fewer people or SSH keys.