[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LDAP et espace de nommage



Le mardi 21 décembre 2004 à 16:20 +0100, Pascal BOYER a écrit :
> Selon Aurélien Labrosse <aurelien.labrosse@free.fr>:
> 
> > Bonjour,
> >
> >
> >   si tu as vraiment besoin d'avoir un historique des utilisateurs, tu peux
> > créer une branche "utilisateurs" et autant de sous branches qu'il y a
> > d'années. Ex:
> >
> > dc=linuxorable,dc=net
> > ou=people,dc=linuxorable,dc=net
> > ou=annee2004,ou=people,dc=linuxorable,dc=net
> > ou=annee2005,ou=people,dc=linuxorable,dc=net
> > ou=annee2006,ou=people,dc=linuxorable,dc=net
> >
> > ....
> >
> Désolé Julien, j'ai dû m'absenter.
> 
> ben jusqu'à présent, j'ai testé LDAP exactement comme tu l'indiques, mais il ne
> m'a pas semblé que cela crée une base pour 2004, une pour 2005 etc...

Une question me vient à l'esprit: as-tu seulement pensé à créer les
répertoires en question ?

> Alors j'ai peut-être mal fais les chôses ou pas compris comment faire les
> choses...

Ce que je ne comprend pas, c'est pourquoi tu persistes à vouloir deux
bases bien distinctes l'une de l'autre. Il faut bien voir avant tout que
LDAP est un protocole et non une base de données en soit. Ce n'est qu'un
modèle d'accès, normalisé via les schémas, à ces données. OpenLDAP
stocke les données par défaut dans des fichiers de type ldbm ou bdb (des
versions spécifiques de la Berkeley DB: la première est dite "légère",
la seconde supporte les transactions), qui sont des formats de bases de
données simples sous forme de fichiers. Mais on peut très bien attaquer
une base SQL (sous postgres ou mysql, par exemple) grâce au "backend"
sql (back_sql.so). D'autres "backend"[1] existent, permettant notamment
d'accéder à des données diverses comme les enregistrements SRV d'un DNS
(back_dnssrv.so) ou la base d'utilisateurs Unix du fichier /etc/passwd
(back_passwd et en lecture seule).

Pour revenir à ta problématique, je pense qu'il te suffirait simplement
de définir comment tu comptes stocker et gérer tes utilisateurs ainsi
que les services qu'ils devront utiliser, avant même de décider d'une
solution via LDAP ou SQL. Si ton choix avec LDAP se confirme, je pense
qu'il conviendrait soit d'utiliser une hiérarchie découpée par année, à
l'aide de OU= (bien que ce ne soit guère approprié), soit d'utiliser les
attributs du schéma inetOrgPerson, comme employeeNumber: et une
nomenclature utilisant la date d'arrivée de l'étudiant dans le numéro.  


[1]:http://www.openldap.org/doc/admin22/slapdconfig.html#General%
20Backend%20Directives
-- 
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net





Reply to: