사용자 정의 스키마 정보

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

• 가능한 경우 기존 스키마 요소를 다시 사용합니다.

• 각 객체 클래스에 정의하는 필수 속성 수를 최소화합니다.

• 객체 클래스 또는 속성을 동일한 용도로 두 개 이상 정의하지 않습니다.

• 스키마를 최대한 단순하게 유지합니다.

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

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

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

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

기본 디렉토리 서버 스키마

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

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

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

객체 식별자

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

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

• IANA(Internet Assigned Numbers Authority) 또는 정부 기관에서 사용자 조직에 필요한 OID를 얻습니다.

  일부 국가의 경우 OID를 이미 할당받은 기관도 있습니다. 사용자 조직에 아직 OID가 없는 경우 IANA에서 OID를 얻을 수 있습니다.

• OID 할당을 추적할 수 있도록 OID 레지스트리를 만듭니다.

  OID 레지스트리는 사용자가 유지관리하는 목록으로서 디렉토리 스키마에 사용되는 OID 및 OID 설명을 제공합니다. OID 레지스트리는 OID가 두 가지 이상의 용도로 사용되지 않도록 합니다.

• OID 트리에 스키마 요소를 수용하기 위한 분기를 만듭니다.

  속성의 경우 OID.1을, 객체 클래스의 경우 OID.2를 사용하여 OID 분기 또는 디렉토리 스키마 아래에 둘 이상의 분기를 만듭니다. 사용자 고유의 일치 규칙 또는 컨트롤을 정의하려면 필요에 따라 OID.3과 같은 새 분기를 추가할 수 있습니다.

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

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

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

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

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

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

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

• 속성을 추가할 각 객체 클래스 구조를 위한 객체 클래스를 포함하여 새 객체 클래스를 여러 개 만듭니다.

• 디렉토리에 대해 만든 모든 속성을 지원하는 단일 객체 클래스를 만듭니다. 이러한 종류의 객체 클래스를 만들려면 해당 클래스를 AUXILIARY 객체 클래스로 정의합니다.

  사용자 사이트에서 ExampleDepartmentNumber 및 ExampleEmergencyPhoneNumber 속성을 만든다고 가정합니다. 이 속성의 일부 하위 집합을 허용하는 객체 클래스를 여러 개 만들 수 있습니다. ExamplePerson이라는 객체 클래스를 만들고 이 클래스가 ExampleDepartmentNumber 및 ExampleEmergencyPhoneNumber 속성을 허용하도록 설정할 수 있습니다. ExamplePerson의 부모는 inetOrgPerson이 됩니다. 그런 다음 ExampleOrganization이라는 객체 클래스를 만들고 이 클래스도 ExampleDepartmentNumber 및 ExampleEmergencyPhoneNumber 속성을 허용하도록 설정할 수 있습니다. ExampleOrganization의 부모는 organization 객체 클래스가 됩니다.

  새 객체 클래스는 다음과 같이 LDAP v3 스키마 형식으로 표시됩니다.

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson'
   DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME
   'ExampleOrganization' DESC 'Example Organization Object Class' SUP
   organization STRUCTURAL MAY (ExampleDepartmentNumber
   $ ExampleEmergencyPhoneNumber) )

  또는 이러한 속성을 모두 허용하는 단일 객체 클래스를 만들 수도 있습니다. 그리고 나면 이 객체 클래스는 속성을 사용할 모든 항목에 사용할 수 있습니다. 단일 객체 클래스는 다음과 같이 표시됩니다.

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry'
   DESC  'Example Auxiliary Object Class' SUP top  AUXILIARY MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )

  새 ExampleEntry 객체 클래스는 AUXILIARY로 표시되며, 이는 구조적 객체 클래스와는 상관없이 모든 항목에 사용할 수 있다는 것을 의미합니다.

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

• STRUCTURAL 객체 클래스가 여러 개 있으면 스키마 요소를 더 많이 만들고 유지관리해야 할 수 있습니다.

  일반적으로 요소 수를 줄이면 유지관리가 줄어듭니다. 스키마에 세 개 또는 네 개 이상의 객체 클래스를 추가하려는 경우에는 단일 객체 클래스를 사용하는 것이 더 쉽습니다.

• 여러 개의 STRUCTURAL 객체 클래스는 보다 세심하고 견고한 데이터 설계가 필요합니다.

  견고한 데이터 설계를 위해 사용자는 모든 데이터 조각이 있는 객체 클래스 구조를 고려하게 됩니다. 이러한 제한은 유용할 수 있지만 번거로울 수도 있습니다.

• 단일 AUXILIARY 객체 클래스는 둘 이상의 객체 클래스 구조 유형에 데이터를 넣으려 할 경우 데이터 설계를 단순화합니다.

  예를 들어 개인 및 그룹 항목 모두에 preferredOS가 필요하다고 가정합니다. 이 속성을 허용하도록 한 개의 객체 클래스만 만들 수 있습니다.

• 실제 그룹화를 구성하는 그룹 요소 및 실제 객체와 관련된 객체 클래스를 설계합니다.

