Сопоставление шаблонов, добавление новой строки и добавление слова в конец строки

Реализация кладжа

Если вы действительно хотите пойти по пути обходного пути, попросив udev повторно -оценить свои правила после того, как AD/LDAP станет доступным, то я предполагаю, что мое предложение будет состоять в том, чтобы использовать выделенный сервисный модуль для запуска этих udevadmкоманды.

Упорядочить это устройство соответствующим образом, чтобы оно запускалось послеsssd.service(, так как это то, что запрашивает ваш сервер AD/LDAP ), а также после network-online.target(, чтобы убедиться, что оно будет доступно, предполагая, что у sssd еще нет кэша этих пользователей/групп )и до службы, которой нужны эти устройства. (Для иллюстрации предположим, что он называется oracle-asm.service.)

Для этого создайте новую единицу обслуживания, например /etc/systemd/system/asm-device-ownership.service, с содержимым, например,:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here)...

[Install]
WantedBy=multi-user.target

Как только этот юнит будет установлен, сообщите об этом systemd с помощью команды sudo systemctl daemon-reloadи включите его с помощью sudo systemctl enable asm-device-ownership.service.

Также обратите внимание, что я рекомендую использовать udevadm trigger --settle, чтобы сделать эту команду синхронной. Вы хотите убедиться, что операция ожидается, так как заказ systemd гарантирует, что этот сервисный модуль (, устанавливающий владение этими устройствами ), будет завершен до того, как тот, который зависит от него (, тот, который использует устройства ASM. )начнется.

Это должно работать, но есть много движущихся частей при ранней перезагрузке и перезагрузке udev, а повторные запуски правил в середине могут вызвать проблемы... Итак, если вы пойдете по этому пути, убедитесь, что вы достаточно протестировали эту настройку, чтобы убедиться, что она действительно надежна.

---

Сказав это, я настоятельно не рекомендую использовать этот кладж.

Вместо этого рассмотрим одно из альтернативных решений ниже:

Локальная репликация пользователя/группы

В комментариях я ранее рекомендовал создавать таких же пользователей локально, как описано в этой статье в вики Arch Linux .

На самом деле нет большой проблемы в том, чтобы пользователь был как в локальной /etc/passwd, так и в /etc/group, а также в AD/LDAP, учитывая, что определения в AD/LDAP не изменятся (, но тогда, если они изменятся, у вас, вероятно, все равно возникнут проблемы, особенно с уже работающими системами.)

Я вижу одну проблему с локальной копией, которая заключается в том, что вы хотите управлять членами группы asmadminв AD/LDAP, и эта информация, вероятно, фактически изменится (, поэтому дублирование ее в локальной /etc/groupэто проблема.)

Оказывается, в glibc 2.24 есть решение для этого, указав, что записи должны быть объединены в/etc/nsswitch.conf:

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

(Подробную информацию о [SUCCESS=merge]см. на справочной странице для nsswitch.conf .)

Но у этого варианта есть недостатки:

• Опция nsswitch.confдля объединения записей доступна только начиная с glibc 2.24, которая является относительно новой. Например, RHEL 7 поставляется с версией 2.17, поэтому там она недоступна.
• Функция «слияния» не идеальна, например, на странице руководства описано, как она не работает с getgrent, которая используется для вывода списка всех групп...
• Использование «слияния» означает, что sssdбудет предпринята попытка разрешения даже для групп, присутствующих в локальных файлах! Это потенциально означает более длительные задержки при ранней загрузке до того, как sssd действительно заработает... (На самом деле, большинство решений, включающих локальную репликацию пользователей/групп, пытаются решить проблему тайм-аутов до того, как внешние службы станут доступны.)

Возможно, лучшим решением будет:

Вместо этого закодируйте числовой UID/GID в конфигурации udev!

Как упоминалось ранее, я ожидаю, что ваш пользователь gridбудет иметь фиксированный UID, который не изменится со временем (, поскольку его изменение во время работы системы, вероятно, создаст больше проблем )и то же самое для GID asmadmin.

Если это действительно так, если вы можете полагаться на фиксированные и выделенные UID и GID, рассмотрите возможность их кодирования в правиле udev, которое может принимать числовые UID и GID в полях OWNER и GROUP.

Например, если gridимеет UID 501, а asmadminимеет GID 601, вместо этого используйте следующее правило:

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

Таким образом, разрешение пользователя/группы не требуется на ранней стадии загрузки, когда udev настраивает эти устройства, но затем, когда разрешение пользователя/группы из AD/LDAP доступно , право собственности будет установлено правильно. чтобы ASM работал с этими устройствами.

Пожалуй, это лучшее решение этой проблемы, существенных недостатков здесь нет.