Ubuntu-fr

mazou

LDAP : Je pige pas la notion d'alias !

Bonjour,

Je suis en train de mettre en place un annuaire LDAP.
Dans cet annuaire j'ai plusieurs branches "ou".
J'ai insérer l'utilisateur toto dans le ou "personnel", mais j'aimerai qu'il soit également dans le ou "commissions".

J'ai cru comprendre qu'il fallait faire un alias, mais je ne vois pas comment le faire ??

Pourriez-vous m'aider ??

Merci d'avance

clarky

Re : LDAP : Je pige pas la notion d'alias !

Salut,
je suis pas au top en LDAP, mais, à ta place, je créerais un minimum de branches (ou) : par exemple personnel et extérieur (au hasard, je connais pas la population que tu gères).
Ensuite, tu peux rajouter un attribut, par exemple service, ou tu mets la valeur commissions. Ou encore, tu crées l'attribut commissions qui prendra la valeur oui ou non. Ca te permettra, à l'avenir, de filtrer sur les personnels qui sont dans commisions.
Bon courage

mazou

Re : LDAP : Je pige pas la notion d'alias !

Merci clarky

En fait c'est ce que je faisais à la base.
Mais après en avoir discuté avec un prestataire, j'en suis venu à créer autant de branches que nécessaire.

Par exemple pour le personnel je déclare :
les "ou" pôle
Puis les "ou" service (qui font partie du pôle)

                      o
               collectivite        
            /                \         \
           ou              ou           ou
     Personnel           Elus      Exterieurs

Ensuite dans personnel
                /         |           \
               ou        ou           ou
             Pole 1    Pole 2    Pole 3

Ensuite dans Pole 1
              /             |           \
           ou              ou           ou
       Service 1    Service 2    Service 3

Et ensuite je créé les utilisateurs.

Par exemple :

dn: cn=Prénom nom, ou=Service 1, ou=Pole 1, o=collectivite, dc=Addressbook, dc=cpm, dc=glo, dc=mx, dc=fr
objectclass: top
objectclass: person
objectClass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mozillaOrgPerson
objectclass: mxPerson
cn: Prénom nom
...

Soit :

                    ou
               Service 1
            /                \         \
      Prénom nom        ...       ...

Seulement il peut arriver qu'une personne soit dans plusieur services ou poles. Et c là que je bloque.

clarky

Re : LDAP : Je pige pas la notion d'alias !

je pense qu'il vaut mieux que tu reviennes à ton idée de base :
tes 3 OU : personnel + élus + extérieurs
avec des attributs pole et service

mazou

Re : LDAP : Je pige pas la notion d'alias !

Mince....

Ca fait plusieurs jours que je bosse dessus !
:rolleyes:

clarky

Re : LDAP : Je pige pas la notion d'alias !

Ne prends pas ma réponse pour argent comptant. J'espère que d'autres personnes pourront intervenir là-dessus pour te donner leur avis.
Pour info, et j'ai été étonné la première fois, dans mon université il y a une base LDAP avec uniquement 3 types d'OU pour ce qui est des personnes : etudiants, personnels et exterieurs. Avec des attributs pertinents, ça te permet de filtrer un maximum et c'est plus simple je pense. Imagine dans ton cas qu'un personnel change de pôle ou de service (les mutations c'est courant), tu n'as qu'à changer la valeur des attributs qui vont bien ...

mazou

Re : LDAP : Je pige pas la notion d'alias !

Le pb des attributs c que, par exemple pour les commissions, je peux en avoir plusieurs. Du coup le nommage de l'attribut est je trouve souvent délicat.
Par exemple : commission appel d'offre, l'attribut serait pas exemple ComAppelOffres. Je ne sais pas si c très parlant.

clarky

Re : LDAP : Je pige pas la notion d'alias !

Excuse-moi, j'ai peut-être pas trop bien compris : c'est pas mieux de créer un seul attribut commission auquel tu pourras donner plusieurs valeurs (dont AppelOffres) ?

mazou

Re : LDAP : Je pige pas la notion d'alias !

Non c surement pas toi... Mais plutôt moi qui ai mal compris !
Peux tu être plus explicite ? Un exemple ?
Tu veux séparer les valeurs par une virgule par exemple ?

clarky

Re : LDAP : Je pige pas la notion d'alias !

Je cite http://www.commentcamarche.net/internet/ldap.php3
Il est possible de définir plusieurs valeurs pour un attribut en répétant la chaîne nom:valeur sur des lignes séparées
Excuse-moi si je suis pas plus explicite (tu trouveras des docs qui le seront je pense) mais je n'ai pas ce cas dans ma base LDAP.

mazou

Re : LDAP : Je pige pas la notion d'alias !

Merci clarky
Il est vrai que je lis trop souvent les docs en diagonale !
Pour les commissions je pense en effet que c'est une bonne solution, bien que se soit moins clair que d'avoir 1 attribut par commission.

Par contre pour le personnel je suis pas sûr.
En effet quand une personne fait partie de plusieurs pôles et donc de plusieurs services, je ne vois pas avec cette méthode, comment attacher les services aux pôles.

Dernière modification par mazou (Le 08/03/2007, à 16:31)

clarky

Re : LDAP : Je pige pas la notion d'alias !

pourquoi veux-tu attacher les services aux pôles ? Si je reprends ton schéma, quand une personne est rattachée au service2, elle est obligatoirement rattachée au pôle2.
Peut-être faudrait-il que tu dégage le niveau "poles" et même "services"
tu crées juste :
                      o
               collectivite       
            /                \         \
           ou              ou           ou
     Personnel           Elus      Exterieurs

et tu renseignes les bons attributs pour chaque personne.

Je prends un exemple (en bois) : un informaticien réseau que tu voulais mettre définir dans l'arbre suivant :
o=collectivite, ou=Personnel, ou=Informatique, ou=Reseau
je te propose de le mettre dans o=collectivite, ou=Personnel avec un attribut Service=Reseau.
Si il appartient à Reseau, tu sais qu'il sera obligatoirement en informatique. Si éventuellement tu veux simplifier tes recherches dans la base, rien ne t'interdit non plus de rajouter Pole=Informatique

J'insiste, mais je ne détiens pas la vérité : si une tierce personne pouvait donner un avis, ce serait chouette.

mazou

Re : LDAP : Je pige pas la notion d'alias !

Mouais... Je sais pas... J'hésite...
Un des avantages d'avoir des branches c'est que je pourrais mieux filtrer selon les droits. Par exemple les personnes du pôle 1 ne voient que leur branche.

JoelS

Re : LDAP : Je pige pas la notion d'alias !

Mouais... Je sais pas... J'hésite...
Un des avantages d'avoir des branches c'est que je pourrais mieux filtrer selon les droits. Par exemple les personnes du pôle 1 ne voient que leur branche.

Tu peux filtrer avec des valeurs d'attributs.

Il y a pleins d'avantages à faire un arbre à plat en LDAP et peu d'inconvénient.

Bon j'ai pas le temps de détailler ce soir mais si ça t'intéresse, je donnerai plus d'arguments un autre jour.

mazou

Re : LDAP : Je pige pas la notion d'alias !

Oui JoelS ça m'intéresse !

JoelS

Re : LDAP : Je pige pas la notion d'alias !

Bon, alors, le problème de base est que bien souvent, on associe un arbre LDAP à son organisation (entreprise, association, administration) et on cherche à calquer l'arbre à cette organisation. Comme ça c'est plus simple pour s'y retrouver. C'est pas faux au départ, mais c'est juste oublier que l'organisation en question évolue, en général infiniment plus vite qu'on l'imagine, et que bien souvent, une fois l'arbre défini (on appelle ça un DIT - Directory Information Tree) il est trés difficile, voir quasiment impossible, de le modifier. On va alors mettre de plus en plus de verrues pour s'en sortir.

Il faut reprendre les choses à la base et commencer par voir comment se comporte LDAP.

LDAP est très performant pour faire des recherches, nettement moins pour faire des modifications d'attributs, pas du tout pour faire des modifications d'entrées (renommage et déplacement dans l'arbre, ...)

Un arbre LDAP permet de se placer au bon endroit dans la hiérarchie  de l'arbre pour limiter l'espace des recherches, mais d'un autre côté, les recherches sur des attributs indexés sont suffisament efficaces même sur de grand nombre d'entrées. En tout cas, dans l'immense majorité des cas, c'est les performances du rendu de la recherche par le client, ou carrément le réseau, qui pénalisera une recherche LDAP, pas le nombre d'entrées potentiellement parcourues par le serveur (mettons en dessous de la dizaine/centaine de milliers d'entrées, suivant la puissance du serveur matériel).

Un arbre LDAP permet de mettre des ACLs sur des portions d'arbres, facilitant la sécurité sur des grands annuaires. Mais d'un autre côté, on peut mettre des ACLs sur des valeurs/présences d'attributs, sans pénaliser LDAP la non plus.

Donc d'un côté découper un DIT en pleins de branches est intéressant si tu manipules de très grands annuaires, mais ça va figer ton DIT et rapidement te géner; d'un autre côté, LDAP est de toute façon suffisament performant pour effectuer des recherches mêmes complexes sur de grandes portions d'arbre.

A mon avis, ça fait déjà une bonne raison pour ne pas s'embêter à vouloir absolument découper au plus près de se qu'on voit dans son organisation. Par exemple, une approche classique consiste à faire un DIT qui reprend l'organigramme de son organisation (voir ton prestataire conseilleur-mais-pas-payeur), et a affecter à chaque noeud de celui-ci les personnes. Bien. Mais ça n'apporte quasiment rien en terme de gain de performance, ni de sécurité, par rapport à créer une branche people et à mettre tout le personnel dedans. Ensuite on utilise un attribut pour lié chaque personne à son service de rattachement. Avantage: quand la personne change de service, on change un attribut, pas son noeud de rattachement dans l'arbre (plus cher et risqué). On peut si c'est nécessaire gérer N services de rattachement (impossible dans le premier cas). Et si un service change de nom, on n'est pas obliger de changer tous les noeuds de rattachement de toutes les personnes dans le sous-arbres: on modifie juste un attribut. Si un responsable crée un nouveau concept d'unité de rattachement, n'importe quoi, la voie hiérarchique de commandement de crise par exemple, et bien hop, on rajoute un attribut sans modifier le DIT

Dans ton cas, on peut alors imaginer qu'il te faut une branche personnel, une branche service, une branche pole, une branche extérieur, une branche elus, une branche collectivité. Bon, la on voit clairement qu'on traite d'un côté des gens, et de l'autre des organisations. Donc tu pourrait même faire:

dc=my,dc=company,dc=com
 |
 ---ou=people
 |    |
 |    ---ou=personnel
 |    |
 |    ---ou=elu
 |    |
 |    ---ou=exterieur
 |
 ---ou=organisation
       |
       ---ou=service
       |
       ---ou=pole
       |
       ---ou=collectivite

Tu peut même pousser le vice plus loin en mettant tous les services à plat dans l'ou=service (même chose pour ou=pole et pour ou=collectivite) et en recréant la hiérarchie par le jeu d'attributs, par exemple:

ou=service
 |
 ---uid=service1
 |     name=Le service qui va bien
 |     organigramme=/
 |
 ---uid=service2
 |     name=Le service qui va moins bien
 |     organigramme=/service1
 |
---uid=service13
 |     name=Le service qui marche pas mal
 |     organigramme=/service1
 |
--uid=service57
 |     name=Le service qui marche pas mal
 |     organigramme=/service2
 |
--uid=service143
 |     name=Le service qui se comporte comme il faut
 |     organigramme=/service2/service57
 ....
ou=personnel
 |
 ---uid=matricule34620
 |    nom=Jean Dupond
 |    service=service143
 |    service=service2
...

Avec ça tu peut recréer facilement l'organigramme de ton organisation, mais aussi mettre des restrictions sur l'appartenance ou pas à un service,...,tout en facilitant les réorganisations de ton DIT et les évolutions du contenu (genre Jean Dupond ne travaille plus pour le service2, pis d'ailleurs il faut le renommer en Jean Dupont :-))

Bon ne prend pas ça pour argent comptant quand même, un DIT se travaille par rapport à ce que tu veut en faire.

Et évite les outils qui t'impose un DIT particulier (qui a dit ADS ?), la seule chose qu'un outil doit faire, c'est utiliser les attributs des entrées.

Bonne chance....

mazou

Re : LDAP : Je pige pas la notion d'alias !

Merci JoelS pour ton intervention.

Il reste une chose que je ne comprends pas.
Dans ton dernier exemple, tu ne mets pas de "ou" pour les services ? Tu les déclarent comme une personne ?

Merci

JoelS

Re : LDAP : Je pige pas la notion d'alias !

Il reste une chose que je ne comprends pas.
Dans ton dernier exemple, tu ne mets pas de "ou" pour les services ? Tu les déclarent comme une personne ?

Non. Bon, j'ai conscience que ça fais un peu court comme réponse, donc je m'étale.

Je reprend quelques bases en LDAP. Je ne connais pas ton niveau, donc excuses moi si c'est évident pour toi, mais c'est pas toujours le cas.

Un annuaire LDAP stoke les données sous forme d'un paquet de couples (attribut=valeur) au sein d'une entrée nommée de manière unique. L'organisation générale est un arbre N-aire. Il n'y a pas de notion de noeud ou de feuille en LDAP, toutes les entrées sont potentiellement les 2, c'est la manière d'organiser le contenu qui crée des noeuds et des feuilles de l'arbre. Je parlerais donc d'entrées.

Le nommage d'une entrée se fait en concatenant le nom de son entrée-mère avec obligatoirement un des couples de l'entrée. Le nom résultant, le DN (Distinguished Name), est unique puisqu'il décrit le chemin complet d'accès depuis l'entrée de plus haut niveau. Le couple utilisé dans le DN, donc chaque couple à chaque niveau de l'arbre, est n'importe lequel. On l'appelle le Relative Distinguished Name (RDN). Aucune restriction n'est imposée, sauf peut être pour l'attribut objectClass mais j'en suis même pas sûr. Il n'est même pas nécessaire que l'attribut utilisé soit mono-valué. Tu peux avoir une entrée contenant l'attribut ou en de multiples exemplaires, avec des valeurs différentes bien sûr, et utiliser un de ceux-ci. Tu peux au sein d'un même sous-arbre de profondeur 1 (toutes les entrées directement filles d'une entrée quelconque) utiliser pour chaque entrée-fille un attribut différent. A éviter en général pour des raisons de facilité d'organisation et de traitement, mais pour certains niveaux et certains cas c'est très utile. A noter qu'un DN n'est pas une chaine de caractéres, et donc que tu ne peux pas faire des comparaisons/recherches partielles dessus via LDAP.

Une entrée n'est pas déclarée de tel ou tel type. Pour qu'une entrée puisse utiliser un attribut, il faut ajouter à l'entrée l'attribut objectClass avec comme valeur le nom d'une classe d'objet déclarée et connue par le serveur d'annuaire utilisé. Ca c'est si le contrôle de schéma est actif, ce qui doit être toujours le cas. Une définition de classe d'objet va déclarer quels sont les attributs obligatoires pour cette classe et quels sont les attributs facultatifs. En général il y a trés peu d'attributs obligatoires et pléthore d'attributs facultatifs. Un attribut est défini indépendamment d'une classe d'objet, et la définition fourni le type d'attribut, ainsi que les  fonctions de comparaison possibles. Il en résulte que si tu as besoin d'un attribut pour une entrée, tu doit d'abord connaître une objectClass qui déclare cet attribut, ajouter cette valeur d'objectClass à ton entrée puis ajouter l'attribut en question. Pour connaitre les définitions d'attributs et de classes d'objet déjà normalisées (la norme LDAP défini aussi un processus de normalisation/déclaration de nouveaux éléments du schéma), il existe un site Web te permettant de browser ces définitions.

Il résulte de tout ceci que en gros tu fais comme tu veux! Donc dans mon exemple qui se veut simplement ... un exemple simplifié, j'ai décidé de donner une valeur unique d'identifiant à toutes mes entrées, d'utiliser l'attribut uid pour celles qui représentent un objet du monde réel et l'attribut ou pour celles qui me permettent d'organiser l'arbrtre, et d'utiliser le couple résultant comme RDN de l'entrée. Ca ne fait pas des entrées service des entrées de type personnel pour autant, d'autant plus que l'attribut uid est probablement défini dans plusieurs objectClass, uid voulant dire Unique IDentifier, et non pas User IDentifier. De même, ou veut dire Organizational Unit, et cela peut être utilisé comme des unités organisationnelles au sein de ton annuaire, ou bien comme des unités organisationnelles au sein de ton organisation, voir les 2 en même temps. Tu choisis.

Voila. C'était pas trop long ?

mazou

Re : LDAP : Je pige pas la notion d'alias !

Long ? A lire non... A écrire sûrement plus ! Mais c'est très utile.
Comme tu peux le remarquer je suis newbie dans ce domaine et il est vrai que je rencontre pas mal de difficultés à mettre en place ce p****n de LDAP !

J'ai regardé des dizaines et des dizaines de sites web, mais je n'arrive pas à avoir une information complète.

Peux tu illustrer tes explications d'exemples ? Car ça serait beaucoup plus parlant pour moi.

clarky

Re : LDAP : Je pige pas la notion d'alias !

Ouaou ! Super pédago JoelS :):) Merci d'avoir pris le temps d'écrire ces réponses très claires, c'est très sympa.

JoelS

Re : LDAP : Je pige pas la notion d'alias !

@clarky: merci.

@mazou: c'est difficile de mettre des exemples comme ça, car comme je l'ai écris plus haut, le DIT idéal ne l'ai vraiment que dans un contexte donné. Par rapport à ce que j'ai écris, est-ce que tu as d'autres questions ?

mazou

Re : LDAP : Je pige pas la notion d'alias !

Pas pour l'instant.

Merci JoelS