LDAP et espace de nommage

j'avoue que les choses sont un peu alambiquées dans mon esprit !

J'ai un serveur LDAP dont le nom de domaine est linuxorable.net
Je veux créer un annuaire dont certaine bases de données seront ins tallées dans:
/var/lib/ldap/2004
et d'autres dans:
/var/lib/ldap/2005

Pascal BOYER a écrit :
> j'avoue que les choses sont un peu alambiquées dans mon esprit !
>
> J'ai un serveur LDAP dont le nom de domaine est linuxorable.net
> Je veux créer un annuaire dont certaine bases de données seront installées
dans:
> /var/lib/ldap/2004
> et d'autres dans:
> /var/lib/ldap/2005
>
> Et donc je me dis qu'il faut que je crée deux sections "database" dans
> /etc/ldap/slapd.conf
> Mais mon problème c'est la définition de la valeur du paramètre
"suffix" (qui,
> si j'ai bien compris, définit l'espace de nommage de l'annuaire).
> En effet, la valeur de "suffix" doit valoir mon nom de domaine
(RFC2247), soit:
> suffix "dc=linuxorable,dc=net"
> ET doit être unique. Or je veux deux bases de données.

Pourquoi veux-tu 2 bases pour faire cela ?
J'ai l'impression que tu raisonnes bases de données et non ldap (donc
sous forme arborescente).

Openldap utilise des bases pour stockés ces données mais les cas ou tu
aura besoin d'en utiliser plusieurs (via la directive database) sont rare.

a+
Julien

Selon COMBES Julien - CETE Lyon/DI/ET/PAMELA <julien.combes@i-carre.net>:

Pascal BOYER a écrit :
> j'avoue que les choses sont un peu alambiquées dans mon esprit !
>
> J'ai un serveur LDAP dont le nom de domaine est linuxorable.net
> Je veux créer un annuaire dont certaine bases de données seront
installées
dans:
> /var/lib/ldap/2004
> et d'autres dans:
> /var/lib/ldap/2005
>
> Et donc je me dis qu'il faut que je crée deux sections "database"
dans
> /etc/ldap/slapd.conf
> Mais mon problème c'est la définition de la valeur du paramètre
"suffix" (qui,
> si j'ai bien compris, définit l'espace de nommage de l'annuaire).
> En effet, la valeur de "suffix" doit valoir mon nom de domaine
(RFC2247), soit:
> suffix "dc=linuxorable,dc=net"
> ET doit être unique. Or je veux deux bases de données.

Pourquoi veux-tu 2 bases pour faire cela ?
J'ai l'impression que tu raisonnes bases de données et non ldap (donc
sous forme arborescente).

Salut julien,

Bon je t'explique ce que je cherche à faire (mais je ne sais pas si c'est
possible. Je commence à en douter)

Chaque année en septembre, de nouveaux étudiants arrivent dans
l'établissement
(lycée).
Je voudrais simplement, chaque année, au mois de septembre, créer une
nouvelle
base de donnée pour les nouveaux arrivant.
Et je voudrais que cette base de donnée soit située dans un répertoire du
nom de
l'année en cours.
Exemple:
pour 2004 => /var/lib/ldap/2004/
pour 2005 => /var/lib/ldap/2005/
etc...

Sachant qu'un étudiant qui rentre au lycée en 2004 en sortira au plus tard
(aux
exceptions prés) 3-4 ans plus tard.
Donc tous les 4 je peux sauvegarder ma base de données sans que cela
affecte la
gestion des étudiants encore présents au lycée.
Et cela évite également de voir grossir indéfiniment une unique base de
donnée.

Et donc mon problème est que je n'arrive pas à savoir comment je dois
faire pour
configurer mon fichier slapd.conf pour avoir 3 ou 4 bases de données en
même
temps.

Ca me semblait simple, sauf que je bute sur la valeur de "suffix"!!!

Si tu peux m'aider, je suis preneur ;-)

Pascal

Openldap utilise des bases pour stockés ces données mais les cas ou tu
aura besoin d'en utiliser plusieurs (via la directive database) sont
rare.

a+
Julien

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org


!DSPAM:41c7e3f4107276801411591!

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

....

Aurélien

> Selon COMBES Julien - CETE Lyon/DI/ET/PAMELA <julien.combes@i-carre.net>:
>
>> Pascal BOYER a écrit :
>> > j'avoue que les choses sont un peu alambiquées dans mon esprit !
>> >
>> > J'ai un serveur LDAP dont le nom de domaine est linuxorable.net
>> > Je veux créer un annuaire dont certaine bases de données seront
>> installées
>> dans:
>> > /var/lib/ldap/2004
>> > et d'autres dans:
>> > /var/lib/ldap/2005
>> >
>> > Et donc je me dis qu'il faut que je crée deux sections "database"
>> dans
>> > /etc/ldap/slapd.conf
>> > Mais mon problème c'est la définition de la valeur du paramètre
>> "suffix" (qui,
>> > si j'ai bien compris, définit l'espace de nommage de l'annuaire).
>> > En effet, la valeur de "suffix" doit valoir mon nom de domaine
>> (RFC2247), soit:
>> > suffix "dc=linuxorable,dc=net"
>> > ET doit être unique. Or je veux deux bases de données.
>>
>> Pourquoi veux-tu 2 bases pour faire cela ?
>> J'ai l'impression que tu raisonnes bases de données et non ldap (donc
>> sous forme arborescente).
>
> Salut julien,
>
> Bon je t'explique ce que je cherche à faire (mais je ne sais pas si c'est
> possible. Je commence à en douter)
>
> Chaque année en septembre, de nouveaux étudiants arrivent dans
> l'établissement
> (lycée).
> Je voudrais simplement, chaque année, au mois de septembre, créer une
> nouvelle
> base de donnée pour les nouveaux arrivant.
> Et je voudrais que cette base de donnée soit située dans un répertoire du
> nom de
> l'année en cours.
> Exemple:
> pour 2004 => /var/lib/ldap/2004/
> pour 2005 => /var/lib/ldap/2005/
> etc...
>
> Sachant qu'un étudiant qui rentre au lycée en 2004 en sortira au plus tard
> (aux
> exceptions prés) 3-4 ans plus tard.
> Donc tous les 4 je peux sauvegarder ma base de données sans que cela
> affecte la
> gestion des étudiants encore présents au lycée.
> Et cela évite également de voir grossir indéfiniment une unique base de
> donnée.
>
> Et donc mon problème est que je n'arrive pas à savoir comment je dois
> faire pour
> configurer mon fichier slapd.conf pour avoir 3 ou 4 bases de données en
> même
> temps.
>
> Ca me semblait simple, sauf que je bute sur la valeur de "suffix"!!!
>
> Si tu peux m'aider, je suis preneur ;-)
>
> Pascal
>>
>> Openldap utilise des bases pour stockés ces données mais les cas ou tu
>> aura besoin d'en utiliser plusieurs (via la directive database) sont
>> rare.
>>
>> a+
>> Julien
>>
>>
>>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> --
> Pensez à lire la FAQ de la liste avant de poser une question :
> http://wiki.debian.net/?DebianFrench
>
> Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
>
> To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> !DSPAM:41c7e3f4107276801411591!
>
>
>

Selon Aurélien Labrosse <aurelien.labrosse@free.fr>:

> Bonjour,
>
>
> si tu as vraiment besoin d'avoir un historique des utilisateurs, tu p eux
> 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...

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

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

> 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 d e 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, to ut 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.

Or, et ce n'est peut-être qu'une lubie de ma part au quel cas il fau t 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.

Et comme le fichier slapd.conf est prévu pour recevoir plusieurs par ties
database, et bien je me suis dit que c'était justement pour faire ce la: mettre
chaque chose à sa place.

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 optiq ue on
utilise la possibilité de définir deux bases de données da ns slapd.conf ?

>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 suf firait simplement
> de définir comment tu comptes stocker et gérer te s 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 posen t d'autres
problème.

>soit d'utiliser les
> attributs du schéma inetOrgPerson, comme employeeNumber: et une
> nomenclature

C'est quoi une nomenclature ?

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

Selon Raphaël 'SurcouF' Bordet <surcouf@debianfr.net>:

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.

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Þbianfr, dc=net

Pascal BOYER a écrit :
> Selon Raphaël 'SurcouF' Bordet <surcouf@debianfr.net>:
>
>>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Þbianfr, dc=net

[...]

[1]: http://listes.cru.fr/wws/info/ldap-fr
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org