A chaque fois que je me motive pour m'y mettre, je finis par abandonner. J'ai toujours pas compris le concept.
Je ne sais pas dans quelle mesure ça c’est amélioré, mais quand je me suis mis à LDAP, il y a presque quinze ans (ça ne me rajeunit pas...), il y avait d’un côté des documentations qui l’abordaient d’un point de vue complètement théorique et souvent abscons, et de l’autre des utilitaires pour « migrer » par exemple d’un annuaire NIS en reproduisant totalement à l’identique son contenu (des tables séparées, pas forcément cohérentes — par exemple un mail nom.prenom qui traîne dans la table des alias pour un login supprimé).
Pas très utile pour faire un annuaire LDAP cohérent mais qui rend le service attendu.
Accessoirement, à l’époque, les applications n’étaient pas forcément documentées par rapport aux attributs LDAP qu’elles utilisaient (quand il n’y avait pas carrément une documentation erronée)...
Par exemple ces fameux schéma. Je sais que je peux puiser dans une base existante de schémas "pas déconnants". Mais ensuite, comment savoir, pour chaque appli qui dit "LDAP compatible" si mon schéma finalement choisi sera le bon ?
Pour ça, j’ai une approche inverse :
– déterminer ce qu’utilisent les applications comme attributs, selon leur documentation si elle est correcte, sinon carrément en activant la trace du serveur LDAP et en les testant pour voir ce qu’elles font comme requêtes ;
– rechercher dans les schémas quelles sont les classes qui fournissent les attributs en question et choisir les plus cohérentes par rapport au besoin ;
– utiliser les schéma qui les contiennent.
Cela dit, certaines applications font des requêtes selon la classe des objets (on utilise plutôt le terme « entrée » selon la nomenclature LDAP, mais ça va peut-être être plus abordable si je m’en tiens à « objet ») ou ont carrément un schéma dédié. Dans ce cas, le choix de la classe et du schéma est sans ambiguïté.
Il faut voir qu’un objet peut appartenir à plusieurs classes, par exemple person pour une personne, inetOrgPerson pour son adresse mail (entre autres), posixAccount pour son compte Unix.
On peut aussi surclasser ou déclasser des objets existants. Par exemple, si on veut créer un compte Unix pour une personne qui n’en avait pas, et donc que l’objet qui la représente ne faisait pas partie de la classe posixAccount, on peut lui ajouter cette classe et les attributs nécessaires pour le compte Unix.
L’intérêt de rassembler dans un seul objet tous les attributs concernant une personne (ou toute autre entité du monde réel), c’est la cohérence. Si une personne part, en supprimant son objet, on supprime à la fois son alias mail, son compte Unix, etc. (bon, une organisation officielle préférera probablement garder trace de ses anciens membres et déplacer les objets qui les représentent dans une branche séparée).
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # LDAP, mon approche
Posté par Arthur Accroc . En réponse à la dépêche Sortie de l’outil ldap-schema-manager. Évalué à 3.
Je ne sais pas dans quelle mesure ça c’est amélioré, mais quand je me suis mis à LDAP, il y a presque quinze ans (ça ne me rajeunit pas...), il y avait d’un côté des documentations qui l’abordaient d’un point de vue complètement théorique et souvent abscons, et de l’autre des utilitaires pour « migrer » par exemple d’un annuaire NIS en reproduisant totalement à l’identique son contenu (des tables séparées, pas forcément cohérentes — par exemple un mail nom.prenom qui traîne dans la table des alias pour un login supprimé).
Pas très utile pour faire un annuaire LDAP cohérent mais qui rend le service attendu.
Accessoirement, à l’époque, les applications n’étaient pas forcément documentées par rapport aux attributs LDAP qu’elles utilisaient (quand il n’y avait pas carrément une documentation erronée)...
Pour ça, j’ai une approche inverse :
– déterminer ce qu’utilisent les applications comme attributs, selon leur documentation si elle est correcte, sinon carrément en activant la trace du serveur LDAP et en les testant pour voir ce qu’elles font comme requêtes ;
– rechercher dans les schémas quelles sont les classes qui fournissent les attributs en question et choisir les plus cohérentes par rapport au besoin ;
– utiliser les schéma qui les contiennent.
Cela dit, certaines applications font des requêtes selon la classe des objets (on utilise plutôt le terme « entrée » selon la nomenclature LDAP, mais ça va peut-être être plus abordable si je m’en tiens à « objet ») ou ont carrément un schéma dédié. Dans ce cas, le choix de la classe et du schéma est sans ambiguïté.
Il faut voir qu’un objet peut appartenir à plusieurs classes, par exemple person pour une personne, inetOrgPerson pour son adresse mail (entre autres), posixAccount pour son compte Unix.
On peut aussi surclasser ou déclasser des objets existants. Par exemple, si on veut créer un compte Unix pour une personne qui n’en avait pas, et donc que l’objet qui la représente ne faisait pas partie de la classe posixAccount, on peut lui ajouter cette classe et les attributs nécessaires pour le compte Unix.
L’intérêt de rassembler dans un seul objet tous les attributs concernant une personne (ou toute autre entité du monde réel), c’est la cohérence. Si une personne part, en supprimant son objet, on supprime à la fois son alias mail, son compte Unix, etc. (bon, une organisation officielle préférera probablement garder trace de ses anciens membres et déplacer les objets qui les représentent dans une branche séparée).
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone