Sommaire
Il y a quelques mois, j'avais, sur un wiki, rédigé un tutoriel sur les bases LDAP. Souvent laissées de côté au profit de SGBDR (système de gestion de base de données relationnelles), considérés comme plus classiques (MySQL, PostgreSQL, …), les bases LDAP peuvent parfois s'avérer pratiques.
Je me propose donc de faire une présentation de ce type de bases de données ici. Je ne cherche pas à inciter les gens à s'en servir, j'utilise moi-même bien plus souvent PostgreSQL, mais lorsqu'on administre plusieurs machines sous Debian (par exemple), on peut parfois se rendre compte que LDAP peut être très utile.
Volontairement, je vais tenter de ne pas être trop technique ici, je parlerai de technique dans un autre journal.
LDAP, c'est quoi ?
LDAP est un acronyme signifiant Lightweight Directory Access Protocol. Il s'agit d'un protocole d'accès et de gestion d'annuaires (distants ou non). Pragmatiquement, c'est un système de base de données sous forme d'arbre. Chaque entrée de la base est un nœud, possédant des attributs (qui définissent ses caractéristiques), éventuellement des nœuds enfants, et souvent, un nœud parent (seul le nœud racine n'a pas de parent). LDAP est hiérarchisé, cela signifie qu'un nœud ne peut pas avoir plus d'un parent (on ne peut y accéder depuis la racine que par un chemin).
Contrairement à ce que l'on peut voir dans un SGBDR, un attribut dans un nœud peut avoir zéro, une, ou plusieurs valeurs (qui n'a pas essayé de trouver une solution propre pour qu'un compte utilisateur dans une base type SQL puisse avoir plusieurs adresses mail par exemple).
La structure hiérarchisée de LDAP impose que chaque nœud ait un identifiant unique, appelé DN (Distinguished Name), qui correspond à un chemin d'accès. Cet identifiant est en fait la concaténation de l'identifiant du nœud parent avec un identifiant propre au nœud courant. Voici un exemple de (toute petite) base LDAP, où l'on représente juste les nœuds.
Par exemple, ici, le nœud me concernant a pour DN uid=peb,ou=users,dc=localdomain. Il peut contenir des informations, mais elles ne seront pas visibles ici.
Les informations que peuvent contenir un nœud dépend du type d'objet que celui-ci doit représenter. Par exemple, un nœud peut représenter un utilisateur système, un groupe posix, une entreprise, une catégorie (dans un forum, par exemple), une machine. En fonction de cela, on voudra qu'il contienne des informations adaptées (adresse IP, nom, prénom, mot de passe, adresse MAC, …).
À ce titre, une base LDAP intègre dans sa configuration des schémas. La plupart sont classiques et livrés tels quels. Souvent, quand on utilise une base LDAP, on ajoutera à ces schémas un ou plusieurs schémas faits maison, qui définiront les objets dont on a besoin, en plus des types d'attributs et d'objets déjà existants.
Là où j'utilise LDAP, on a un schéma pour représenter les adhérents de notre association, leurs machines, etc… Voici un exemple du contenu d'un nœud.
dn: aid=3775,ou=data,dc=crans,dc=org
objectClass: adherent
objectClass: cransAccount
objectClass: posixAccount
objectClass: shadowAccount
aid: 3775
charteMA: TRUE
chbre: 404
cn: PEB
droits: RTech
droits: Bureau
gecos: PEB,,,
gidNumber: 100
homeDirectory: peb
loginShell: /bin/zsh
mail: peb@example.com
mailAlias: taiste@example.com
nom: B
prenom: PE
uid: peb
uidNumber: 2573
userPassword: {SSHA}xwEP3a1xdO003bBeKfykI4gMbeGiT3kV
On a donc des couples attributs/valeurs, stockés dans un nœud, qui le caractérisent. Certains, tels dn et objectClass, se trouvent dans tout nœud. D'autres sont propres au type de nœud (défini par l'attribut objectClass).
LDAP, pourquoi ?
Outre le fait que certaines choses se représentent mieux sous forme d'arbre que dans une base de données relationnelle, il y a des raisons pratiques d'utiliser LDAP sous Debian : la compatibilité avec les autres logiciels.
Imaginons, vous administrez une vingtaine de machines sous Debian, et vous êtes quatre ou cinq administrateurs, plutôt que de créer des utilisateurs locaux, vous pourriez par exemple installer un serveur LDAP sur une de ces machines, le configurer, créer des utilisateurs dedans, et installer le paquet nslcd sur les autres machines. Celles-ci iraient alors demander au serveur LDAP les informations de connexion pour les utilisateurs qu'elles ne connaissent pas, et feraient le nécessaire pour qu'ils puissent se connecter.
Ainsi, plus besoin de créer vingt fois le même utilisateurs, plus besoin de changer son mot de passe partout, etc. Seul défaut : si le serveur LDAP est dans les choux, plus personne ne peut se connecter avec son compte LDAP sur les machines. Il faut soit prévoir des utilisateurs locaux, soit utiliser le compte root (lui doit toujours être local).
PAM et LDAP s'interfacent bien, donc (PAM et PostgreSQL aussi, mais le module développé à cet effet avait tendance à crasher, sous squeeze…), mais ce n'est pas tout !
LDAP et postfix s'interfacent également bien (donc votre MX peut aller lire dans une (ou plusieurs) bases LDAP si un utilisateur existe, et lui délivrer des messages), LDAP et dovecot (POP/IMAP), LDAP et django s'interfacent bien, LDAP et Moinmoin s'interfacent bien, SOGo/Roundcube/Horde et LDAP s'interfacent bien, en fait, dans l'ensemble, la plupart des services qu'on peut souhaiter avoir et LDAP s'interfacent bien. Pourquoi s'en priver ?
LDAP, c'est difficile ?
L'approche de LDAP nécessite un peu plus de doigté que l'approche de PostgreSQL ou MySQL. Déjà, comme pour ceux-ci, il y a une syntaxe à apprendre : la syntaxe LDIF (pour LDAP Data Interchange Format), mais la configuration est plus technique, elle nécessite dans un premier temps d'écrire un fichier de configuration puis de l'incorporer avec une commande dans la base de configuration (la configuration des diverses bases LDAP sur un serveur est stockée dans… une base LDAP), après avoir choisi les schémas qui vous intéressent.
Une fois la configuration faite, il faut créer une première base de données pour y stocker des données. Pour cela, il faut encore faire de la configuation, choisir le type de base de donnée (hdb, bdb, …). Il faut la peupler, sachant que par défaut, il n'existe pas une command-line spécifique comme psql ou mysql. On peut installer des outils (ldap-tools, shelldap, etc) pour faciliter la navigation. Essentiellement, la difficulté réside dans le fait que l'approche est différente des SGBD habituels, et dans la légèreté du protocole qui oblige à faire pas mal de choses à la main.
Il faut savoir que la plupart des langages de programmation comportent une librairie pour communiquer avec les bases LDAP, cela diminue certaines difficultés que l'on pourrait croiser.
LDAP n'est donc pas extrêmement difficile en soi, mais impose de s'adapter et de découvrir de nouvelles choses. Je proposerai prochainement une approche plus technique, entres autres comment installer et configurer un serveur LDAP. (paquet slapd sous debian)
Un peu de doc
[en] OpenLDAP, le site du projet OpenLDAP.
[en] Zytrax, un très bon site avec pas mal d'infos.
[en] Ubuntu propose également une doc.
Ce dernier lien a d'ailleurs donné :
[fr] Doc LDAP sur Ubuntu
Bonne lecture !
# Un annuaire en deux temps, trois mouvements
Posté par Benoît Bailleux (Mastodon) . Évalué à 4.
Ok, je ne saurais dire combien un annuaire LDAP est utile/pratique/performant quand il est bien structuré et utilisé à bon escient(*).
Et justement, pour ceux qui veulent faire un galop d'essai tout en restant hype, je tiens à signaler quelque chose que j'ai découvert il y a juste deux jours : ldapjs.org.
C'est un couple client et serveur LDAP implémenté dans node.js. Au delà de l'exercice de style, c'est un moyen original de se familiariser avec LDAP, et je ne doute pas qu'il puisse avoir des utilisations judicieuses dans certains cas.
(*) j'ai vu trop souvent des gens utiliser n'importe comment un annuaire LDAP avec de fausses bonnes raisons, et finir par s'en mordre les doigts en accusant LDAP plutôt qu'en se remettant en question…
[^] # Re: Un annuaire en deux temps, trois mouvements
Posté par Kaane . Évalué à 5.
Et justement, pour ceux qui veulent faire un galop d'essai tout en restant hype, je tiens à signaler quelque chose que j'ai découvert il y a juste deux jours : ldapjs.org.
Attention ! Contrairement à ce que son nom peut laisser penser, ldapjs n'est pas un annuaire LDAP. C'est une base de données hiérarchique compatible avec une grande partie de l'API LDAPv3.
Mais on peut tout à fait faire du "schema-less" en LDAP JS. Ce qui peut s'avérer très pratique si on ne veut pas s'encombrer d'un schema pour faire une base NO-SQL hiérarchique, mais aussi très très casse gueule si on veut faire du LDAP avec et que l'on débute.
A bon entendeur…
[^] # Re: Un annuaire en deux temps, trois mouvements
Posté par PEB (site web personnel) . Évalué à 3.
J'avoue n'avoir jamais testé LDAP JS, je regarderai quand j'aurai un peu de temps !
Merci à vous deux pour les infos.
# Mongueur
Posté par barmic . Évalué à 8.
Je tiens à signaler l'excellente série d'articles des mongueurs de perl parut sur GLMF sur le sujet :
Personnellement, je trouve dommage qu'il ne soit pas fait mention des bases LDAP lors des principales formations en informatique. LDAP est plus simple qu'un SGBDR (mais a un peu moins de flexibilité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
O.O moins flexible ??? Il faudra que tu m'expliques ? Honnêtement il est difficile de faire plus flexible que les annuaires LDAP, hormis des bases "clé valeur" sans schéma.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par barmic . Évalué à 2.
Je me suis probablement mal exprimé. Un SGBDR c'est un choix par défaut, tu sais que ce que tu veut faire sera certainement possible même si ce sera pénible.
Mais de ce que j'en sais tu peut faire faire énormément plus de chose à une base relationnel qu'à un LDAP. Je pense particulièrement aux agrégations, aux requêtes OLAP, à la gestion de l'intégrité (j'entends par là des règles de gestions métier qui peuvent prendre en paramètres plusieurs champs),… Plus globalement j'ai l'impression qu'on peut bien moins contraindre un schemas LDAP qu'une tables SQL (même si on peut faire des choses très sympa comme les énumération en LDAP). AMHA SQL permet de faire à peut prêt tout ce que l'on peut imaginer faire avec des données alors que LDAP va nécessité pour une partie de ces traitements de les faire dans le code de l'appli client (mais je peux me tromper).
D'un point de vu configuration un serveur LDAP est largement optimisé pour faire énormément des lecture et assez peu (en relatif) d'écriture. C'est en partie grâce à ça qu'il est plus simple de faire de la réplication avec.
Je ne cherche pas à dire que l'un est meilleur que l'autre, juste qu'ils ont chacun leur avantages.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mongueur
Posté par PEB (site web personnel) . Évalué à 2.
C'est vrai qu'au niveau des requêtes, LDAP est moins fourni, l'opposition filtre / requêtes dans un SGBDR est incontestablement emportée par les seconds.
Après, pour les contraintes au niveau du schéma, LDAP propose des syntaxes, qui sont des règles qui semblent passives, tout comme les règles de matching. Du coup, pas vraiment de contrainte, certes, mais ces informations peuvent être vues comme des directives.
Les contraintes seront du coup reportées au binding, un avantage de cela est que tu n'as pas besoin de modifier les données dans la base pour changer les contraintes (en gros, tu risques pas de péter ta base, seulement ton binding).
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Je suis pas encore convaincu de ça. Dès que tu commences à vouloir croiser beaucoup de données différentes dans un SGBDR tu galères. Un LDAP ça reste une seule requête et peu importe le nombre de données différentes que tu croises.
Tu peux toujours créé un objet extensible, soit un objet qui peut contenir tous les attributs connus de ton annuaire. Mais c'est moins performant.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par MCMic (site web personnel) . Évalué à 6.
Tu peux préciser?
J'ai dû rater quelque chose mais j'ai toujours vu des requêtes séparées pour croiser les informations.
Typiquement si tu as un nœud qui représente un groupe qui a des membres sous la forme de dn dans un champ memberdn et que ces membres ont dans leur nœud un email dans le champ mail, est-ce que tu es capable de croiser les infos pour avoir la liste des mails des membres d'un groupe en une seule requête?
Ça et le UPDATE WHERE de SQL sont les choses qui me manque en LDAP pour pas me retrouver à faire pleins de requêtes pour des opérations simples.
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Ton exemple est très pertinent. Ça dépend comment tu as construit ton arbre.
Tu peux l'avoir fait comme ça :
Et des personnes :
(&(|(objectclass=Personne)(objectclass=Groupe))(NomGroupe=groupe1))(&(objectclass=Personne)(NomGroupe=groupe1))(&(objectclass=Groupe)(NomGroupe=groupe1))Du coups tu peux mettre des ACL de manière à ce que la personne authentifiée ne puisse récupérer que les groupes dont elle est membre (et ainsi cacher l'existence du groupe "Partouze entre collègue" aux personnes non-initiées).
Il existe d'autre méthode, comme l'utilisation des références (qui pourrait être très intéressant dans un cas d'annuaire décentralisé), pour faire ce genre de choses.
Dans ton cas particulier j'utiliserais quelque chose comme les groupes dynamiques ou les listes dynamiques afin que le serveur me fasse le travail.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par MCMic (site web personnel) . Évalué à 7.
Oui, le soucis c'est que je pensais à un cas où les groupes ont la liste de leurs membres et pas l'inverse.
Typiquement le cas avec l'objectClass posixGroup qui sert pour les groupes UNIX, ou groupOfNames : http://www.zytrax.com/books/ldap/ape/core-schema.html#groupofnames
Dans un cas on a les dn, dans l'autre les uid, mais dans les deux cas il faut faire plusieurs requêtes pour obtenir des infos détaillées sur les utilisateurs, là où en SQL on s'en sortirai par jointure en une seule requête.
C'est pour ça que ta remarque m'étonnait, «peu importe le nombre de données différentes que tu croises.», parce que justement j'ai l'impression que rien n'a été prévu en LDAP pour croiser les données, il faut faire des requêtes séparées là où le langage SQL est prévu pour ça.
Pour en revenir à ton exemple, ça met juste le problème dans l'autre sens : maintenant c'est obtenir tous les 'NumeroGroupe' associés à une personne qui ne peut plus se faire en une seule requête.
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Dans ce cas là tu utilises, par exemple, des overlays sur OpenLDAP. C'est une autre approche que les SGBDR, en fait au lieu de donner le pouvoir aux requêtes, tu donnes le pouvoir au serveur. Et, pour moi, ça a plus de sens, la généricité des bases de données est plus une légende qu'une réalité, petit à petit tu personnalises ta base de données pour ton application si elle grandit.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Pour tout ce qui est contraintes, tu dois déjà pouvoir faire pas mal de choses avec des overlays comme : constraint, refint, rwm, unique (et d’autres).
Pour ce qui est de l’optimisation et écriture, ça peut dépendre aussi du backend et de sa configuration, mais je vois assez peu de cas d’utilisation d’une base de données où on écrit plus qu’on ne lit.
[^] # Re: Mongueur
Posté par barmic . Évalué à 3.
Et tu perd la compatibilité (c'est pas forcément vital mais c'est dommage).
Sans aller jusqu'à avoir beaucoup plus d'écriture que de lecture, il y a des fois où tu en a plus ou moins autant des deux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Non, le protocole est standard. Par contre dans le monde des SGBDR, SQL c'est standard mais faut pas vouloir changer la base de données derrières si tu n'utilises pas que SELECT, INSERT, DELETE, UPDATE. Bien que les différences s'estompent, ça reste, je trouve, très casse gueule (et dieu sait comme je maîtrise peu SQL l'ayant abandonné depuis ma rencontre avec LDAP).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
LDAP est un protocole. Après les serveurs d'annuaire parlant le LDAP sont pléthores (OpenLDAP, ActiveDirectory, Samba4, 389 Directory Server (Fedora), …). Le protocole LDAP permet de faire des requêtes genre "je veux tous les objets ayant le type X ou le type Y, ayant l'attribut Z présent, ayant l'attribut V = blabla ou V = blibli. Retournes-moi les attributs A, B et C de ces objets. Applique cette recherche sur les enfants directes de l'entrée E". Je crois que ce qui agrégation et OLAP c'est couvert par les méthodes de recherches. Ensuite les objets LDAP doivent avoir un schéma, mais peuvent avoir autant de schéma que l'on souhaite. Il suffit juste d'en ajouter. Et c'est pas un truc définitif. On créer un objet avec un schéma et six mois plus tard on rajoute un schéma et chaque objet, finalement, à son propre jeu de schéma. Bien entendu il y a les références vers des autres objets.
Et tout le côté orienté objet des schémas avec l'héritage (mais pas multiple) rend le tout très intéressant et les options des attributs, la multiplicité des attributs (un objet peut avoir 0 ou N attribut (le schéma peut forcer un attribut à être 0 ou 1)).
Après tu as encore des trucs comme les entrées ayant une durée de vie. La sécurité avec des règles comme "l'attribut X n'est accessible que si le niveau de sécurité est plus grand que Z (ce niveau correspondra à une recherche faites depuis une connexion TLS authentifiée client et serveur), … Après il y a bien entendu toute la partie d'extension du protocole et tellement d'autres choses …
Par contre c'est très, très mal utilisé en général. Tu prends déjà tous les codes php sont dramatiques : tu n'as pas de connexion persistante possible (donc les résultats paginés tu l'as dans l'os), il te manque l'accès à toute une partie du protocole (les extensions et j'ai proposé un patch), tu n'as pas accès à toutes les requêtes asynchrones et bon, ayant essayé de patcher php-ldap, le code du module me fait peur (et le corriger, j'ai passé pas mal de temps dessus et là j'ai plus le temps, mais il faudrait réécrire complètement parce 1) pas possible de garder les codes existants fonctionnelles 2) l'arrivée d'horreur comme ldap_control_paged_result_response qui normalement est juste une extension que l'on passe avec la requête ldap_search).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs (DN, TLS ou pas, …) alors que normalement c'est 1) requête DNS pour savoir où se trouve l'annuaire 2) requête sur le Root DSE de l'annuaire pour savoir ce qu'il a comme schéma, supporte comme sécurité, comme version de TLS, sa racine, ses extensions, … bref tout ce que tu souhaites savoir et 3) tu peux intégrer un nouveau schéma directement par une requête au bonne endroit (le bonne endroit étant donné par l'annuaire).
Avec un annuaire LDAP, tu te poses moins de question quant à la création de ta base de données. Alors qu'avec du relationnel tu vas te poser des questions sur "comment stocker", avec LDAP une fois que tu as répondu à "quoi stocker" tu as ta base prête. Il reste juste à écrire le schéma (ce que tu fais aussi sur une base relationnelle) et utiliser.
Et pour finir, LDAP est certe optimisé en lecture, mais concrètement les cas où tu as la lecture/écriture avec un ratio 1/1 sont rares. Généralement c'est plus proche du 90/10. Et quand tu regardes les performances du dernier né dans les backend de OpenLDAP et face à InnoDB (en gros le backend mdb de OpenLDAP atteint des performances proches de celle de Memcached et lecture/écriture et est même plus rapide en multi-thread car c'est un backend lockless.
Bon dans un système de type transaction comme les banques, une base relationnelle est la seule réponse valable (du moins pour stocker les transations).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Benoît Bailleux (Mastodon) . Évalué à 2.
Effectivement, et pas seulement techniquement (comme dans l'exemple de PHP que tu donnes). Il n'est pas rare que les concepts de LDAP soient mal compris, et que l'annuaire envisagé n'ait pas de sens à être implémenté en LDAP. J'ai en tête des exemples de gens disant « je doit implémenter un annuaire, je fais du LDAP », et créant un schéma de données fortement relationnel, avec des contraintes techniques totalement inadaptées (nombreuses écritures, par exemple). Au final, cela ne marche pas, bien entendu, et ils déclarent que LDAP, c'est mauvais, alors que ce sont eux, qui sont mauvais (oui, oui, carrément…).
Ça, c'est un truc formidable avec LDAP et sa normalisation poussée (même si cette forte normalisation lui est souvent reprochée). Toute cette auto-découverte qui permet normalement d'interroger n'importe quel annuaire LDAP avec n'importe quel client, c'est vraiment un avantage énorme, mais dont il est rarement question.
Le truc, c'est qu'effectivement les annuaires ont un champ d'utilisation plus étroit que les SGBD[R], et que, de ce fait, personne n'en utilise avant d'y être confronté brutalement. Là où tout le monde a déjà créé N bases de données (SQL etc.) et pense assez bien connaître le principe, les gens ayant un minimum d'expérience pour concevoir un annuaire LDAP sont assez rares. Et les concepts même ne sont habituellement pas maitrisés (ce n'est pas de leur faute, hein ?, c'est juste qu'ils n'ont pas eu l'occasion de savoir). D'où la transposition des principes des SGBD[R] qui conduisent fatalement à de mauvaises expériences.
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Je dirais même que le problème c'est que tu trouves des tonnes de documentations sur LDAP mais aucune apportant une approche idéologique sur comment structuré son annuaire. J'aimerais bien le faire, mais pour l'instant je suis pas encore certain de pouvoir le faire.
Là je suis pas convaincu, je penses que le champs peut être élargi très facilement et que, typiquement, un site comme celui-ci bénéficierait l'utilisation de LDAP comme backend. Et c'est juste un exemple.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par barmic . Évalué à 4.
Tu met quoi dans ton annuaire ? Tu met tout ou juste la gestion des utilisateur ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4. Dernière modification le 22 juin 2013 à 10:19.
L'idée serait de mettre un peu tout sauf les votes. Après la question, et ça il faudrait tester, c'est de savoir si c'est plus intéressant de mettre toutes les méta-données dans un LDAP et de garder le contenu dans des fichiers. À quelque part en mettant dans des fichiers, on sert presque des données statiques vu que le temps pour modifier un commentaire est limité et que les journaux/dépêches ne sont pas modifiables (enfin uniquement par les administrateurs/modérateurs). Globalement, au moment de la publication, le document original et sa version HTML sont stockés en simple fichier et les méta-données (dates, auteurs, tags, evt. résumé). Après j'ai pas étudié les détails du site mais un site qui est majoritairement lu (il y a quoi, 40'000 hits par heure) et finalement peut écrit pourrait avoir un intérêt d'utiliser LDAP.
En regardant vite fait le schéma de la base de données du site, finalement un commentaire, un journal, une dépêche, … ils ont tous des points en commun : auteur, titre, création, modification. Ça te fais le schéma structurel et ensuite les différences c'est un schéma auxiliaire que tu ajoutes à tes objets suivant qu'il s'agisse d'un commentaire, un journal, une dépêche ou autre (et les dates de créations et modifications, l'annuaire tiens déjà ces informations, donc tu as juste besoin de le demander et pas t'en occuper). Ensuite pour les commentaires, la structure en arbre de LDAP te permet de ne pas avoir à gérer ça puisque tu garde la même (la réponse à
comment=X,comment=Y,publication=Z,dc=linuxfr,dc=orgest forcémentcomment=W,comment=X,comment=Y,publication=Z,dc=linuxfr,dc=org)."It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par PEB (site web personnel) . Évalué à 1.
Je rejoins Étienne, tu peux configurer des acl différents pour chaque attributs, utiliser des raisonnements ensemblistes pour donner des droits à certains et pas d'autres, l'implémentation de SSL est un peu laborieuse mais robuste, et le format LDIF permet de faire extrêmement de choses. (j'en oublie)
Du coup, qu'est-ce qui te semble manquer à LDAP d'un point de vue flexibilité ?
[^] # Re: Mongueur
Posté par barmic . Évalué à 3.
Je n'ai pas dis qu'il manquait de quoi que ce soit, j'ai dis qu'il était moins flexible. Le prix de cette flexibilité des SGBDR c'est l'incompatibilité des serveurs entre eux, LDAP est génial aussi (surtout ?) parce que tu n'a pas à avoir 36 000 drivers pour accéder à chacun des serveur imaginable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mongueur
Posté par PEB (site web personnel) . Évalué à 1.
Je précise ce que je voulais dire. Ma question était plutôt : quelle flexibilité perd-on selon-toi de LDAP à PostgreSQL, par exemple ?
[^] # Re: Mongueur
Posté par barmic . Évalué à 3.
cf : https://linuxfr.org/users/peb--2/journaux/gestion-de-ldap-sous-debian-openldap#comment-1463261
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Disponibilité
Posté par claudex . Évalué à 7.
Bravo pour l'article. Je voudrais juste revenir sur le problème de l'accès au serveur pour se logger. Est-il possible de faire de la redondance avec plusieurs serveurs Ldap? J'ai aussi lu qu'il existait des caches Ldap pour PAM pour pouvoir se logger quand le serveur n'est pas accessible (parce qu'il a craché ou parce qu'on utilise un portable). Quelqu'un les a déjà testé ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Disponibilité
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
Il est en effet possible de gérer de la redondance au niveau serveur, en actif passif ou actif actif et réplication continue. si le nom de la racine de ton arbre LDAP correspond à un domaine que tu gère (dc=example,dc=fr => example.fr), il est même possible de référencer dans les configuration une URL ldap du style ldap:///dc%3dexample%2cdc%3dcom (encodage URL de dc=example,dc=fr), la plupart des clients font alors une résolution DNS sur l’enregistrement SRV _ldap._tcp.example.com.
Pour ce qui est du cache local pour les clients « mobiles », il y a plusieurs solutions possibles comme nscd, libpam-ccreds, libnss-cache…
[^] # Re: Disponibilité
Posté par claudex . Évalué à 6.
Merci pour les explications de redondance.
J'avais déjà vu qu'il existait des solutions, ma question était de savoir si quelqu'un les avait déjà testées pour avoir un retour d'expérience sur la mise en pratique en condition réelles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Disponibilité
Posté par Misc (site web personnel) . Évalué à 5.
On utilise sssd au taf pour kerberos/ldap sur 3000/4000 postes Linux, et ça marche (tm).
Le déploiement est pas spécialement compliqué, et je pense qu'il est dispo dans la plupart des distributions.
[^] # Re: Disponibilité
Posté par viking . Évalué à 2.
Chez nous, on utilise openldap en tant que PDC pour plusieurs centaines de comptes avec une réplication master/slave de l'annuaire vers la DMZ pour le webmail. La redondance fonctionne sans problème.
[^] # Re: Disponibilité
Posté par PEB (site web personnel) . Évalué à 4.
Merci !
Oui, LDAP propose un système de réplication (le serveur principal utilise un module syncprov, pour envoyer les modifications effectuées chez lui aux réplicats, qui utilisent syncrepl pour les reproduire). Ensuite, dans nslcd, tu peux préciser plusieurs serveurs LDAP, ils seront contactés dans l'ordre, si certains ont crashé, les autres seront toujours joignables.
Enfin, il existe un outil, nscd, qui fait de la mise en cache, pour un quart d'heure environ. Le paquet sous Debian s'appelle également nscd.
N'hésite pas si tu as d'autres questions.
# La suite
Posté par kadalka . Évalué à -3.
Merci
J'ai hâte de lire la suite. :P
J'espère ne pas être le seul.
[^] # Re: La suite
Posté par PEB (site web personnel) . Évalué à 2.
Merci.
Promis, la suite va viendre. :)
# FusionDirectory
Posté par MCMic (site web personnel) . Évalué à 6.
Plusieurs fois présenté sur linuxfr, il existe l'outil FusionDirectory qui permet de gérer tous les services qui s'interfacent avec LDAP.
Donc création et paramétrages des comptes utilisateurs, mail, samba, des groupes, attribution des IPs et noms de domaine aux machines, …
et tout ça sans savoir écrire un LDIF.
http://fusiondirectory.org/
[^] # Re: FusionDirectory
Posté par PEB (site web personnel) . Évalué à 1. Dernière modification le 20 juin 2013 à 13:18.
Yep, je connais, mais je n'utilise guère. (je n'ai jamais testé une interface entre FD et slapd)
Ce n'est pas par snobisme, ni parce que je ne trouve pas fusiondirectory bien, la raison est que j'ai voulu apprendre à utiliser les bases LDAP de fond en comble, pour pouvoir écrire des outils précis.
Du coup, j'ai pris l'habitude de bosser ainsi. Par ailleurs, on avait besoin d'un binding LDAP dans notre association, j'ai contribué à la rédaction de celui-ci (en python), et je préférais donc savoir de quoi je parlais avant de toucher au code. :)
Merci d'avoir fait cette précision, elle peut servir à d'autres !
[^] # Re: FusionDirectory et autre
Posté par viking . Évalué à 2.
Dans le genre Alien sur Debian, il existe MDS (Mandriva Directory Server). Je me suis amusé à l'installer sous Debian. Cela marche vraiment très bien par contre c'est plus limité que FD.
FD je l'avais utilisé du temps de GOSa mais le gros problème c'était l'ajout d'attribut supplémentaire de GOSa. On as donc finalement adopté MDS.
[^] # Re: FusionDirectory et autre
Posté par Benoit Mortier . Évalué à 2.
Hello,
l'argument on doit mettre des attributs en plus m’étonne toujours car un annuaire LDAP contient de nombreux schémas, pas toujours normalisé (hélas) et donc on se retrouve à gérer de nombreux ObjectClass / Attributs.
Je ne vois donc pas en quoi les attributs supplémentaires peuvent être gênants.
Benoit Mortier - CEO FusionDirectory
[^] # Re: FusionDirectory et autre
Posté par MCMic (site web personnel) . Évalué à 3.
On a déjà eu des remarques sur le problème des attributs GOsa/FD.
Maintenant on stock toute la configuration de FD dans l'annuaire, donc on est obligé d'avoir un schéma au moins pour ça. Est-ce que le problème est d'insérer des schémas, ou juste d'avoir des attributs non standards sur certains types de nœuds?
Parce qu'on pourrait imaginer un version de FD qui n'utilise pas de champs/objectClass FD/GOsa pour les utilisateurs par exemple, par contre un FD qui n'insère aucun schéma c'est pas possible (ça veut dire pas de configuration, pas de snapshot, …)
[^] # Re: FusionDirectory et autre
Posté par viking . Évalué à 2. Dernière modification le 21 juin 2013 à 01:10.
Si je me souviens bien, le problème que j'avais avec Gosa, c'était les attributs supplémentaires à rajouter à tous les nœuds gérés. Pour moi, un gestionnaire LDAP ne devrait pas obliger à rajouter d'attributs. C'est un peu comme si webmin demandait à rajouter des lignes de config dans chacun des fichiers /etc/ gérés.
J'aime pas trop cette façon de faire, car si chaque interface graphique de gestion d'annuaire se mettait à faire la même chose, on en sortirai pas. Pour contre pour l'ajout de schéma supplémentaire, c'est pas un problème. Avoir mis la config de FD dans l'annuaire c'est une bonne chose, si cette config est bien dans une branche séparée.
Bon maintenant, je parle de l'époque de Gosa. C'est peut-être différent avec FD.
[^] # Re: FusionDirectory et autre
Posté par MCMic (site web personnel) . Évalué à 3.
Non ce n'est pas différent, on utilise toujours les classes et attributs GOsa sur les users et certaines autres choses.
Il faudrait faire un audit précis pour vérifier à quoi ils servent, c'est assez varié, par exemple dans user on utilise un champ perso gosaLoginRestriction qui permet de faire des restrictions sur les connexions à FD en fonction de la machine avec laquelle l'utilisateur tente de se connecter.
Il est certain qu'il serait possible de faire une version minimaliste de FD qui évite l'utilisation de ce genre d'attribut, mais on a jamais eu la demande de la part d'un client (ou de contributions utilisateurs allant dans ce sens, d'ailleurs).
Ensuite FD se présente comme un gestionnaire d'infrastructure, ce n'est pas un bête éditeur de nœud LDAP, il propose une vue travaillée des objets, il sait dire si un nœud est un user ou une machine, etc…
# Debian ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 8.
Cet article est intéressant, mais en fait il ne contient rien de spécifique à Debian : c’est une présentation générale de LDAP, indépendamment du système utilisé.
[^] # Re: Debian ?
Posté par PEB (site web personnel) . Évalué à 3.
Tu as raison, et j'ai sans doute eu tort de procéder ainsi, mais en fait, je n'ai testé correctement slapd et LDAP que sous des systèmes Debian/Ubuntu, du coup j'ai préféré ne pas prétendre à l'universalité de mes explications.
Cela m'a permis d'ailleurs de parler de slapd/nslcd/nscd, dont je ne sais pas s'ils se retrouvent sous toutes les distros. (j'ai cru comprendre que sous Fedora et REHL, c'était fort possible que si)
[^] # Re: Debian ?
Posté par Misc (site web personnel) . Évalué à 3.
openldap est présent partout que je sache, contrairement à 389ds est déjà plus rare, et en parlant de ça, je conseille de lire la doc sur le deploiment, elle parle de l'organisation du schema et les principes sont applicables à tout type de ldap :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/index.html
Nscd vient avec la glibc, donc présent partout. Et nslcd, j'ai croisé la première fois sur les serveurs RHEL du taf, donc ça doit être pas trop mal en terme de portabilité.
# Dur :/
Posté par MTux . Évalué à 5.
Je connais tous les avantages théoriques de LDAP (que tu as bien résumé d'ailleurs).
Mais à mettre en pratique c'est juste l'horreur, sauf si tu peux scripter les ajouts/modifications ou passer par une interface web. C'est à mon sens incompréhensible pour un humain. Pire encore si tu veux ajouter les composants te permettant de mettre en place un système d'authentification.
J'ai honte de lâcher cette phrase, mais dans plusieurs cas d'utilisation je préfère administrer de l'Active Directory plutôt que du OpenLDAP.
[^] # Re: Dur :/
Posté par PEB (site web personnel) . Évalué à 4.
Disons qu'il est difficile de commencer. Une fois qu'on sait comment cela se passe, c'est bien plus facile.
Pour l'authentification etc, normalement, c'est assez rapide, c'est plus l'ajout de nouvel utilisateur, ou d'autres manipulations de ce genre qui compliquent la donne. Pour cela, il y a ldap-tools, et sinon, rédiger un petit programme dans un langage interprété (genre python) prend quelques heures et te rend libre sur les outils.
Mais je concède que l'initiation à LDAP peut-être difficile.
[^] # Re: Dur :/
Posté par Benoit Mortier . Évalué à 6.
Hello,
pour avoir fait les deux, administrer des annuaires OpenLdap est bien plus facile à gérer que Active Directory. j’admets cependant que ça oblige à étudier le fonctionnement d'un annuaire LDAP, ActiveDirectory n'est pas un vrai annuaire ldap mais un annuaire customise pour les besoin de microsoft :)
Et comme indiqué plus haut il existe de jolie interface qui nous seulement faciliteront ton travail mais en plus de permettront d'intégrer l'ensemble de tes services à gérer.
Benoit Mortier - CEO FusionDirectory
[^] # Re: Dur :/
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4. Dernière modification le 20 juin 2013 à 14:45.
ActiveDirectory (le backend) est un vrai annuaire LDAP. Ils ont par contre des schémas bien à eux (mais ça c'est normal pour du LDAP), ils ont des contraintes particulières (mais ça c'est normal pour LDAP), mais ça reste un vrai annuaire LDAP que tu peux attaquer en respectant le standard sans jamais manqué la moindre fonctionnalité. Sous le nom ActiveDirectory se cache aussi les outils d'administration, mais le serveur d'annuaire est un vrai LDAP, le seul manquement au standard est le fait que si tu utilises les résultats paginés sur AD, tu peux dépasser la limite imposée par le serveur en nombre d'objets retournés alors que la RFC 2696 dit bien que ça ne doit pas être le cas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Dur :/
Posté par Benoit Mortier . Évalué à 2.
oui je suis presque d'accord sur tout, a part une chose rajouter des schémas dans un annuaire ActiveDirectory est très risquée surtout si celui ci fait office de Contrôleur de domaine. Cela empêche donc de faire un intégration plus poussée comme on le fait en OpenLdap.
Benoit Mortier - CEO FusionDirectory
# LDAP une horreur !
Posté par Blueicefield . Évalué à -2.
Salut,
S'il y a bien une techno que je déteste mettre en place, c'est bien LDAP !
Je rêve que les annuaires LDAP soient remplacés par des technologies NoSQL schemaless comme MongoDB, qui en plus d'être simple et efficace, offre nativement des mécanismes de haute disponibilité.
[^] # Re: LDAP une horreur !
Posté par PEB (site web personnel) . Évalué à 1.
Peut-être qu'ils ne le sont pas du fait de certains atouts non néligeables qu'ils ont ?
# OpenDJ
Posté par djano . Évalué à 3.
J'arrive un peu tard sur ce journal, mais il existe un autre annuaire LDAP libre: il s'agit d'OpenDJ.
C'est un serveur LDAP distribué sous licence CDDL et écrit en Java.
OpenDJ est un fork et la continuation de la communauté d'OpenDS de Sun Microsystems.
Disclaimer: je travaille pour Forgerock, la société qui édite OpenDJ avec l'aide de la communauté
Nous allons très très bientôt sortir (dans moins d'une semaine) la version 2.6 du serveur avec une interface REST + JSON pour faire des requêtes ou des modifications sur la base LDAP.
Par ailleurs, nous fournirons aussi une gateway Rest2LDAP qui permet de mettre une interface REST en frontal de n'importe quel annuaire LDAP.
Comme ldapjs, nous proposons un LDAP SDK qui permet d'écrire facilement un client LDAP sans parler le protocole LDAP. Il y a de nombreux exemples dans la doc.
La documentation est extensive avec des guides pour l'installation, l'administration, et les developpeurs entre autres.
[^] # Re: OpenDJ
Posté par PEB (site web personnel) . Évalué à 1.
Coucou,
Je regarderai, par curiosité. :)
Merci de l'information !
[^] # Re: OpenDJ
Posté par barmic . Évalué à 2.
N'hésite surtout pas à nous envoyer une dépêche pour nous parler plus longuement d'OpenDJ :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: OpenDJ
Posté par djano . Évalué à 3.
Ça marche. On a sorti la version 2.6 mercredi dernier, je vais regarder pour la dépêche demain au boulot.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.