![sssd 启动后需要 UDEV 通过 AD/LDAP 用户和组设置设备所有权](https://linux22.com/image/142790/sssd%20%E5%90%AF%E5%8A%A8%E5%90%8E%E9%9C%80%E8%A6%81%20UDEV%20%E9%80%9A%E8%BF%87%20AD%2FLDAP%20%E7%94%A8%E6%88%B7%E5%92%8C%E7%BB%84%E8%AE%BE%E7%BD%AE%E8%AE%BE%E5%A4%87%E6%89%80%E6%9C%89%E6%9D%83.png)
给定的约束是:
- 系统:Oracle 12.2。 ASM集群
- 必须使用基于 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。
例如,如果grid
UID 501 且asmadmin
GID 601,则使用以下规则:
ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"
这样,当 udev 设置这些设备时,在启动早期不需要用户/组解析,但是当从 AD/LDAP 进行用户/组解析时是可用时,所有权将被正确设置,以便 ASM 能够与这些设备一起使用。
这可能是解决这个问题的最佳解决方案,实际上没有明显的缺点。