Connecting your own SLURM cluster

Signed-in users can connect a personal SLURM account (for example Uni Jena Draco). The app never SSHs into the cluster. A small cron worker on the login nodes calls the app API with a per-cluster token, pulls jobs via short-lived S3 URLs, submits them to SLURM, and uploads results.

Connect

1. Sign in with ORCID.
2. Open Clusters → Connect cluster.
3. Choose the Draco preset (or Generic SLURM) and save.
4. On the setup page, copy the one-time token and run the listed commands on the login node:
   • download and inspect setup.sh
   • run bash setup.sh (paste the token at the prompt, or set QMNMR_TOKEN)
   • from your laptop, arm the standby login node with the printed ssh … install-cron command
5. Wait for the live checklist to turn green (worker ping, storage round-trip, SLURM, NWChem 7.2.2, compute test).

Submit jobs

On the submit form, choose your connected cluster under Execution Location. Offline or incomplete clusters are disabled.

Status badges

Badge	Meaning
online	Ping within the last 5 minutes
delayed	5–15 minutes since last ping
offline	No ping for 15+ minutes
degraded	Worker alive but a check failed
building / setup incomplete	Install still in progress

Use Test connection on the cluster detail page for an on-demand re-check (quick or full).

Troubleshooting

• Worker never pings: Check the HTTP proxy was captured in ~/qm-nmr-worker/config.json, that BASE_URL is reachable from the login node, and that cron is installed (crontab -l should show # qm-nmr-worker).
• Storage check fails: Confirm the app S3 endpoint is reachable (often direct, outside the proxy via no_proxy).
• SLURM check fails: Partition/account must match what sbatch --test-only accepts.
• NWChem version wrong: The worker uses an isolated Spack under ~/qm-nmr-worker/spack pinned to 7.2.2. Do not reuse a personal ~/spack develop tree.
• Revoke: Revoking invalidates the token; the worker uninstalls itself after the next 401.

Security notes

• Never put the token on a command line as an argument (ps on shared login nodes would show it).
• The worker never holds S3 credentials — only presigned URLs.
• Tokens and URLs must not appear in worker or app logs.