J'arrive à créer l'ensemble des mes mailshares, utilisateurs et
groupes à partir de mon
CMS, mais quelques problèmes subsistent :
- PROBLEME 1 - je n'ai pas trouvé de table dans OBM recensant
l'ensemble des logins utilisés dans
les utilisateurs, alias, groupes, mailshare. Y en a t'il une ? Comment
fait OBM pour savoir
que le login est unique et ne pas mettre le ouaille dans Cyrus et
Postfix ??
il n'y a pas de table pour ca.
Il y a une fonction dediee a ca qui verifie l'existence ou unicite d'une
adresse email dans obm. Testé a chaque creation/modif de user / mailshare /
groupe public,.. dans obm web
ces checks là sont "manuels" il me semble. C'est à dire au mieu dans
l'interface web.
- PROBLEME 2 - lorsque je met à jour toute sorte d'info, Update.pl
joue pleinement son rôle entre
Postgres OBM et LDAP OBM par une automatisation toutes les 10 minutes
néanmoins, lorsque je change le mot de passe, ca ne marche pas, j'ai
vu un second script
ChangePassword.pl appellé à partir de la page de changement de mot de
passe, ce script
est-il automatisable dans Update.pl ? Quelle est la raison ? Comment
détourner ce problème ??
Nous redemandons toutes les semaines aux auteurs de cette partie du code
pourquoi le mode global de update.pl n'applique pas les passwords...
(j'avoue je ne me rappelle jamais de la réponse).
Un pre-recquis pour ceci est d'avoir les passwords dans obm, ce qui n'est pas
toujours le cas n'est-ce pas...
Un mode "instant apply" (pour tout) dans l'interface a déjà été évoqué.
- PROBLEME 3 - Il semblerait que même en changeant le MDP par
l'interface, cela ne se fait pas automatique
sur Cyrus. Comment se fait ensuite la synchro des MDP avec Cyrus ?
une sombre histoire de saslauthd et de cache. Le changement est propagé
instantanément côté ldap via changepassword.pl. Nous avons déjà d'autres
sujets sur saslauthd et les sso ouverts, donc je pense qu'un truc pour
notifier saslauthd que le password du user X a été changé va être devoir
être implémenté. Si vos saslauthd/ldap ne sont pas surchargés, le mieux
est de désactiver le cache pour avoir un comportement cohérent.
- QUESTION 1 - Peut-on simplement supprimer un mailshare service.com@
et créer dans la foulée un groupe service.com@
sans que cela pose problème (est-ce que Cyrus va détruire le compte ?)
Et vise versa ? Y a t'il une procédure pour faire
ceci automatiquement ?
Je dirai intuitivement que ça va merder.
en fait oui biensur que cyrus va supprimer le compte.
Un groupe n'a pas d'existence dans cyrus, mais uniquement sous forme d'alias
de postfix
ensuite c'est une question de sequencement. Il y a un sens dans lequel ca
devrait marcher.
Pour le vrai renommage de login voir reponse de thomas
Pour ne rien cacher nous discutions aujourd'hui de ce type de pb. Obm
implémente le renommage de login. Une opération du type
- rename login a -> a.tmp
- renane login b -> a
- rename a.tmp -> b
doit déjà créer de sacrés problèmes. Un problème connu est que lors de
cette opération minig n'est pas notifié. Les caches (l'équivalent du
profil mozilla) des 2 users se retrouvent alors inversés....
- QUESTION 2 - Peut-on masquer de l'interface utilisateur les menus
"changer de mot de passe", ... Si oui comment ?
oui, via la conf des modules (global) ou la definition des profils (specifique
au profil dans ce cas)
- QUESTION 3 - Enfin, avez-vous un shéma détaillé MCD des datas et le
dico des données peut-il être fourni ?
Pas de schema mcd. Voir du cote des scripts de creation de la BD
Bref, si je réussi à bien avancer mes investigations, je m'engage à
remettre mes classes PHP (gestion OBM et gestion OpenLDAP)
à la communauté et à Linagora (il faudra juste les adapter légérement
à chaque projet ...).
Cordialement
--
Pierre Baudracco Directeur LINAGORA GSO, 05 62 19 24 91 - 06 82 84 63 67
OBM project leader, www.obm.org, [email protected]
AliaSource devient LINAGORA GSO
_______________________________________________
Obm mailing list
[email protected]
http://www.list.aliasource.fr/mailman/listinfo/obm
