3.5. 일관된 스키마 유지 관리
- 스키마 검사를 사용하여 속성 및 오브젝트 클래스가 스키마 규칙을 준수하는지 확인합니다.
- 구문 검증을 사용하여 속성 값이 required 특성 구문과 일치하는지 확인합니다.
- 일관된 데이터 형식을 선택하고 적용합니다.
3.5.1. 스키마 검사
cn
) 및 surname(sn
) 속성이 필요합니다. 즉, 이러한 속성의 값은 항목을 만들 때 설정해야 합니다. 또한 전화 번호
,uid
,StreetAddress
및 userPassword
와 같은 설명적 특성을 포함하여 항목에서 선택적으로 사용할 수 있는 속성의 긴 목록이 있습니다.
3.5.2. 구문 검증
telephoneNumber
속성에 실제로 해당 값에 유효한 전화 번호가 있는지 확인합니다.
3.5.2.1. 구문 검증 개요
3.5.2.2. 구문 검증 및 기타 디렉터리 서버 작업
데이터베이스 암호화
일반적인 LDAP 작업의 경우 값이 데이터베이스에 기록되기 직전에 속성이 암호화됩니다. 즉, 특성 구문의 유효성을 검사한 후 암호화가 수행됩니다.
-E
플래그를 사용하여 수행하는 것이 좋습니다. 이렇게 하면 가져오기 작업에 구문 유효성 검사가 수행될 수 있습니다. 그러나 암호화된 데이터베이스가 -E
플래그(지원되지 않음)를 사용하지 않고 내보낸 경우 암호화된 값이 있는 LDIF가 생성됩니다. 그러면 이 LDIF를 가져오면 암호화된 특성을 검증할 수 없으며, 경고가 기록되고 가져온 항목에서 속성 유효성 검사를 건너뜁니다.
동기화
Windows Active Directory 항목 및 Red Hat Directory Server 항목에서 속성에 대해 허용되거나 강제 적용되는 구문에 차이가 있을 수 있습니다. 이 경우 구문 검증에서 Directory Server 항목의 RFC 표준을 적용하기 때문에 Active Directory 값을 올바르게 동기화할 수 없었습니다.
복제
Directory Server 11.0 인스턴스가 사용자에게 변경 사항을 복제하는 공급자인 경우 구문 유효성 검사를 사용하는 데 문제가 없습니다. 그러나 복제된 공급자가 이전 버전의 Directory Server이거나 구문 검증이 비활성화된 경우 Directory Server 11.0 소비자가 공급자가 허용하는 특성 값을 거부할 수 있으므로 11.0 소비자에서 구문 유효성 검사를 사용해서는 안 됩니다.
3.5.3. 일관된 데이터 형식 선택
- ITU-T 권장 사항 E.123. 국가 및 국제 전화 번호에 대한 표기법입니다.
- ITU-T 권장 사항 E.163. 국제 전화 서비스에 대한 번호 지정 계획 예를 들어, 미국 전화번호는 +1 555 222 1717 로 포맷되어 있습니다.
postalAddress
속성은 달러 기호($)를 줄 구분 기호로 사용하는 다중 줄 문자열 형식의 속성 값을 예상합니다. 올바르게 포맷된 디렉터리 항목이 다음과 같이 표시됩니다.
postalAddress: 1206 Directory Drive$Pleasant View, MN$34200
3.5.4. 복제된 스키마에서 일관성 유지
- 읽기 전용 복제본에서 스키마를 수정하지 마십시오.읽기 전용 복제본에서 스키마를 수정하면 스키마의 불일치가 발생하고 복제가 실패합니다.Moding the schema on a read-only replica introduces an inconsistency in the schema and causes replication to fail.
- 다른 구문을 사용하는 것과 동일한 이름의 두 속성을 생성하지 마십시오.provider 복제본에 특성과 이름이 동일하지만 공급업체의 특성과 다른 구문이 있는 읽기-쓰기 복제본에서 속성이 생성되면 복제가 실패합니다.