디렉토리 서버 스키마 확장

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

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

디렉토리 서버 스키마는 cn=schema 항목 속성에 저장됩니다. 구성 항목과 마찬가지로 이 항목은 서버 시작 중에 파일에서 읽은 스키마의 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 온라인 도움말을 참조하십시오.

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

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

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

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

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

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

LDAP를 통한 스키마 확장

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

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

LDAP를 통해 스키마를 확장하려면

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

시작하기 전에

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

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

   자세한 내용은 속성 유형을 만들려면 또는 속성 유형을 삭제하려면을 참조하십시오.

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

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

참조

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

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

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

스키마 파일 및 복제를 사용하여 스키마를 확장하려면

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

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

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

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

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

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

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

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

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