test

Sun Java System Directory Server Enterprise Edition 6.3 관리 설명서

12장 디렉토리 서버 스키마

디렉토리 서버는 수백 개의 객체 클래스 및 속성이 포함된 표준 스키마와 함께 제공됩니다. 표준 객체 클래스 및 속성만으로도 대부분의 요구 사항을 충족시킬 수 있지만, 새로운 객체 클래스 및 속성을 만들어 스키마를 확장해야 하는 경우도 있습니다. 표준 스키마에 대한 개요와 배포에 적합한 스키마 설계에 대한 지침은 Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide를 참조하십시오.

이 장은 스키마 관리 방법에 대해 설명하며 다음 내용으로 구성되어 있습니다.

스키마 검사 관리

스키마 검사가 활성화되어 있으면 디렉토리 서버에서 모든 가져오기, 추가 및 수정 작업이 현재 정의된 디렉토리 스키마에 맞는지 확인합니다.

주 –

항목을 수정하면 디렉토리 서버는 수정되는 속성만이 아닌 전체 항목에 대해 스키마 검사를 수행합니다. 따라서 항목의 객체 클래스 또는 속성이 스키마에 맞지 않으면 작업이 실패할 수 있습니다.

그러나 스키마 검사는 구문과 관련하여 속성 값의 유효성을 확인하지는 않습니다.

스키마 검사는 기본적으로 활성화되며 일반적으로 스키마 검사를 활성화한 상태에서 디렉토리 서버를 실행합니다. 대부분의 클라이언트 응용 프로그램은 스키마 검사를 활성화하면 모든 항목이 스키마에 맞을 것이라고 가정합니다. 그러나 스키마 검사를 활성화해도 디렉토리 서버에서 디렉토리의 기존 내용은 확인되지 않습니다. 모든 디렉토리 내용이 스키마에 맞도록 하려면 항목을 추가하거나 모든 항목을 다시 초기화하기 전에 스키마 검사를 활성화해야 합니다.

스키마에 맞는 LDAP 파일의 가져오기 작업 속도를 향상시키기 위해 예외적으로 스키마 검사를 비활성화할 수도 있습니다. 그러나 스키마 검사가 비활성화되면 스키마에 맞지 않는 항목을 가져올 위험이 있으며 가져온 항목이 스키마에 맞지 않으면 감지되지 않습니다.

복제된 환경에서 스키마 검사를 사용하는 방법에 대한 자세한 내용은 디렉토리 스키마 복제를 참조하십시오.

Procedure스키마 호환 문제를 해결하는 방법

항목이 스키마에 맞지 않으면 해당 항목을 검색하지 못할 수 있으며 이 항목에 대한 수정 작업이 실패할 수 있습니다. 이 문제를 해결하려면 이 절차의 단계를 수행합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

시작하기 전에

스키마 호환 문제를 발생시키지 않으려면 배포 전에 스키마를 계획하여 스키마 변경을 최소화합니다. 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide를 참조하십시오.

  1. 항목이 스키마에 맞지 않는 이유를 확인하려면 항목을 검색한 다음 현재 정의된 스키마와 수동으로 비교합니다.

    자세한 내용은 속성 유형을 보는 방법 및 객체 클래스를 보는 방법을 참조하십시오.

  2. 스키마와 맞도록 항목을 수정하거나 항목과 맞도록 스키마를 수정합니다.

사용자 정의 스키마 정보

표준 스키마가 디렉토리 요구 사항에 대해 너무 제한되어 있는 경우 이를 확장할 수 있습니다. 스키마를 사용자 정의하는 경우 다음 지침을 수행합니다.

스키마를 사용자 정의할 때 표준 스키마에서 속성 또는 객체 클래스의 기존 정의를 수정, 삭제 또는 대체하지 마십시오. 이렇게 하면 다른 디렉토리 및 LDAP 클라이언트 응용 프로그램과의 호환성 문제가 발생할 수 있습니다.

