Identity, time, network, and authentication

Audience: Authorized administrators · Reviewed: 2026-10-04

Version and teaching scope

Use documentation matching your installed release and local policy. Check sinfo --version; upstream documentation identified itself as 26.05 at review. Paths, partitions, accounts, modules, memory, MPI, GPUs and services are site-specific. Example programs beginning ./ must already exist. These are teaching examples, not a validated deployment recipe or evidence that a cluster was modified. Administrative operations require authorized operators and a reviewed change plan; ordinary users must not execute them or paste them into production.

Test prerequisites independently

Treat prerequisites as separate tests. A working SSH connection is not proof that Slurm authentication, shared paths, or MPI networking work. Agree on stable hostnames, matching user/group identities, synchronized clocks, and required service connectivity. Protect management interfaces and allow only the necessary traffic between authorized hosts; application communication may need additional documented network access.

Read-only checks, adapted to the host OS:

hostname -f
getent hosts compute01
id researcher
getent passwd researcher
date -u
findmnt /shared

Compare numeric UID/GID values across relevant hosts. A same-looking username with different numeric IDs can cause ownership failures. Check storage paths as an ordinary test user, not only as root. Verify time synchronization using the site's configured time service.

Primary daemon authentication

Slurm has two primary daemon authentication choices: auth/munge with cred/munge, or auth/slurm with cred/slurm (available since 23.11). Both depend on protected shared keys. MUNGE requires munged; with Slurm-native authentication, login-only hosts generally use sackd. Keep keys outside repositories, images distributed to untrusted people, and job environments. Changing authentication type requires a coordinated drained/stopped-daemon transition, not a casual reload.

JWT is an alternate client mechanism

Do not confuse auth/slurm with alternate JWT authentication. JWT supports client requests to controller/accounting services and API workflows; it does not replace all cluster-daemon authentication. Tokens and token-signing authority are sensitive, and an internet-facing REST service needs its own reviewed authorization and transport-security design.

Checkpoint: Document the trust boundary: who can read a shared key, administer a submit host, request a token, and reach controller services?

Official sources

Previous: Build a safe learning lab; provision production deliberately · Learning path · Next: Read Slurm configuration as a system