proj-esup-grouper

Raccourcis espace

Arborescence des pages

Comparaison des versions

Ancienne version 48

changes.mady.by.user Vincent Bonamy

Sauvegardée le

comparé à

Nouvelle version Actuel

changes.mady.by.user Vincent Bonamy

Sauvegardée le

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.

...

Pour faciliter l'installation de Grouper, ce document propose ainsi de partir d'un "fork" github de Grouper (correspondant initialement aux travaux de configuration de Grouper de l'Université de Paris1) à reparamétrer. Ce document vous indique ce qu'il faut reparamétrer et comment installer les services correspondants. Cette démarche a par ailleurs fait l'objet d'une présentation en 2018 lors d'Esup-Days  n°25, présentation que nous vous invitons à consulter ; diaporama et vidéo disponible ici : Installation rapide de Grouper à la ESUP

Une fois que vous aurez une installation "simple" et fonctionnelle intégrée dans votre système d'information, libre à vous par la suite d'aller (éventuellement) plus loin dans l'usage de Grouper.
Gouper peut cependant tout à fait convenir à un usage circonscrit comme proposé ici ; cette intégration ayant alors le mérite de rester relativement simple, de ne pas sortir des clous par rapport à ce qui se fait "basiquement" avec Grouper ; on retire alors les avantages d'une maintenance facilitée par exemple.

...

  • authentification shibboleth sur les interfaces web Grouper - même si ici seuls les personnels de l'établissement sont amenés à s'authentifier sur celles-ci dans cette configuration.
  • le LDAP de l'établissement est un openldap basé sur les recommandations (et schémas) Supann
  • les potentiels membres des groupes (source des individus pour grouper) sont tous issus du LDAP de l'établissement et on utilise comme identifiant non pas leur uid ldap mais leur eppn (eduPersonPrincipalName)

  • les groupes sont poussés/synchronisés dans le Ldap comme groupOfNames ('plus supann' et ‘plus standard’ que les posixGroup) côté ou=groups et éventuellement (conseillé) memberOf côté ou=people (via un overlay) par Grouper

  • la nomenclature des groupes dans ldap reprend la nomenclature hiérarchique des groupes de grouper Grouper - les ":" sont transformés  en "." dans le passage de l'id de grouper Grouper au dn ldap
  • les applications utilisant les groupes ne conversent pas avec Grouper mais avec LDAP (cf schéma ci-dessous)

...

  • eduPersonPrincipalName et memberOf côté ou=people (Attention constaté une dégradation des perfs en indexant l'attribut interne memberOf (D.Lalot))
  • member côte ou=groups

https://www.vincentliefooghe.net/content/ajout-dindex-sur-un-annuaire-openldap

...

https://www.vincentliefooghe.net/content/optimisation-openldap-pour-la-suppression-dun-membre-dun-groupe

Dimensionnement serveurs

Le service Grouper peut fonctionner sur un unique serveur sur lequel on fait tourner 

  • les services java/tomcat correspondant aux applications web grouper et tâches de fond de synchronisation de groupes avec ldap
  • le frontal apache/mod_shib
  • la base de données postgresql

La gestion de synchronisation de calcul et synchronisation de groupes de quelques milliers d'individus peut solliciter beaucoup le ldap mais également le serveur Grouper.
Aussi pour un établissement de quelques dizaines de milliers de personnes, vous pouvez envisager l'usage d'un serveur (VM) avec 4 CPUs et 8 GB de RAM.

Pour l'espace disque, il faut compter simplement quelques GB pour la base de données et quelques GB pour les sources et binaires Grouper.

Pour la disponibilité du service, notre contexte d'usage fait qu'une indisponibilité de Grouper ne permet plus de mettre à jour les groupes simplement. L'usage des groupes par les applicatifs est en effet porté par LDAP.
Une indisponibilité de Grouper n'est donc pas critique.

Eléments techniques à installer sur le serveur qui héberge Grouper.

Java / Tomcat

Les service Grouper correspondent à des applications Java / Tomcat.

Ceux-ci fonctionnent avec un JDK 1.7 et Tomcat 6.

  • vous pouvez prendre le JDK 1.7 distribué par Oracle ou plutôt (recommandation) la version openjdk 1.7 de votre distribution (yum install java-1.7.0-openjdk-devel pour CentOs 7) ... en effet, le JDK 1.7 distribué par Oracle n'est plus disponible/maintenu publiquement (gratuitement).
  • pour Tomcat, prenez la dernière version 6 proposée - https://archive.apache.org/dist/tomcat/tomcat-6/v6.0.39/bin/

Pour construire les binaires depuis les sources, nous avons également de ANT

Ant

Si vous avez installé le JDK de votre distribution, installez dans la foulée le Apache Ant de la même façon (yum install ant pour CentOS 7).

Java

On édite un fichier /opt/grouper-env qui est un fichier d'environnement utilisé par les différents scripts de démarrage de service et par un utilisateur 'grouper' (à créer) sous lequel on travaille (lancement du tomcat, scripts de synchro, client shell grouper).

Bloc de code
#!/bin/sh
JAVA_HOME=/usr/lib/jvm/java
JAVA_OPTS="-Dgrouper.home=/opt/grouper-esup/grouper -Xms1512m -Xmx1512m -XX:MaxPermSize=512m"

Pour faciliter la prise en compte de ce  fichier d'environnement dans un environnement bash, on réalise également un fichier /opt/env.sh :

Bloc de code
#!/bin/sh
set -o allexport
source /opt/grouper-env
PATH=$PATH:$JAVA_HOME/bin
set +o allexport

Ainsi dans ~grouper/.bashrc en fin de fichier on ajoute : 

Bloc de code
. /opt/env.sh

...

Dézippez le tomcat dans /opt et faites le appartenir à l'utilisateur 'grouper'.

Un lien symbolique est fait /opt/tomcat-grouper -> /opt/apache-tomcat-6.0.35 - on utilise ensuite /opt/tomcat-grouper comme chemin d'accès au tomcat dans les fichiers de configuration.

Dans /opt/tomcat-grouper/conf/server.xml on ajoute dans la balise Server < Service < Host les 2 contextes suivants : 

Bloc de code
<Context docBase="/opt/grouper-esup/grouper-ui/dist/grouper" path="/grouper" reloadable="false"/>
<Context docBase="/opt/grouper-esup/grouper-ws/grouper-ws/build/dist/grouper-ws" path="/grouper-ws" reloadable="false"/>

Pour que l'authentification avec shibboleth fonctionne (passe), il est important (requis) d'ajouter l'attribut tomcatAuthentication="false" dans le connector utilisé (ajp a priori avec apache devant en proxypass ajp) :

Bloc de code
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false"/>

PostgreSQL

Grouper utilise une base de données SQL. Installez le serveur postgresql fourni par votre distribution puis créez une base pour grouper : 

Bloc de code
create database grouper;
create USER grouper  with password 'esup';
grant ALL ON DATABASE grouper to grouper;

Apache et mod_shib

Comme pour la plupart des applications 'shibbolethisées', l'authentification/identification shibboleth est effectuée par Apache et le mod_shib.

Il faut donc configurer un SP shibboleth prêt à l'emploi pour Grouper et un virtualhost en https://grouper.univ-ville.fr 

Différentes documentations peuvent vous aider : 

Une fois le Virtualhost apache et SP shibboleth paramétré comme il se doit, on doit accéder et tester la bonne configuration de l'ensemble via une url du type : https://grouper.univ-ville.fr/secure

Votre fichier de configuration Apache pouvant ressembler à cela : 

...

Info
titlemoteur backend

Cet ajustement de tri est effectivement utile lorsqu'on utilise un backend comme BDB (Berkeley DataBase)

Avec d'autres moteurs plus récents/évolués comme LMDB, il semblerait que ce ne soit plus nécessaire.

Ce backend plus récent se montre plus performant ; openldap recommande maintenant son usage : https://www.vincentliefooghe.net/content/openldap-changer-moteur-backend

Ajustement de la RAM pour openldap avec LMDB

Rappel : cf plus haut, (L)MDB est recommandé et est maintenant le backend donné par défaut dans la plupart des distributions.

  • LMDB monte la base en RAM pour pouvoir l'exploiter ;
  • grouper fait des requêtes assez conséquentes (1 pour trouver un groupe puis 1 par membre d'un groupe) qui, si vous avez des groupes comprenant finalement l'ensemble des individus, correspondent finalement à requêter très régulièrement toute la base ;
  • les requêtes, notamment sur les membres, sont mises en cache par grouper (via ehcache) en RAM ... 
    • on peut ajuster cette configuration d'ehcache
    • cependant, le script export-modified-groups-to-LDAP fonctionne en lançant une nouvelle instance de gsh (== grouper) à chaque modification de groupe : le cache ehcache de grouper est alors impuissant
  • si votre serveur LDAP dispose d'un espace RAM plus petit que la taille de votre base, alors :
    • LMDB se verra contraint de flusher une partie de la base pour monter la partie qu'il doit lire et qu'il n'avait pas pu monter en RAM faute d'espace ; si vous consultez l'ensemble de la base très régulièrement, vous provoquez ce mécanisme de manière cyclique !
    • en conséquence, vous pouvez alors constater un usage du disque en lecture (IO READ) très important.

→ en LMDB, et notamment avec grouper qui peut solliciter beaucoup le ldap, il est vivement recommandé de fournir assez de RAM au serveur pour que l'ensemble de la base (ou au moins la base "utile") puisse être monté en RAM :
en disposant d'un volume de RAM supérieur à la taille (effective) du .mdb (dans /var/lib/ldap/ généralement), on s'assure d'éviter de l'IO (lecture) trop important. Privilégiez également des disques SSD pour les VMs du LDAP (imports LDIFs et réindexations).

Pour avoir la taille effective: ll -sh *mdb
1,9G -rw------- 1 openldap openldap 6,6G nov.   8 12:06 data.mdb
4,0K -rw------- 1 openldap openldap 8,0K nov.   8 12:08 lock.mdb

Dimensionnement serveurs

Le service Grouper peut fonctionner sur un unique serveur sur lequel on fait tourner 

  • les services java/tomcat correspondant aux applications web grouper et tâches de fond de synchronisation de groupes avec ldap
  • le frontal apache/mod_shib
  • la base de données postgresql

La gestion de synchronisation de calcul et synchronisation de groupes de quelques milliers d'individus peut solliciter beaucoup le serveur ldap mais également le serveur Grouper.
Aussi pour un établissement de quelques dizaines de milliers de personnes, vous pouvez envisager l'usage d'un serveur (VM) avec 4 CPUs et 8 GB de RAM.

Pour l'espace disque, il faut compter simplement quelques GB pour la base de données et quelques GB pour les sources et binaires Grouper.

Pour la disponibilité du service, notre contexte d'usage fait qu'une indisponibilité de Grouper ne permet plus de mettre à jour les groupes simplement. L'usage des groupes par les applicatifs est en effet porté par LDAP.
Une indisponibilité de Grouper n'est donc pas critique.

Éléments techniques à installer sur le serveur qui héberge Grouper.

Java / Tomcat

Les service Grouper correspondent à des applications Java / Tomcat.

Ceux-ci fonctionnent avec un JDK 1.7 et Tomcat 6.

  • vous pouvez prendre le JDK 1.7 distribué par Oracle ou plutôt (recommandation) la version openjdk 1.7 de votre distribution (yum install java-1.7.0-openjdk-devel pour CentOs 7) ... en effet, le JDK 1.7 distribué par Oracle n'est plus disponible/maintenu publiquement (gratuitement).
  • pour Tomcat, prenez la dernière version 6 proposée - https://archive.apache.org/dist/tomcat/tomcat-6/v6.0.39/bin/

Pour construire les binaires depuis les sources, nous avons également besoin de ANT

Ant

Si vous avez installé le JDK de votre distribution, installez dans la foulée le Apache Ant de la même façon (yum install ant pour CentOS 7).

Java

On édite un fichier /opt/grouper-env qui est un fichier d'environnement utilisé par les différents scripts de démarrage de service et par un utilisateur 'grouper' (à créer) sous lequel on travaille (lancement du tomcat, scripts de synchro, client shell grouper).

Bloc de code
#!/bin/sh
JAVA_HOME=/usr/lib/jvm/java
JAVA_OPTS="-Dgrouper.home=/opt/grouper-esup/grouper -Xms1512m -Xmx1512m -XX:MaxPermSize=512m"

Pour faciliter la prise en compte de ce  fichier d'environnement dans un environnement bash, on réalise également un fichier /opt/env.sh :

Bloc de code
#!/bin/sh
set -o allexport
source /opt/grouper-env
PATH=$PATH:$JAVA_HOME/bin
set +o allexport

Ainsi dans ~grouper/.bashrc en fin de fichier on ajoute : 

Bloc de code
. /opt/env.sh


Tomcat

Dézippez le tomcat dans /opt et faites le appartenir à l'utilisateur 'grouper'.

Un lien symbolique est fait /opt/tomcat-grouper -> /opt/apache-tomcat-6.0.35 - on utilise ensuite /opt/tomcat-grouper comme chemin d'accès au tomcat dans les fichiers de configuration.

Dans /opt/tomcat-grouper/conf/server.xml on ajoute dans la balise Server < Service < Host les 2 contextes suivants : 

Bloc de code
<Context docBase="/opt/grouper-esup/grouper-ui/dist/grouper" path="/grouper" reloadable="false"/>
<Context docBase="/opt/grouper-esup/grouper-ws/grouper-ws/build/dist/grouper-ws" path="/grouper-ws" reloadable="false"/>

Pour que l'authentification avec shibboleth fonctionne (passe), il est important (requis) d'ajouter l'attribut tomcatAuthentication="false" dans le connector utilisé (ajp a priori avec apache devant en proxypass ajp) :

Bloc de code
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false"/>

PostgreSQL

Grouper utilise une base de données SQL. Installez le serveur postgresql fourni par votre distribution puis créez une base pour grouper : 

Bloc de code
create database grouper;
create USER grouper  with password 'esup';
grant ALL ON DATABASE grouper to grouper;

Apache et mod_shib

Comme pour la plupart des applications 'shibbolethisées', l'authentification/identification shibboleth est effectuée par Apache et le mod_shib.

Il faut donc configurer un SP shibboleth prêt à l'emploi pour Grouper et un virtualhost en https://grouper.univ-ville.fr 

Différentes documentations peuvent vous aider : 

Une fois le Virtualhost apache et SP shibboleth paramétré comme il se doit, on doit accéder et tester la bonne configuration de l'ensemble via une url du type : https://grouper.univ-ville.fr/secure

Votre fichier de configuration Apache pouvant ressembler à cela : 

Bloc de code


</VirtualHost>
 

<VirtualHost *:443>80>

    ServerName grouper.univ-ville.fr
    ServerAlias grouper

    ServerAdmin dsi@univ-ville.fr
    ServerSignature Off

    LogLevel warn
    ErrorLog /var/log/apache2/error.log
    CustomLog /var/log/apache2/access.log combined
 
  Redirect / https://grouper.univ-ville.fr/

</VirtualHost>
 

<VirtualHost *:443>

   ErrorDocument 503 /503/index.html
ServerName grouper.univ-ville.fr
    ProxyPass /503 !ServerAlias grouper

    RewriteEngineLogLevel Onwarn
    RewriteCond %{HTTP_HOST}   !^grouper.univ-ville.fr$ErrorLog /var/log/apache2/error.log
    RewriteRule ^(.*)         https://grouper.univ-ville.fr [L,R,NE]
    RewriteRule ^/$ 	      /grouper [L,R,NE]CustomLog /var/log/apache2/access.log combined
    ErrorDocument 503 /503/index.html

    ProxyPass /503 !

    SSLEngineRewriteEngine onOn
    SSLCertificateFileRewriteRule /etc/pki/tls/certs/localhost.crt
^/$ 	     SSLCertificateKeyFile /etc/pki/tls/private/localhost.key /grouper [L,R,NE]

    SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crtSSLEngine on

    ProxyPass /Shibboleth.sso !
    ProxyPass /secure !
    ScriptAlias /secure /var/www/printenv.pl

   <Location /secure>
     AuthType shibboleth
     ShibRequestSetting requireSession 1
     require shib-session
     ShibUseHeaders On
   </Location>

   <Location /grouper>
     AuthType shibboleth
     ShibRequestSetting requireSession 1
     require shib-session
     ShibUseHeaders On
   </Location>

   ProxyPass / ajp://localhost:8009/ ttl=10 timeout=3600 loadfactor=100 retry=1

</VirtualHost>

Grouper ESUP

...

Info
titlegrouper-loader.properties

grouper-loader.properties permet en effet de paramétrer des bases de données permettant de réaliser des groupes dynamiques par requettages sql (ces requêtes étant données / paramétrées via l'interface homme machine).

 Une Une fois votre grouper d'Grouper installé, c'est le seul fichier que vous aurez à modifier de temps en temps pour pour pouvoir requêter de nouvelles bases de données ; la requête en elle-même est saisi dans l'IHM mais pas les paramètres d'accès aux bases de données ... en tout cas en Grouper 2.3 car en 2.4 il se pourrait que ce soit une nouvelle possibilité de l'IHM de Grouper !

...

Pour que les modifications de fichiers (configurations) soient prises en compte, en plus de redémarrer les services Grouper (cf ci-dessousplus de redémarrer les services Grouper (au sens unix / daemon; cf ci-dessous cela correspond aux services tomcat-grouper.service, grouper-loader-daemon.service et export-modified-groups-to-LDAP.service) vous devez redéployer les briques Grouper.

Vous stoppez les 3 services Grouper puis vous lancez successivement les redéploiements redéploiements suivants :

Bloc de code
cd /opt/grouper-esup/grouper-ui/
ant clean dist
cd /opt/grouper-esup/grouper-ws/grouper-ws/
ant clean dist

Vous redémarrez les 3 services précédemment stoppés.

Présent dans les sources Grouper, nous avons ici déployé naturellement grouper-ws ... même si celui-ci est complètement optionnel. Si vous ne vous en servez pas, vous n'êtes docn donc pas obligé de le déployer et de déclarer son contexte dans la configuration tomcat.

...

Vérifiez dans /var/log/messages la bonne exécution de l'ensemble. Pour une bonne mise en oeuvre de ces services, vous pouvez les tester individuellement avec l'utilisateur grouper en els les lançant depusi depuis une console directement.
En effet, certains scripts peuvent requérir la présence de certaines bibliothèques supplémentaires : export-modified-groups-to-LDAP est un script perl qui utilise des bibliothèques perl comme DBI ou  encore DBD-PG (yum install perl-DBI perl-DBD-Pg pour Centos).

...

Vous pouvez maintenant utiliser votre grouper Grouper et initier votre arborescence de groupes.

...