디렉토리 서버의 내부 작업 속성을 수정하지 마십시오. 대신 외부 응용 프로그램에 사용자 고유의 작업 변수를 만들 수 있습니다.

objectClass: extensibleObject를 사용하는 대신 항상 객체 클래스를 정의합니다. 디렉토리 서버는 객체 클래스 extensibleObject가 있는 항목에 대해 스키마 검사를 수행하지 않으므로 해당 항목에 대한 속성을 제한하거나 검사하지 않습니다. givenName 속성 유형에 대해 giveName과 같은 응용 프로그램의 오타는 디렉토리 서버에서 감지되지 않습니다. 디렉토리 서버에서는 다른 한 편으로 extensibleObject 항목의 정의되지 않은 모든 속성에 여러 값을 가지고 있고, 대소문자를 구분하지 않는 문자열 구문이 있어야 한다고 가정해야 합니다. 또한, 일부 응용 프로그램은 특정 객체 클래스가 있는 항목을 사용합니다. 일반적으로 응용 프로그램에 객체 클래스 확장이 필요한 경우에는 스키마 관리를 계속 유지하고 대신, 응용 프로그램에 필요한 속성이 포함된 보조 객체 클래스를 만듭니다.

이 절은 기본 디렉토리 스키마에 대한 내용과 사용자 정의 속성 및 객체 클래스 만들기에 대한 내용으로 구성되어 있습니다.

기본 디렉토리 서버 스키마

디렉토리 서버와 함께 제공된 스키마는 instance-path/config/schema/ 디렉토리에 저장된 파일 집합에서 설명합니다.

이 디렉토리에는 디렉토리 서버에 대한 일반 스키마 및 관련 제품이 모두 포함되어 있습니다. LDAP v3 표준 사용자 및 조직 스키마는 00core.ldif 파일에 있습니다. 이전 버전의 디렉토리에서 사용된 구성 스키마는 50ns-directory.ldif 파일에 있습니다.

주 –

서버가 실행 중일 때에는 이 디렉토리에서 파일을 수정하지 마십시오.

객체 식별자

각 LDAP 객체 클래스 또는 속성에는 고유 이름 및 객체 식별자(OID)를 할당해야 합니다. 스키마를 정의하는 경우 해당 조직에 고유한 OID가 필요합니다. OID는 한 개만 있어도 모든 스키마 요구 사항을 충족합니다. 이후에 사용자의 속성 및 객체 클래스에 따라 해당 OID에 새 분기를 추가합니다.

사용자 스키마에서 OID를 얻고 할당하려면 다음 작업을 수행합니다.

속성 및 객체 클래스 이름 지정

새 속성 및 객체 클래스에 이름을 만드는 경우 스키마에서 사용하기 편하도록 의미있는 이름을 만듭니다.

사용자 정의 요소에 고유 접두어를 포함시켜 사용자 정의 스키마 요소와 기존 스키마 요소 간의 이름 충돌을 방지합니다. 예를 들어 Example.com Corporation의 경우 각 사용자 정의 스키마 요소 앞에 접두어 Example을 추가할 수 있습니다. 또한, 해당 디렉토리에서 Example.com 직원을 식별할 수 있도록 ExamplePerson이라는 특수 객체 클래스를 추가할 수도 있습니다.

LDAP에서 속성 유형 이름 및 객체 클래스 이름은 대소문자를 구분하지 않습니다. 응용 프로그램에서 이 이름은 대소문자를 구분하지 않는 문자열로 처리해야 합니다.

새 객체 클래스를 정의하는 경우

기존 객체 클래스가 디렉토리 항목에 저장해야 할 모든 정보를 지원하지 않는 경우 새 객체 클래스를 추가합니다.

새 객체 클래스를 만드는 방법에는 두 가지가 있습니다.

새 객체 클래스를 구현하는 방법을 결정할 때에는 다음 사항을 고려해야 합니다.

