Poiché LDIF può rappresentare operazioni di aggiornamento LDAP, è possibile utilizzare questo formato per modificare lo schema.
Per aggiungere una classe, è sufficiente aggiungere un valore di attributo conforme alla specifica per NDSObjectClassDescription dell'attributo objectClasses di 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 ")"
Mediante il file LDIF di esempio che segue viene aggiunta allo schema la classe di oggetti 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
Gli attributi obbligatori sono elencati nella sezione MUST della descrizione della classe di oggetti. Per la classe di oggetti person, gli attributi obbligatori sono cn e sn.
Gli attributi facoltativi sono elencati nella sezione MAY della descrizione della classe di oggetti. Per la classe di oggetti person tali attributi sono description, seeAlso, telephoneNumber, fullName, givenName, initials, uid e userPassword.
NOTA:l'attributo userPassword non può essere utilizzato come attributo facoltativo (MAY). Se si tenta di utilizzarlo come attributo obbligatorio (MUST) nella nuova objectClass per estendere lo schema mediante il formato LDIF, l'operazione ha esito negativo.
Le classi di oggetti che possono contenere quella che si sta definendo sono indicate nella sezione X-NDS_CONTAINMENT della descrizione della classe di oggetti. Le classi di oggetti che possono contenere la classe person sono organization, organizationalUnit e domain.
Per aggiungere un attributo, è sufficiente aggiungere un valore di attributo conforme alla specifica per NDSAttributeTypeDescription degli attributi di 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 ")"
Mediante il file LDIF di esempio che segue viene aggiunto allo schema il tipo di attributo 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
Un attributo viene impostato per default su un valore multiplo, a meno che non venga specificato esplicitamente come valore singolo. Mediante il file LDIF di esempio che segue viene creato un titolo con valore singolo aggiungendo la parola chiave SINGLE-VALUE dopo la sezione 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
Sebbene l'aggiunta di nuovi elementi nello schema sia una prassi accettabile, la modifica o l'estensione di uno schema esistente è in genere un'operazione rischiosa. Poiché ciascun elemento dello schema viene identificato in modo univoco da un OID, quando si estende un elemento dello schema standard, viene in effetti creata una seconda definizione per l'elemento, nonostante si utilizzi ancora l'OID originale. Questa condizione può creare problemi d'incompatibilità.
Esistono casi in cui è opportuno modificare gli elementi dello schema. Ad esempio, potrebbe essere necessario estendere o modificare i nuovi elementi di uno schema come quando vengono ottimizzati in fase di sviluppo. Anziché aggiungere nuovi attributi direttamente a una classe, è consigliabile utilizzare le classi ausiliarie solo per:
Aggiungere nuovi attributi a una classe di oggetti esistente.
Dividere in sottoclassi una classe di oggetti esistente.
Il file LDIF di esempio riportato di seguito consente di creare due nuovi attributi e una classe ausiliaria con i nuovi attributi, nonché di aggiungere una voce inetOrgPerson con la classe auxiliary come classe di oggetti della voce e con i valori degli attributi per la classe 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
Quando si rimuovono classi ausiliarie, non è necessario eliminare tutti i valori associati alla classe auxiliary se si rimuove la classe auxiliary stessa dall'elenco di classi di oggetti. In eDirectory questa operazione viene eseguita automaticamente.
Se la classe auxiliary contiene attributi MUST, affinché la modifica venga eseguita è necessario specificarli tutti nella medesima operazione di modifica che aggiunge la classe auxiliary all'elenco delle classi di oggetti.
L'elaborazione XML dei record LDIF (formato LDIF o record generati dal server LDAP) ha esito negativo nel caso in cui i singoli record non soddisfino tutte le regole XML specificate nel file XML.