Re: LDAP et espace de nommage
Selon Raphaël 'SurcouF' Bordet <surcouf@debianfr.net>:
> 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...
>
Des deux observations que tu fais, j'en conclu qu'il est absurde de vouloir
plusieurs bases.
Ok.
> > 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 ?
>
Ce qui soutend ma problèmatique, c'est que je me disais la chose suivante:
Si tout est situé dans une seule base, alors le jour où la base est corrompue
(pour une raison X) TOUT est perdu.
(passons sur le fait qu'une réponse peut-être: les backup c'est pas fait pour
les chiens)
Et de ce constat, à germé dans mon esprit que la possibilté de déclarer 2 bases
de données dans slapd.conf servait, entre autres, à cela (ce qui semble être
tout à fait faut en regard de ce que tu me dis).
Une deuxième chose qui m'a poussé dans mon raisonnement:
Ce sont les limites d'une base Berkeley.
Je ne connais pas ces limiyes, mais il doit bien y en avoir.
Le nombre d'entrées d'une telle base ne peut être infini.
Donc qu'arrive t-il quand la base est si grosse qu'elle engendre un
ralentissement du système, ou des temps de recherche trop longs ? ou que
sais-je encore.
> > 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.
>
Ca veut dire quoi "héberge plusieurs suffixes" ? Que la machine est aussi une
passerelle entre plusieurs réseaux ?
> > >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 ?
Je sais plus. J'ai lu ça cet après midi sur un site. Mais je lis tellement
d'information en ce moment sur LDAP que je ne retiens pas tout.
Et apparamment il m'arrive même de retenir de travers !!!
>
> > >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
>
>
Pascal
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Reply to: