4.2. 디렉터리 트리 설계


디렉터리 트리 설계에서 계획해야 하는 몇 가지 주요 결정이 있습니다.
  • 데이터를 포함할 접미사 선택.
  • 데이터 항목 간 계층적 관계를 확인합니다.
  • 디렉터리 트리 계층 구조의 항목 이름 지정.

4.2.1. Suffix 선택

접미사는 디렉터리 트리의 루트에 있는 항목의 이름이며 디렉터리 데이터는 그 아래에 저장됩니다. 디렉터리에는 접미사가 두 개 이상 포함될 수 있습니다. 자연적인 공통 루트가 없는 정보가 두 개 이상 있는 경우 여러 접미사를 사용할 수 있습니다.
기본적으로 표준 Directory Server 배포에는 데이터를 저장하기 위한 접미사가 여러 개 포함되어 있으며, 다른 하나는 내부 디렉터리 작업에 필요한 데이터(예: 구성 정보 및 디렉터리 스키마)를 포함합니다. 이러한 표준 디렉터리 접미사에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.

4.2.1.1. 접미사 이름 지정

디렉터리의 모든 항목은 공통 기본 항목인 root 접미사 아래에 있어야 합니다. 루트 디렉터리 접미사 이름을 선택할 때 다음 네 가지 점을 고려하여 이름을 유효하게 만듭니다.
  • 전역적으로 고유합니다.
  • 정적(정적)이므로 거의 변경되지 않습니다.
  • 짧은 기능으로 아래 항목을 화면에 쉽게 읽을 수 있습니다.
  • 사람이 쉽게 입력하고 기억할 수 있습니다.
단일 엔터프라이즈 환경에서 엔터프라이즈의 DNS 이름 또는 인터넷 도메인 이름과 일치하는 디렉터리 접미사를 선택합니다. 예를 들어 엔터프라이즈에 example.com 의 도메인 이름이 있는 경우 디렉터리 접미사는 논리적으로 dc=example,dc=com 입니다.
dc 속성은 도메인 이름을 구성 요소 부분으로 분할하여 접미사를 나타냅니다.
일반적으로 모든 속성을 사용하여 루트 접미사의 이름을 지정할 수 있습니다. 그러나 호스팅 조직의 경우 root 접미사를 다음 속성으로 제한합니다.
  • DC 는 도메인 이름의 구성 요소를 정의합니다.
  • C에는 ISO에 정의된 대로 국가 이름을 나타내는 두 자리 코드가 포함되어 있습니다.
  • L은 항목이 위치하거나 항목과 연관된 지, 도시 또는 기타 지리적 영역을 식별합니다.
  • st 은 항목이 있는 상태 또는 주를 식별합니다.
  • O는 항목이 속한 조직의 이름을 식별합니다.
이러한 속성이 있으면 구독자 애플리케이션과의 상호 운용성을 허용합니다. 예를 들어 호스팅 조직에서는 이러한 속성을 사용하여 클라이언트 중 하나에 대한 루트 접미사를 생성할 수 있습니다(예: o= example_a, st=Washington,c=US ).
조직 이름 뒤에 국가 지정을 사용하는 것은 접미사에 대한 X.500 이름 지정 규칙에서 일반적입니다.

4.2.1.2. 여러 Suffixes 이름 지정

디렉터리에 사용되는 각 접미사는 고유한 디렉터리 트리입니다. 디렉터리 서비스에 여러 트리를 포함하는 방법은 여러 가지가 있습니다. 첫 번째는 Directory Server에서 제공하는 별도의 데이터베이스에 저장된 여러 디렉터리 트리를 만드는 것입니다.
예를 들어 example_aexample_b 에 대한 별도의 접미사를 생성하여 별도의 데이터베이스에 저장합니다.

그림 4.1. 데이터베이스에 여러 디렉터리 트리 포함

리소스 제약 조건에 따라 데이터베이스를 단일 서버 또는 여러 서버에 저장할 수 있습니다.

4.2.2. 디렉터리 트리 생성

플랫 또는 계층 트리 구조를 사용할지 여부를 결정합니다. 일반적으로 디렉터리 트리를 가능한 한 플랫으로 만듭니다. 그러나 복제를 준비할 때 또는 액세스 제어를 설정할 때 정보가 여러 데이터베이스에 분할되는 경우 일정 양의 계층 구조가 중요할 수 있습니다.
트리 구조에는 다음 단계와 고려 사항이 포함됩니다.

4.2.2.1. 디렉터리 분기

계층 구조를 설계하여 문제가 있는 이름 변경을 방지합니다. 네임스페이스가 이므로 이름이 변경될 가능성이 줄어듭니다. 이름을 변경할 가능성은 잠재적으로 변경될 수 있는 이름의 구성 요소 수에 대략적으로 비례합니다. 디렉터리 트리를 계층화할수록 이름에 더 많은 구성 요소가 있을 수 있으며 이름이 변경될 가능성이 높아집니다.
다음은 디렉터리 트리 계층 구조를 설계하기 위한 몇 가지 지침입니다.
  • 기업에서 가장 큰 조직 하위 항목만 나타내기 위해 트리를 분기합니다.
    이러한 분기 지점은 회사 정보 서비스, 고객 지원, 영업 및 엔지니어링과 같은 부서로 제한되어야 합니다. 디렉터리 트리를 분기하는 데 사용되는 분할이 안정적인지 확인합니다. 엔터프라이즈가 자주 재구성되는 경우 이러한 유형의 분기를 수행하지 마십시오.
  • 분기 지점의 실제 조직 이름이 아닌 기능 또는 일반 이름을 사용합니다.
    이름이 변경됩니다. 하위 트리의 이름을 변경할 수 있지만 하위 항목이 많은 하위 항목이 있는 대규모 접미사에 대해 길고 리소스를 많이 사용하는 프로세스가 될 수 있습니다. 조직의 기능을 나타내는 일반 이름(예: research 및 Development대신 Engineering 사용)을 사용하면 조직 또는 프로젝트를 변경한 후 하위 트리의 이름을 변경해야 할 가능성이 훨씬 적습니다.
  • 유사한 기능을 수행하는 조직이 여러 개인 경우, 부서를 따라 분기하는 대신 해당 함수에 대한 단일 분기 지점을 생성해 보십시오.
    예를 들어 여러 마케팅 조직이 있지만 각 조직이 특정 제품 라인을 담당하는 경우 각각 단일 ou=Marketing 하위 트리를 생성합니다. 그런 다음 모든 마케팅 항목은 해당 트리에 속합니다.

엔터프라이즈 환경의 분기

디렉터리 트리 구조가 변경될 가능성이 없는 정보를 기반으로 하는 경우 이름 변경을 방지할 수 있습니다. 예를 들어 조직이 아닌 트리의 오브젝트 유형에 대한 구조를 기반으로 합니다. 이렇게 하면 비용이 많이 드는 작업인 고유 이름(DN)을 수정해야 하는 조직 단위 간 항목을 축소하는 것을 방지할 수 있습니다.

구조를 정의하는 데 사용할 수 있는 몇 가지 공통 개체가 있습니다.
  • ou=people
  • ou=groups
  • ou=services
이러한 오브젝트를 사용하여 구성된 디렉터리 트리는 다음과 같이 표시될 수 있습니다.

그림 4.2. 환경 디렉터리 트리의 예

Cryostat 환경에서 분기

호스팅 환경의 경우 오브젝트 클래스 조직 (O)의 두 항목이 포함된 트리와 루트 접미사 아래에 있는 개체 클래스 organizationalUnit (ou)의 하나의 항목을 만듭니다. 예를 들어 ExampleHCI는 아래 표시된 대로 디렉터리를 분기합니다.

그림 4.3. cinder 디렉터리 트리의 예

4.2.2.2. 분기 지점 식별

