Так как LDIF может выполнять операции LDAP по обновлению, LDIF можно использовать для изменения Схемы.
Чтобы добавить класс, просто добавьте значение атрибута, соответствующее спецификации для NDSObjectClassDescription атрибута objectClasses объекта subschemaSubentry.
NDSObjectClassDescription = "(" whsp
numericoid whsp
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
[ "MUST" oids ]
[ "MAY" oids ]
[ "X-NDS_NOT_CONTAINER" qdstrings ]
[ "X-NDS_NONREMOVABLE" qdstrings ]
[ "X-NDS_CONTAINMENT" qdstrings ]
[ "X-NDS_NAMING" qdstrings ]
[ "X-NDS_NAME" qdstrings ]
whsp ")"
В следующем примере файла LDIF в схему добавляется класс объекта person:
1 version: 1 2 dn: cn=schema 3 changetype: add 4 objectClasses: ( 2.5.6.6 NAME ’person’ DESC ’Standard 5 ObjectClass’ SUP ndsLoginProperties STRUCTURAL MUST 6 (cn $ sn) MAY (description $ seeAlso $ telephoneNum 7 ber $ fullName $ givenName $ initials $ uid $ userPa 8 ssword) X-NDS_NAMING (’cn’ ’uid’) X-NDS_CONTAINMENT 9 (’organization’ ’organizationalUnit’ ’domain’) X-NDS 10 _NAME ’Person’ X-NDS_NOT_CONTAINER ’1’ X-NDS_NONREMO 11 VABLE ’1’) 12
Обязательные атрибуты перечислены в разделе MUST описания класса объекта. Для класса объектов "person" обязательными атрибутами являются cn и sn.
Необязательные атрибуты перечислены в разделе MAY описания класса объекта. Необязательными атрибутами в классе объекта person являются description, seeAlso, telephoneNumber, fullName, givenName, initials, uid и userPassword.
ПРИМЕЧАНИЕ.Атрибут userPassword невозможно использовать как необязательный атрибут (MAY). При попытке использовать его как обязательный атрибут (MUST) в новом objectClass, использующем формат LDIF для расширения схемы, соответствующая операция не будет выполнена.
Классы объектов, которые могут содержать определяемый класс объектов, приводятся в разделе X-NDS_CONTAINMENT описания классов объектов. Класс объектов person может содержаться в классах объектов organization, organizationalUnit и domain.
Чтобы добавить атрибут, просто добавьте значение атрибута, соответствующее спецификации для NDSObjectClassDescription атрибута атрибутов subschemaSubentry.
NDSAttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other AttributeType
[ "EQUALITY" woid] ; Matching Rule name
[ "ORDERING" woid] ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ] ; default user modifiable
[ "USAGE" whsp AttributeUsage ] ; default userApplications
[ "X-NDS_PUBLIC_READ" qdstrings ]
; default not public read (’0’)
[ "X-NDS_SERVER_READ" qdstrings ]
; default not server read (’0’)
[ "X-NDS_NEVER_SYNC" qdstrings ]
; default not never sync (’0’)
[ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ]
; default sched sync immediate (’0’)
[ "X-NDS_SCHED_SYNC_NEVER" qdstrings ]
; default schedule sync (’0’)
[ "X-NDS_LOWER_BOUND" qdstrings ]
; default no lower bound(’0’)
;(upper is specified in SYNTAX)
[ "X-NDS_NAME_VALUE_ACCESS" qdstrings ]
; default not name value access (’0’)
[ "X-NDS_NAME" qdstrings ] ; legacy NDS name
whsp ")"
В следующем примере файла LDIF в схему добавляется тип атрибута title:
1 version: 1
2 dn: cn=schema
3 changetype: add
4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa
5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} X-NDS_NAME ’Title’ X-NDS_NOT_SCHED_SYNC_IMMEDIA
7 TE ’1’ X-NDS_LOWER_BOUND ’1’)
8
По умолчанию используются многозначные атрибуты, пока не будет явно указана их однозначность. В следующем примере файла LDIF создается тип однозначного атрибута "title" путем добавления ключевого слова SINGLE-VALUE в разделе SYNTAX:
1 version: 1
2 dn: cn=schema
3 changetype: add
4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa
5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} SINGLE-VALUE X-NDS_NAME ’Title’ X-NDS_NOT_SCHED
7 _SYNC_IMMEDIATE ’1’ X-NDS_LOWER_BOUND ’1’)
8
Если добавление новых элементов Схемы является обычным действием, то изменение или расширение существующих элементов Схемы в большинстве случаев является рискованной операцией. Поскольку каждый элемент cхемы определяется по уникальному идентификатору объекта (OID), то при расширении стандартного элемента cхемы вы действительно создаете второе определение для элемента, даже если он по-прежнему использует исходный идентификатор объекта (OID). Это может привести к проблемам несовместимости.
Правда, иногда бывает удобно изменять элементы Схемы. Например, нужно расширить или изменить новые элементы Схемы при их переопределении в процессе разработки. Вместо добавления новых атрибутов непосредственно к классу, следует использовать вспомогательные классы только для:
добавления атрибута к существующему классу объектов;
добавления подкласса в существующий класс объектов.
В следующем примере файл LDIF создает два новых атрибута, вспомогательный класс с этими новыми атрибутами, затем добавляет запись inetOrgPerson с классом auxiliary в качестве класса объектов для данной записи и со значениями для атрибутов класса auxiliary.
version: 1 # Add an attribute to track a bear’s hair. The attribute is # multi-valued, uses a case ignore string syntax, # and has public read rights # Values may include: long hair, short, curly, straight, # none, black, and brown # X-NDS_PUBLIC_READ ’1’ The 1 allows public read, # 0 denies public read dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.10 NAME ’bearHair’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-NDS_PUBLIC_READ ’1’ ) # add an attribute to store a bear’s picture dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.11 NAME ’bearPicture’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE ) # create an Auxiliary class for the bearfeatures dn: cn=schema changetype: modify add: objectclasses objectclasses: (2.16.840.1.113719.1.186.6.101 NAME ’bearFeatures’ MAY (bearHair $ bearPicture) AUXILIARY) # now create a user named bobby dn: cn=bobby,o=bearcave changetype: add cn: bobby sn: bear givenName: bobby bearHair: Short bearHair: Brown bearHair: Curly bearPicture:< file:///c:/tmp/alien.jpg objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: bearFeatures # now create a person named john that will later be changed # into a bear when bearFeatures is added to its objectClass # list dn: cn=john,o=bearcave changetype: add cn: John sn: bear givenName: john objectClass: top objectClass: person objectClass: inetOrgPerson # now morph john into a bear by adding bearFeatures dn: cn=john,o=bearcave changetype: modify add: objectClass objectClass: bearFeatures - add: bearHair bearHair: long bearHair: black #bearPicture:< file:///c:/tmp/john.jpg> - # to morph john back to a person, simply delete the # objectClass bearFeatures dn: cn=john,o=bearcave changetype: modify delete: objectClass objectClass: bearFeatures
При удалении вспомогательных классов нет необходимости удалять все значения, связанные с классом auxiliary, когда класс auxiliary удаляется из списка objectClass. eDirectory выполняет это автоматически.
Если класс auxiliary имел атрибуты MUST, все они должны быть указаны в той же операции изменения, которая добавляет класс auxiliary в список классов объекта. В противном случае изменение выполнено не будет.
XML-обработка любой записи LDIF (в формате LDIF или записи, сформированные с сервера LDAP) не будет выполнена, если отдельные записи не будут удовлетворять всем правилам XML, указанным в файле XML.