Pascal BOYER a �crit :
Selon Rapha�l 'SurcouF' Bordet <[EMAIL PROTECTED]>:
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.
Plusieurs bases avec le m�me suffixe, oui.
Par contre, plusieurs bases ayant leurs propres suffixes, non.
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)
Outre les backups: la s�curit� des donn�es couvre plusieurs niveaux tous
compl�mentaires. Un syst�me de fichiers journalis� (au moins ext3), une
partition d�di�e, un syst�me RAID et ...la sauvegarde r�guli�re. De
toutes fa�ons, rien ne saurait remplacer la sauvegarde. Sa p�riodicit�
d�pendra essentiellement de tes besoins et des risques � encourir.
Mais il ne faut pas croire qu'en d�coupant les fichiers ainsi, �a
ajoutera une s�curit� vraiment substantielle...
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.
Etant donne qu'il s'agit de fichiers, ca depend donc aussi du systeme de
fichiers choisis (un journalis�): XFS ou reseirfs voire JFS, mais aussi
du support physique: tu ne vas pas mettre un disque IDE UDMA 133, non
plus. Pour �largir la question, je t'invite � poser cette question sur
la liste LDAP-FR du CRU[1], bien que le sujet soit LDAP et non pas
sp�cifiquement OpenLDAP (en tout cas, plus qu'ici).
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 ?
Non, qu'un serveur peut h�berger plusieurs bases chacune d�finie par sa
racine propre:
- dc=linuxorable, dc=net
- dc=debianfr, dc=net
[...]
[1]: http://listes.cru.fr/wws/info/ldap-fr
--
Rapha�l 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
