我最近遇到一个问题，我的服务器在运行脚本的过程中关闭，似乎是随机的，但每次都大约在同一时间点，然后每当我尝试再次打开服务器时，它都会启动启动过程，然后当它到达某个点时，在到达登录选项之前再次自动关闭。
我最初以为这与正在安装的脚本和包有关，但查看安全性和 CIS 基准文档后，我发现该操作系统安装了 2 级服务器配置，以满足安全要求。
对于我需要在自己的服务器上执行的操作，我可以采用一种解决方法，编辑 auditd.conf 文件并更改此设置，以便能够执行我需要的操作。然而，在生产环境中，这种解决方法可能不合适或不是一种允许的选项。
我对此有几个问题：
当服务器达到这种状态时，可以做什么吗，因为此时您甚至无法登录，或者唯一的选择是重新映像服务器？（这是我一直采取的措施）
据推测（我仍在尝试理解所有配置选项），这不应该发生，并且日志具有某种轮换和保留策略，而我刚刚遇到了一个极端情况，我需要做的事情最终会填充这些日志，超出预期的用例是什么？
答案1
当然，auditd 是 Linux 的东西。
如果 auditd 认为空间严重不足，您的组织应该决定采取什么行动。有些环境非常重视监视安全性或完整性事件，以至于日志记录中的空白是无法容忍的。许多其他环境不需要牺牲可用性来减少审计日志中的空白。
至于您的选择，请参阅man auditd.conf 配置指令，包括 admin_space_left_action。halt 将解释您关闭主机的原因。single 可能是一种有用的折衷方案，可以停止几乎所有服务，但允许在控制台上修复空间问题。或者只是报告问题（系统日志、电子邮件）、丢失数据（旋转）或不执行任何操作（忽略）。当然，其中一些意味着您不能声称已经完成“确保在审计日志已满时禁用系统”。
请注意，自动化工具可能会配置最保守的选项，例如此 Ansible playbook 默认停止。
就我个人而言，与诚实且配置了系统日志的策略相比，我更怀疑策略为暂停但某些主机存在自动化例外情况的环境。虽然我不是合规人员。
解决问题的方法总是不止一种。可以启动救援发行版或单用户模式，然后扩展存储或清除日志以恢复空间。
所有存储都有可能被填满。在这种情况下找到根本原因。评估规则的必要性，审计日志空间需求因规则和工作负载的不同而有很大差异。改进容量规划和存储警报，以减少未来的空间问题。
答案2
因此我找到了我提出的两个问题的答案：
当服务器进入此状态时，对服务器进行电源循环，当出现 grub 菜单时按“e”进入编辑模式并设置
audit = 0此项以禁用此启动的审计守护进程，允许服务器启动，然后您可以清除目录并再次启动 auditd。对于 CIS Level 2 - 服务器，这是默认行为，并且日志管理未设置为轮换日志以避免发生这种情况。在日志足够长的时间内，如果使用得当，除非您手动删除文件，否则这些默认设置将会发生这种情况。如果这是不可接受的，您可以编辑 auditd.conf 以更适合您的用例的方式管理日志文件。