3.4. 스키마 사용자 지정
디렉터리에 너무 제한적인 경우 표준 스키마를 확장할 수 있습니다. Directory Server의 웹 콘솔을 사용하여 특성 및 개체 클래스를 쉽게 추가하여 스키마를 확장할 수 있습니다. LDIF 파일을 생성하고 스키마 요소를 수동으로 추가할 수도 있습니다. 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.
Directory Server 스키마를 사용자 정의할 때 다음 규칙을 고려하십시오.
- 스키마를 최대한 간단하게 유지합니다.
- 가능한 경우 기존 스키마 요소를 재사용합니다.
- 각 오브젝트 클래스에 정의된 필수 특성 수를 최소화합니다.
- 동일한 목적(데이터)에 대해 둘 이상의 오브젝트 클래스 또는 속성을 정의하지 마십시오.
- 특성 또는 개체 클래스의 기존 정의를 수정하지 마십시오.
참고
스키마를 사용자 정의할 때 표준 스키마를 삭제하거나 교체 하지 마십시오. 이렇게 하면 다른 디렉터리 또는 기타 LDAP 클라이언트 애플리케이션과의 호환성 문제가 발생할 수 있습니다.
사용자 지정 오브젝트 클래스 및 속성은
99user.ldif 파일에 정의됩니다. 각 개별 인스턴스는 /etc/dirsrv/slapd-instance_name/schema/ 디렉터리에 자체 99user.ldif 파일을 유지 관리합니다. 사용자 지정 스키마 파일을 만들고 스키마를 서버에 동적으로 다시 로드할 수도 있습니다.
3.4.1. 스키마를 확장해야 하는 경우
Directory Server와 함께 제공되는 개체 클래스와 특성은 가장 일반적인 기업 요구 사항을 충족해야 하지만 지정된 개체 클래스는 조직에 대한 특수 정보를 저장하지 않을 수 있습니다. 또한 LDAP 지원 애플리케이션의 고유 데이터 요구에 필요한 오브젝트 클래스 및 특성을 지원하려면 스키마를 확장해야 할 수 있습니다.
3.4.2. 오브젝트 식별자 가져오기 및 할당
각 LDAP 개체 클래스 또는 속성에 고유 이름 및 개체 식별자 (OID)가 할당되어야 합니다. 스키마가 정의되면 요소에는 조직에 고유한 기본 OID가 필요합니다. 하나의 OID는 모든 스키마 요구 사항을 충족하기에 충분합니다. 단순히 특성 및 개체 클래스에 대한 새 분기를 생성하려면 다른 계층 수준을 추가하기만 하면 됩니다. 스키마에서 OID를 가져오고 할당하려면 다음 단계를 수행해야 합니다.
- INA(Internet Assigned Numbers Authority) 또는 국가 조직에서 OID를 받습니다.일부 국가에는 이미 OID가 할당되어 있습니다. 조직에 OID가 아직 없는 경우 IANA에서 가져올 수 있습니다. 자세한 내용은 다음에서 IANA 웹 사이트로 http://www.iana.org/cgi-bin/enterprise.pl 이동하십시오.
- OID 레지스트리를 생성하여 OID 할당을 추적합니다.OID 레지스트리는 OID 목록 및 디렉터리 스키마에 사용되는 OID에 대한 설명입니다. 이렇게 하면 OID가 두 개 이상의 용도로 사용되지 않습니다. 그런 다음 OID 레지스트리를 스키마와 함께 게시합니다.
- OID 트리에 분기를 생성하여 스키마 요소를 수용합니다.OID 분기 또는 디렉터리 스키마 아래에 두 개 이상의 분기를 생성합니다. 속성의 경우 OID.1 을 사용하고 개체 클래스의 경우 OID.2 를 사용합니다. 사용자 정의 일치 규칙 또는 제어를 정의하려면 필요에 따라 새 분기를 추가합니다(예:OID.3).
3.4.3. 속성 및 오브젝트 클래스 이름 지정
새 특성 및 개체 클래스에 대한 이름을 생성할 때 이름을 가능한 한 의미 있게 만듭니다. 이렇게 하면 Directory Server 관리자가 스키마를 더 쉽게 사용할 수 있습니다.
모든 스키마 요소에 고유한 접두사를 포함하여 스키마 요소와 기존 스키마 요소 간에 충돌하지 않도록 합니다.Avoid naming collisions between schema elements and existing schema elements by including a unique prefix on all schema elements. 예를 들어 Example Corp.은 각 사용자 지정 스키마 요소 앞에 접두사 예제 를 추가할 수 있습니다. 디렉터리에 Example Corp. employees를 식별하기 위해 examplePerson 이라는 특수 오브젝트 클래스를 추가할 수 있습니다.
3.4.4. 새 오브젝트 클래스를 정의하는 전략
새 개체 클래스를 생성하는 방법은 다음 두 가지가 있습니다.
- 특성을 추가할 각 개체 클래스 구조에 대해 하나씩 많은 새 개체 클래스를 만듭니다.
- 디렉터리에 대해 생성된 모든 사용자 지정 특성을 지원하는 단일 오브젝트 클래스를 만듭니다. 이러한 종류의 오브젝트 클래스는 보조 오브젝트 클래스로 정의하여 생성됩니다.
두 가지 방법을 혼합하는 것이 가장 쉽습니다.
예를 들어, 관리자가 예제
DateOfBirth ,example PreferredOS,exampleBuildingFloor, exampleVicePresident 속성을 생성하려고 한다고 가정해 보겠습니다. 간단한 솔루션은 이러한 속성의 일부 하위 집합을 허용하는 여러 개체 클래스를 만드는 것입니다.
- 하나의 오브젝트 클래스 examplePerson 이 생성되고
exampleDateOfBirth및examplePreferredOS를 허용합니다. examplePerson 의 상위는 inetOrgPerson 입니다. - 두 번째 오브젝트 클래스 exampleOrganization 에서는
exampleBuildingFloor및exampleVicePresident를 허용합니다. exampleOrganization 의 상위는 조직 오브젝트 클래스입니다.
새 오브젝트 클래스는 다음과 같이 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 로 표시됩니다. 즉, 구조적인 오브젝트 클래스에 관계없이 모든 항목에 사용할 수 있습니다.
참고
예제의 새 오브젝트 클래스의 OID(2.16.840.1.117370)는 이전 Netscape OID 접두사를 기반으로 합니다. 사용자 정의 오브젝트 클래스를 생성하려면 3.4.2절. “오브젝트 식별자 가져오기 및 할당” 에 설명된 대로 OID를 가져옵니다.
조직 환경에 따라 새 오브젝트 클래스를 구성하는 방법에는 여러 가지가 있습니다. 새 개체 클래스를 구현하는 방법을 결정할 때는 다음을 고려하십시오.
- 여러 오브젝트 클래스를 사용하면 더 많은 스키마 요소를 생성하고 유지 관리할 수 있습니다.일반적으로 요소 수는 작게 남아 있으며 유지 관리가 거의 필요하지 않습니다. 그러나 스키마에 두 개 이상의 개체 클래스가 추가되는 경우 단일 오브젝트 클래스를 사용하는 것이 더 쉬워질 수 있습니다.
- 여러 오브젝트 클래스에는 보다 주의하고 안전한 데이터 설계가 필요합니다.데이터 설계는 모든 데이터가 배치되는 객체 클래스 구조에 중점을 두고 있으며, 이는 도움이되거나 번거로울 수 있습니다.
- 단일 오브젝트 클래스는 사람 및 자산 항목과 같이 둘 이상의 오브젝트 클래스에 적용할 수 있는 데이터가 있을 때 데이터 설계를 단순화합니다.예를 들어 사용자 지정
preferredOS속성은 사용자와 그룹 항목 모두에 설정할 수 있습니다. 단일 오브젝트 클래스는 두 유형의 항목에 대해 이 속성을 허용할 수 있습니다. - 새 개체 클래스에 대한 필수 특성을 방지합니다.새 개체 클래스의 속성을
허용하는대신require를 지정하면 스키마를 유연하게 만들 수 있습니다. 새 개체 클래스를 만들 때 가능한 한 많이필요하지않고allow을 사용합니다.새 오브젝트 클래스를 정의한 후 허용하는 특성과 필요한 속성과 특성을 상속하는 오브젝트 클래스를 결정합니다.
3.4.5. 새 특성을 정의하는 전략
애플리케이션 호환성과 장기 유지 관리 모두 가능한 경우 표준 특성을 사용하십시오. 기본 디렉터리 스키마에 이미 존재하는 특성을 검색하고 새 개체 클래스와 연결하여 사용하거나 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')
고려해야 할 한 가지 중요한 사항: 표준 스키마 요소에 사용자 지정 속성을 추가하거나 삭제하지 마십시오. 디렉터리에 사용자 지정 특성이 필요한 경우 사용자 지정 개체 클래스를 추가하여 포함합니다.
3.4.6. 스키마 삭제
Directory Server에 기본적으로 포함된 스키마 요소를 삭제하지 마십시오. 사용되지 않는 스키마 요소는 운영 또는 관리 오버헤드를 나타내지 않습니다. 표준 LDAP 스키마의 일부를 삭제하면 나중에 Directory Server 및 기타 디렉터리 사용 애플리케이션의 호환성 문제가 발생할 수 있습니다.
그러나 사용되지 않는 사용자 지정 스키마 요소는 삭제할 수 있습니다. 스키마에서 오브젝트 클래스 정의를 제거하기 전에 오브젝트 클래스를 사용하여 각 항목을 수정합니다. 먼저 정의를 제거하면 오브젝트 클래스를 사용하는 항목이 나중에 수정되지 않을 수 있습니다. 알 수 없는 개체 클래스 값이 항목에서 제거되지 않는 한 스키마가 수정된 항목도 실패합니다.
3.4.7. 사용자 지정 스키마 파일 생성
관리자는 Directory Server와 함께 제공되는
99user.ldif 파일 외에도 사용할 Directory Server에 대한 사용자 지정 스키마 파일을 만들 수 있습니다. 이러한 스키마 파일에는 조직과 관련된 새로운 사용자 지정 속성 및 개체 클래스가 있습니다. 새 스키마 파일은 스키마 디렉터리 /etc/dirsrv/slapd-instance_name/schema/ 에 있어야 합니다.
모든 표준 특성 및 개체 클래스는 사용자 지정 스키마 요소가 로드된 후에만 로드됩니다.
참고
사용자 지정 스키마 파일은
99user.ldif 보다 숫자 또는 알파벳 순으로해서는 안 됩니다. 그렇지 않으면 서버에 문제가 발생할 수 있습니다.
사용자 지정 스키마 파일을 만든 후에는 모든 서버에 스키마 변경 사항을 분산하는 두 가지 방법이 있습니다.
- 이러한 사용자 지정 스키마 파일을 인스턴스의 스키마 디렉터리
/etc/dirsrv/slapd-인스턴스/schema에 수동으로 복사합니다. 스키마를 로드하려면 schema-reload.pl 스크립트를 실행하여 서버를 다시 시작하거나 스키마를 동적으로 다시 로드합니다. - 웹 콘솔 또는 ldapmodify 와 같은 LDAP 클라이언트를 사용하여 서버의 스키마를 수정합니다.
- 서버가 복제되면 복제 프로세스에서 각 소비자 서버에 스키마 정보를 복사할 수 있습니다.복제를 사용하면 복제된 모든 스키마 요소가 소비자 서버의
99user.ldif파일에 복사됩니다.90example_schema.ldif와 같은 사용자 지정 스키마 파일에 스키마를 유지하려면 파일을 소비자 서버로 수동으로 복사해야 합니다. 복제는 스키마 파일을 복사하지 않습니다.
이러한 사용자 지정 스키마 파일이 모든 서버에 복사되지 않은 경우 스키마 정보는 웹 콘솔 또는 ldapmodify 와 같은 LDAP 클라이언트를 사용하여 공급자 서버의 스키마를 변경한 경우에만 복제본(소유 서버)에 복제됩니다.
스키마 정의가 아직 없는 소비자 서버에 복제되면
99user.ldif 파일에 저장됩니다. 디렉터리는 스키마 정의가 저장되는 위치를 추적하지 않습니다. 소비자의 99user.ldif 파일에 스키마 요소를 저장해도 공급자 서버에서 스키마가 유지 관리되는 한 문제가 발생하지 않습니다.
사용자 지정 스키마 파일이 각 서버에 복사되는 경우 스키마 파일을 다시 각 서버에 복사해야 합니다. 파일을 다시 복사하지 않으면 변경 사항을 복제하여 소비자의
99user.ldif 파일에 저장할 수 있습니다. 99user.ldif 파일을 변경하면 스키마 관리가 어려울 수 있습니다. 일부 속성은 공급자에서 복사한 원래 사용자 지정 스키마 파일에 한 번 복제 후 99user.ldif 파일에 다시 나타납니다.
복제 스키마에 대한 자세한 내용은 7.4.4절. “스키마 복제” 을 참조하십시오.
3.4.8. 사용자 정의 스키마 모범 사례
스키마 파일을 사용할 때는 호환 가능하고 관리하기 쉬운 스키마를 만들어야 합니다.
3.4.8.1. 스키마 파일 이름 지정
사용자 정의 스키마 파일 이름을 지정할 때 다음 이름 지정 형식을 사용합니다.
[00-99]yourName.ldif
99user.ldif 보다 사용자 지정 스키마 파일의 이름을 더 낮게 (numerically 및 alphabetically)로 지정합니다. 그러면 Directory Server가 LDAP 툴과 웹 콘솔을 통해 99user.ldif 에 쓸 수 있습니다.
99user.ldif 파일에는 'user defined' 의 X-ORIGIN 값이 있는 속성이 포함되어 있지만 디렉터리 서버는 모든 'user defined' 스키마 요소를 가장 높은 이름이 지정된 파일에 기록한 다음 알파벳순으로 작성합니다. 99z.ldif 라는 스키마 파일이 있는 경우 다음에 스키마가 업데이트되고(LDAP 명령줄 도구 또는 웹 콘솔을 통해) 'user defined' 값이 있는 모든 속성이 99zzz.ldif 에 기록됩니다. 그 결과 중복 정보가 포함된 두 개의 LDIF 파일이 있으며 99zzz.ldif 파일의 일부 정보는 삭제될 수 있습니다.
3.4.8.2. 원본으로 'user defined' 사용
LDAP를 통해 스키마를 추가할 때 'user defined'
가디렉터리 서버에서 내부적으로 사용되므로 사용자 지정 스키마 파일의 X-ORIGIN 필드에 'user defined' 를 사용하지 마십시오. 사용자 지정 스키마 파일에서 'Example Corp. defined' 와 같은 설명이 포함된 항목을 사용하십시오.
그러나 사용자 지정 스키마 요소가
99user.ldif 에 직접 추가되는 경우 'user defined' 를 X-ORIGIN 값으로 사용합니다. 다른 X-ORIGIN 값이 설정된 경우 서버는 간단히 덮어쓸 수 있습니다.
'user defined' 값의 X-ORIGIN 을 사용하면
99user.ldif 파일의 스키마 정의가 Directory Server에서 파일에서 제거되지 않습니다. 디렉터리 서버는 'user defined' 값 'user'의 X-ORIGIN 을 사용하여 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') )3.4.8.3. 오브젝트 클래스 이전의 속성 정의
새 스키마 요소를 추가할 때 모든 특성을 오브젝트 클래스에서 사용하려면 먼저 정의해야 합니다. 특성 및 개체 클래스는 동일한 스키마 파일에 정의할 수 있습니다.
3.4.8.4. 단일 파일에서 스키마 정의
각 사용자 지정 특성 또는 오브젝트 클래스는 하나의 스키마 파일에만 정의해야 합니다. 이렇게 하면 서버가 가장 최근에 생성된 스키마를 로드할 때 이전 정의를 덮어쓰지 않습니다(서버가 먼저 스키마를 로드한 다음 알파벳순으로 표시됨). 중복 파일에 스키마를 사용하지 않도록 하는 방법을 결정합니다.
- 각 스키마 파일에 포함된 스키마 요소에 주의하십시오.
- 스키마 파일의 이름 지정 및 업데이트할 때는 주의하십시오. LDAP 툴을 통해 스키마 요소를 편집하면 변경 사항이 마지막 파일(alphabetically)에 자동으로 작성됩니다. 대부분의 스키마가 변경되면 기본 파일
99user.ldif에 쓰이고 사용자 지정 스키마 파일(예:60example.ldif)에 씁니다. 또한99user.ldif의 스키마 요소는 다른 스키마 파일에서 중복 요소를 재정의합니다. 99user.ldif파일에 모든 스키마 정의를 추가합니다. 이 기능은 웹 콘솔을 통해 스키마를 관리하는 경우 유용합니다.