새 속성을 정의하는 경우

기존 속성이 디렉토리 항목에 저장해야 할 모든 정보를 지원하지 않는 경우 새 속성을 추가합니다. 가능한 경우 표준 속성을 사용합니다. 기본 디렉토리 스키마에 이미 있는 속성을 검색하고 이 속성을 새 객체 클래스와 연관하여 사용합니다.

예를 들어 person, organizationalPerson 또는 inetOrgPerson 객체 클래스의 지원보다는 개인 항목에 대한 자세한 정보를 저장하려고 할 수 있습니다. 디렉토리에 생년월일을 저장하려면 표준 디렉토리 서버 스키마 내에 속성이 없어야 하며 dateOfBirth라는 새 속성을 만들 수 있습니다. 이 속성을 허용하는 새 보조 클래스를 정의하여 이 속성이 사람을 나타내는 항목에 사용될 수 있도록 허용합니다.

사용자 정의 스키마 파일을 만드는 경우

사용자 정의 스키마 파일을 만드는 경우, 특히 복제를 사용하는 경우에는 다음 사항에 유의하십시오.

LDAP를 통한 속성 유형 관리

이 절에서는 LDAP를 통해 속성 유형을 만들고 보고 삭제하는 방법에 대해 설명합니다.

속성 유형 만들기

cn=schema 항목에는 디렉토리 스키마에 각 속성 유형의 정의가 포함된, 여러 값을 갖는 속성 attributeTypes가 있습니다. ldapmodify(1) 명령을 사용하면 이러한 정의에 다른 내용을 추가할 수 있습니다.

새 속성 유형 정의 및 사용자 정의 속성 유형에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.

새 속성 유형을 정의하려면 각 속성 유형 정의에 반드시 OID를 입력해야 합니다. 또한 새 속성 유형에 반드시 다음 요소를 사용해야 합니다.

Procedure속성 유형을 만드는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. RFC 4517에 지정된 구문에 따라 속성 유형 정의를 준비합니다.

  2. ldapmodify(1) 명령을 사용하여 속성 유형 정의를 추가합니다.

    디렉토리 서버에서는 사용자가 입력한 정의에 X-ORIGIN 'user defined'를 추가합니다.

예 12–1 속성 유형 만들기

다음 예에서는 ldapmodify 명령을 사용하여 디렉토리 문자열 구문으로 새 속성 유형을 추가합니다.


$ cat blogURL.ldif 
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.2.3.4.5.6.7 
 NAME ( 'blog' 'blogURL' ) 
 DESC 'URL to a personal weblog' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
 SINGLE-VALUE )

$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogURL.ldif
Enter bind password: 
modifying entry cn=schema

$

작업 환경에서 1.2.3.4.5.6.7이 아닌 유효한 고유 OID를 입력합니다.

속성 유형 보기

cn=schema 항목에는 디렉토리 스키마에서 각 속성 유형의 정의가 포함된, 여러 값을 갖는 속성 attributeTypes가 있습니다. ldapsearch(1) 명령을 사용하면 이러한 정의를 읽을 수 있습니다.

Procedure속성 유형을 보는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. ldapsearch 명령을 사용하여 현재 디렉토리 스키마에 있는 모든 속성 유형 정의를 봅니다.

예 12–2 속성 유형 보기

다음 명령을 실행하면 모든 속성 유형 정의가 표시됩니다.


$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes

-T 옵션을 사용하면 ldapsearch 명령 실행 시 LDIF 줄이 겹치지 않으므로 grep 또는 sed와 같은 명령을 사용하여 출력 작업을 쉽게 수행할 수 있습니다. 그런 다음 grep 명령을 통해 이 명령의 출력을 파이프하면 디렉토리 스키마에 대해 사용자 정의 확장만 볼 수 있습니다. 예를 들면 다음과 같습니다.


$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes | grep "user defined"
 attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) 
 DESC 'URL to a personal weblog' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE 
 X-ORIGIN 'user defined' )

