Bonjour forum,
J'ai une question (bête?) sur LDAP et les (trop) nombreuses possibilités (les super copines des "difficultés") qu'il offre pour parler d'un cas (qui pourrait être un cas d'école, parce que là j'ai rien sous la main pour tester de toute façon!)
Supposons que je veuille utiliser LDAP comme carnet d'adresses en ligne. L'intérêt serait par exemple pour utiliser mon webmail de partout avec en plus mon carnet d'adresse (auto-hébergé?).
Je sais que ça reste compatible avec la plupart des clients mails classiques.
Alors je vais maintenant compliquer un peu:
Je veux qu'il puisse également servir de liste de contact pour d'autres logiciels (au pif: xmpp).
Ca veut dire que je veut rajouter une entrée dans ce carnet si je créé un contact xmpp. Et je veux que tout ça soit cohérent. Pour la partie "j'ai 3 fois la même personne parce que 2 adresses mais et 1 JID", bien sûr, ce serait à la charge de l'utilisateur!
(Déjà, je ne sais pas si on trouve un ensemble webmail, client mail, et serveur xmpp qui accepte un schéma commun... bon, disons que ça se trouve!!)
Donc:
1 - Est-ce que c'est possible dans l'état actuel des choses?
2 - Si oui, à quel point est-ce compliqué à mettre en place?
En fait, je n'arrête pas de penser aux trucs genre Telepathy ou tout communique avec tout via un gestionnaire de communication, mais que vu de ma fenêtre, la gestion de contacts devrait être côté serveur plutôt que de lancer des requêtes sur 4 services pour avoir une description complète du contact, et que ça ne marche que sur une seule machine avec un seul utilisateur.
PS: Pour ceux qui paniqueraient sur l'ultra-centralisation des données, cette question n'est pas totalement déconnectée d'un précédent journal dans lequel je prônais l'auto-hébergement pour le grand public non averti.
Forum général.général Carnets d'adresse centralisés LDAP
21
avr.
2009
# Les schémas, ça s'empile.
Posté par Gyro Gearllose . Évalué à 5.
Je vais peut-être dire une clownerie, mais il me semble que les schémas ldap sont empilables, et ne sont pas exclusifs. J'en veux pour exemple la définition même des utilisateurs de mon domaine samba.
Je ne me souviens plus quels schémas sont associés à mon annuaire (vacances powa), mais je peux renseigner tout un tas de choses sur chacun des utilisateurs de mon domaine :
- évidement leurs uid, gid(s), passwords, ntpasswords, etc
- mais aussi l'organisation dont ils font partie, leurs noms, prénoms, adresse mail, numéro de téléphones, etc.
Le mieux pour toi, serait de faire un test si tu en as la possibilité avant de mettre ton annuaire en prod, en incluant les schémas dont tu as besoin dans /etc/openldap/slapd.conf, puis de voir ce que ça peut donner en ajoutant une ou deux entrées à l'aide de phpldapadmin ou similaire.
Si j'en ai bien compris le fonctionnement, du définis une entrée pour qu'elle soit rangée au bon endroit (par exemple un contact), puis tu lui ajoutes (ou pas) des attributs et/ou des classes. Ce dernier cas te permets d'ajouter des attributs en fonction de la classe choisie.
Voilà déjà pour la première partie.
Ensuite, tu n'as qu'à renseigner la chaine de connexion à ton annuaire ldap (adresse du serveur, paramètres de connexion, root dn, etc.) et ça devrait rouler. Evidement, si xmpp ne propose pas d'interface avec ldap, c'est mort.
Voilà, en espérant avoir éclairé un tant soit peu ta lanterne.
[^] # Re: Les schémas, ça s'empile.
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
Par contre, ils définissent des classes d'objets et des attributs.
Il existe plusieurs types de classes :
- les classes structurelles ;
- les classes auxiliaires.
Les premières sont exclusives pour une entrée donnée. Il ne peut y avoir d'autres classes du même type pour un même objet. Par contre, on peut ajouter des classes du second type à volonté. Les classes structurelles imposent généralement la présence d'au moins un des attributs qui leur sont liées, les classes auxiliaires ne l'imposent pas toujours.
Ajoutons à tout cela qu'il y a également de l'héritage entre les classes. Par exemple, inetOrgPerson hérite des mêmes attributs que organizationalPerson, qui elle-même, hérite des attributs de la classe person, etc.. Toutes les classes dépendent normalement de la classe top qui ne définit qu'un seul attribut, indispensable : objectClass.
[^] # Re: Les schémas, ça s'empile.
Posté par Gyro Gearllose . Évalué à 1.
[^] # Re: Les schémas, ça s'empile.
Posté par NeoX . Évalué à 3.
suffit de voir zimbra qui fait deja webmail, groupware, jabber
et qui si on lui rajoute les schemas posixGroup et samba
peut alors aussi servir de serveur ldap pour ces services...
sinon j'avais essayé le server de chat openfire
qui peut s'interfacer avec un ldap
# JID = mail
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
La syntaxe de l'attribut mail peut donc être largement reprise pour définir un attribut supplémentaire (avec une classe auxiliaire supplémentaire) pour stocker les jid des utilisateurs s'ils doivent être distincts des adresses de messagerie électroniques.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.