디렉토리 서버는 수백 개의 객체 클래스 및 속성이 포함된 표준 스키마와 함께 제공됩니다. 표준 객체 클래스 및 속성만으로도 대부분의 요구 사항을 충족시킬 수 있지만, 새로운 객체 클래스 및 속성을 만들어 스키마를 확장해야 하는 경우도 있습니다. 표준 스키마에 대한 개요와 배포에 적합한 스키마 설계에 대한 지침은 Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide를 참조하십시오.
이 장은 스키마 관리 방법에 대해 설명하며 다음 내용으로 구성되어 있습니다.
스키마 검사가 활성화되어 있으면 디렉토리 서버에서 모든 가져오기, 추가 및 수정 작업이 현재 정의된 디렉토리 스키마에 맞는지 확인합니다.
각 항목의 객체 클래스와 속성이 스키마에 맞는지 여부
정의된 모든 객체 클래스에 필요한 속성이 항목에 모두 포함되어 있는지 여부
객체 클래스에서 허용하는 속성만 항목에 포함되어 있는지 여부
항목을 수정하면 디렉토리 서버는 수정되는 속성만이 아닌 전체 항목에 대해 스키마 검사를 수행합니다. 따라서 항목의 객체 클래스 또는 속성이 스키마에 맞지 않으면 작업이 실패할 수 있습니다.
그러나 스키마 검사는 구문과 관련하여 속성 값의 유효성을 확인하지는 않습니다.
스키마 검사는 기본적으로 활성화되며 일반적으로 스키마 검사를 활성화한 상태에서 디렉토리 서버를 실행합니다. 대부분의 클라이언트 응용 프로그램은 스키마 검사를 활성화하면 모든 항목이 스키마에 맞을 것이라고 가정합니다. 그러나 스키마 검사를 활성화해도 디렉토리 서버에서 디렉토리의 기존 내용은 확인되지 않습니다. 모든 디렉토리 내용이 스키마에 맞도록 하려면 항목을 추가하거나 모든 항목을 다시 초기화하기 전에 스키마 검사를 활성화해야 합니다.
스키마에 맞는 LDAP 파일의 가져오기 작업 속도를 향상시키기 위해 예외적으로 스키마 검사를 비활성화할 수도 있습니다. 그러나 스키마 검사가 비활성화되면 스키마에 맞지 않는 항목을 가져올 위험이 있으며 가져온 항목이 스키마에 맞지 않으면 감지되지 않습니다.
복제된 환경에서 스키마 검사를 사용하는 방법에 대한 자세한 내용은 디렉토리 스키마 복제를 참조하십시오.
항목이 스키마에 맞지 않으면 해당 항목을 검색하지 못할 수 있으며 이 항목에 대한 수정 작업이 실패할 수 있습니다. 이 문제를 해결하려면 이 절차의 단계를 수행합니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
스키마 호환 문제를 발생시키지 않으려면 배포 전에 스키마를 계획하여 스키마 변경을 최소화합니다. 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide를 참조하십시오.
항목이 스키마에 맞지 않는 이유를 확인하려면 항목을 검색한 다음 현재 정의된 스키마와 수동으로 비교합니다.
자세한 내용은 속성 유형을 보려면 및 객체 클래스를 보려면을 참조하십시오.
스키마와 맞도록 항목을 수정하거나 항목과 맞도록 스키마를 수정합니다.
표준 스키마가 디렉토리 요구 사항에 대해 너무 제한되어 있는 경우 이를 확장할 수 있습니다. 스키마를 사용자 정의하는 경우 다음 지침을 수행합니다.
가능한 경우 기존 스키마 요소를 다시 사용합니다.
각 객체 클래스에 정의하는 필수 속성 수를 최소화합니다.
객체 클래스 또는 속성을 동일한 용도로 두 개 이상 정의하지 않습니다.
스키마를 최대한 단순하게 유지합니다.
스키마를 사용자 정의할 때 표준 스키마에서 속성 또는 객체 클래스의 기존 정의를 수정, 삭제 또는 대체하지 마십시오. 이렇게 하면 다른 디렉토리 및 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 이외의 사용자 정의 스키마 파일에 대한 변경 사항 또는 추가 사항은 복제되지 않습니다. 따라서 모든 스키마 정보를 전체 토폴로지에 제공하려면 사용자 정의 스키마 파일을 다른 모든 서버에 전달해야 합니다.
이 절에서는 LDAP를 통해 속성 유형을 만들고 보고 삭제하는 방법에 대해 설명합니다.
cn=schema 항목에는 디렉토리 스키마에 각 속성 유형의 정의가 포함된, 여러 값을 갖는 속성 attributeTypes가 있습니다. ldapmodify(1) 명령을 사용하면 이러한 정의에 다른 내용을 추가할 수 있습니다.
새 속성 유형 정의 및 사용자 정의 속성 유형에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.
새 속성 유형을 정의하려면 각 속성 유형 정의에 반드시 OID를 입력해야 합니다. 또한 새 속성 유형에 반드시 다음 요소를 사용해야 합니다.
속성 OID. 속성의 객체 식별자에 해당합니다. OID는 스키마 객체를 고유하게 식별하는 문자열이며 대체로 점으로 구분된 10진수로 구성됩니다.
LDAP v3를 엄격히 준수하려면 유효한 숫자 OID를 입력해야 합니다. OID에 대한 자세한 내용을 보거나 사용자 회사에 대한 접두어를 요청하려면 IANA(Internet Assigned Number Authority)로 전자 메일(iana@iana.org)을 보내거나 IANA 웹 사이트를 참조하십시오.
속성 이름. 속성의 고유 이름에 해당하며 속성 유형이라고도 합니다. 속성 이름은 문자로 시작해야 하며 ASCII 문자, 숫자 및 하이픈만 사용할 수 있습니다.
속성 이름에는 대문자를 사용할 수 있지만, LDAP 클라이언트가 속성을 구별할 목적이라면 대소문자를 사용해서는 안 됩니다. 속성 이름은 RFC 4512의 섹션 2.5에 따라 대소문자를 구분하지 않고 처리해야 합니다.
별칭으로도 참조되는 대체 속성 이름을 속성 유형에 포함시킬 수도 있습니다.
속성 설명. 속성의 용도를 설명하는 짧은 설명 텍스트입니다.
구문. OID에서 참조되며 속성에 포함할 데이터를 설명합니다.
OID에 따른 속성 구문은 RFC 4517에 나열되어 있습니다.
허용되는 값 수. 기본적으로 속성은 여러 값을 갖지만 속성이 단일 값을 갖도록 제한할 수 있습니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
RFC 4517에 지정된 구문에 따라 속성 유형 정의를 준비합니다.
ldapmodify(1) 명령을 사용하여 속성 유형 정의를 추가합니다.
디렉토리 서버에서는 사용자가 입력한 정의에 X-ORIGIN 'user defined'를 추가합니다.
다음 예에서는 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) 명령을 사용하면 이러한 정의를 읽을 수 있습니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
ldapsearch 명령을 사용하여 현재 디렉토리 스키마에 있는 모든 속성 유형 정의를 봅니다.
다음 명령을 실행하면 모든 속성 유형 정의가 표시됩니다.
$ 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 파일에 저장됩니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
삭제할 속성 유형 정의를 봅니다.
자세한 내용은 속성 유형을 보려면을 참조하십시오.
ldapmodify(1) 명령을 사용하여 스키마에 표시된 대로 속성 유형 정의를 삭제합니다.
다음 명령을 실행하면 예 11–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를 통해 객체 클래스를 만들고 보고 삭제하는 방법에 대해 설명합니다.
cn=schema 항목에는 디렉토리 스키마에서 각 객체 클래스의 정의가 포함된, 여러 값을 갖는 속성 objectClasses가 있습니다. ldapmodify(1) 명령을 사용하면 이러한 정의에 다른 내용을 추가할 수 있습니다.
새 객체 클래스 정의 및 사용자 정의 객체 클래스에 대한 변경 사항은 99user.ldif 파일에 저장됩니다.
다른 객체 클래스에서 상속 받는 객체 클래스를 여러 개 만드는 경우에는 먼저 부모 객체 클래스를 만들어야 합니다. 새 객체 클래스에 사용자 정의 속성이 사용되면 이러한 속성도 먼저 정의해야 합니다.
각 객체 클래스 정의에 반드시 OID를 입력해야 합니다. 또한 새 객체 클래스에 반드시 다음 요소를 사용해야 합니다.
객체 클래스 OID. 객체 클래스의 객체 식별자에 해당합니다. OID는 스키마 객체를 고유하게 식별하는 문자열이며 대체로 점으로 구분된 10진수로 구성됩니다.
LDAP v3를 엄격히 준수하려면 유효한 숫자 OID를 입력해야 합니다. OID에 대한 자세한 내용을 보거나 사용자 회사에 대한 접두어를 요청하려면 IANA(Internet Assigned Number Authority)로 전자 메일(iana@iana.org)을 보내거나 IANA 웹 사이트를 참조하십시오.
객체 클래스 이름. 객체 클래스의 고유 이름에 해당합니다.
부모 객체 클래스. 이 객체 클래스가 속성을 상속 받을 기존 객체 클래스입니다.
이 객체 클래스가 다른 특정 객체 클래스에서 상속 받지 않게 하려면 top을 사용합니다.
일반적으로 사용자 항목에 새 속성을 추가하려는 경우에는 inetOrgPerson 객체 클래스가 부모입니다. 기업 항목에 새 속성을 추가하려는 경우에는 대체로 organization 또는 organizationalUnit가 부모입니다. 그룹 항목에 새 속성을 추가하려는 경우에는 대체로 groupOfNames 또는 groupOfUniqueNames가 부모입니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
RFC 4517에 지정된 구문에 따라 객체 클래스 정의를 준비합니다.
ldapmodify(1) 명령을 사용하여 객체 클래스 정의를 추가합니다.
디렉토리 서버에서는 사용자가 입력한 정의에 X-ORIGIN 'user defined'를 추가합니다.
다음 예에서는 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) 명령을 사용하면 이러한 정의를 읽을 수 있습니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
ldapsearch 명령을 사용하여 현재 디렉토리 스키마에 있는 모든 객체 클래스 정의를 봅니다.
다음 명령을 실행하면 모든 객체 클래스의 정의가 표시됩니다.
$ 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 파일에 저장됩니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
삭제할 객체 클래스의 정의를 봅니다.
자세한 내용은 객체 클래스를 보려면을 참조하십시오.
ldapmodify(1) 명령을 사용하여 스키마에 표시된 대로 객체 클래스 정의를 삭제합니다.
다음 명령을 실행하면 예 11–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 뷰입니다.
디렉토리 서버 스키마를 확장하는 데 사용하는 방법은 스키마 확장이 저장되는 파일 이름을 제어할지 여부에 따라 달라집니다. 또한 복제를 통해 변경 사항을 사용자에게 푸시할지 여부에 따라서도 달라집니다. 특정 상황에 맞게 수행할 절차를 결정하려면 다음 표를 참조하십시오.
표 11–1 스키마 확장 방법
작업 |
지침 |
---|---|
복제를 사용하지 않고 사용자 정의 스키마 파일을 추가하여 스키마를 확장합니다. | |
LDAP를 통해 스키마를 확장합니다. | |
복제를 사용하고 모든 서버에 사용자 정의 스키마 파일의 파일 이름을 유지합니다. | |
복제를 사용하고 마스터 복제본에 사용자 정의 스키마 파일을 추가하여 스키마를 확장합니다. 그런 다음 복제 메커니즘을 통해 스키마 확장을 사용자 서버에 복사합니다. |
객체 클래스, 속성 및 디렉토리 스키마에 대한 자세한 내용과 스키마 확장에 대한 지침은 Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide의 Designing a Directory Schema를 참조하십시오. 표준 속성 및 객체 클래스에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.0 Man Page Reference를 참조하십시오.
이 절에서는 디렉토리 스키마를 확장하는 다양한 방법에 대해 설명합니다.
스키마 파일은 instance-path/config/schema/에 있는 LDIF 파일입니다. instance-path는 디렉토리 서버 인스턴스가 있는 파일 시스템 디렉토리에 해당합니다. 예를 들어 인스턴스는 /local/ds/에 있을 수 있습니다. 이 파일은 디렉토리 서버에서 사용하는 표준 스키마와 디렉토리 서버를 사용하는 모든 서버를 정의합니다. 이 파일과 표준 스키마는 Sun Java System Directory Server Enterprise Edition 6.0 Reference 및 Sun Java System Directory Server Enterprise Edition 6.0 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 파일에 스키마 요소를 정의한 다음 이 파일을 모든 서버의 스키마 디렉토리에 복사할 수 있습니다. 그런 다음 모든 서버를 다시 시작하여 새 스키마 파일을 로드해야 합니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
98mySchema.ldif와 같은 사용자 고유의 스키마 정의 파일을 만듭니다.
스키마 파일의 정의 구문은 RFC 4517에서 설명합니다.
(옵션) 이 서버가 다른 서버에 업데이트를 전송하는 마스터 복제본인 경우 스키마 정의 파일을 복제 토폴로지의 각 서버 인스턴스에 복사합니다.
스키마가 포함된 LDIF 파일에서 직접 변경한 사항은 복제 메커니즘에서 감지할 수 없으므로 마스터를 다시 시작해도 변경 사항이 사용자에 복제되지는 않습니다.
스키마 정의 파일이 복사된 각 디렉토리 서버 인스턴스를 다시 시작합니다.
서버가 다시 시작되어 스키마 정의가 다시 로드되면 변경 사항이 적용됩니다.
스키마는 cn=schema에 있는 LDAP 뷰에서 정의되기 때문에 ldapsearch 및 ldapmodify 유틸리티를 사용하여 온라인으로 스키마를 보고 수정할 수 있습니다. 그러나 X-ORIGIN 필드에 대해서는 ’user defined’ 값이 있는 스키마 요소만 수정할 수 있습니다. 다른 정의에 대한 수정은 서버에서 모두 거부합니다.
사용자 정의 요소에 대한 변경 사항과 새로운 요소 정의는 99user.ldif 파일에 저장됩니다.
DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.
명령줄에서 스키마 정의를 수정하는 경우 긴 값을 정확하게 입력해야 하기 때문에 오류가 발생할 가능성이 큽니다. 하지만 디렉토리 스키마를 업데이트해야 하는 스크립트에 이 기능을 사용할 수 있습니다.
ldapmodify(1) 명령을 사용하여 개별 attributeTypes 속성 값을 추가하거나 삭제합니다.
자세한 내용은 속성 유형을 만들려면 또는 속성 유형을 삭제하려면을 참조하십시오.
ldapmodify(1) 명령을 사용하여 개별 objectClasses 속성 값을 추가하거나 삭제합니다.
자세한 내용은 객체 클래스를 만들려면 또는 객체 클래스를 삭제하려면을 참조하십시오.
값 중 하나를 수정하려면 특정 값을 삭제한 다음 이 값을 새 값으로 추가해야 합니다. 이 프로세스는 속성이 여러 값을 갖기 때문에 필요합니다. 자세한 내용은 여러 값을 갖는 속성의 값 하나만 수정을 참조하십시오.
사용자 정의 스키마 파일에 대한 자세한 내용은 사용자 정의 스키마 파일을 사용한 스키마 확장을 참조하십시오. 다음 절차에서는 복제 메커니즘을 사용하여 스키마 확장을 토폴로지의 모든 서버에 전달하는 방법에 대해 설명합니다.
이 절차의 일부로, DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오. 해당 절차의 다른 부분은 명령줄에서만 수행할 수 있습니다.
다음 방법 중 하나를 사용하여 스키마 확장을 준비합니다.
스키마 파일의 정의 구문은 RFC 4517에서 설명합니다.
스키마 정의 파일이 있는 마스터 서버에서 schema_push 명령을 실행합니다.
이 스크립트는 실제로 스키마를 복제본으로 푸시하지는 않습니다. 대신 스크립트는 스키마 파일이 로드되는 즉시 복제되도록 특수 속성을 스키마 파일에 씁니다. 자세한 내용은 schema_push(1M) 설명서 페이지를 참조하십시오.
스키마 정의 파일이 있는 마스터 서버를 다시 시작합니다.
스키마가 포함된 LDIF 파일에서 직접 변경한 사항은 복제 메커니즘에서 감지할 수 없습니다. 그러나 schema_push를 실행한 후 서버를 다시 시작하면 서버에서 모든 스키마 파일이 로드된 후 복제 메커니즘이 새 스키마를 사용자에 복제합니다.
두 서버 간에 하나 이상의 접미어 복제를 구성하면 스키마 정의도 자동으로 복제됩니다. 이렇게 해서 모든 복제본은 소비자로 복제될 수 있는 모든 객체 클래스 및 속성을 정의하는 동일한 스키마를 갖게 되며 마스터 서버에도 마스터 스키마가 있습니다.
그러나 스키마 복제는 LDAP를 통해 스키마를 수정할 때에도 즉시 수행되지 않습니다. 스키마 복제는 디렉토리 데이터에 대한 업데이트 시 또는 스키마가 수정된 후 첫 번째 복제 세션 시작 시에 실행됩니다.
모든 복제본에서 스키마를 실행하려면 반드시 모든 마스터에서 스키마 검사를 활성화해야 합니다. LDAP 작업이 수행되는 마스터에서 스키마를 검사하기 때문에 사용자를 업데이트할 때는 스키마를 검사할 필요가 없습니다. 성능을 향상시키기 위해 복제 메커니즘은 소비자 복제본에 대한 스키마 검사를 무시합니다.
허브 및 전용 사용자에서는 스키마 검사를 비활성화하지 마십시오. 스키마 검사는 사용자 성능에 영향을 주지 않으므로 복제본 내용이 스키마에 맞는지 나타내려면 스키마 검사를 계속 활성화 상태로 유지합니다.
마스터 서버는 사용자 초기화 중에, 그리고 DSCC 또는 명령줄 도구를 통해 스키마를 수정할 때에 자동으로 스키마를 해당 사용자에 복제합니다. 기본적으로 전체 스키마가 복제되며, 사용자에 없는 추가 스키마 요소는 사용자에 새로 만들어져 99user.ldif 파일에 저장됩니다.
예를 들어 마스터 서버를 시작할 때 해당 서버에 98mySchema.ldif 파일의 스키마 정의가 포함되고 이후 다른 서버(마스터, 허브 또는 전용 사용자)에 대한 복제 계약을 정의한다고 가정합니다. 나중에 이 마스터에서 복제본을 초기화하면 복제된 스키마에는 98mySchema.ldif의 정의가 포함되지만 이 정의는 복제본 서버의 99user.ldif에 저장됩니다.
스키마가 사용자 초기화 중에 복제된 경우 마스터의 cn=schema에 있는 스키마를 수정해도 전체 스키마가 사용자에 복제되므로 명령줄 유틸리티나 DSCC를 통한 마스터 스키마의 모든 수정 사항이 사용자에 복제됩니다. 이러한 수정 사항은 마스터의 99user.ldif에 저장되며, 또한 이전 설명과 동일한 메커니즘으로 사용자의 99user.ldif에도 저장됩니다.
복제된 환경에서 스키마의 일관성을 유지하려면 다음 지침을 수행합니다.
사용자 서버의 스키마는 수정하지 마십시오.
사용자 서버의 스키마를 수정하면 복제 오류가 발생할 수 있습니다. 사용자의 스키마가 변경되면 공급자로부터의 업데이트가 사용자의 스키마와 맞지 않을 수 있기 때문입니다.
다중 마스터 복제 환경에서는 단일 마스터 서버의 스키마를 수정합니다.
두 개의 마스터 서버에서 스키마를 수정하면 최신으로 업데이트된 마스터에서 해당 버전의 스키마를 사용자에 전달합니다. 그러면 사용자의 스키마가 다른 마스터의 스키마와 일치하지 않을 수 있습니다.
단편 복제를 구성할 때에는 다음 사항도 고려해야 합니다.
단편 복제 구성에서는 공급자가 스키마를 푸시하므로 단편 소비자 복제본의 스키마는 마스터 복제본 스키마의 복사본입니다. 따라서, 스키마가 현재 적용 중인 단편 복제 구성에 맞지 않을 수 있습니다.
일반적으로 디렉토리 서버는 스키마 위반을 방지하기 위해 스키마에 정의된 대로 모든 필수 속성을 각 항목에 복제합니다. 필수 속성을 필터링하도록 단편 복제를 구성하는 경우 스키마 검사를 비활성화해야 합니다.
단편 복제 시 스키마 검사를 활성화하면 복제본을 오프라인으로 초기화하지 못할 수 있습니다. 필수 속성이 필터링되면 디렉토리 서버를 통해 LDIF에서 데이터를 로드할 수 없습니다.
단편 소비자 복제본에 대한 스키마 검사를 비활성화하면 단편 소비자 복제본이 있는 전체 서버 인스턴스에서 스키마 검사가 실행되지 않습니다. 따라서, 단편 사용자와 동일한 서버 인스턴스에는 공급자 복제본을 구성하지 마십시오.
기본적으로 복제 메커니즘은 스키마를 복제할 때 항상 전체 스키마를 사용자에게 보냅니다. 다음 두 가지 상황과 같이 전체 스키마를 사용자에게 보내지 않아야 하는 경우도 있습니다.
DSCC 또는 명령줄에서 cn=schema를 수정하면 사용자 정의 스키마 요소만 변경되고 표준 스키마는 변경되지 않습니다. 자주 스키마를 수정하면 변경되지 않는 스키마 요소의 대규모 집합을 매번 보내야 하기 때문에 성능이 저하됩니다. 이 경우 사용자 정의 스키마 요소만 복제하여 복제 및 서버 성능을 향상시킬 수 있습니다.
디렉토리 서버의 마스터를 Directory Server 5.1의 사용자에 복제하면 두 버전의 구성 속성 스키마가 다르기 때문에 충돌이 발생합니다. 이 경우 반드시 사용자 정의 스키마 요소만 복제해야 합니다.
디렉토리 서버는 11rfc2307.ldif 스키마 파일을 사용합니다. 이 스키마 파일은 RFC 2307을 준수합니다.
Directory Server 5.2 이전 버전에서는 10rfc2307.ldif 스키마 파일을 사용합니다.
DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.
사용자 정의 스키마만 복제되도록 스키마 복제를 제한합니다.
$ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on |
기본값 off를 설정하면 필요한 경우 전체 스키마가 복제됩니다.