PEB a écrit 22 commentaires

Euh, tu as bien démarré slapd après avoir créé une config ?

Pour le niveau de journalisation, mieux vaut utiliser des valeurs textuelles que numériques, c'est plus lisible. Et contrairement à ce que le commentaire laisse supposer, le choix n'est pas entre 0 (rien) et 255 (trop), il y a tout un éventail de possibilité. Loglevel stats, par exemple, est largement supportable par n'importe quel annuaire, et permet d'identifier les problèmes après qu'ils soient signalés.

Je ne vois pas ce qui te permet d'affirmer que je situe le logging de 0 à 255, c'est faux, et je précise que les informations sont dans la manpage de slapd.conf.

Pour les ACLs, mieux vaut éviter d'entrelacer les déclaration par objet (sur quoi porte une règle) et par sujet (sur qui elle porte), pour éviter les erreurs. Par exemple, il est plus lisible de commencer par:

# l'admin peut tout écrire
access to dn.subtree="dc=localdomain"
by dn.exact="cn=admin,dc=localdomain" write
by * break

# readonly peut tout lire
access to dn.subtree="dc=localdomain"
by dn.exact="cn=admin,dc=localdomain" read
by * break

Plutôt que de gérer ces cas par des clauses supplémentaires dans la règle par défaut qui vient tout à la fin.

Bof, à l'usage, quelle que soit la forme des ACL, elle ne m'a jamais posé de problème, et sont difficilement sujetes à erreurs.

Cela étant, c'est toujours un bon conseil pour qui commence…

Par ailleurs, l'utilisateur déclaré par les directives rootdn et rootpw dans les fichiers de configuration ignore totalement les ACLs, il n'y a aucune nécessité d'en prévoir pour lui. Ou alors, de ne pas utiliser ces directives (rootdn n'est nécessaire que sur un esclave) pour plus de contrôle.

Là dessus, je ne répondrai pas directement, c'est une question d'idéologie, je préfère, dans la mesure du faisable, que les ACL rappellent explicitement les droits du superutilisateur plutôt que de laisser cette information tacitement admise. C'est plus intelligible.

Enfin, je suis très sceptique sur la nécessité pour une application d'avoir accès en lecture à l'attribut userPassword. Les seuls cas que je connaisse concernent radius ou kerberos, dans des configuration particulières, dans lesquelles l'annuaire est utilisé comme solution de stockage de mots de passe, avec des syntaxes spécifiques, et jamais en réutilisant l'attribut mot de passe de l'annuaire lui-même. Toutes les autres applications se contentent d'une opération bind sur l'annuaire, avec l'identificant de l'utilisateur, pour laquelle seul la permission by anonymous auth est nécessaire.

Cette permission n'existe que depuis récemment, mon exemple décrit un ACL qui remonte à 2006 je crois. Par ailleurs, je crois que dovecot ne sa(va)it pas se binder directement en tant que l'utilisateur pour vérifier son mot de passe, je n'exclus pas de ne pas être à jour sur la question, mais du coup, l'acl dovecot semble utile…

Coucou,

Je regarderai, par curiosité. :)

Merci de l'information !

Peut-être qu'ils ne le sont pas du fait de certains atouts non néligeables qu'ils ont ?

Je me cite :

Ici, on configure les acl. Ils ne sont pas dépendants du backend, comme c'est un des points les plus techniques de LDAP, j'en reparlerai dans un journal séparé, après avoir pu faire mon lot de tests.

Il m'a fallu une bonne heure et demie pour maîtriser la plupart des ACL, et une heure rien que pour la partie sets. Je préfère faire un journal entier, avec des exemples à la pelle.

J'en profite pour préciser que je ferai sans doute un journal sur la réplication et la modification à chaud des configurations, un sur la partie SSL, et un dernier sur la notion de binding, et les utilisations pratiques des bases LDAP.

En espérant que j'aie rien oublié.

Le mieux est de lire les schémas qui préexistent, ça prend certes un peu de temps, mais une fois que c'est fait, ça aide grandement à ne pas créer des données redondantes.

J'espère avoir répondu à ta question. :)

Oui, je l'ai précisé dans le journal, mais je pense qu'il faut commencer en douceur, quand on débute. Pour avoir dû apprendre sur le tas à modifier la configuration, j'ai conscience des problèmes psychologiques que ça peut poser à quelqu'un de non initié. :)

Il y a un niveau d'indirection de moins : tu peux directement modifier la configuration, sans avoir besoin que la base fonctionne pour le faire proprement.

Si ta base est pétée, changer la config via cn=config devient plus difficile, et somme toute, tu confies toujours les modifications à une commande, au lieu de les faire toi-même.

Bien entendu, c'est plus psychologique que réel, mais je comprends assez bien ce qu'il veut dire.

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.

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).

Je précise ce que je voulais dire. Ma question était plutôt : quelle flexibilité perd-on selon-toi de LDAP à PostgreSQL, par exemple ?

J'avoue n'avoir jamais testé LDAP JS, je regarderai quand j'aurai un peu de temps !

Merci à vous deux pour les infos.

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)

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 !

Merci.

Promis, la suite va viendre. :)

Bravo pour l'article.

Merci !

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é ?

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.

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é).

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é ?

J'ai tout lu jusqu'ici (c'était long).

J'appuie également la proposition, et j'espère que kadalka en tirera partie.

Si tu t’en fous, arrête d’en parler. Ça deviens lourd, et personnellement, tes messages commencent à m’insupporter… je ne vais pas tarder à te moinsser par principe !

Moinsser par principe, c'est donner plus d'importance aux inepties de la personne qui les prononce qu'ignorer.

Tu as écris une dépêche utile, mais avec des fils de commentaire où tu passes ton temps à te plaindre… ça nuit clairement à l’ensemble, c’est bien dommage.

En effet, s'il faisait preuve d'optimisme, et la dépêche, et ses commentaires lui auraient été profitables.

3/ La majorité sur LinuxFR sont des pro d'informatique. Mais comme je l'ai dit, cela fait fuir le candidat potentiel.

Non !

Ce qui fait fuir le candidat potentiel, c'est l'absence de pédagogie, pas le fait que le type qui lui parle soit un professionnel.

6/ Ubuntu… :-D
Votre exemple me fait rire: Je n'aime pas windows et je l'installe. Rarement j'ai eu à installer Linux car il faut un vrai suivi… Donc, beaucoup n'aiment pas ubuntu mais concrètement c'est ce qu'ils installent… chez les potes

Je ne comprends pas pourquoi le fait de ne pas avoir Ubuntu d'installé sur mon laptop peut signifier que je n'aimerais pas Ubuntu. On fait tous le choix de l'outil qui nous convient. Ça veut pas dire qu'on déconsidère le reste.

J'irai jamais installer une debian à quelqu'un qui n'y connaît rien. Je l'initierai clairement via une (K|Edu|X)?ubuntu.

Non on ne s'en fiche pas.
Moi, je m'en fiche parce que pour MOI c'est débile et ça ne me dérange pas si je suis vu comme un troll alors que je n'en suis pas un.
Par contre, la plupart non pas envie d'être vu comme un troll et je ne parle même pas des malheureux qui aiment linux et l'esprit libre et qui n'osent pas mettre un journal de peur de se faire moinser et à terme ne plus pouvoir écrire un journal.

Par exemple, pour pouvoir écrire un journal il faut être au dessus de zéro.
Pour pouvoir écrire dans les suivi il faut être au dessus de zéro.
Et si on veut lire les éléments de la rédac, ils faut être au dessus de zéro.
Si j'écris une dépêche je ne pourrais même pas poser des questions dans la barre de droite, ni même répondre aux questions qu'on me poserait.
Et là, c'est un soucis.

Ah, là on tient quelque chose.

Alors excuses moi si j'ai le défaut de penser aux autres, parce qu'à titre personnel ne pas écrire chez linuxFR ne me pose pas de problème.
Ce qui me pose un problème c'est qu'on dise du mal du libre à cause de quelques personnes qui avec leur commentaires de gamins donnent l'impression que linux et le libre en général c'est un truc de geek réservé aux geeks: ça c'est grave.

Quel altruisme ! Tu sais, si tu t'exprimais toujours dans l'objectif d'être utile aux autres, et pas pour imposer ton point de vue sur le monde du libre et son contenu, peut-être que tu serais crédible. Malheureusement, il ne semble pas que ça soit le cas.

Tu passes ton temps à jouter avec les gens, qui manifestement n'approuvent pas ton point de vue, (mais c'est pas grave, c'est eux qui ont tort, après tout, tu n'es pas un troll) mais plutôt que d'avoir un échange constructif en tenant compte des arguments des autres, dans le but, par exemple, d'être vraiment utile aux gens qui te lisent, tu préfères camper sur tes positions, parce que surtout, quand on est en déphasage avec une communauté, il faut rien changer.

J'ai surtout l'impression que tu vis très mal le fait d'être plus ou moins traité comme un paria sur ce site, mais tu considères que les autres (en particulier, le karma) en sont responsables. Plutôt que de changer d'attitude, tu insistes.

Que tu aies tes opinions et ta façon de voir les choses, c'est très bien, et je t'encourage à la partager avec les autres, mais malheureusement, le jeu social de l'échange impose que lorsqu'on est en minorité vis-à-vis des autres, il faille faire preuve de tact et de délicatesse pour pouvoir exprimer ses idées sans être méjugé.

Enfin, c'est mon point de vue sur la question. Bon surf.

M'enfin, cher kadalka, on s'en fiche qu'il essaie de faire baisser ton karma, vu que le karma est une débilité.