学习 slurm 时，我遇到过这样一行配置：
AuthType=auth/munge文档说，这是“使用 munge 进行认证”。但如果从来没接触过 munge，这句话其实还是没解释清楚：它是什么？为什么提交一个作业还需要它？装好后又该怎么用？
先把它翻译成一句人话：
slurm 收到请求时，通过 munge 核对请求者的身份。
这篇文章沿着一个简单例子，把身份凭证、共享密钥、安装配置和 slurm 集成串起来。命令都是供阅读的示例，没有在真实集群执行，也不是对已有生产集群的变更方案。
先从一张防伪工牌说起
假设小李在公司的计算平台上提交作业。他告诉平台：“我是小李，请帮我运行这个程序。”
平台不能只凭这句话就相信他。否则，任何人都可以在请求中写“我是管理员”。平台需要一种能够核验的身份证明。
可以把 munge 理解成一套“防伪工牌系统”：
- 用户命令借助本机 munge 服务，取得包含调用者身份信息的凭证。
- 请求带着凭证发送给 slurm。
- 接收方通过 munge 验证凭证，确认其中的用户身份。
这里的“工牌”是一小段经过密码学保护的数据，叫作身份凭证。它由程序自动生成和验证，不需要用户手动填写。
类比也有边界：凭证不是一个永久有效的员工编号，更不是用户自己写一句“我是小李”。它与真实进程的用户身份有关，并且有有效期。
确认身份之后，slurm 还要检查这个用户能否使用指定分区、是否超过资源限额。munge 负责身份认证，具体使用权限由 slurm 的规则处理。
三个名字，分别做什么
安装 munge 后，容易看到三个相近的名字：
| 名字 | 用途 |
|---|---|
munged | 后台服务，处理凭证的生成和验证 |
munge | 生成凭证的命令 |
unmunge | 验证并显示凭证信息的命令 |
slurm 通常通过 munge 的运行库与本机服务配合。管理员可以用后两个命令观察认证链路，普通用户提交作业时不需要手动调用它们。
再看这行配置就容易理解了：
AuthType=auth/mungeAuthType 表示选择认证方式；auth/munge 是 slurm 中 munge 认证模块的名称。它不是网址，也不是需要创建的文件路径。
用两台服务器串起整个过程
假设有这样一个全新的小集群：
| 主机名 | 角色 |
|---|---|
ctl01 | 控制节点，运行 slurmctld |
node01 | 计算节点，运行 slurmd |
为方便理解，用户直接从 ctl01 提交作业。两台机器都需要安装并运行 munge。
如果另外设置了登录节点，用户从那里提交作业，登录节点也需要相应的 munge 配置。使用 slurmdbd 的机器同样需要加入这套认证环境。
单节点 slurm 的原理相同，只是控制、计算和提交角色都在一台机器上。
安装前先对齐用户身份和时间
linux 在内部用数字识别用户和用户组：
- uid：用户编号。
- gid：用户组编号。
例如，alice 在两台机器上都应对应同一个用户身份。如果一个节点上的 uid 1001 是 alice，另一个节点上的 uid 1001 却属于别人，跨机器运行程序和访问文件时就会产生身份混淆。
因此，要保持集群用户的 uid/gid 映射一致。munge 不会替管理员创建业务用户，也不会自动同步账号。
时间同步同样重要。凭证只在一定时间内有效；生成方和验证方的时钟相差太大，就可能把刚生成的凭证判断为过期或尚未生效。实际环境通常通过时间同步服务保持一致。
安装 munge
下面以 ubuntu 24.04、使用 systemd 管理服务的环境为例。管理员在两台机器上分别安装：
sudo apt update
sudo apt install mungeapt update 更新软件包索引，apt install munge 安装软件。sudo 表示以管理员权限执行。
安装后应具备 munge 服务账号、相关目录、后台服务和命令。具体打包行为以发行版为准，软件包也可能已经初始化了密钥。
如果自行编译 slurm，还需要在编译前安装 munge 的开发文件；ubuntu 中对应的软件包是：
sudo apt install libmunge-dev它用于编译依赖 munge 的程序，不是要求每个普通用户都安装一套开发环境。使用现成 slurm 软件包时，需要确认软件包包含 munge 认证支持。
rocky linux 等其他发行版的软件包名称、来源及安装方式可能不同，不能直接照搬这里的 apt 命令。
密钥：两台机器共同认可的“防伪秘密”
常见密钥位置是：
/etc/munge/munge.key同一个认证范围内的机器，需要使用同一份密钥。它用于保护和核验凭证，普通用户不需要知道它的内容。
最容易犯的错误是：每台机器都各自生成一份新密钥。这样文件名虽然相同，内容却不同，机器之间就无法按预期互相验证凭证。
正确关系是：选定或生成一份集群密钥，再安全分发到相关机器。
如果是全新环境，且密钥尚不存在，官方提供的生成示例是：
sudo -u munge /usr/sbin/mungekey --verbosesudo -u munge 表示使用 munge 服务账号执行，mungekey 用于创建密钥，--verbose 显示操作信息。命令位置需与安装版本一致。
如果已有密钥，应先确认它的用途。尤其不能把这条命令当作修复认证错误的通用办法，在运行中的集群里重新生成密钥。
怎样把同一份密钥交给其他节点
可以通过 ssh 加密连接复制文件，常见工具是 scp。
这里要分清两种作用：ssh 负责这次文件传输的加密和登录认证；munge 使用传过去的密钥，为后续 slurm 请求提供认证。 slurm 正常运行时，并不需要每次提交作业都重新传一次密钥。
下面只演示一种直观情况：管理员已经获准从 ctl01 通过 ssh 使用 node01 的 root 账号；目标节点属于尚未承载作业的新环境，并已确认允许安装这份集群密钥。
在控制节点 ctl01 上：
sudo scp /etc/munge/munge.key \
root@node01:/etc/munge/munge.key这条命令的左边是源文件，右边是目标机器和保存位置：
| 内容 | 含义 |
|---|---|
/etc/munge/munge.key | 当前机器的源文件 |
root@node01 | 使用 root 账号连接 node01 |
:/etc/munge/munge.key | 在目标机器上的保存位置 |
行尾的反斜杠表示命令在下一行继续。首次建立 ssh 连接时，要通过可信渠道核对目标主机指纹，确认连接的是正确机器。
若目标机器禁止 root ssh 登录，就使用环境允许的管理员账号和提权流程完成分发，不需要为了这个例子开放 root 登录。目标位置若已存在文件，复制可能覆盖它，因此这段命令不适合直接用于已有集群换密钥。
接着，在目标节点由管理员设置所有者和权限：
sudo chown munge:munge /etc/munge/munge.key
sudo chmod 400 /etc/munge/munge.keychown 将文件交给 munge 用户和用户组；chmod 400 表示只允许文件所有者读取，其他普通用户不能读取或修改。源节点的密钥也需要正确设置权限。
slurm 官方示例使用 0400，munge 安装指南也给出了仅所有者可读写的 0600。核心要求一致：所有者应与服务账号匹配，密钥不能暴露给其他用户，相关目录也要满足安全权限要求。
启动服务，再看一眼凭证
密钥和目录准备好后，管理员在各相关节点启动服务：
sudo systemctl enable --now mungeenable 设置开机启动，--now 同时让服务立即启动。
服务运行后，管理员可以用下面的命令理解本机认证是否连通：
munge -n | unmungemunge -n 生成一份不附带业务数据的凭证，管道符 | 把它交给 unmunge 验证。成功时，输出中会包含类似：
STATUS: Success (0)这只能说明本机这一段链路工作正常。跨节点验证还需要确认另一台机器能够解读凭证，例如从 ctl01 发出：
munge -n | ssh node01 unmunge它把本机生成的凭证，通过 ssh 交给 node01 的 unmunge。示例假设执行者已经有相应 ssh 登录权限，不要求把前面的 root 账号用于这次检查。
在 slurm 中接入 munge
当相关机器上的 munge 都准备好后，在一致的 slurm.conf 中设置：
AuthType=auth/munge
CredType=cred/munge第一行选择请求认证方式，第二行选择 slurm 作业启动等内部凭据的对应机制。这只是认证配置片段，节点、分区、账号和目录等其他配置仍需完成。
如果使用 slurmdbd，它的 slurmdbd.conf 中还需要相应设置：
AuthType=auth/munge新环境中，先启动 munge，再启动 slurm 服务。控制节点启动控制服务：
sudo systemctl start slurmctld计算节点启动计算服务：
sudo systemctl start slurmd已有集群切换认证方式需要统一安排：先让运行中的作业结束、停止相关 slurm 服务，再切换配置并重启。不能只修改一个节点，也不能把 scontrol reconfigure 当作完成认证方式切换的替代步骤。
普通用户究竟怎样使用
配置完成后，用户还是正常提交作业：
sbatch job.sbatch请求的身份凭证由软件自动生成和验证。用户不需要读取 munge.key，不需要把密钥写进作业脚本，也不需要每次先手动运行 munge。
可以把整个配合理解为四件事：
- linux 账号提供用户身份。
- munge 让接收方能够核验请求中的身份凭证。
- slurm 检查分区权限、资源限制并安排运行。
- 程序在分配到的资源上，以对应用户身份执行。
遇到错误时，先区分是哪一层
| 现象 | 优先关注的方向 |
|---|---|
| 无法连接本机 munge 服务 | 服务是否运行、通信路径和权限是否正确 |
Invalid credential | 密钥或兼容性问题；服务可能仍加载旧密钥 |
Expired credential | 凭证已过期，或者机器时钟不同步 |
| 本机验证成功、跨节点失败 | 两端密钥、时间和版本是否匹配 |
| 凭证验证成功、作业仍无法运行 | 继续查看 slurm 的权限、资源和节点状态 |
错误信息只能提供排查方向，不能据此直接认定根因。身份验证成功，也不代表作业一定能立即获得资源。
以后再看到 auth/munge，我会把它理解为：slurm 选择使用这套“防伪工牌系统”核对请求者身份。安装和密钥管理主要是管理员的工作，普通用户感受到的仍然是提交作业和查看结果。
参考资料
资料核对日期：2026-10-24。实际部署应使用受支持、已更新的发行版软件包，并以所选 slurm 与 munge 版本的文档为准。