디렉터리 트리에서 분기를 계획할 때 분기 지점을 식별하는 데 사용할 속성을 결정합니다. DN은 attribute-data 쌍으로 구성된 고유한 문자열입니다. 예를 들어 Example Corp.의 직원인 Barbara Jensen 항목의 DN은 uid=bjensen,ou=people,dc=example,dc=com 입니다.
각 특성-데이터 쌍은 엔터프라이즈 Example Corp의 디렉터리 트리에 대해 그림 4.4. “Example Corp의 디렉터리 트리입니다.” 에 표시된 대로 디렉터리 트리의 분기 지점을 나타냅니다.

그림 4.4. Example Corp의 디렉터리 트리입니다.

그림 4.5. “예제 Cryostat의 디렉터리 트리” 인터넷 호스트인 ExampleHCI의 디렉터리 트리를 보여줍니다.

그림 4.5. 예제 Cryostat의 디렉터리 트리

c=US,o=example 접미사 항목 아래에 트리는 세 개의 분기로 나뉩니다. knative 분기에는 ExampleHCI의 고객 데이터 및 내부 정보가 포함되어 있습니다. 인터넷 분기는 도메인 트리입니다. groups 분기에는 관리 그룹에 대한 정보가 포함되어 있습니다.
분기 지점의 속성을 선택할 때는 다음을 고려하십시오.
  • 일관성이 있어야 합니다.
    디렉터리 트리에서 고유 이름(DN) 형식이 일치하지 않는 경우 일부 LDAP 클라이언트 애플리케이션이 혼동될 수 있습니다. 즉, l 이 디렉토리 트리의 한 부분에서 ou 에 종속된 경우 디렉토리 서비스의 다른 모든 부분에서 lou 에 종속되어 있는지 확인합니다.
  • 기존 속성만 사용하십시오( 4.2.2.2절. “분기 지점 식별”에 표시됨).
    기존 속성을 사용하면 타사 LDAP 클라이언트 애플리케이션과의 호환성을 유지할 가능성이 높아집니다. 기존 속성을 사용하면 기본 디렉터리 스키마가 알려지므로 분기 DN에 대한 항목을 더 쉽게 빌드할 수 있습니다.
Expand
표 4.1. 기존 DN 분기 포인트 속성
속성 정의
dc 도메인 이름(예: dc=example )의 요소(예: dc=example,dc=com 또는 dc= mtv, dc=example,dc= com )와 같은 도메인에 따라 쌍으로 지정됩니다.
c 국가 이름입니다.
o 조직 이름입니다. 이 속성은 일반적으로 회사 부서, 학문적 징계 (인간, 과학), 자회사 또는 기업 내의 기타 주요 분기와 같은 대규모 부서 분기를 나타내는 데 사용됩니다. 4.2.1.1절. “접미사 이름 지정”.
ou 조직 단위입니다. 일반적으로 이 속성은 조직보다 엔터프라이즈의 소규모 분기를 나타내는 데 사용됩니다. 조직 단위는 일반적으로 이전 조직에 종속됩니다.
st 주 또는 주 이름입니다.
L 또는 locality 도시, 국가, 사무실 또는 시설 이름과 같은 지역입니다.
참고
일반적인 오류는 고유 이름에 사용된 특성을 기반으로 디렉터리가 검색된다고 가정하는 것입니다. 고유 이름은 디렉터리 항목의 고유 식별자일 뿐이며 검색 키로 사용할 수 없습니다. 대신 항목 자체에 저장된 attribute-data 쌍을 기반으로 항목을 검색합니다. 따라서 항목 고유 이름이 uid=bjensen,ou=People,dc=example,dc=com 인 경우 dc:example 이 해당 항목의 속성으로 명시적으로 추가되지 않는 한 해당 항목과 일치하지 않습니다.

4.2.2.3. 복제 고려 사항

디렉터리 트리 설계 프로세스 중에 복제 중인 항목을 고려하십시오. 복제할 항목 세트를 설명하는 자연적인 방법은 하위 트리 상단에 DN을 지정하고 그 아래의 모든 항목을 복제하는 것입니다. 이 하위 트리는 디렉터리 데이터의 일부를 포함하는 디렉터리 파티션인 데이터베이스에도 해당합니다.
예를 들어 엔터프라이즈 환경에서 한 가지 방법은 엔터프라이즈의 네트워크 이름에 해당하도록 디렉터리 트리를 구성하는 것입니다. 네트워크 이름은 변경되지 않으므로 디렉터리 트리 구조가 안정적입니다. 또한 네트워크 이름을 사용하여 디렉터리 트리의 최상위 분기를 만드는 것은 복제를 사용하여 다른 디렉터리 서버와 연결할 때 유용합니다.
예를 들어 Example Corp.에는lightd#178.example.com , ticket .example.comhangar.example.com 이라는 세 가지 주요 네트워크가 있습니다. 처음에 디렉터리 트리를 주요 조직 분할을 위해 세 개의 주요 그룹으로 분기합니다.

그림 4.6. Example Corp의 디렉터리 트리의 초기 분기입니다.

트리의 초기 구조를 생성한 후 각 조직 그룹의 분석을 보여주는 추가 분기를 생성합니다.

그림 4.7. Example Corp의 확장 분기입니다.

Example Cryostat는 조직을 미러링하는 비대칭 트리로 디렉터리를 분기합니다.

그림 4.8. 예제 Cryostat의 디렉터리 분기

디렉터리 트리의 초기 구조를 생성한 후 논리 하위 그룹에 대한 추가 분기를 생성합니다.

그림 4.9. Example Cryostat의 확장 분기

엔터프라이즈와 호스팅 조직 모두 자주 변경되지 않는 정보를 기반으로 데이터 계층을 설계합니다.

4.2.2.4. 액세스 제어 고려 사항

디렉터리 트리에 계층 구조를 도입하여 특정 유형의 액세스 제어를 활성화할 수 있습니다. 복제와 마찬가지로 유사한 항목을 그룹화한 다음 단일 분기에서 관리하는 것이 더 쉽습니다.
계층적 디렉터리 트리를 통해 관리 배포를 활성화할 수도 있습니다. 예를 들어 마케팅 부서의 관리자에게 마케팅 항목에 대한 액세스 권한과 영업 부서의 관리자에게 영업 항목에 대한 액세스 권한을 부여하려면 해당 부서에 따라 디렉터리 트리를 설계합니다.
액세스 제어는 디렉터리 트리가 아닌 디렉터리 콘텐츠를 기반으로 할 수 있습니다. 필터링된 메커니즘은 디렉터리 항목에 특정 특성 값이 포함된 모든 항목에 대한 액세스 권한이 있음을 나타내는 단일 액세스 제어 규칙을 정의할 수 있습니다. 예를 들어 영업 관리자에게 속성 값이 포함된 모든 항목에 액세스할 수 있는 ACI 필터를 설정합니다.
그러나 ACI 필터는 관리하기가 어려울 수 있습니다. 디렉터리 트리 계층 구조, ACI 필터 또는 이 둘의 조합에서 조직 분기에 가장 적합한 액세스 제어 방법을 결정합니다.

4.2.3. 항목 이름 지정

디렉터리 트리의 계층 구조를 설계한 후 구조 내의 항목의 이름을 지정할 때 사용할 속성을 결정합니다. 일반적으로 이름은 RDN(상대적으로 고유 이름) 을 형성하기 위해 하나 이상의 특성 값을 선택하여 생성됩니다. RDN은 DN 내의 단일 구성 요소입니다. 표시된 첫 번째 구성 요소이므로 해당 구성 요소에 사용된 속성은 항목의 고유 이름을 설정하므로 이름 지정 속성입니다. 사용할 속성은 이름이 지정된 항목 유형에 따라 다릅니다.
항목 이름은 다음 규칙을 준수해야 합니다.
  • 이름 지정에 대해 선택한 속성은 변경되지 않을 수 있습니다.
  • 이름은 디렉터리에서 고유해야 합니다.
    고유한 이름을 사용하면 DN에서 디렉터리의 최대 하나의 항목을 볼 수 있습니다.
항목을 생성할 때 항목 내에 RDN을 정의합니다. 항목 내에 최소한 RDN을 정의하면 항목을 더 쉽게 찾을 수 있습니다. 검색은 실제 DN에 대해 수행되는 것이 아니라 항목 자체에 저장된 속성 값이기 때문입니다.
특성 이름에는 의미가 있으므로 나타내는 항목 유형과 일치하는 속성 이름을 사용하십시오. 예를 들어 l 을 사용하여 조직을 대표하거나 조직 단위를 나타내는 데 c 를 사용하지 마십시오.

4.2.3.1. 개인 항목 이름 지정

사람 항목의 이름, DN은 고유해야 합니다. 일반적으로 고유 이름은 commonName 또는 cn 특성을 사용하여 사용자 항목의 이름을 지정합니다. 즉, Babs Jensen이라는 이름의 항목에는 cn=Babs Jensen,dc=example,dc=com 의 고유 이름이 있을 수 있습니다.
공통 이름을 사용하면 해당 항목과 더 쉽게 연결할 수 있지만 이름이 동일한 사람을 제외할 수 있을 만큼 고유하지 않을 수 있습니다. 이렇게 하면 동일한 고유 이름의 여러 항목인 DN 이름 충돌 이라는 문제가 빠르게 발생합니다.
cn=Babs Jensen+employeeNumber=23,dc=example,dc=com 과 같은 일반 이름 충돌을 방지합니다.
그러나 이로 인해 대규모 디렉터리의 일반 이름이 어색하게 될 수 있으며 유지 관리하기 어려울 수 있습니다.
더 나은 방법은 cn 이 아닌 다른 속성을 가진 사람 항목을 식별하는 것입니다. 다음 속성 중 하나를 사용하는 것이 좋습니다.
  • uid
    uid 속성을 사용하여 해당 사용자의 고유한 값을 지정합니다. 사용자 로그인 ID 또는 직원 번호가 포함될 수 있습니다. 호스팅 환경의 구독자는 uid 특성으로 식별해야 합니다.
  • mail
    mail 속성에는 항상 고유한 사람 이메일 주소가 포함되어 있습니다. 이 옵션을 사용하면 중복 속성 값(예: mail=bjensen@example.com,dc=example,dc=com)을 포함하는 어색한 DN이 발생할 수 있으므로 uid 속성에 사용할 다른 고유 값이 없는 경우에만 이 옵션을 사용합니다. 예를 들어 엔터프라이즈에서 임시 또는 계약직원에 직원 번호 또는 사용자 ID를 할당하지 않는 경우 uid 속성 대신 mail 속성을 사용합니다.
  • employeeNumber
    inetOrgPerson 오브젝트 클래스의 직원의 경우 employeeNumber 와 같은 고용주가 할당한 특성 값을 사용하는 것이 좋습니다.
RDNs의 직접 항목 RDN에 대한 특성-데이터 쌍에 사용되는 모든 항목이 고유한 영구 값인지 확인합니다. RDN 사용자 항목도 읽을 수 있어야 합니다. 예를 들어, uid=bjensen,dc=example,dc=comuid=b12r56A,dc=example,dc=com 에 선호되며 인식 가능한 DN은 고유 이름을 기반으로 디렉터리 항목 변경과 같은 일부 디렉터리 작업을 간소화하기 때문입니다. 또한 일부 디렉터리 클라이언트 애플리케이션에서는 uidcn 속성이 사람이 읽을 수 있는 이름을 사용한다고 가정합니다.

호스팅 환경에서 개인 등록 고려 사항

사용자가 서비스에 대한 구독자인 경우 항목은 개체 클래스 inetUser 여야 하며 항목에 uid 속성이 포함되어야 합니다. 속성은 customer 하위 트리 내에서 고유해야 합니다.

사람이 호스팅 조직의 일부인 경우 nsManagedPerson 개체 클래스를 사용하여 inetOrgPerson 으로 표시합니다.

DIT에 Person Entries 배치

다음은 디렉터리 트리에 사람 항목을 배치하기 위한 몇 가지 지침입니다.

  • 엔터프라이즈의 사용자는 조직의 항목 아래에 있는 디렉터리 트리에 있어야 합니다.
  • 호스팅 조직의 구독자는 호스팅 조직의 ou=people 분기 아래에 있어야 합니다.

