Dado que LDIF puede representar las operaciones de actualización LDAP, puede utilizarlo para modificar el esquema.
Para añadir una clase, simplemente añada un valor de atributo que se ajuste a la especificación para NDSObjectClassDescription del atributo objectClasses de 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 ")"
El siguiente archivo LDIF de ejemplo añade la clase de objeto person al esquema:
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
En la sección MUST de la descripción de la clase de objeto se indican los atributos obligatorios. Para la clase de objeto person, los atributos obligatorios son cn y sn.
En la sección MAY de la descripción de la clase de objeto se indican los atributos opcionales. Los atributos opcionales de la clase de objeto person son description, seeAlso, telephoneNumber, fullName, givenName, initials, uid y userPassword.
NOTA:El atributo userPassword no se puede utilizar como atributo opcional (MAY). La operación producirá un error si intenta utilizarlo como atributo obligatorio (MUST) en la nueva objectClass con este formato LDIF para extender el esquema.
Las clases de objeto que pueden contener la clase de objeto definida se indican en la sección X-NDS_CONTAINMENT de la descripción de la clase de objeto. La clase de objeto person puede estar incluida en las clase de objeto organization, organizationalUnity y domain.
Para añadir un atributo, simplemente añada un valor de atributo que se ajuste a la especificación para NDSAttributeTypeDescription del atributo attributes de 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 ")"
El siguiente archivo LDIF de ejemplo añade el tipo de atributo title al esquema:
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
Un atributo toma por defecto varios valores, a menos que se configure explícitamente como monovalente. El siguiente archivo LDIF de ejemplo configura el atributo title como monovalente mediante la adición de la palabra clave SINGLE-VALUE después de la sección 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
Aunque la adición de nuevos elementos de esquema es una práctica aceptable, normalmente resulta peligroso modificar o extender los elementos de esquema existentes. Cada elemento del esquema se identifica mediante un OID de forma exclusiva, por lo que al extender un elemento de esquema estándar puede crear eficazmente una segunda definición para el elemento aunque este siga utilizando el OID original. Esto puede provocar problemas de incompatibilidad.
En algunas ocasiones es apropiado cambiar los elementos del esquema. Por ejemplo, quizás tenga que extender o modificar los elementos nuevos del esquema cuando los perfeccione durante el desarrollo. En lugar de añadir atributos nuevos directamente a una clase, por lo general solo debería utilizar las clases auxiliares para:
añadir nuevos atributos a una clase de objeto existente:
incluir como subclase de una clase de objeto existente.
El siguiente archivo LDIF de ejemplo crea dos atributos nuevos, crea una clase auxiliar con estos atributos nuevos y añade una entrada inetOrgPerson con la clase auxiliary como clase de objeto de la entrada y con valores para los atributos de la clase 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
Al eliminar clases auxiliares, no tiene que suprimir todos los valores asociados a la clase auxiliary cuando elimine la clase auxiliary de la lista de objectClass. eDirectory lo hace automáticamente.
Si la clase auxiliary tenía atributos MUST, deben especificarse todos en la misma operación de modificación que añade la clase auxiliary a la lista objectClass, de lo contrario la modificación producirá un error.
El procesamiento XML de un registro LDIF (formato LDIF o registros generados desde el servidor LDAP) no tendrá éxito si los registros individuales no cumplen todas las reglas XML especificadas en el archivo XML.