속성 유형 삭제

cn=schema 항목에는 디렉토리 스키마에서 각 속성 유형의 정의가 포함된, 여러 값을 갖는 속성 attributeTypes가 있습니다. ldapmodify(1) 명령을 사용하면 X-ORIGIN 'user defined'가 포함된 정의를 삭제할 수 있습니다.

스키마는 cn=schema에 있는 LDAP 뷰에서 정의되기 때문에 ldapsearch 및 ldapmodify 유틸리티를 사용하여 온라인으로 스키마를 보고 수정할 수 있습니다. 그러나 X-ORIGIN 필드에 대해서는 ’user defined’ 값이 있는 스키마 요소만 삭제할 수 있습니다. 서버에서 다른 정의는 삭제되지 않습니다.

사용자 정의 속성에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.

Procedure속성 유형을 삭제하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 삭제할 속성 유형 정의를 봅니다.

    자세한 내용은 속성 유형을 보는 방법을 참조하십시오.

  2. ldapmodify(1) 명령을 사용하여 스키마에 표시된 대로 속성 유형 정의를 삭제합니다.

예 12–3 속성 유형 삭제

The following command deletes the attribute type that is created in 예 12–1:


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password: 
dn: cn=schema
changetype: delete
delete: attributeTypes
attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) 
 DESC 'URL to a personal weblog' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE 
 X-ORIGIN 'user defined' )
^D

이 스키마 정의를 확장으로 분류하려면 디렉토리 서버에서 추가된 X-ORIGIN 'user defined'를 포함시켜야 합니다.

LDAP를 통한 객체 클래스 관리

이 절에서는 LDAP를 통해 객체 클래스를 만들고 보고 삭제하는 방법에 대해 설명합니다.

객체 클래스 만들기

cn=schema 항목에는 디렉토리 스키마에서 각 객체 클래스의 정의가 포함된, 여러 값을 갖는 속성 objectClasses가 있습니다. ldapmodify(1) 명령을 사용하면 이러한 정의에 다른 내용을 추가할 수 있습니다.

새 객체 클래스 정의 및 사용자 정의 객체 클래스에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.

다른 객체 클래스에서 상속 받는 객체 클래스를 여러 개 만드는 경우에는 먼저 부모 객체 클래스를 만들어야 합니다. 새 객체 클래스에 사용자 정의 속성이 사용되면 이러한 속성도 먼저 정의해야 합니다.

각 객체 클래스 정의에 반드시 OID를 입력해야 합니다. 또한 새 객체 클래스에 반드시 다음 요소를 사용해야 합니다.

Procedure객체 클래스를 만드는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. RFC 4517에 지정된 구문에 따라 객체 클래스 정의를 준비합니다.

  2. ldapmodify(1) 명령을 사용하여 객체 클래스 정의를 추가합니다.

    디렉토리 서버에서는 사용자가 입력한 정의에 X-ORIGIN 'user defined'를 추가합니다.

예 12–4 객체 클래스 만들기

다음 예에서는 ldapmodify 명령을 사용하여 새 객체 클래스를 추가합니다.


$ cat blogger.ldif 
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.2.3.4.5.6.8 
 NAME 'blogger' 
 DESC 'Someone who has a blog' 
 SUP inetOrgPerson 
 STRUCTURAL 
 MAY blog )

$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif
Enter bind password: 
modifying entry cn=schema

$

작업 환경에서 1.2.3.4.5.6.8이 아닌 유효한 고유 OID를 입력합니다.

객체 클래스 보기

cn=schema 항목에는 디렉토리 스키마에서 각 객체 클래스의 정의가 포함된, 여러 값을 갖는 속성 objectClasses가 있습니다. ldapsearch(1) 명령을 사용하면 이러한 정의를 읽을 수 있습니다.

Procedure객체 클래스를 보는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. ldapsearch 명령을 사용하여 현재 디렉토리 스키마에 있는 모든 객체 클래스 정의를 봅니다.

예 12–5 객체 클래스 보기

다음 명령을 실행하면 모든 객체 클래스의 정의가 표시됩니다.


$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses

-T 옵션을 사용하면 ldapsearch 명령 실행 시 LDIF 줄이 겹치지 않으므로 grep 또는 sed와 같은 명령을 사용하여 출력 작업을 쉽게 수행할 수 있습니다. 그런 다음 grep 명령을 통해 이 명령의 출력을 파이프하면 디렉토리 스키마에 대해 사용자 정의 확장만 볼 수 있습니다. 예를 들면 다음과 같습니다.


$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined"
objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger'
 DESC 'Someone who has a blog' STRUCTURAL MAY blog
 X-ORIGIN 'user defined' )
$

객체 클래스 삭제

cn=schema 항목에는 디렉토리 스키마에서 각 객체 클래스의 정의가 포함된, 여러 값을 갖는 속성 objectClasses가 있습니다. ldapmodify(1) 명령을 사용하면 X-ORIGIN 'user defined'가 포함된 정의를 삭제할 수 있습니다.

스키마는 cn=schema에 있는 LDAP 뷰에서 정의되기 때문에 ldapsearch 및 ldapmodify 유틸리티를 사용하여 온라인으로 스키마를 보고 수정할 수 있습니다. 그러나 X-ORIGIN 필드에 대해서는 ’user defined’ 값이 있는 스키마 요소만 삭제할 수 있습니다. 서버에서 다른 정의는 삭제되지 않습니다.

사용자 정의 요소에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.

Procedure객체 클래스를 삭제하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 삭제할 객체 클래스의 정의를 봅니다.

    자세한 내용은 객체 클래스를 보는 방법을 참조하십시오.

  2. ldapmodify(1) 명령을 사용하여 스키마에 표시된 대로 객체 클래스 정의를 삭제합니다.

예 12–6 객체 클래스 삭제

다음 명령을 실행하면 예 12–4에서 만든 객체 클래스가 삭제됩니다.


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password: 
dn: cn=schema
changetype: delete
delete: objectClasses
objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' 
 STRUCTURAL MAY blog X-ORIGIN 'user defined' )
^D

이 스키마 정의를 확장으로 분류하려면 디렉토리 서버에서 추가된 X-ORIGIN 'user defined'를 포함시켜야 합니다.

디렉토리 서버 스키마 확장

스키마에 새 속성을 추가하는 경우 새 속성이 포함될 새 객체 클래스를 만들어야 합니다. 대부분의 필수 속성이 포함되어 있는 기존의 객체 클래스에 속성을 추가하는 것이 더 편리할 수도 있지만 LDAP 클라이언트와의 상호 운용성이 저하되는 단점이 있습니다.

디렉토리 서버와 기존 LDAP 클라이언트와의 상호 운용성은 표준 LDAP 스키마에 기반을 두고 있으므로 표준 스키마를 변경하면 서버를 업그레이드할 때 문제가 발생합니다. 표준 스키마 요소를 삭제할 수 없는 것도 이 때문입니다.

디렉토리 서버 스키마는 cn=schema 항목 속성에 저장됩니다. 구성 항목과 마찬가지로 이 항목은 서버 시작 중에 파일에서 읽은 스키마의 LDAP 뷰입니다.

디렉토리 서버 스키마를 확장하는 데 사용하는 방법은 스키마 확장이 저장되는 파일 이름을 제어할지 여부에 따라 달라집니다. 또한 복제를 통해 변경 사항을 사용자에게 푸시할지 여부에 따라서도 달라집니다. 특정 상황에 맞게 수행할 절차를 결정하려면 다음 표를 참조하십시오.

표 12–1 스키마 확장 방법

작업 

지침 

복제를 사용하지 않고 사용자 정의 스키마 파일을 추가하여 스키마를 확장합니다. 

사용자 정의 스키마 파일을 사용하여 스키마를 확장하는 방법

LDAP를 통해 스키마를 확장합니다. 

LDAP를 통해 스키마를 확장하는 방법

복제를 사용하고 모든 서버에 사용자 정의 스키마 파일의 파일 이름을 유지합니다. 

사용자 정의 스키마 파일을 사용하여 스키마를 확장하는 방법

복제를 사용하고 마스터 복제본에 사용자 정의 스키마 파일을 추가하여 스키마를 확장합니다. 그런 다음 복제 메커니즘을 통해 스키마 확장을 사용자 서버에 복사합니다. 

스키마 파일 및 복제를 사용하여 스키마를 확장하는 방법

객체 클래스, 속성 및 디렉토리 스키마에 대한 자세한 내용과 스키마 확장에 대한 지침은 Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide의 Designing a Directory Schema를 참조하십시오. 표준 속성 및 객체 클래스에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference를 참조하십시오.

이 절에서는 디렉토리 스키마를 확장하는 다양한 방법에 대해 설명합니다.

사용자 정의 스키마 파일을 사용한 스키마 확장

스키마 파일은 instance-path/config/schema/에 있는 LDIF 파일입니다. instance-path는 디렉토리 서버 인스턴스가 있는 파일 시스템 디렉토리에 해당합니다. 예를 들어 인스턴스는 /local/ds/에 있을 수 있습니다. 이 파일은 디렉토리 서버에서 사용하는 표준 스키마와 디렉토리 서버를 사용하는 모든 서버를 정의합니다. 이 파일과 표준 스키마는 Sun Java System Directory Server Enterprise Edition 6.3 Reference 및 Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference에서 설명합니다.

서버는 시작 시에만 한 번 스키마 파일을 읽습니다. 파일의 LDIF 내용은 cn=schema에 있는 스키마의 메모리 내장 LDAP 뷰에 추가됩니다. 스키마 정의의 순서가 중요하기 때문에 스키마 파일 이름 앞에는 번호가 붙으며 영숫자순으로 로드됩니다. 이 디렉토리에 있는 스키마 파일은 설치 중에 정의된 시스템 사용자만 쓸 수 있습니다.

LDIF 파일에 스키마를 직접 정의하는 경우 X-ORIGIN 필드에 ’user defined’ 값을 사용하지 마십시오. 이 값은 cn=schema의 LDAP 뷰를 통해 정의되며 99user.ldif 파일에 표시되는 스키마 요소에 예약된 값입니다.

99user.ldif 파일에는 cn=schema 항목에 대한 추가 ACI 및 명령줄이나 DSCC에서 추가된 모든 스키마 정의가 포함됩니다. 새 스키마 정의가 추가되면 99user.ldif 파일을 덮어쓰기 때문에 이 파일을 수정하려는 경우에는 즉시 서버를 다시 시작하여 변경 사항을 저장해야 합니다.

다른 스키마 파일에 정의된 표준 스키마를 수정할 수는 없지만 대신 새 파일을 추가하여 새 속성과 객체 클래스를 정의할 수 있습니다. 예를 들어 여러 서버에 새 스키마 요소를 정의하려면 98mySchema.ldif 파일에 스키마 요소를 정의한 다음 이 파일을 모든 서버의 스키마 디렉토리에 복사할 수 있습니다. 그런 다음 모든 서버를 다시 시작하여 새 스키마 파일을 로드해야 합니다.

Procedure사용자 정의 스키마 파일을 사용하여 스키마를 확장하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 98mySchema.ldif와 같은 사용자 고유의 스키마 정의 파일을 만듭니다.

    스키마 파일의 정의 구문은 RFC 4517에서 설명합니다.

  2. (옵션) 이 서버가 다른 서버에 업데이트를 전송하는 마스터 복제본인 경우 스키마 정의 파일을 복제 토폴로지의 각 서버 인스턴스에 복사합니다.

    스키마가 포함된 LDIF 파일에서 직접 변경한 사항은 복제 메커니즘에서 감지할 수 없으므로 마스터를 다시 시작해도 변경 사항이 사용자에 복제되지는 않습니다.

  3. 스키마 정의 파일이 복사된 각 디렉토리 서버 인스턴스를 다시 시작합니다.

    서버가 다시 시작되어 스키마 정의가 다시 로드되면 변경 사항이 적용됩니다.

LDAP를 통한 스키마 확장

스키마는 cn=schema에 있는 LDAP 뷰에서 정의되기 때문에 ldapsearch 및 ldapmodify 유틸리티를 사용하여 온라인으로 스키마를 보고 수정할 수 있습니다. 그러나 X-ORIGIN 필드에 대해서는 ’user defined’ 값이 있는 스키마 요소만 수정할 수 있습니다. 다른 정의에 대한 수정은 서버에서 모두 거부합니다.

사용자 정의 요소에 대한 변경 사항과 새로운 요소 정의는 99user.ldif 파일에 저장됩니다.

ProcedureLDAP를 통해 스키마를 확장하는 방법

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

시작하기 전에

명령줄에서 스키마 정의를 수정하는 경우 긴 값을 정확하게 입력해야 하기 때문에 오류가 발생할 가능성이 큽니다. 하지만 디렉토리 스키마를 업데이트해야 하는 스크립트에 이 기능을 사용할 수 있습니다.

  1. ldapmodify(1) 명령을 사용하여 개별 attributeTypes 속성 값을 추가하거나 삭제합니다.

    자세한 내용은 속성 유형을 만드는 방법 또는 속성 유형을 삭제하는 방법을 참조하십시오.

  2. ldapmodify(1) 명령을 사용하여 개별 objectClasses 속성 값을 추가하거나 삭제합니다.

    자세한 내용은 객체 클래스를 만드는 방법 또는 객체 클래스를 삭제하는 방법을 참조하십시오.

참조

값 중 하나를 수정하려면 특정 값을 삭제한 다음 이 값을 새 값으로 추가해야 합니다. 이 프로세스는 속성이 여러 값을 갖기 때문에 필요합니다. 자세한 내용은 여러 값을 갖는 속성의 값 하나만 수정을 참조하십시오.

스키마 파일 및 복제를 사용한 스키마 확장

사용자 정의 스키마 파일에 대한 자세한 내용은 사용자 정의 스키마 파일을 사용한 스키마 확장을 참조하십시오. 다음 절차에서는 복제 메커니즘을 사용하여 스키마 확장을 토폴로지의 모든 서버에 전달하는 방법에 대해 설명합니다.

Procedure스키마 파일 및 복제를 사용하여 스키마를 확장하는 방법

이 절차의 일부로, DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오. 해당 절차의 다른 부분은 명령줄에서만 수행할 수 있습니다.

  1. 다음 방법 중 하나를 사용하여 스키마 확장을 준비합니다.

    • 98mySchema.ldif와 같은 사용자 고유의 스키마 정의 파일을 만듭니다.

    • 스키마 확장을 99user.ldif에 추가합니다.

    스키마 파일의 정의 구문은 RFC 4517에서 설명합니다.

  2. 스키마 정의 파일이 있는 마스터 서버에서 schema_push 명령을 실행합니다.

    이 스크립트는 실제로 스키마를 복제본으로 푸시하지는 않습니다. 대신 스크립트는 스키마 파일이 로드되는 즉시 복제되도록 특수 속성을 스키마 파일에 씁니다. 자세한 내용은 schema_push(1M) 설명서 페이지를 참조하십시오.

  3. 스키마 정의 파일이 있는 마스터 서버를 다시 시작합니다.

    스키마가 포함된 LDIF 파일에서 직접 변경한 사항은 복제 메커니즘에서 감지할 수 없으므로 그러나 schema_push를 실행한 후 서버를 다시 시작하면 서버에서 모든 스키마 파일이 로드된 후 복제 메커니즘이 새 스키마를 사용자에 복제합니다.

디렉토리 스키마 복제

두 서버 간에 하나 이상의 접미어 복제를 구성하면 스키마 정의도 자동으로 복제됩니다. 이렇게 해서 모든 복제본은 소비자로 복제될 수 있는 모든 객체 클래스 및 속성을 정의하는 동일한 스키마를 갖게 되며 마스터 서버에도 마스터 스키마가 있습니다.

그러나 스키마 복제는 LDAP를 통해 스키마를 수정할 때에도 즉시 수행되지 않습니다. 스키마 복제는 디렉토리 데이터에 대한 업데이트 시 또는 스키마가 수정된 후 첫 번째 복제 세션 시작 시에 실행됩니다.

모든 복제본에서 스키마를 실행하려면 반드시 모든 마스터에서 스키마 검사를 활성화해야 합니다. LDAP 작업이 수행되는 마스터에서 스키마를 검사하기 때문에 사용자를 업데이트할 때는 스키마를 검사할 필요가 없습니다. 성능을 향상시키기 위해 복제 메커니즘은 소비자 복제본에 대한 스키마 검사를 무시합니다.

주 –

허브 및 전용 사용자에서는 스키마 검사를 비활성화하지 마십시오. 스키마 검사는 사용자 성능에 영향을 주지 않으므로 복제본 내용이 스키마에 맞는지 나타내려면 스키마 검사를 계속 활성화 상태로 유지합니다.

마스터 서버는 사용자 초기화 중에, 그리고 DSCC 또는 명령줄 도구를 통해 스키마를 수정할 때에 자동으로 스키마를 해당 사용자에 복제합니다. 기본적으로 전체 스키마가 복제되며, 사용자에 없는 추가 스키마 요소는 사용자에 새로 만들어져 99user.ldif 파일에 저장됩니다.

예를 들어 마스터 서버를 시작할 때 해당 서버에 98mySchema.ldif 파일의 스키마 정의가 포함되고 이후 다른 서버(마스터, 허브 또는 전용 사용자)에 대한 복제 계약을 정의한다고 가정합니다. 나중에 이 마스터에서 복제본을 초기화하면 복제된 스키마에는 98mySchema.ldif의 정의가 포함되지만 이 정의는 복제본 서버의 99user.ldif에 저장됩니다.

스키마가 사용자 초기화 중에 복제된 경우 마스터의 cn=schema에 있는 스키마를 수정해도 전체 스키마가 사용자에 복제되므로 명령줄 유틸리티나 DSCC를 통한 마스터 스키마의 모든 수정 사항이 사용자에 복제됩니다. 이러한 수정 사항은 마스터의 99user.ldif에 저장되며, 또한 이전 설명과 동일한 메커니즘으로 사용자의 99user.ldif에도 저장됩니다.

복제된 환경에서 스키마의 일관성을 유지하려면 다음 지침을 수행합니다.

단편 복제를 구성할 때에는 다음 사항도 고려해야 합니다.

스키마 복제 제한

기본적으로 복제 메커니즘은 스키마를 복제할 때 항상 전체 스키마를 사용자에게 보냅니다. 다음 두 가지 상황과 같이 전체 스키마를 사용자에게 보내지 않아야 하는 경우도 있습니다.

주 –

디렉토리 서버는 11rfc2307.ldif 스키마 파일을 사용합니다. 이 스키마 파일은 RFC 2307을 준수합니다.

Directory Server 5.2 이전 버전에서는 10rfc2307.ldif 스키마 파일을 사용합니다.

Procedure스키마 복제를 제한하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. 사용자 정의 스키마만 복제되도록 스키마 복제를 제한합니다.


    $ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on

    기본값 off를 설정하면 필요한 경우 전체 스키마가 복제됩니다.