4.2.3.2. 그룹 항목 이름 지정

그룹을 나타내는 4 가지 주요 방법이 있습니다.
  • 명시적으로 정의하는 정적 그룹은 멤버입니다. groupOfNames 또는 groupOfUniqueNames 오브젝트 클래스에는 그룹의 멤버 이름을 지정하는 값이 포함되어 있습니다. 정적 그룹은 디렉터리 관리자 그룹과 같이 멤버가 적은 그룹에 적합합니다. 정적 그룹은 수천 개의 멤버가 있는 그룹에 적합하지 않습니다.
    uniqueMembergroupOfUniqueNames 오브젝트의 필수 특성이므로 정적 그룹 항목에는 uniqueMember 속성 값이 포함되어야 합니다. 이 오브젝트 클래스에는 그룹 항목의 DN을 형성하는 데 사용할 수 있는 cn 속성이 필요합니다.
  • 동적 그룹은 검색 필터 및 하위 트리가 있는 그룹을 나타내는 항목을 사용합니다. 필터와 일치하는 항목은 그룹의 멤버입니다.
  • 역할은 정적 및 동적 그룹 개념을 통합합니다. 자세한 내용은 4.3절. “그룹화 디렉토리 항목”를 참조하십시오.
호스팅 조직이 포함된 배포에서 groupOfUniqueNames 오브젝트 클래스를 사용하여 디렉터리 관리에 사용되는 그룹의 멤버라는 값을 포함하는 것이 좋습니다. 호스팅된 조직에서는 디렉터리 관리에 사용되는 그룹 항목을 ou=Groups 분기 아래에 있는 것이 좋습니다.

4.2.3.3. 조직 항목 이름 지정

다른 항목 이름과 마찬가지로 조직 항목 이름은 고유해야 합니다. 조직의 법적 이름과 다른 속성 값을 사용하면 이름이 o=example_a+st=Washington,o=ISP,c=US 와 같은 고유한 이름을 확인하는 데 도움이 됩니다.
상표는 사용할 수도 있지만 고유하게 보장되는 것은 아닙니다.
호스팅 환경에서 조직 (o) 속성을 naming 속성으로 사용합니다.

4.2.3.4. 기타 유형의 항목 이름 지정

디렉터리에는 지역, 상태, 국가, 장치, 서버, 네트워크 정보 및 기타 종류의 데이터와 같이 많은 것을 나타내는 항목이 포함되어 있습니다.
이러한 유형의 항목은 가능한 경우 RDN에서 cn 속성을 사용합니다. 그런 다음 그룹 항목의 이름을 지정하려면 cn=administrators,dc=example,dc=com 과 같은 이름을 지정합니다.
그러나 항목의 오브젝트 클래스에서 commonName 속성을 지원하지 않는 경우가 있습니다. 대신 항목의 개체 클래스에서 지원하는 속성을 사용합니다.
항목의 DN에 사용되는 속성은 항목에서 실제로 사용된 속성에 해당하지 않아도 됩니다. 그러나 항목에서 사용하는 DN 속성과 특성 간에 몇 가지 상관 관계가 있으면 디렉터리 트리의 관리가 간소화됩니다.

4.2.4. Entries 및 Subtrees 이름 변경

4.2.3절. “항목 이름 지정” Red Hat Directory Server에서 항목 이름 지정의 중요성에 대해 설명합니다. 항목 이름(적용)은 디렉터리 트리 구조를 정의합니다. 각 분기 지점(아래 항목이 있는 각 항목)은 계층 구조에 새 링크를 생성합니다.

예 4.1. 항목 DN 빌드

                                                                  dc=example,dc=com  =>  root suffix
                                                        ou=People,dc=example,dc=com  =>  org unit
                                          st=California,ou=People,dc=example,dc=com  =>  state/province
                          l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  city
           ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  leaf entry
Copy to Clipboard Toggle word wrap
항목의 이름 지정 특성이 DN의 왼쪽 요소가 변경되면 이는 modrdn 작업입니다. 즉, 디렉터리 트리 내에서 항목을 이동하므로 특별한 종류의 수정 작업입니다. 리프 항목( 자식이 없는 항목)의 경우 modrdn 작업은 나중에 이동하며 항목에는 새 이름만 있는 동일한 상위 항목이 있습니다.

