Re: LDAP et espace de nommage
Le mardi 21 décembre 2004 à 23:25 +0100, Pascal BOYER a écrit :
>
> > 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.
>
> Justement, ce qui me surprend, c'est qu'une fois l'espace de nommage définit
> (valeur de suffix) je peux bien créer autant de "OU" que je veux, tout semble
> conserver dans une seule base de donnée.
> Donc je me rends compte qu'ensuite toutes les entrées que je crée, que ce soit
> sous l'OU 2004 ou l'OU 2005, vont dans la même base.
Normal puisque le suffixe définit la racine de la base. Les objets OU=
définissent autant de branches pour cette base.
> Or, et ce n'est peut-être qu'une lubie de ma part au quel cas il faut me le
> dire, mais j'aime bien que chaque chose soit à sa place.
> Donc je me dis que ce serait bien si les entrées de 2004 soient placées dans une
> base dédiée aux entrées de 2004 et que les entrées de 2005 soient placées dans
> une base dédiée aux entrées de 2005.
Oui, mais je ne vois aucune contrainte imposant d'avoir deux bases
distinctes au sens LDAP. Pire, j'en vois qui se profilent si tu
persistes dans cette voie: les différents clients devront être
renseignés de l'arborescence à utiliser pour chaque base. Chaque année,
tu devras donc non seulement modifier slapd.conf mais aussi les
différents clients de ton réseau...
> Et comme le fichier slapd.conf est prévu pour recevoir plusieurs parties
> database, et bien je me suis dit que c'était justement pour faire cela: mettre
> chaque chose à sa place.
Mettre les choses à leur place ne signifie pas nécessairement de ranger
le système de fichiers. Les bases d'OpenLDAP sont à leur place. D'autre
part, pourquoi est-ce que les étudiants de l'année suivante
devraient-ils être placés dans une base distincte ?
> J'insiste: si je fais une grossière erreur de compréhension, il faut me le dire.
> Mais si c'est le cas, alors dans quelle circonstance et dans quelle optique on
> utilise la possibilité de définir deux bases de données dans slapd.conf ?
Dans le cadre où un même serveur OpenLDAP héberge plusieurs suffixes
comme un serveur DNS hébergerait plusieurs zones. La comparaison
s'arrête là: tu ne peux pas définir deux fois le même suffixe.
> >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é),
>
> En effet j'ai lu que les arborescence à plat sont rapides mais posent d'autres
> problème.
Lesquels ?
> >soit d'utiliser les
> > attributs du schéma inetOrgPerson, comme employeeNumber: et une
> > nomenclature
>
> C'est quoi une nomenclature ?
Une norme d'écriture que tu définis pour l'usage de ton application.
Par exemple: 200412220001 peut désigner le premier élève inscrit le
Mercredi 22 Décembre 2004 (sur 1000 maximum, à toi d'évaluer le maxima
possible par jour). Ainsi, grâce à cette définition et à ce champ, tu
pourras faire des recherches sélectives en fonction de l'année d'entrée
de l'élève mais aussi du mois ou du jour, libre à toi.
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
Reply to: