Iniziamo a popolare il nostro database

Introduzione

Adesso che abbiamo il nostro server openldap funzionante occorre iniziare a popolarlo con quelle informazioni che potrebbero servirci. In particolare potremmo iniziare a prevedere un suo utilizzo per quanto riguarda l'autenticazione degli utenti, e per fare questo possiamo creare l'organizational unit "people" e "groups" inserendoci così al suo interno gli utenti.

Diagramma esemplificativo

Di seguito una schematizzazione di quello che si vuole ottenere

File LDIF risultante

Iniziamo col creare un file "ldif" dove immettere i nostri record:

$ touch /tmp/example-com.ldif

In seguito bisognerà popolare il file con i blocchi seguenti

Base

########
# Base #
########
# definizione del DN base example.com
dn: dc=example,dc=com
description: Example com Industries
o: example.com
dc: example
objectClass: top
objectClass: dcObject
objectClass: organization

Come potete vedere il base DN viene definito con gli objectClass top, dcObject e organization. Riguardo l'objectClass organization ha come parametro obbligatorio 'o'  sinonimo di organizationName, questa objectClass ci permette di definire tutta una serie di attributi utili ad identificare un'organizzazione.

Organizational Unit

######
# OU #
######
# people ou
dn: ou=people,dc=example,dc=com
ou: people
description: People OU
objectClass: organizationalUnit

# groups ou
dn: ou=groups,dc=example,dc=com
ou: groups
description: Groups OU
objectClass: organizationalUnit

La definizione delle organizationalUnit è molto semplice, basta richiamare l'objectClass organizationalUnit dove l'unico parametro obbligatorio è ou.

Inserimento delle persone

##########
# people #
##########
# amedeo uid
dn: uid=amedeo,ou=people,dc=example,dc=com
uid: amedeo
ou: people
sn: Amedeo
cn: Amedeo Salvati
displayName: Amedeo Salvati
mail: amedeo@example.com
userPassword: password
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# paolo uid
dn: uid=paolo,ou=people,dc=example,dc=com
uid: paolo
ou: people
sn: Paolo
cn: Paolo Bianchi
displayName: Paolo Bianchi
mail: paolo@example.com
userPassword: password
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# mario uid
dn: uid=mario,ou=people,dc=example,dc=com
uid: mario
ou: people
sn: Mario
cn: Mario Rossi
displayName: Mario Rossi
mail: mario@example.com
userPassword: password
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

Qui i campi obbligatori sono 'sn' (surname) e 'cn' (common name) nella classe person.

Associazione degli utenti ai gruppi

##########
# groups #
##########
# users group
dn: cn=users,ou=groups,dc=example,dc=com
cn: users
ou: groups
description: Users Group
member: uid=amedeo,ou=people,dc=example,dc=com
member: uid=paolo,ou=people,dc=example,dc=com
member: uid=mario,ou=people,dc=example,dc=com
objectClass: groupOfNames

# sales group
dn: cn=sales,ou=groups,dc=example,dc=com
cn: sales
ou: groups
description: Sales Group
member: uid=mario,ou=people,dc=example,dc=com
objectClass: groupOfNames

# admins group
dn: cn=admins,ou=groups,dc=example,dc=com
cn: admins
ou: groups
description: Admins Group
member: uid=amedeo,ou=people,dc=example,dc=com
objectClass: groupOfNames

Qui i campi obbligatori della classe groupOfNames sono 'member' e 'cn'.

Verifica del file

Ora non ci resta che verificare di aver scritto tutto in modo corretto, e per fare questo possiamo utilizzare il comando slapadd, che lanciato in modalità dry-run ci permette di verificare la consistenza dei nostri record senza apportare alcuna modifica al nostro database; questo può essere utile in quanto così come lo stiamo utilizzando, il nostro server LDAP non supporta le transazioni, che nello specifico comporta il fatto che se vogliamo caricare un file LDIF contenente svariati record e ad un certo punto del caricamento il nostro comando restituisce un errore, questo farà si che avremo caricato soltanto parzialmente il nostro database, e per tornare alla situazione precedente saremmo noi a dover eliminare manualmente i record caricati o ripristinare il tutto da un backup.

Per verificare il contenuto del file dobbiamo prima effettuare lo stop del demone slapd perchè i nostri comandi slap* agiscono direttamente sui file/directory del database.

$ sudo cat /usr/local/etc/openldap/slapd.conf | egrep '^pidfile' | \
    awk '{print $2}' | xargs sudo cat | xargs sudo kill
$ sudo /usr/local/sbin/slapadd -v -u -c \
   -f /usr/local/etc/openldap/slapd.conf \
   -l /tmp/example-com.ldif

Dove nello specifico:

• con il parametro -v indicheremo la modalità verbosa;

• con il parametro -u lanceremo il comando in modalità dry-run, ovvero non apportando modifiche al database;

• con il parametro -c indicheremo la volontà di continuare l'esecuzione anche se si incontreranno degli errori;

• con il parametro -f indicheremo il file di configurazione slapd.conf da utilizzare;

• con il parametro -l indicheremo il nostro file ldif appena creato.

Nel caso fosse tutto corretto verrà visualizzato il messaggio

added: "dc=example,dc=com"
added: "ou=people,dc=example,dc=com"
added: "ou=groups,dc=example,dc=com"
added: "uid=amedeo,ou=people,dc=example,dc=com"
added: "uid=paolo,ou=people,dc=example,dc=com"
added: "uid=mario,ou=people,dc=example,dc=com"
added: "cn=users,ou=groups,dc=example,dc=com"
added: "cn=sales,ou=groups,dc=example,dc=com"
added: "cn=admins,ou=groups,dc=example,dc=com"
_#################### 100.00% eta   none elapsed            none fast!

Caricamento del file

A questo punto possiamo caricare il nostro file ldif sempre tramite il comando slapadd

$ sudo /usr/local/sbin/slapadd -v \
  -f /usr/local/etc/openldap/slapd.conf \
  -l /tmp/example-com.ldif

ed infine avviare il nostro demone slapd

$ sudo /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf

Conclusioni

In questo articolo abbiamo visto come iniziare a popolare il nostro database LDAP con alcuni record, ma soprattutto abbiamo iniziato a prendere visione dei file LDIF e della loro sintassi.