Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Ce script permet d'interroger le ldap pour connaître les personnes qui sont à resynchroniser par rapport à ce qui existe dans Grouper. Ceux qui sont à modifier sont enregistrer dans le fichier uidATraiter et sont synchronisés l'un après l'autre par un sync. S'il y a eu des personnes synchronisées, le fichier uidATraiter est mémorisé dans un répertoire à part avec la date de publication. Cela permet de suivre ce qu'il se fait, c'est rassurant au début !

Il faut savoir que la synchronisation Grouper-Ldap version 1.6.3 n'est pas optimum car elle interroge systématiquement ldap pour chaque personne présente dans un groupe Grouper, ce qui est consommateur côté ldap. L'administrateur ldap ayant des craintes, il n'a pas souhaité que j'utilise un bulkSync mais un sync sur ceux à modifier. Finalement, en connaissant mieux cette synchronisation, je me rends compte que cela revient au même mais au moins, cela l'a rassuré et m'a permis de continuer Grouper. Il faut attendre les futures versions de ce connecteur pour avoir une version incrémentale : plutôt que d'interroger ldap, le connecteur interrogera Grouper pour savoir ce qui a été modifié depuis la dernière synchronisation (voir la version 2.1 de Grouper qui devrait sortir fin 2011).

  2. Mettre tous les membres des groupes (publiant dans la branche ou=people du ldap) dans un groupe témoin

NettoyerPuisDonnerLeRoleTemoin.sh - pourNettoyerRoleTemoin.sh - nettoyerLeRoletemoin.gsh - pourDonnerLeRoleTemoin.sh - donnerLeRoleTemoin.gsh -

Il y a actuellement un problème avec le couple Grouper/ldappcng (sera corrigé avec l'arrivée du "real-time and incremental provisioning" prévu à la roadmap). Le problème est qu'il ne publie les modifications dans le ldap QUE pour les membres des groupes. Cela fait que si la personne n'est plus membre d'aucun groupe, il ne sera pas publié et l'on pourrait donc avoir un décalage entre ce qui est dans le ldap et ce qui est dans Grouper. Par exemple, user1 est membre de mongroupe1 et mongroupe2. Il est publié dans le ldap avec l'attribut ustlRole (pour Lille1) égal à 2 valeurs : mongroupe1-users et mongroupe2-users. Après sa publication dans le ldap, il est retiré de ces 2 groupes et ne figure plus dans aucun autre groupe : à ce moment-là, il n'est pas republié dans le ldap car le module ldappcng n'interroge et met à jour ldap que pour ceux qui sont dans des groupes Grouper...

...

En attendant, j'ai prévu une "rustine" pour éviter que cela se produise. Je mets systématiquement tout membre d'un groupe publiable dans le ldap (mes fameux groupes de type ustlRole) dans un groupe qui sert de témoin de présence : groupe témoinustlRole.

...

Attention, j'ai dû créer 2 sources.xml différents : l'un pour ce groupershell et l'un pour LiteUI car mon administrateur ldap souhaitait que j'optimise mes requêtes ldap pour ces scripts. Donc, dans le script pourDonnerLeRoleTemoin.sh, j'utilise la fonction SubjectFinder.findAll("*") qui utilise la recherche sur l'attribut "ustlRole" paramétrée dans sources.xml(.gsh) :

Bloc de code

<search>
       <searchType>search</searchType>
         <param>
            <param-name>filter</param-name>
            <param-value>(ustlRole=%TERM%)</param-value>
etc
</search>

Si je laissais le sources.xml comme cela, LiteUI ne fonctionnerait pas car il rechercherait sur l'attribut ustlRole plutôt que sur l'uid et le displayName comme paramétré dans sources.xml(.liteui) :

Bloc de code

<search>
       <searchType>search</searchType>
         <param>
            <param-name>filter</param-name>
            <param-value>(&amp; (|(uid=%TERM%)(displayName=*%TERM%*)))</param-value>
        </param>
etc
</search>

  3. Initialisation des données : peupler les groupes depuis le ldap

chargerustlRoles.gsh - chargerAdmin.gsh

Ceux-ci permettent de peupler les groupes Grouper à partir des valeurs déjà présentes dans l'annuaire (reprise de l'existant dans ldap dans Grouper).

Le premier permet de mettre comme membres du groupe Grouper de type "PAGSRole" toutes les personnes du ldap dont l'attribut ustlRole a la même valeur que l'attribut "ustlRole" du groupe Grouper.

Le second permet de mettre le droit Grouper "UPDATE" à toutes les personnes du ldap dont l'attribut ustlRole est égal à admin-+"valeur de l'attribut "ustlRole" du groupe Grouper. Par exemple, ceux qui ont ustlRole=admin-IntranetEquipeDirection auront le droit UPDATE sur le groupe Grouper dont l'attribut "ustlRole=IntranetEquipeDirection-users". Ils rejoindront aussi le seul groupe d'administration d'application que nous avons créé dans Grouper : le groupe des administrateurs d'application dont l'attribut "ustlRole=admin-appli".

Brigitte WALLAERT-TAQUET