☰

sssdが起動した後、UDEVはAD / LDAPユーザーとグループを介してデバイスの所有権を設定する必要があります。

tag-icon • tag-icon systemd udev
sssdが起動した後、UDEVはAD / LDAPユーザーとグループを介してデバイスの所有権を設定する必要があります。

与えられた制約は次のとおりです。

  1. システム：Oracle 12.2。 ASMクラスター
  2. ソフトウェアとASMディスクデバイスの所有権を取得するには、AD / LDAPベースのユーザーとグループを使用する必要があります。

Oracle ASMクラスタは、Oracleソフトウェア所有者（grid）と管理者グループ（asmadmin）が所有する必要がある多数のネイティブブロックデバイスを使用します。これは通常、次のような udev ルールを生成することによって行われます。

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

これは、ユーザーとグループがローカルの場合にうまく機能します。テストルールを使用すると、ADユーザーでもうまく機能しますudevadm testが、再起動時にAD / LDAP統合を使用できるようになる前にudevがトリガーされ、もちろんユーザー名の解析は失敗します。その結果、ASMデバイスは最終的にroot：rootの所有になります。

ルールがロードされると、UDEVはユーザー名を解決しようとしないため、sssd.serviceが起動してAD / LDAP統合が可能になると、udevがルールを再ロードしてルールセットをASMデバイスに再適用するための信頼できる方法が必要です。 oracle-ohasd.serviceが起動する前。

以下を含めるために、oracleが提供するスクリプトを簡単に編集することをお勧めします。

udevadm control --reload
udevadm trigger ...

クラスタが正常に起動する前。ただし、スクリプトはベンダーから提供され、いつでも（パッチを介して）置き換えることができるため、これは不適切なようです。これは簡単に忘れられるハッシュです。

起動中に、AD統合が機能している間、oracle-ohasdが起動する前にudevルールを再ロードするためにsystemdでよりよくサポートされている方法はありますか？

ベストアンサー1

実装パッチワーク

AD / LDAPに到達できるようになったら、udevにルールを再評価する必要がある回避策が本当に必要な場合は、専用サービスデバイスを使用してこれらのコマンドをudevadm実行することをお勧めします。

動作するようにデバイスを適切に注文してください。後ろに sssd.serviceこれが始まりました（これはAD / LDAPバックエンドがクエリされる理由です）。後ろに network-online.target（アクセス可能にするには、sssdにそのユーザー/グループのキャッシュがまだないとします）今後これらのデバイスのサービスが必要です。 （説明の便宜のために名前をと仮定しますoracle-asm.service。）

これを行うには、/etc/systemd/system/asm-device-ownership.service次のコンテンツで新しいサービスユニットを作成します。

[単位]
説明=Oracle ASMデバイスの所有権の更新
以降=sssd.service network-online.target
前=oracle-asm.service

[提供する]
種類=使い捨て
ExecStart=/bin/udevadm コントロール --reload
ExecStart=/bin/udevadm トリガー --settle...（ここにデバイスがあります）...

[インストールする]
WantedBy =マルチユーザー。ターゲット

デバイスがインストールされたら、コマンドを使用してsystemdに通知し、を使用してsudo systemctl daemon-reload有効にしますsudo systemctl enable asm-device-ownership.service。

また、このコマンドを同期化するには、を使用することをお勧めします。 systemdの順序付けは、サービスユニット（これらのデバイスの所有権を設定する）が依存するサービスユニット（ASMデバイスを使用するサービスユニット）が開始する前に完了することを保証するため、この操作を待つ必要があります。udevadm trigger --settle

これしなければならないこれはうまくいきますが、udevを早期に再起動して再ロードするときに移動する部分が多く、途中でルールを再起動することが問題になる可能性があります。してください。信頼できる。

しかし、このパッチワークを使用しないことをお勧めします。

代わりに、次の代替ソリューションの1つを検討してください。

ユーザー/グループをローカルにコピー

コメントでは、私は前述のように同じユーザーをローカルに作成することを提案しました。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ローカルファイルに存在するグループについても解析が試みられます。これは、SSDが実際に起動する前に初期起動時に遅延が長くなる可能性があることを意味します。解決しようとしています。）

したがって、より良い解決策は次のとおりです。

代わりに、udev設定で数値UID / GIDをエンコードしてください。

前述のように、ユーザーは時間が経っても変更されない固定UIDを持つことが予想されますgrid（システムの動作中にこれを変更すると、より多くの問題が発生する可能性があるため）。 .gidのGIDも同じですasmadmin。

この場合、固定 UID とプライベート UID と GID を使用できる場合は、OWNER フィールドと GROUP フィールドで数値 UID と GID を使用できる udev ルールにエンコードすることを検討してください。

たとえば、gridUID 501とasmadminGID 601の場合は、次の規則を使用します。

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

これにより、udevがこれらのデバイスを設定したときに起動時にユーザー/グループの確認が不要になりますが、AD/LDAPでユーザー/グループの確認が完了した場合はい使用可能な場合、ASM をこれらのデバイスで使用できるように所有権が正しく設定されます。

これはおそらくこの問題に対する最善の解決策であり、実際には明らかな欠点はありません。

おすすめ記事