Selon Rapha�l 'SurcouF' Bordet <[EMAIL PROTECTED]>: > 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.
