![时钟向后移动后 Kerberos NFS 加密停止工作](https://linux22.com/image/203889/%E6%97%B6%E9%92%9F%E5%90%91%E5%90%8E%E7%A7%BB%E5%8A%A8%E5%90%8E%20Kerberos%20NFS%20%E5%8A%A0%E5%AF%86%E5%81%9C%E6%AD%A2%E5%B7%A5%E4%BD%9C.png)
我有一个系统,其 NFS 安装使用 krb5p 安全性。似乎一切都运行良好,除非时间向后移动(几个小时左右,不确定确切的阈值)。当时钟向后移动时,共享在尝试挂载(使用 autofs)时会报告“没有这样的文件或目录”。假设某处的加密检查之一正在检查向后时间并只是中止,这将是正常的默认行为。
我有一个测试用例,其中客户端/服务器是同一台机器,以及一些使用单独的计算机,结果相同。所有时间均通过 NTP 同步。在这个测试用例中,每个人使用的NTP服务器都被向后移动。
我意识到一个有点奇怪的测试用例,但这是一个完全离线的环境,该软件旨在处理任何类型的奇怪输入,例如操作员未正确配置 NTP(打字错误或其他),而这只是测试该边缘案件。
一旦我将时钟移回到现在或未来,共享就会在 kdestroy/kinit 周期后再次开始工作。
我已经尝试使用新的 kinit 进行 kdestroy,清除 sssd 缓存,重新启动 kadmin/k5rb-server 服务并完全重新启动系统(这会破坏 /tmp),但似乎没有任何效果。
我对系统有完全的控制权,所以我可以“重新安装”某些东西或擦除任何配置/数据文件,我只是找不到存储任何东西的位置来真正让 kerberos 或 NFS 忘记它曾经有一个未来的时间(假设我的理论甚至是正确的)。
系统:RHEL7.9
非常感谢。
更新 只是因为我们在下面有点偏离主题,我想澄清一下,我理解时间倒退是很奇怪的情况。虽然所有建议都值得讨论,但这个问题集中在如何修复软件来处理这种情况。我意识到有可能通过硬件解决这个问题,但我更好奇的是为什么它会具体失败以及如何恢复,而不是如何从一开始就防止它失败(如果这有意义)。虽然有一些硬件解决方案限制了这种边缘情况的潜力,但至少在我当前的系统限制下,没有任何解决方案可以将其降低到 0,而且遗憾的是,硬件选项不可行。软件选项也可能不可行,但只是试图理解它们。到目前为止似乎有效的一种解决方案是重新映像机器,但希望有一些不那么严厉的东西。
答案1
它不存储时间,它进行 vdso 系统调用以从操作系统内核中提取时间。如果它们不同步,那么就会失败。如果它处于离线状态,则查看带有 GPS 帽子的 RPi 并将其用作时间源。
答案2
你有一个错误的边缘情况。NTP设计除了首次部署时之外,不要向后跳跃时钟。即便如此,只有当主时钟错得无法修复时,它才会跳变。
向后跳跃时间会破坏许多应用程序的基础,因此这并不是一个真正的选择。数据库、Kerberos、甚至程序开发只是我想到的三个。
NTP 更喜欢改变时钟,而不是向前或向后跳跃。所以在你的例子中,它并没有向后跳,而是试图减慢时钟的速度。 NTP 实现还ntpd
要求内核解释其对本地硬件时钟的读取:了解它是喜欢运行得快还是慢,并告诉内核偏移时钟值多少,以便在没有时钟的情况下获得相当准确的时间。外部时间源。
此外,如果您将时间提前超过几(五)分钟,您将不会带上您的家属;您必须手动重置他们的时钟。
本质上,如果您跳过时间,Kerberos 将停止工作;任何其他结果都是错误的。