Puppet执行puppet agent --test后节点故障/bin目录疑似丢失问题排查

你代码中最致命的问题出在site.pp的deleting_log_file执行资源上，这是导致/bin目录被删除、SSH连接失败的直接原因：

exec {'deleting_log_file':
    command => 'sudo cd /pg/; sudo rm  *',
    path     => [ '/bin', '/sbin' , '/usr/bin', '/usr/sbin' ],
    provider => 'shell',
}

具体错误点：

• Shell中分号;分隔的命令不会因为前序命令失败就终止后续执行。如果/pg目录不存在、权限不足导致cd /pg/执行失败，后续的sudo rm *会直接在Puppet Agent默认工作目录（通常是/根目录）执行，root权限下会直接删除根目录下所有可删除的文件，包括/bin、/etc/ssh、用户家目录下的.ssh密钥目录等核心系统文件，自然会出现SSH公钥认证失败的报错。
• 该exec没有配置onlyif/unless执行判断条件，每次Puppet Agent运行都会触发，只要出现一次cd失败就会触发删根事故。
• rm *没有任何安全防护，即使cd执行成功，也会误删/pg目录下所有数据。

• 系统目录文件权限设置错误：/bin下部署的所有脚本都设置了mode => 777，任意用户都可以篡改这些脚本，结合你用root身份执行的定时任务，只要脚本被篡改就能直接获取服务器root权限，属于严重安全漏洞。
• 定时任务无校验：new_cron任务每分钟以root身份执行/bin/new_cron.sh，如果该脚本存在路径遍历、无校验删除等逻辑，也会导致系统故障。
• Exec资源滥用：大部分exec资源没有配置幂等判断条件，重复执行会带来不可预期的副作用；Puppet Agent本身就以root身份运行，所有exec中多余的sudo语句完全没有必要，反而会引入权限混淆风险。
• 系统全局配置修改不规范：直接修改/etc/bash.bashrc这类系统原生配置文件，容易在系统更新时被覆盖，也会影响所有用户的默认环境。

• 优先修复删除逻辑：

# 安全的清理写法
exec {'deleting_log_file':
    command => 'rm -f /pg/*',
    path     => [ '/bin', '/sbin' , '/usr/bin', '/usr/sbin' ],
    provider => 'shell',
    onlyif => 'test -d /pg', # 只有/pg目录存在时才执行
}

更推荐用Puppet原生的file资源管理目录清理，不要用exec执行rm命令。

• 将/bin下脚本的权限修改为合理值，比如可执行脚本用755，禁止全局可写权限。
• 去掉所有exec中多余的sudo语句。
• 检查所有自行编写的shell脚本逻辑，避免出现路径类错误。
• 自定义全局环境变量优先放在/etc/profile.d/目录下的独立配置文件中，不要直接修改系统原生全局配置。

内容的提问来源于stack exchange，提问作者hariraj