3.4. 스키마 사용자 정의

각 LDAP 오브젝트 클래스 또는 속성에 대해 고유 이름 및 OID(오브젝트 ID)를 할당해야 합니다. 스키마를 정의할 때 요소에는 조직에 고유한 기본 OID가 필요합니다. 다른 계층 구조를 추가하여 특성 및 개체 클래스에 대한 새 분기를 만듭니다. 스키마에서 OID를 가져오고 할당하려면 다음 단계를 수행해야 합니다.

다음과 같은 두 가지 방법으로 새 오브젝트 클래스를 생성할 수 있습니다.

두 가지 방법을 혼합할 수 있습니다. 예를 들어 예제 DateOfBirth ,example PreferredOS,exampleBuildingFloor 및 exampleVicePresident 속성을 생성하려고 합니다. 간단한 솔루션은 이러한 속성의 일부 하위 집합을 허용하는 여러 개체 클래스를 만드는 것입니다.

새 오브젝트 클래스는 다음과 같이 LDAPv3 스키마 형식으로 표시됩니다.

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

또는 이러한 모든 특성을 허용하는 단일 오브젝트 클래스를 만들고 이를 필요한 모든 항목과 함께 사용할 수 있습니다. 단일 오브젝트 클래스는 다음과 같습니다.

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )

새로운 exampleEntry 오브젝트 클래스는 A Cryostat ILIARY 로 표시됩니다. 즉, 구조적인 오브젝트 클래스에 관계없이 모든 항목에 사용할 수 있습니다.

조직 환경에 따라 새 오브젝트 클래스를 구성할 수 있습니다. 새 개체 클래스의 구현을 결정할 때는 다음을 고려하십시오.

애플리케이션 호환성과 장기 유지 관리 모두에 표준 특성을 사용해야 합니다. 기본 디렉터리 스키마에 이미 존재하는 특성을 검색하고 새 개체 클래스와 함께 사용하거나 Directory Server 스키마 가이드를 확인해야 합니다. 그러나 표준 스키마에 필요한 모든 정보가 포함되어 있지 않은 경우 새 특성과 새 개체 클래스를 추가합니다.

예를 들어 사람 항목에는 기본적으로 사람, organizationalPerson 또는 inetOrgPerson 개체 클래스보다 많은 속성이 필요할 수 있습니다. 생년월일을 저장하기 위한 표준 Directory Server 스키마 내에는 특성이 없습니다. 새 특성을 생성하고 설정할 수 있습니다. dateOfBirth 는 새 보조 개체 클래스 내에서 허용되는 속성인 examplePerson:

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')

Directory Server에 기본적으로 포함된 스키마 요소는 삭제할 수 없습니다. 사용되지 않는 스키마 요소는 운영 또는 관리 오버헤드를 나타내지 않습니다. 표준 LDAP 스키마의 일부를 삭제하면 나중에 Directory Server 및 기타 디렉터리 지원 애플리케이션의 호환성 문제가 발생할 수 있습니다.

그러나 사용되지 않는 사용자 지정 스키마 요소를 삭제할 수 있습니다. 스키마에서 오브젝트 클래스 정의를 제거하기 전에 오브젝트 클래스를 사용하여 각 항목을 수정합니다. 먼저 정의를 제거하면 오브젝트 클래스를 사용하는 항목이 나중에 수정되지 않을 수 있습니다. 알 수 없는 개체 클래스 값이 항목에서 제거되지 않으면 스키마가 수정된 항목도 실패합니다.

Directory Server에 대한 사용자 지정 스키마 파일을 생성하여 Directory Server와 함께 제공된 99user.ldif 파일 외에도 사용할 수 있습니다. 이러한 스키마 파일에는 조직과 관련된 새로운 사용자 지정 속성 및 개체 클래스가 있습니다. 새 스키마 파일은 스키마 디렉터리 /etc/dirsrv/slapd-instance_name/schema/ 에 있습니다. 모든 표준 특성 및 개체 클래스는 사용자 지정 스키마 요소가 로드된 후에만 로드됩니다.

사용자 지정 스키마 파일을 만든 후 다음과 같은 방식으로 모든 서버에 스키마 변경 사항을 배포할 수 있습니다.

이러한 사용자 지정 스키마 파일을 모든 서버에 복사하지 않으면 공급자 서버의 스키마를 변경하는 경우에만 스키마 정보가 소비자 서버에 복제됩니다. 스키마 정의가 아직 없는 소비자 서버에 복제되면 99user.ldif 파일에 저장됩니다.

다음 제안 사항은 호환 가능하고 관리하기 쉬운 사용자 정의 스키마를 정의하는 데 도움이 됩니다.

사용자 지정 스키마 파일 이름을 지정할 때 다음 이름 지정 형식을 사용합니다 .yourName.ldif.

사용자 지정 스키마 요소가 수동으로 99user.ldif 에 직접 추가되는 경우 X-ORIGIN 값으로 'user defined'를 사용합니다. 다른 X-ORIGIN 값이 설정된 경우 서버는 간단히 이를 덮어쓸 수 있습니다.

'사용자 정의' 값의 X-ORIGIN 을 사용하면 Directory Server에서 99user.ldif 파일에서 스키마 정의를 제거할 수 없습니다.

예를 들면 다음과 같습니다.

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')

Directory Server가 스키마 항목을 로드하면 다음과 같이 표시됩니다.

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )