☰

sssd 启动后需要 UDEV 通过 AD/LDAP 用户和组设置设备所有权

tag-icon • tag-icon systemd udev
sssd 启动后需要 UDEV 通过 AD/LDAP 用户和组设置设备所有权

给定的约束是：

  1. 系统：Oracle 12.2。 ASM集群
  2. 必须使用基于 AD/LDAP 的用户和组来获得软件和 ASM 磁盘设备所有权

oracle ASM集群使用大量原始块设备，这些原始块设备必须由Oracle软件所有者（grid）和管理员组（asmadmin）拥有。这通常是通过创建如下所示的 udev 规则来完成的：

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="grid", GROUP="asmadmin", MODE="0660"

当用户和组是本地时，这很有效。当他们是 AD 用户时，使用 测试规则udevadm test也效果很好，但在重新启动时，udev 会在 AD/LDAP 集成可用之前被触发，并且解析用户名会失败，这是可以理解的。结果，ASM 设备最终归 root:root 所有。

加载规则后，UDEV 不会尝试解析用户名，因此我们需要一种可靠的方法来使 udev 重新加载规则，并在 sssd.service 启动且 AD/LDAP 集成可用后将规则集重新应用到 ASM 设备，并且在 oracle-ohasd.service 启动之前。

建议简单地编辑 oracle 提供的脚本以包括：

udevadm control --reload
udevadm trigger ...

在集群正常启动之前。然而，这似乎不太合适，因为脚本是供应商提供的，并且可以随时被他们替换（通过补丁）。这是一个很容易被遗忘的杂凑。

systemd 中是否有更好、更受支持的方法来在启动期间、AD 集成工作时以及 oracle-ohasd 启动之前重新加载 udev 规则？

答案1

实施拼凑

如果您确实想采取解决方法，要求 udev 在 AD/LDAP 可达后重新评估其规则，那么我想我的建议是使用专用服务单元来运行这些udevadm命令。

适当地订购该单元以便它运行后 sssd.service已启动（因为这就是查询 AD/LDAP 后端的原因）并且后 network-online.target（为了确保它可以访问，假设 sssd 还没有这些用户/组的缓存）并且前需要这些设备的服务。 （为了便于说明，我们假设它名为oracle-asm.service。）

为此，请创建一个新的服务单元，其/etc/systemd/system/asm-device-ownership.service内容如下：

[单元]
描述=更新 Oracle ASM 设备的所有权
After=sssd.service network-online.target
之前=oracle-asm.service

[服务]
类型=一次性
ExecStart=/bin/udevadm 控制 --reload
ExecStart=/bin/udevadm 触发器 --settle...（这里是您的设备）...

[安装]
WantedBy=多用户.target

一旦该单元就位，请使用命令让 systemd 知道它sudo systemctl daemon-reload并使用 启用它sudo systemctl enable asm-device-ownership.service。

另请注意，我建议使用, 以使该命令同步。您需要确保等待该操作，因为 systemd 排序将确保该服务单元（设置这些设备的所有权）在依赖它的服务单元（使用 ASM 设备的服务单元）启动之前完成。udevadm trigger --settle

这应该工作，但在早期重新启动和重新加载 udev 时有很多移动部件，并且在中间重新触发规则可能会出现问题...因此，如果您走这条路，请确保对这个设置进行足够的测试以确保它是实际上可靠。

话虽如此，我真的建议不要使用这种拼凑。

相反，请考虑以下替代解决方案之一：

本地复制用户/组

在评论中，我之前建议在本地创建相同的用户，如中所述Arch Linux wiki 中的这篇文章。

考虑到 AD/LDAP 中的定义，让用户同时在本地/etc/passwd和AD/LDAP 中并没有太大的问题/etc/group不会改变（但是，如果它们确实发生了变化，您可能无论如何都会遇到麻烦，特别是对于已经运行的系统。）

我可以看到本地副本存在一个问题，即如果您想管理 AD/LDAP 上的组成员asmadmin，并且该信息可能会实际更改（因此在本地复制它/etc/group是一个问题。）

事实证明 glibc 2.24 有一个解决方案，通过指定条目应该是合并在/etc/nsswitch.conf：

passwd: files sssd
group:  files [SUCCESS=merge] sssd

（参见nsswitch.conf 的手册页的详细信息[SUCCESS=merge]。）

但这个选项有一些缺点：

  • 合并条目的选项nsswitch.conf仅从 glibc 2.24 开始可用，这是相当新的。例如，RHEL 7 附带版本 2.17，因此该版本不可用。
  • “合并”功能并不完美，例如，手册页描述了它如何不与getgrent用于列出所有组的一起使用......
  • 使用“合并”意味着sssd即使对于本地文件中存在的组也会尝试进行解析！这可能意味着在 sssd 实际启动之前，早期启动会出现更长的延迟...（事实上，大多数涉及本地复制用户/组的解决方案都试图解决外部服务可用之前的超时问题。）

所以也许更好的解决方案是：

而是在 udev 配置中对数字 UID/GID 进行编码！

如前所述，我希望您的用户grid将有一个固定的 UID，该 UID 不会及时更改（因为在系统操作期间更改它可能会产生更多问题），并且 .gid 的 GID 也是如此asmadmin。

如果确实如此，如果您可以依赖固定且专用的 UID 和 GID，那么请考虑在 udev 规则中对它们进行编码，该规则可以在 OWNER 和 GROUP 字段中采用数字 UID 和 GID。

例如，如果gridUID 501 且asmadminGID 601，则使用以下规则：

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

这样，当 udev 设置这些设备时，在启动早期不需要用户/组解析，但是当从 AD/LDAP 进行用户/组解析时是可用时，所有权将被正确设置，以便 ASM 能够与这些设备一起使用。

这可能是解决这个问题的最佳解决方案，实际上没有明显的缺点。

相关内容