• 새 객체 클래스의 속성이 요청되지 않도록 합니다.

  속성이 요청되면 스키마의 유연성이 감소될 수 있습니다. 새 객체 클래스를 만들 때 속성을 요청하지 않고 허용하도록 합니다.

  새 객체 클래스를 정의한 후에는 객체 클래스가 어떤 속성을 허용하고 요청하는지와 어떤 객체 클래스에서 상속받는지를 결정해야 합니다.

새 속성을 정의하는 경우

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

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

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

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

• 새 스키마 요소를 추가할 때 모든 속성을 객체 클래스에 사용하려면 먼저 해당 속성을 정의해야 합니다. 동일한 스키마 파일에서 속성과 객체 클래스를 정의할 수 있습니다.

• 사용자가 만들 각 사용자 정의 속성 또는 객체 클래스는 한 스키마 파일에서만 정의해야 합니다. 이렇게 하면 서버에서 가장 최근에 만들어진 스키마를 로드할 때 이전 정의를 무시하지 않습니다. 디렉토리 서버는 먼저 숫자순으로 스키마 파일을 로드하고 그 다음 알파벳순으로 파일을 로드합니다.

• 새 스키마 정의를 수동으로 정의할 때에는 일반적으로 이러한 정의를 99user.ldif 파일에 추가하는 것이 좋습니다.

  LDAP를 사용하여 스키마 요소를 업데이트하는 경우 새 요소가 99user.ldif 파일에 자동으로 쓰여집니다. 따라서, 사용자 정의 스키마 파일에서 변경한 다른 스키마 정의 내용을 덮어쓸 수 있습니다. 99user.ldif 파일만 사용하면 스키마 요소의 중복 가능성과 스키마 변경 내용을 덮어쓸 수 있는 위험성이 방지됩니다.

• 디렉토리 서버가 먼저 숫자순으로 스키마 파일을 로드하고 그 다음 알파벳순으로 파일을 로드하므로 사용자 정의 스키마 파일의 이름을 다음과 같이 지정해야 합니다.

  [00-99] filename.ldif

  이 숫자는 이미 정의된 디렉토리 표준 스키마보다 큽니다.

  사용자 정의 스키마 파일의 이름이 표준 스키마 파일보다 작은 숫자로 지정되면 스키마를 로드할 때 서버에서 오류가 발생할 수 있으며 또한, 모든 표준 속성과 객체 클래스는 사용자 정의 스키마 요소가 로드된 후에 로드됩니다.

• 디렉토리 서버는 내부 스키마 관리에 우선 순위가 가장 높은 파일을 사용하기 때문에 사용자 정의 스키마 파일의 이름은 99user.ldif보다 숫자순으로나 알파벳순으로 우선 순위가 더 높아서는 안 됩니다.

  예를 들어 스키마 파일을 만들고 이름을 99zzz.ldif로 지정한 경우 다음에 스키마를 업데이트하면 X-ORIGIN 값이 'user defined'인 모든 속성이 99zzz.ldif에 쓰여집니다. 결과적으로 두 개의 LDIF 파일에 중복된 정보가 포함되며, 99zzz.ldif 파일의 일부 정보가 지워질 수도 있습니다.

• 일반적으로 추가하는 사용자 정의 스키마 요소는 다음 두 가지 항목으로 식별합니다.

  • 사용자 정의 스키마 파일에서 X-ORIGIN 필드의 'user defined'

  • 다른 관리자가 사용자 정의 스키마 요소를 쉽게 이해할 수 있도록 잘 설명된 X-ORIGIN 필드의 'Example.com Corporation defined'와 같은 레이블(예: X-ORIGIN ('user defined' 'Example.com Corporation defined'))

    스키마 요소를 수동으로 추가하는 경우 X-ORIGIN 필드에 'user defined'를 사용하지 않으면 스키마 요소가 DSCC에서 읽기 전용으로 표시됩니다.

    LDAP 또는 DSCC를 사용하여 사용자 정의 스키마 정의를 추가하면 'user defined' 값이 서버에서 자동으로 추가됩니다. 그러나, X-ORIGIN 필드에 의미가 잘 설명된 값을 추가하지 않으면 나중에 스키마와 관련된 내용을 이해하기 어려울 수 있습니다.

  이러한 변경 사항은 자동으로 복제되지 않기 때문에 사용자 정의 스키마 파일을 모든 서버로 수동으로 전달합니다.

  디렉토리 스키마를 변경할 때 서버는 스키마가 변경되었을 때의 타임스탬프를 유지합니다. 각 복제 세션 시작 시에 서버는 자신의 타임스탬프와 사용자의 타임스탬프를 비교하여, 필요한 경우 스키마 변경 사항을 푸시합니다. 서버는 사용자 정의 스키마 파일에 대해 99user.ldif 파일과 연관된 타임스탬프를 한 개만 유지관리합니다. 즉, 99user.ldif 이외의 사용자 정의 스키마 파일에 대한 변경 사항 또는 추가 사항은 복제되지 않습니다. 따라서 모든 스키마 정보를 전체 토폴로지에 제공하려면 사용자 정의 스키마 파일을 다른 모든 서버에 전달해야 합니다.