그림 4.10. Leaf Entry에 대한 modrdn 작업

하위 트리 항목의 경우 modrdn 작업에서는 하위 트리 항목 자체의 이름을 바꿀 뿐만 아니라 하위 트리 아래에 있는 모든 하위 항목의 DN 구성 요소도 변경합니다.

그림 4.11. Subtree Entry에 대한 modrdn 작업

중요
하위 트리 modrdn 작업도 이동하고 하위 트리 항목 아래의 모든 하위 항목의 이름을 변경합니다. 대규모 하위 트리의 경우 시간 및 리소스 집약적인 프로세스일 수 있습니다. 자주 하위 트리 이름 변경 작업이 필요하지 않도록 디렉터리 트리 계층 구조의 이름 지정 구조를 계획합니다.
하위 트리의 이름을 바꾸는 것과 유사한 작업이 한 하위 트리에서 다른 하위 트리로 항목을 이동하는 것입니다. 이는 확장된 유형의 modrdn이며, 이는 항목 이름을 동시에 변경하고 항목을 부모 간에 이동하는 newsuperior 특성을 설정합니다.

그림 4.12. 새 상위 항목에 대한 수정 작업

항목이 entryrdn.db 인덱스에 저장되는 방법 때문에 새로운 우수성 및 하위 트리 이름 변경 작업이 가능합니다. 각 항목은 자체 키( 자체 링크 ) 및 해당 상위 링크(부모 링크 ) 및 모든 자식을 식별하는 하위 키로 식별됩니다. 부모와 자식을 항목에 대한 속성으로 취급하여 디렉터리 트리 계층 구조를 설명하는 형식이 있으며 모든 항목은 전체 DN이 아닌 고유한 ID와 RDN으로 설명되어 있습니다.
numeric_id:RDN => self link  
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
P#:RDN => parent link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
C#:RDN => child link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
Copy to Clipboard Toggle word wrap
예를 들어 ou=people 하위 트리에는 dc=example,dc=comuid=jsmith 의 하위 항목이 있습니다.
4:ou=people
   ID: 4; RDN: "ou=People"; NRDN: "ou=people"
P4:ou=people
   ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com"
C4:ou=people
   ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
Copy to Clipboard Toggle word wrap
이름 변경 작업을 수행할 때 고려해야 할 몇 가지 사항이 있습니다.
  • 루트 접미사의 이름을 변경할 수 없습니다.
  • 하위 트리 이름 변경 작업은 복제에 최소한의 영향을 미칩니다. 복제 계약은 데이터베이스의 하위 트리가 아닌 전체 데이터베이스에 적용되므로 하위 트리 이름 변경 작업에 복제 계약을 다시 구성할 필요가 없습니다. 하위 트리 이름 변경 작업이 정상적으로 복제된 후 모든 이름이 변경됩니다.
  • 하위 트리의 이름을 변경하려면 모든 동기화 계약을 다시 구성해야 할 수 있습니다. 동기화 계약은 접미사 또는 하위 트리 수준에서 설정되므로 하위 트리의 이름을 변경하면 동기화가 중단될 수 있습니다.
  • 하위 트리의 이름을 변경하려면 하위 트리에 대해 설정된 모든 하위 트리 수준 ACI와 하위 트리의 하위 항목에 대해 설정된 모든 항목 수준 ACI를 수동으로 구성해야 합니다.
  • 하위 트리의 이름을 자식으로 변경할 수는 있지만 하위 트리를 자식으로 삭제할 수는 없습니다.
  • ou 에서 dc 로 이동하는 것과 같이 하위 트리의 구성 요소를 변경하려고 하면 스키마 위반으로 실패할 수 있습니다. 예를 들어 organizationalUnit 오브젝트 클래스에는 ou 특성이 필요합니다. 해당 특성이 하위 트리 이름 변경의 일부로 제거되면 작업이 실패합니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat