☰

sssd가 시작된 후 UDEV는 AD/LDAP 사용자 및 그룹을 통해 장치 소유권을 설정해야 합니다.

tag-icon • tag-icon systemd udev
sssd가 시작된 후 UDEV는 AD/LDAP 사용자 및 그룹을 통해 장치 소유권을 설정해야 합니다.

주어진 제약조건은 다음과 같습니다:

  1. 시스템: 오라클 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를 조기에 다시 시작하고 다시 로드할 때 움직이는 부분이 많고 중간에 규칙을 다시 트리거하는 것이 문제가 될 수 있습니다... 따라서 이 경로를 선택하는 경우 이 설정을 충분히 테스트하여 실제로 작동하는지 확인하세요. 믿을 수 있는.

그렇긴 하지만, 이 패치워크를 사용하지 않는 것이 좋습니다.

대신 다음 대체 솔루션 중 하나를 고려하세요.

사용자/그룹을 로컬로 복사

의견에서 나는 이전에 언급한 대로 동일한 사용자를 로컬로 생성할 것을 제안했습니다.Arch Linux 위키의 이 기사.

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와 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을 이러한 장치와 함께 사용할 수 있도록 소유권이 올바르게 설정됩니다.

이는 아마도 이 문제에 대한 최선의 해결책일 것이며 실제로는 뚜렷한 단점이 없습니다.

관련 정보