|
|
|
##LSC R\&D Test how LSC can be used for account synchronization from and towards FD
|
|
|
|
|
|
|
|
**synchro from fd to others services**
|
|
|
|
|
|
|
|
A few plugins like :
|
|
|
|
|
|
|
|
* renater-partage
|
|
|
|
* sinaps
|
|
|
|
an future
|
|
|
|
|
|
|
|
|
|
|
|
* lucca (renater)
|
|
|
|
* zimbra (telecom)
|
|
|
|
* xivo
|
|
|
|
* bluemindare used for account synchronization.
|
|
|
|
|
|
|
|
|
|
|
|
synchro from other service to fd
|
|
|
|
|
|
|
|
exemple of student provisioning at telecom
|
|
|
|
|
|
|
|
|
|
|
|
* database / webservice to lsc
|
|
|
|
* lsc plugin webservice fd to fd rest API
|
|
|
|
Ya aussi le cas de la synchro AD et/ou samba4 non?
|
|
|
|
|
|
|
|
oui mais ca on le fait deja avec lsc et ya pas d'appel webservice depuis ces plugins
|
|
|
|
|
|
|
|
Et ça ne gagnerait pas à passer par le webservice aussi?
|
|
|
|
Notre config pour ces cas là est stockée quelque part que je puisse regarder?
|
|
|
|
|
|
|
|
les donnees samba sont stocke par le plugin samba
|
|
|
|
|
|
|
|
Pour samba4 c'est un appel de hook et puis on créer une config lsc pour que ça reprenne depuis FD
|
|
|
|
|
|
|
|
Je veux bien voir la config LSC et le hook utilisé.
|
|
|
|
|
|
|
|
\url{https://gitlab.opensides.be/opensides-documentation/lsc/wikis/samba4/hooks}
|
|
|
|
\url{https://gitlab.opensides.be/opensides-documentation/lsc/wikis/samba4/scripts}
|
|
|
|
|
|
|
|
Y a les hooks FD avec ce qu'on passe et le script utisé pour le hook qui concat la config LSC avec les modifications
|
|
|
|
|
|
|
|
ma question est de fd -> ailleurs et l'idee d'un bus de synchro ce qui posera le probleme des retours
|
|
|
|
d'info et de quoi faire cote fd avec ses retour d'erreurs mais qui permettrait de pas choper des erreurs 500 comme avec partage lors de l'edition d'un user
|
|
|
|
|
|
|
|
A priori pas de retours d’erreurs dans FD même, puisque la synchro va se faire de manière asynchrone sans bloquer l’UI.
|
|
|
|
|
|
|
|
si partage me renvoie une erreur 500 on gere ca comment par exemple a travers lsc ?
|
|
|
|
|
|
|
|
LSC peut avoir des erreurs mais je suis pas sur que ce soit très détaillé
|
|
|
|
Dans les hooks samba j'utilise un
|
|
|
|
|
|
|
|
*ERROR=$(lsc -f "$DIRECTORY" -s samba4 | grep 'ERROR')
|
|
|
|
|
|
|
|
Pour choper l'erreur car c'est plus une "phrase"
|
|
|
|
|
|
|
|
\url{https://lsc-project.org/documentation/latest/monitoring/start}
|
|
|
|
|
|
|
|
Ah je savais pas qui avait un option remote
|
|
|
|
|
|
|
|
Mais dans notre cas on sera pas remote si? À mon avis ça passera par les logs.
|
|
|
|
|
|
|
|
Ca dépend si on considere que LSC dans etre sur la machine FD (dans le cas des hooks samba4 c'est le cas) Si c'est sur la machine les logs son surement plus simple en effet
|
|
|
|
|
|
|
|
et aussi le buffering des infos eventuellement genre :
|
|
|
|
|
|
|
|
demande 1 service 1
|
|
|
|
demande 2 service 2
|
|
|
|
demande 3 service 1
|
|
|
|
|
|
|
|
C’est à dire?
|
|
|
|
|
|
|
|
si j'ai plusieurs demandes genre 1 vers partage 1 vers zimbra et une AD par exemple, est ce que j'aurait tout les reponses dans le bon ordre et en sequence ou certaines vont mettre plus longtemps que l'autre ... probleme de queue
|
|
|
|
|
|
|
|
C’est quoi le «bon» ordre?
|
|
|
|
|
|
|
|
ca veut dire si j'ai pas les reponses dans l'ordre d'envoi que se passe til ? ca pose aussi le probleme des actions concurrentes dans lsc
|
|
|
|
|
|
|
|
Je suis pas sûr de comprendre tu parles d’un cas où on synchronise depuis FD vers plusieurs services? Pourquoi l’ordre des réponses importe?
|
|
|
|
|
|
|
|
si j'ai une fiche utilisateur qui comprend un compte partage, un compte samba (ad) et que je demande un synchro a partage et un synchro vers AD j'ai donc deux synchro en cours
|
|
|
|
|
|
|
|
hors du cote fd c'est un tout
|
|
|
|
|
|
|
|
Si coté fd c'est un tout je penses qui faudrait qu'on lance le premier et qu'on attends sa réponse du coup avant de lancer le suivant uniquement si ça a été fait avec succes
|
|
|
|
|
|
|
|
Oui mais l’ordre on s’en fiche, que ça synchronise d’abord partage puis AD ou l’inverse ou les deux en même temps je comprnends pas ce que ça change
|
|
|
|
|
|
|
|
actuellement si la synchro partage rate, ca ne synchronisera pas vers ad
|
|
|
|
|
|
|
|
Je voyais plus ça comme un bug qu’une feature a priori.
|
|
|
|
|
|
|
|
dans les chantier qu'on a de plus en plus on est responsable de la coherence de l'ensemble vu qu'on est le portail des identites et qu'on pousse vers les autres ou qu'on recoit (mais c'est pas le sujet ici)
|
|
|
|
|
|
|
|
donc si on decide de sortir certains comportements on doit s'assurer de la coherence des donnees envoyes et de leur bonne propagation
|
|
|
|
|
|
|
|
Dès que tu as une synchro en erreur tu as des problématiques de cohérence je suis pas sûr que l’ordre ait à voir avec, dans le cas actuel si la synchro partage passe et pas la AD tu as le même problème. Je pense que pour les cas complexes où l’ordre peut compter on regardera ça dans un second temps. En première étape je pensais plutôt implémenter les nouveaux usages sur LSC, et si ça se passe bien convertir les synchro existantes. (Donc dans un premier temps on ne sort pas de comportements on en ajoute de nouveaux, c’est moins contraignant en termes d’attentes)
|
|
|
|
|
|
|
|
je suis d'accord d'apres ce que je lit de la doc lsc on peut le contacter sur un port precis
|
|
|
|
|
|
|
|
\url{https://lsc-project.org/documentation/latest/execution/start}
|
|
|
|
|
|
|
|
est plus interessant que d'utiliser les hooks ?
|
|
|
|
|
|
|
|
Les hooks de FD tu veux dire?oui
|
|
|
|
|
|
|
|
Que ce soit en local ou par le port ça peut passer par un hook FD, c’est orthogonal.
|
|
|
|
À mon avis on va utiliser des hooks FD au début et quelque chose de plus intégré à terme.
|
|
|
|
|
|
|
|
Je penses que le port est plus généric si on veut installer LSC sur une autre machine, mais pas sur que ça se produira
|
|
|
|
|
|
|
|
|
|
|
|
===========================================================
|
|
|
|
|
|
|
|
il faut donc faire une page de wiki par service qu'on veut convertir avec
|
|
|
|
|
|
|
|
* comment on compte faire
|
|
|
|
* les flux
|
|
|
|
* le retour d'erreur
|
|
|
|
* ce qui doit etre developpe pour ce cas precis
|
|
|
|
|
|
|
|
et on lie ses pages sur le ticket \url{https://gitlab.fusiondirectory.org/fusiondirectory/fd/issues/5958#}
|
|
|
|
|
|
|
|
Le retour d’erreur sera commun non?probablement mais certains sont des webservice et d'autres pas donc a voir
|
|
|
|
|
|
|
|
|
|
|
|
=================
|
|
|
|
|
|
|
|
**Les flux**
|
|
|
|
|
|
|
|
je comprend pas cette phrase
|
|
|
|
|
|
|
|
La source déclarée dans LSC peut être soit FD via son API REST, soit directement le LDAP.
|
|
|
|
|
|
|
|
je vois pas comment fonctionne l'interaction une fois que j'ai sauve mon user ?
|
|
|
|
|
|
|
|
C’est à dire?
|
|
|
|
LSC fonctionne en déclarant des sources et des destinations de données, ici les données viennent de FD et vont dans Zimbra, soit par REST soit par LDAP.
|
|
|
|
|
|
|
|
oui mais cote fd comment ca marche
|
|
|
|
|
|
|
|
C’est le déclenchement de la synchro qui t’interroge? oui
|
|
|
|
|
|
|
|
Ah ok je voyais pas.
|
|
|
|
Oui faut rajouter une section dans le wiki pour ça.
|
|
|
|
|
|
|
|
Possibilités:
|
|
|
|
|
|
|
|
* - Hook FD
|
|
|
|
* - Surveillance du LDAP par LSC (si source LDAP)
|
|
|
|
* - Synchro régulière (si pas de besoin de synchro immédiate)
|
|
|
|
* - Code spécifique dans FD
|
|
|
|
fd fait de l'evenementiel donc je pense qu'on doit rester dans le schema fd dirige je pense que :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* - Hook FD
|
|
|
|
* - Surveillance du LDAP par LSC (si source LDAP)
|
|
|
|
*
|
|
|
|
|
|
|
|
* sont les scenarios les plus interessant
|
|
|
|
*
|
|
|
|
|
|
|
|
* Les hooks iront bien pour les premiers tests, mais à terme on voudra probablement que les utilisateurs puissent mettre en place ces synchronisation sans ajouter des hooks à la main, c’est pour ça que je laissais la possibilité de code spécifique.
|
|
|
|
*
|
|
|
|
|
|
|
|
* note: on a jamais accès au ldap des autres applis correctement, c'est assez rare
|
|
|
|
*
|
|
|
|
|
|
|
|
* -> Tu dis ça par rapport à l’idée de synchroniser dans le LDAP de Zimbra en destination?
|
|
|
|
oui de maniere generale les infras sont complexes et l'api est la meilleure solutions pour des contraintes techniques / securite / organisationelles
|
|
|
|
|
|
|
|
|
|
|
|
* Ben le lien que je donnais c’est une réponse de Clément que j’ai trouvé qui dit de synchro dans le LDAP. Dans le cas de Zimbra j’ai l’impression que l’accès au LDAP est une fonctionnalité voulue et présente depuis longtemps, alors que l’API REST a l’air un peu fraiche. En tous cas en cherchant s’il existait un plugin Zimbra pour LSC je suis tombé que sur des gens qui synchronisent dans le LDAP de Zimbra directement.
|
|
|
|
l'api a plus de 10 ans elle est pas vraiment fraiche :) les gens font ce qu'il veulent chez eux mais nous on a pas les meme challenges
|
|
|
|
|
|
|
|
|
|
|
|
* Ah dingue. Je sais pas où j’avais vu un truc qui la présentait comme expérimentale. les propres outils zimbra l'utilisent
|
|
|
|
|
|
|
|
* \url{https://wiki.zimbra.com/wiki/Zimbra\_REST\_API\_Reference} Hum la doc est pas complète ou ya pas de méthodes pour créer des utilisateurs? c'est du 6 ils sont en 8
|
|
|
|
*
|
|
|
|
|
|
|
|
* je connais des gens chez zextras donc je pourrait demander
|
|
|
|
*
|
|
|
|
|
|
|
|
* Ben si ya pas de doc ça va être compliqué de passer par l’API en tous cas.
|
|
|
|
* Visiblement c’est possible via une API SOAP mais c’est une autre paire de manche SOAP de mémoire de mes études c’est pas simple à utiliser.
|
|
|
|
*
|
|
|
|
|
|
|
|
* visiblement le soap est a jour \url{https://files.zimbra.com/docs/soap\_api/8.6.0/api-reference/index.html}
|
|
|
|
*
|
|
|
|
**gestion des erreurs**
|
|
|
|
|
|
|
|
LSC stock les erreurs dans un log, et propose des commandes pour lister les erreurs rencontrées.
|
|
|
|
|
|
|
|
je craint que ca ne soit pas suffisant il faudrait une remontee d'erreur vers fd comme actuellement qui permettrait de savoir qu'un erreur est arrive, sinon on introduit un probleme suplementaire d'access ssh et shell qui est non voulu
|
|
|
|
|
|
|
|
On ne peut pas avoir de remontée d’erreur directe au moment des modifications FD dès lors qu’on est plus synchrone. (Et l’idée est de ne pas l’être)
|
|
|
|
Donc les systèmes qu’on peut imaginer c’est soit un démon/script qui écrit leur log dans le LDAP et une interface dans FD qui affiche ça.
|
|
|
|
Soit une interface dans FD qui tape directement dans le log d’une manière ou d’une autre.
|
|
|
|
Après là on entre dans le champ du monitoring et c’est ptet pas le moment d’entamer ce genre de transformations dans FD ya déjà des outils dédiés non?
|
|
|
|
|
|
|
|
oui faut discuter et mettre ces problemes dans le wiki car si on perd les notifications d'erreur ca va etre inutilisable
|
|
|
|
|
|
|
|
L’idée c’est que la synchro soit gérée coté LSC donc j’imaginais des notifications email ou autre à partir de là en cas d’erreurs.
|
|
|
|
|
|
|
|
non email ou autre impraticable dans la vraie vie :)
|
|
|
|
|
|
|
|
Il reste quoi alors? justement je ne sais pas a l'heure actuelle mais passer de ya des erreurs a tout va bien car on vois pas les erreurs n'est pas jouable. c'est le but de nos discussions
|
|
|
|
|
|
|
|
et je suis pas fige sur lsc
|
|
|
|
|
|
|
|
À partir du moment où la synchro est asynchrone que ce soit LSC ou autre tu as plus de pop-up dans FD. Je dirais même que c’est le but.
|
|
|
|
|
|
|
|
le but est d'enlever les appel webservice et autre mais on doit contrebalancer ca avec le fait de perdre des infos importantes, k1412 va nous dire comment il gere ca sous samba4
|
|
|
|
|
|
|
|
Sous samba4 de ce que j’ai compris la synchro est synchrone.
|
|
|
|
|
|
|
|
Oui pour Samba4 on déclenche le sync et on remonte avec un grep d'erreur un peut violente
|
|
|
|
|
|
|
|
On ne perd pas d’infos c’est juste qu’elles sont ailleurs et pas mélées dans le workflow FD. j'ai bien compris mais en termes utilisateurs on perd de la donnée importante et donc du user friendly meme si il ralent sur les erreurs maintenant :)
|
|
|
|
Ben justement elle pas perdue le flow est différent, et la question du user-friendly est bien celle qui est en jeu, quand tu as une personne de la RH qui peut pas changer une info sur une fiche parce qu’elle mange une erreur partage, c’est pas user-friendly.
|
|
|
|
|
|
|
|
ca voudrait dire qu'on doit creer/utiliser un genre de queue de notifications qui stockerait les erreurs ?
|
|
|
|
|
|
|
|
Je pense que ce serait mieux, un peu comme ce que fait argonaut-fai-monitor car au final on veut juste lancer les syncs pour au finals avoir un retour de ce qui sait passé
|
|
|
|
|
|
|
|
C’est fait comment actuellement pour les autres cas d’erreurs à remonter? Ya pas des outils en place pour les erreurs LDAP, PHP, ou autre?
|
|
|
|
|
|
|
|
syslog -> greylog mais desitne au admins, rien du cote utilisateur fonctionel c'est tres rare
|
|
|
|
|
|
|
|
Greylog c'est plus du full monitoring, y faudrait quand meme avoir un moyen d'avoir un "sync reussi / raté"
|
|
|
|
|
|
|
|
Oui pour moi la cible est bien l’admin où tu situe l’utilisateur fonctionnel là-dedans?
|
|
|
|
|
|
|
|
l'admin c'est 10% max de nos utilisateurs, le user standard aka fonctionel, rh, support etc c'est 90% de nos users
|
|
|
|
|
|
|
|
D’accord mais pourquoi on retournerait les erreurs de synchro à la RH je comprends pas.
|
|
|
|
|
|
|
|
parceque dans un schema traditionel elle doit ouvrir undemande de support ou appel collegue pour dire j'ai eu un probleme lors de tel operation, on peut pas masquer les erreurs dans des process complexes
|
|
|
|
|
|
|
|
Pourquoi lui faire faire à la main ce qu’on peut automatiser?
|
|
|
|
|
|
|
|
Je penses aussi qu'on a 2 cas, l'utilisation de LSC de façon fonctionnel ou on veut faire un synchro systématiquement mais aussi le cas ou FD serait utilisé pour "créer" a config LSC dans le LDAP en quelque sorte (c'est l'impression que j'ai)
|
|
|
|
|
|
|
|
bonne question parceque les autre equipes vont pas le voir ou trop tard attend je paste un schema complexe pour bien comprendre
|
|
|
|
|
|
|
|
|
|
|
|
\url{https://images.opensides.be/xVQm9GII/8w3BMWmh}
|
|
|
|
|
|
|
|
cas de l'insa
|
|
|
|
|
|
|
|
mais je suis d'accord il faut evaluer comment gerer la question des erreurs on peut pas avoir un interface qui dit oui tjrs a lors que c'est pas le cas et que ca va generer des erreurs dans les autres systemes
|
|
|
|
|
|
|
|
En regardant le schéma j'ai l'impression que ce serait un peu comme si on dirait si on créer un utilisateur et qu'on à une config associé on fait une synchro
|
|
|
|
|
|
|
|
Je suis pas d’accord de définir ça comme ça, l’interface dit oui parce que la sauvegarde a fonctionné, la sauvegarde par FD et la synchronisation vers les autres systèmes sont deux systèmes différents et si la synchro échoue, ce n’est pas la faute de la personne qui édite les données, c’est un problème de configuration de la synchro, à gérer par les admins.
|
|
|
|
|
|
|
|
Le souci c'est le risque de modification en chaine, on créer un user on croit que ça synchro on dit à l'utilisateur qu'il peut se connecter mais ça marche pas or que pour nous tout a bien fonctionné. Pour être qu'on à pas besoin de retourner une erreur précise, mais au moins un statut si ça sait bien passé ou pas, en cas d'erreur l'admin peut toujours aller voir l'erreur précise (même si avoir l'erreur disponible directement resterait sympa ^^)
|
|
|
|
|
|
|
|
Tant qu’on considère ça comme ça on est obligé de garder un fonctionnement synchrone.
|
|
|
|
|
|
|
|
Ca peut marcher en décalé aussi, ou on fait a modification on dit que ce sera bon demain matin mais ça marche pas et l'admin n'est pas au courant qui a eu une synchro la veille donc il checkera surement pas le log pour lsc et on peut pas imposer au client d'installer du monitoring de log (déjà qui ont du mal à nous écouter ^^)
|
|
|
|
|
|
|
|
Ah ben pour moi c’était l’idée, effectivement si les logs sont juste consultés à la main tous les 4 jours c’est galère, il faut une remontée d’erreur qui prévient l’admin des erreurs.
|
|
|
|
|
|
|
|
C'est pour ça que j'aurais pensé à un systeme de queue comme pour argonaut qui mettrait juste "reussi" ou "rate", après je sais pas si FD garde les queue à long terme (c'est assez rare qu'on en aie besoin)
|
|
|
|
|
|
|
|
Ben ça c’est bien du monitoring.
|
|
|
|
|
|
|
|
non c'est juste du retour de status, il faut pas oublier aussi que de plus en plus ils vont utiliser les webservices de fd en entree donc tout ce qu'on discute doit aussi etre valable dans le scenario
|
|
|
|
|
|
|
|
appli metiers -> REST FD -> FD -> synchro appli tierces
|
|
|
|
|
|
|
|
Avec LSC on a une autre possibilité après qu'il a fini une synchro (comme un genre de hook) ?
|
|
|
|
|
|
|
|
Je sais pas, mais je vois pas trop la différence avec un script qui surveille le fichier d’erreurs.
|
|
|
|
|
|
|
|
J'aurais pensé à queque chose du genre
|
|
|
|
-> Action dans FD qui provoque une synchro
|
|
|
|
-> On créer un élément dans le ldap qui dit qu'une synchro est lancé (avec un statut comme quoi c'est start)
|
|
|
|
-> apres lsc il dit a fd de mettre la tache en status (reussi / raté)
|
|
|
|
De cette facon on pourrait avoir un genre de dashboard qui liste les taches et status que sur demande (ça pourrait marcher en interface en API) mais pour ça faut pouvoir flag une tache comme reussi
|
|
|
|
|
|
|
|
C’est de ça que je parlais plus haut: «Donc les systèmes qu’on peut imaginer c’est soit un démon/script qui écrit leur log dans le LDAP et une interface dans FD qui affiche ça.
|
|
|
|
Soit une interface dans FD qui tape directement dans le log d’une manière ou d’une autre.»
|
|
|
|
|
|
|
|
Le démon serait mieux d'après moi comme ça on garde les infos de façon consistante dans le LDAP et il faut juste que l'utilisateur check le status de la queue / dashboard. On a pas de technique de popup pour montrer une erreur en asychrone de toute façon je penses mais au moins y aura un retour
|
|
|
|
|
|
|
|
en gros ca nous ramene a ca \url{https://en.wikipedia.org/wiki/Advanced\_Message\_Queuing\_Protocol}
|
|
|
|
|
|
|
|
Je vois pas le rapportgestionnaire de queue avec protocole standard gere par la fondation oasis
|
|
|
|
|
|
|
|
Si ça permet de ping FD une fois qu'on a un le statut pour faire un popup oui, mais ça me parait encore différent que juste une gestion de LSC (ça touchera au core de FD je crois)
|
|
|
|
|
|
|
|
ca me fait penser que lsc est peut etre pas le meilleur choix dans toute les situations
|
|
|
|
|
|
|
|
J’ai pas compris pour quel fonctionnement tu voulais utiliser AMQP
|
|
|
|
|
|
|
|
Et je pense que c’est une mauvaise idée de vouloir faire un système de pop-up asynchrone dans FD.
|
|
|
|
|
|
|
|
je pense a ce stade de la discussion qu'on doit faire un page pour chaque logiciel qu'on veut interfacer pour comprendre tout les problemes que ca pose
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
La question du retour d’erreur qui semble bloquer pour vous sera la même quelque soit la destination vers laquelle on synchronise non?
|
|
|
|
|
|
|
|
ca c'est un fait mais il y a de grandes differences entre sinaps et zimbra par exemple donc pour faire un choix eclaire de techno globale
|
|
|
|
|
|
|
|
Pour moi Sinaps est vraiment en cas particulier, et qui nécessitera quasiment à coup sûr des adaptation spéciales quelque soit l’architecture.
|
|
|
|
|
|
|
|
L'idée général serait pas plus de pouvoir lancer n'importe quel logiciel de façon asynchrone ? Que ce soit LSC ou un autre truc si on veut synchroniser sur un autre système ?
|
|
|
|
|
|
|
|
Ça c’est le rôle des hooks on peut déjà lancer ce qu’on veut.
|
|
|
|
|
|
|
|
Sauf qui sont synchrone il me semble vu que j'arrive à avoir le retour d'erreur sur LSC par exemple
|
|
|
|
|
|
|
|
Ils sont synchrone si tu lances un truc synchrone et asynchrone si ton hook déclenche un truc en arrière plan (via fork ou appel webservice ou autre)
|
|
|
|
|
|
|
|
mon idee globale pour ce qu'on discute est d'avoir un bus de synchronisation modulaire et adaptable avec des connecteurs a chaque type de synchro
|
|
|
|
|
|
|
|
Ce qu’apporte LSC là-dessus c’est d’avoir la logique de synchro (avec des politiques de gestion des conflits etc il me semble) et le système de plugin pour faire des connecteurs.
|
|
|
|
|
|
|
|
Je suis assez d'accord, je penses pas qu'on a autre chose qui permet d'être aussi extensible actuellement (même si j'aime pas le XML ^^)
|
|
|
|
|
|
|
|
On peut comme pour samba4 faire du LSC synchrone pour avoir le retour d’erreur (ou le faire selon les cas) mais c’est vrai que pour moi ça perd de l’intérêt puisque ça ne scale pas si on veut synchroniser vers plusieurs destinations. Mais quelque part on peut choisir de découpler la question synchrone/asynchrone de la synchro en elle même et essayer de supporter les deux.
|
|
|
|
|
|
|
|
oui il faut detailler tout ces problemes et questionnement dans la page du wiki connecteur zimbra
|
|
|
|
|
|
|
|
en ce qui concerne la config xml de lsc helas je ne voit pas de moyen de la simplifier via le ldap
|
|
|
|
|
|
|
|
A première vue que FD puisse aider a avoir des config lsc en ldap qu'il utilise lors de la synchro ça permettrait d'avoir un truc plus simple et de garder les configurations en ldap (quitte a mettre des zones de texte si on veut remplir)
|
|
|
|
|
|
|
|
Je pense qu’on va se coltiner du XML au début mais qu’à long terme on peut imaginer faire un schéma LDAP pour la config LSC et dans un premier temps avoir un code qui convertit en XML, et dans un second temps ptet faire un backend LDAP dans LSC.
|
|
|
|
|
|
|
|
Oui c'est plus de la facilité, mais faudra de toute facon un endroit ou on stock notre XML de base (ou notre futur ldap qu'on convertira par la suite)
|
|
|
|
|
|
|
|
|
|
|
|
===============================
|
|
|
|
|
|
|
|
je propose on ouvre un page lsc dans le wiki des plugins avec la formalisation des idees sur le backend ldap de lsc, schema prevu et idee de mise en place
|
|
|
|
|
|
|
|
Pour moi c’est trop tôt j’ai pas encore utilisé LSC même en test, j’ai pas d’idée précise des options de config qui servent ou pas, et la configuration XML LSC mélange au même endroits des choses qu’on voudra probablement séparer dans LDAP (configuration, sources/destinations, taches, logs…).
|
|
|
|
|
|
|
|
on peut deja laisser k1412 ecrire ce qu'il pense vu que c'est le plus gros utilisateurs ici :) ca servira de base de reflexion
|
|
|
|
|
|
|
|
on complemente la page zimbra avec les differentes discussions ici pour bien montrer quels sont les idees , facon de faire possible et problemes actuels
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
================================
|
|
|
|
|
|
|
|
Synchro vers FD
|
|
|
|
|
|
|
|
Une des idées derrière l’utilisation de LSC et d’un plugin pour l’API REST de FD c’est de pouvoir synchroniser vers FD.
|
|
|
|
Et dans ce cas là on aura pas la possibilité d’afficher dans FD le retour d’erreur (FD sera même pas forcément lancé).
|
|
|
|
|
|
|
|
J'aurais pensé voir FD comme l'interface qui permettrait de "lancer" des config LSC du coup il aurait toujours les infos (sauf si la sychro écrase les infos qu'il stock pour LSC bien sur). J'aurais plus vu ça comme du OPSI/FAI ou on peut égalemet trigger une synchro avec une config si on veut. En plus si FD simplifie dans le futur la configuration de LSC, y a interet à le lancer depuis FD même si la synchro c'est AD -> FD par exemple
|
|
|
|
Dans ces cas là tu le «lance» une fois, tu le démarre en mode service après tu touches plus. Donc ça change rien à la question du retour d’erreur.
|
|
|
|
Pour moi le retour doit juste être un statut, le démon qui stock dans le ldap la tache x a reussi ou raté ça me va ^^ (l'erreur complete serait mieux mais je penses pas qu'on popup qui s'affiche des que c'est fini soit prioritaire avoir un visuel des taches sera déjà un gros truc a faire)
|
|
|
|
|
|
|
|
|
