e-sup UNR PACA

Vous êtes ici -> ArchiFinale
Home :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-34-230-84-215.compute-1.amazonaws.com

Architecture Avignon

Version définitive : ! done

1. Présentation

1.1 Objectifs

La plate-forme doit fournir les services ESUP et CAS de manière a tolérer les pannes quelqu'elles soient et d'être échelonnable en cas de monter en charge de la plate-forme. De plus elle doit pouvoir accueillir d'autres applications java/webapps sans impacter les services déja en production (concept de mutualisation).

1.2 Fonctionnalités

Les fonctionnalités ci-après ont été implémenté :
  • Hebergement mutualisé d'applications (virtualhosting)
  • Répartition de charge en fonction de l'adresse IP du client et persistance de la connexion "client/serveur" tant que le service est disponible
  • Données partagées (NFS)
  • Configuration Apache & Tomcat partagées (NFS)
  • Surveillance mutuelle des VS
  • Surveillance de la disponibilité des serveurs applicatifs.


2. Choix technique

Notre choix technique s'est basé très simplement en fonction de nos acquis, c'est à dire :
  • des serveurs bas et moyen gamme :)
  • nos connaissances dans le domaine GNU/Linux Debian
  • l'implémentation de nos services déja existants (LDAP, NFS, etc)

2.1 Matériel

Nous avons utilisé 4 serveurs sous GNU/Linux Debian.
- 2 serveurs LVS (linuxvirtualserver) utilisés pour le loadbalancing des services (seront utilisés par 2 autres plate-formes web a venir)
- 2 serveurs Apache Tomcat utilisés pour héberger nos applications Java & webapps

Les serveurs LVS sont des Céléron 500Mhz avec 128Mo de RAM. La répartition de charge ne prend pas de ressources, tout ce fait au niveau de la couche 2 (OSI). C'est à dire remplacer une adresse MAC par une autre. En effet nous utilisons le mode Direct Routing (DR) de LVS. Nos deux fiers Céleron encaissent sans problème un trafic de 90Mbps avec un petit 0.05 de load.

Les serveurs Tomcat sont des P4 3Ghz avec 512Mo de RAM. Ces machines devraient être suffisant costauds pour tenir une charge de 200 connectés simultanés. Il n'est pas improbable qu'un jour nous augmentions la RAM (a voir en f° de l'utilisation).

Quant à l'infrastructure réseau, nous utilisons nos switchs niveaux 2 sans aucunes modifs ou crontraintes particulières.

2.2 Logiciel

Pour la répartition de charge nous utilisons Linux Virtual Server (LVS) couplé a Keepalived.
- LVS : effectue le travail de loadbalacing en mode actif/actif
- keepalived : effectue le travail de haute disponibilité (redondance des VS, add/suppr du pool un serveur applicatif)

Les serveurs applicatifs utilisent:
- apache2 : pour la gestion des pages statiques et des connexions SSL
- mod_jk 1.2.16 : comme connecteur AJP13 entre apache2 et tomcat
- tomcat 5.5.17 : pour la gestion des JSP et des servlets

Enfin de nombreux scripts shells/perl « home made »

3. Fonctionnement

Nous expliquerons ci-après le fonctionnement de la plate-forme dans des conditions normales. Les cas de pannes seront détaillés a l'aide schémas ci-après.

3.1 Répartion de charge

LVS va répartir la charge en fonction d'un algorithme de "routage" : SH (Source Hash de Wensong). Il route le client toujours vers le même serveur, pour cela il se base sur l'adresse MAC. L'avantage de cette technique face un « round robbin » ou un « least connected » est l'absence « d'affinity » (persistence d'une session - relation client/serveur_applicatif). Si nous utilisons des sessions et que le serveur applicatifs tombe, il faudra que le client attende l'expiration de la session avant qu'il soit redirigé vers un serveur en fonction. Le timeout d'une session est évidemment paramétrable. Cependant il ne faut pas le régler trop bas au risque de rediriger le client vers un autre serveur applicatif (autre session suite a expiration) qui n'est pas au courant de la session applicative en cours (limitation dû à la conception des sessions d'ESUP). En résumé, nous allons tester SH. Dans le cas où la répartition de charge ne serait pas équitable (bcp d'accès NATés ou externes) nous changerons le mécanisme de routage en « least connected » avec un persistence des sessions à 5min. Remarque : A savoir que le poids (weight) d'un serveur (realserver) défini dans ipvsadm pour un l'algo SH signifie le nbre de connexions simultanées x 2. Donc il ne faut le laisser a 1, nous l'avons configuré a 500 :)

3.2 Haute disponibilité

Keepalived se charge de :
  • de surveiller les Virtuals IP (VIP) des 2 serveurs LVS (dits directeur/director)
  • de surveiller la disponibilité des serveurs applicatifs donc de les retirer et de les reintégrer du pool.

Keepalived est configuré pour mettre LVS en mode actif/actif. Cela signifie que nos 2 directors gèrent des accès a des VIPs en mode master/slave et slave/master.
Pour le moment nous avons 2 VIPs en place. Notre premier director gère la VIP d'ESUP alors que le second gère la VIP de CAS (cas particulier voir plus loin). Les 2 Keepalived se surveillent via VRRP. Enfin Keepalived surveille les serveurs applicatifs via des connexions TCP sur le port 80 et 443 des Real IP (RIP) des serveurs applicatifs.

3.3 Applicatif

Nous avons décidé de mettre le tuple : (apache2, mod_jk, tomcat) sur une même machine. En effet, ce n'est pas une méthode courante. De manière générale, on rencontre un couple (apache2,mod_jk) et (tomcat). Le dialogue entre ces 2 couples s'effectuent via un protocole empirique nommé AJP13.
Par rapport a notre expérience dans le domaine, nous avons tout mis sur un même serveur pour éviter les locks et perte de connexion AJP13 qui ne peuvent pas arriver sur un même serveur (puisque localhost, pas de notions de "vrais" socket et de "superbes" TIME_WAIT en série).

Le but étant la mutualisation, apache2 est configuré en mode « Virtual Host » (modulaire avec a2ensite/a2dissite). Et Tomcat de même avec un système de gestion des VHOSTS modulaire « home made ». Oui, nous n'avons pas utilisé le package Tomcat d'ESUP puisque nous ne voulions pas dédier ces 2 serveurs applicatifs uniquement à ESUP. Nous ne voulions pas que d'autres applications java/webapps soit dépendante de la distribution ESUP.

Vous trouverez en annexe les configs VHOST de ESUP/CAS (apache2 & tomcat)

Versions :
- apache 2.0.16 (paquet debian stable)
- mod_jk 1.2.16 (last)
- Tomcat 5.5.17 (last)

4. Schémas de fonctionnement

Les schémas ci-après essayent d'imager les dialogues réseaux entre les protagonistes de la plate-forme dans un cas normal et dans des cas particuliers de pannes.
Voici tout d'abord un schéma présentant la plate-forme dans sa totalité. Comme on peut le voir un client désirant se connecter aux services applicatifs passe par un directeur (VS ayant la VIP demandée) puis est redirigé vers un serveur applicatif suivant l'algorithme SH. Le serveur applicatif charge et cherche les données demandées sur NFS pui traite la demande et répond directement au client.

LVS-final.png?

4.1 ESUP

Esup est un service mutualisable (non pas sans encombres!) qui est donc loadbalancé sur les 2 ou n serveurs applicatifs que nous pourrions avoir dans le futur. Les 3 schémas ci-après font montrer un fonctionnement normal, une panne de directeur, et une panne de serveur applicatif.
4.1.1 Normal
Imaginons 2 clients qui désirent se connecter a ESUP. Le loadbalancing se charge de repartir les clients équitablement. Chaque serveur répond directement à ses clients.
LVS-ESUP.png?

4.1.2 VS HS
Nous sommes dans un premier cas de panne. Le VS01 tombe en panne. Or c'est lui qui gère l'adresse IP virtuelle du service ESUP. Au bout de 3 à 5 secondes, le mécanisme de surveillance mutuelle des VS (via VRRP) détecte l'absence de VS01. De ce fait VS02 monte la VIP d'ESUP (et les autres que VS01 aurait géré). Les clients C1 et C2 se connectent de manière transparente a VS02, ni vu ni connu. Cependant, il y aura des effets de bords du aux sessions applicatifs ESUP. Il se peut très bien que C1 était sur le serveur applicatif TOMCAT01 et que maintenant via le directeur VS02 il soit dirigé vers le serveur applicatif TOMCAT02 avec des identifiants de sessions de TOMCAT01 n'ayant aucune valeur sur TOMCAT02
LVS-ESUP-VS.png?

4.1.3Tomcat HS
Voici le second cas de panne, un serveur applicatif tombe en rade. Les directeurs détectent la panne du serveur applicatifs via un test TCP récurrent et sortent automatiquement le serveur applicatif du pool de serveurs dédiés à la VIP d'ESUP. TOMCAT01 gére tout le trafic, mais dans le cas ou nous aurions eu un TOMCAT03, c'est TOMCAT01 et TOMCAT03 qui recupereraient tout le trafic de manière équitable.
LVS-ESUP-TOMCAT.png?

4.2 CAS

CAS, de part sa conception n'est pas mutualisable. En effet, le service conserve en zone mémoire tous ses tickets. De ce fait il est difficile de partager la charge du service avec un autre serveur CAS. Ce défaut de conception sera corrigé dans CAS 3.0 qui intégrera une zone de stockage des tickets lisible par d'autres serveurs CAS. En attendant, il nous est peut etre impossible de répartir la charge mais l'on peut toujours redonder le service en mode passif (principe master/slave). Dans notre cas c'est TOMCAT01 qui héberge le service CAS et qui délivre les tickets nécessaires. En cas de panne, c'est TOMCAT02 qui prend le relais.

4.2.1 Normal
Nos clients lambda se connectent sur le meme serveur TOMCAT car tout le flux de la VIP associé au service CAS pointe vers un seul serveur.
LVS-CAS.png?

4.2.2 VS HS
Premier cas de panne, un VS est hors service. Comme pour ESUP, le directeur toujours en lice récupère les VIPs du directeur HS et effectue le meme travail de routage que son prédécesseur.
LVS-CAS-VS.png?

4.2.3 Tomcat HS
Deuxième cas de panne, le serveur CAS est HS, en somme TOMCAT01 est HS. Le service CAS est donc totalement HS vu qu'il ne fonctionne que sur un seul serveur. Que faire ?! C'est là qu'intervient le serveur CAS "esclave", le "titulaire". C'est ici que nous avons bricolé une solution en détournant des fonctionnalités de keepalived (systeme de surveillance des VS et des pools de serveurs). Keepalived a une fonctionnalité nommée « Sorry Server ». Cette fonctionnalité permet de rediriger les clients vers un serveur d'excuse lorsque tous les serveurs du pool sont HS. Ceci permet d'être poli envers le client.

Pour en revenir a CAS, nous avons défini un pool de serveur pour CAS contenant uniquement un seul serveur, c'est à dire TOMCAT01 et nous avons défini TOMCAT02 en tant que "sorryserver". Ensuite nous avons configuré le systeme d'alerte SMTP de keepalived pour envoyer un mail à l'utilisateur "caskouil" de tomcat02c afin de le prévenir. Mais pourquoi le prévenir ? Pour que TOMCAT02 monte l'IP virtuel associé (VIP) au service CAS. En effet, la VIP n'est pas constamment monté sur TOMCAT02 car sinon lorsque le service ESUP qui tourne sur TOMCAT02 va essayer de contacter CAS pour une authentification il va trouver la VIP en local et donc interogger le service CAS en local. Qui lui, n'est pas en production mais juste là en secours.

En résumé, si TOMCAT01 tombe, les VS redirigent le flux vers TOMCAT02 en signalement également a TOMCAT02 qu'il doit monter son interface. Ce montage et démontage (qd TOMCAT01 est de nouveau OK) d'interface s'effectue via un script perl qui parse le contenu des mails et décident quoi faire selon les mails réceptionnés. Voilà. Nous avons appelé ce système « CAS Kouil ».

LVS-CAS-TOMCAT.png?

5. Détails

5.1 LVS et ARP HIDDEN

Pour que LVS fonctionne correctement, il faut attribuer les VIP sur les interfaces de loopback (lo en aliasing) les VIPs qu'ils servent. C'est à dire qu'il faut préciser aux serveurs fournissant du services (ici les tomcat) qu'il ne doivent pas répondre aux requetes ARP concernant les VIP du loopback. Sinon y a conflit d'adresse IP.
Avant il fallait patcher le noyau maintenant il est possible de désactiver cela via /proc.

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 2


5.2 multiserver ESUP kesako (web.xml) ?

Mais qu'est ce que « esup.multiserver=true » dans esup.properties. C'est très mal documenté mais voici ce qu'on a compris.
Ce paramètre est nécessaire pour le fonctionnement en mode CAS proxy d'ESUP. Pour mieux comprendre étudions qq infos de uPortal/WEB-INF/web.xml qui sont :
[..]
<!-- ESUP_CAS_PROXY -->
    <init-param>
      <param-name>edu.yale.its.tp.cas.client.filter.proxyCallbackUrl</param-name>
      <param-value>https://cas01c.univ-avignon.fr/CasProxyServlet</param-value>
    </init-param>
<!-- FIN_ESUP_CAS_PROXY -->
[..]
    <init-param>
        <param-name>org.esupportail.portal.security.HTTPSGatewayServlet.realUrl</param-name>
        <param-value>https://cas01c.univ-avignon.fr</param-value>
    </init-param>
[..]


Comme on peut le voir il y a 2 paramètres qui parlent de realURL ou de proxyCallBackURL. En théorie ces arguments sont complétés à partir du champ « esup.real.host » présent dans le esup.properties. Quoiqu'il arrive sur chaque serveur applicatif supportant ESUP il faut modifier le fichier web.xml afin de définir un FQDN pointant sur l'ip "réelle" du serveur applicatif (on utilise des CNAME). Mais pourquoi ?

Ceci est du au fonctionnement du proxy CAS. En effet, lorsqu'un client se connecte a ESUP via CAS, il se connecte via l'adresse de service esup.univ-avignon.fr (donc une VIP) et se trouve ensuite sur un serveur applicatif défini par le routage LVS. Jusque là tout va bien. Mais maintenant, lorsqu'on "proxycassifie" une application, il faut un ticket PGT pour avoir un ticket PT (cf charabia CAS). Or pour valider le PGT, CAS doit pouvoir se reconnecter sur le serveur applicatif qui en a fait la demande. Or s'il passe par l'adresse de service (donc VIP) il tombera ou tombera pas sur le bon (en gros 1/n chance de reussir avec n = nbre de serveurs). On ne peut pas se permettre de se baser sur la chance donc on définit une url de callback en https (indispensable) basée sur un alias du serveur applicatif. L'alias doit etre placé dans le virtualhost tomcat de ESUP (et non pas un vhost différent car contexte différent).
Cependant, nous ne savons pas trop à quel moment et à quoi sert le paramètre HTTPSGatewayServlet. Toute contribution est la bienvenue.
Voila.

5.3 vhost apache

Exemple de vhosts apache2

5.3.1ESUP
<VirtualHost 195.83.163.188:443>
        ServerName esup.univ-avignon.fr
        ServerAdmin cri@univ-avignon.fr

        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/esup.univ-avignon.fr.pem
        SSLCertificateKeyFile /etc/apache2/ssl/esup.univ-avignon.fr.nopass.key
        SSLCACertificateFile /etc/ssl/cacert.pem

        #JkMount  /* ajp13
        JkMount  /*.jsp ajp13
        JkMount  /*.uP ajp13
        JkMount /AxisServlet ajp13
        JkMount /CasProxyServlet ajp13
        JkMount /EsupMonitor ajp13
        JkMount /ExternalURLStats ajp13
        JkMount /Guest ajp13
        JkMount /HTTPSGateway ajp13
        JkMount /HttpProxyServlet ajp13
        JkMount /Instrumentation ajp13
        JkMount /Login ajp13
        JkMount /Logout ajp13
        JkMount /Problems ajp13
        JkMount /uPortal ajp13
        JkMount /manager/* ajp13

        <Location /manager/>
           Order deny,allow
           Deny from all
           Allow from .univ-avignon.fr
        </Location>

        DocumentRoot /var/www/esup/uPortal
        DirectoryIndex index.jsp
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/esup>
                Options FollowSymLinks 
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        LogLevel warn
        ErrorLog /var/log/apache2/vhosts/esup.univ-avignon.fr/error.log
        CustomLog /var/log/apache2/vhosts/esup.univ-avignon.fr/access.log combined

</VirtualHost>

# HTTP
<VirtualHost *>
      #
      # idem que la config HTTPs
      #
</VirtualHost>


5.3.2 CAS
<VirtualHost 195.83.163.189:443>
        ServerName cas.univ-avignon.fr
        ServerAdmin cri@univ-avignon.fr

        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/cas.univ-avignon.fr.pem
        SSLCertificateKeyFile /etc/apache2/ssl/cas.univ-avignon.fr.nopass.key
        SSLCACertificateFile /etc/ssl/cacert.pem

        JkMount  /*.jsp ajp13
        JkMount  /login ajp13
        JkMount  /logout ajp13
        JkMount  /validate ajp13
        JkMount  /serviceValidate ajp13
        JkMount  /proxy ajp13
        JkMount  /proxyValidate ajp13
        JkMount  /manager/* ajp13

        <Location /manager/>
           Order deny,allow
           Deny from all
           Allow from .univ-avignon.fr
        </Location>

        DocumentRoot /var/www/cas
        DirectoryIndex index.jsp
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/cas>
                Options FollowSymLinks
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        LogLevel warn
        ErrorLog /var/log/apache2/vhosts/cas.univ-avignon.fr/error.log
        CustomLog /var/log/apache2/vhosts/cas.univ-avignon.fr/access.log combined

</VirtualHost>

# HTTP
<VirtualHost *>
        ServerName cas.univ-avignon.fr
        ServerAdmin cri@univ-avignon.fr
        RewriteEngine on
        RewriteRule ^/(.*)         https://cas.univ-avignon.fr/$1 [L,R]
</VirtualHost>


5.4 vhosts tomcat

Exemple des vhosts tomcat

5.4.1 ESUP
<Host name="esup.univ-avignon.fr" appBase="/var/www/esup/uPortal" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
        <Alias>cas01c.univ-avignon.fr</Alias>
        <Context path="/manager" debug="0" privileged="true" docBase="/usr/local/server/webapps/manager"/>
        <Context path="" docBase="" crossContext="true" reloadable="true" debug="true" allowLinking="true">
          <!-- necessaire pour suivre les symlinks! -->
          <Resources className="org.apache.naming.resources.FileDirContext" allowLinking="true"  />
          
            <!-- Maximum number of dB connections in pool. Set to 0 for no limit.-->
            <!-- Maximum number of idle dB connections to retain in pool. Set to 0 for no limit.-->
            <!-- Maximum time to wait for a dB connection to become available in ms, in this example 10 seconds.-->
            <!-- An Exception is thrown if this timeout is exceeded.  Set to -1 to wait indefinitely. -->
          <Resource name="jdbc/PortalDb" auth="Container" type="javax.sql.DataSource"
            username="esup_main" password="toctoccpasceluila"
            driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://195.83.163.42/esup_main"
            maxActive="100" maxIdle="30" maxWait="10000"/>

          <Resource name="jdbc/PersonDb" auth="Container" type="javax.sql.DataSource"
            username="esup_main" password="toctoccpasceluila"
            driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://195.83.163.42/esup_main"
            maxActive="100" maxIdle="30" maxWait="10000"/>

            <!-- Disables restart persistence of sessions -->
            <Manager pathname=""/>
        </Context>
        <Valve className="org.apache.catalina.valves.AccessLogValve"
                 directory="/var/log/tomcat/vhosts/esup.univ-avignon.fr"  prefix="access_log." suffix=".txt"
                 pattern="common" resolveHosts="false"/>
      </Host>


5.4.2 CAS
<Host name="cas.univ-avignon.fr" appBase="/var/www/cas" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
        <Context path="/manager" debug="0" privileged="true" docBase="/usr/local/server/webapps/manager"/>
        <Context path="" docBase=""/>
        <Valve className="org.apache.catalina.valves.AccessLogValve"
                 directory="/var/log/tomcat/vhosts/cas.univ-avignon.fr"  prefix="access_log." suffix=".txt"
                 pattern="common" resolveHosts="false"/>
      </Host>


5.5 redondance CAS

Euh, je l'ai déja expliqué en fait... Voir principe « CasKouil? » plus haut. En tout ca été chiant; d'ou peut être le nom du principe :)


5.6 MOD_CAS


Voici le cheminement d'installation sur une debian Sarge avec apache2. Attention la configuration de "cas.conf" est étroitement lié a la configuration de votre serveur CAS. Vérifiez bien les paramètres.
# cd /usr/local/src
# wget http://www.esup-portail.org/consortium/espace/download/Mod_cas/Mod_cas-2.0.11-esup-1-RC1.tar.gz
# tar xvzf Mod_cas-2.0.11-esup-1-RC1.tar.gz 
# cd Mod_cas-2.0.11-esup-1-RC1/sources/cas
# apxs2 -i -c mod_cas.c ssl_client.c
   Le module est installé, via apxs2, dans /usr/lib/apache2/modules/mod_cas.so

# cd /etc/apache2/mods-available/
# cat > cas.load
LoadModule cas_module /usr/lib/apache2/modules/mod_cas.so
[CTRL+D]

# cat > cas.conf
<IfModule mod_cas.c>
      CASLocalCacheInsecure On
      CASLocalCacheFile /tmp/CAScache
      CASLocalCacheSize 1000
      CASLocalCacheTimeout 3600
      CASTrustedCACert /etc/ssl/cacert.pem
      CASLoginURL https://cas.univ-avignon.fr
      CASHost cas.univ-avignon.fr
      CASPort 443
      CasMethod GET
      CASValidate /validate
      CASCookieDomain .univ-avignon.fr
</IfModule>
[CTRL+D]

# a2enmod cas
# /etc/init.d/apache2 restart


Le CasCookieDomaine? est configuré pour tout notre domaine. Ainsi il n'y aura pas de problèmes pour les reverse proxy. Voir chapitre ci-après.

Pour tester mod_cas et l'authentification SSL :
curl --cacert sureserverEDU.pem https://cas.univ-avignon.fr



5.7 Reverse Proxy (mod_proxy) - FIXME FIXME

C'est non sans mal que nous avons réussi a faire fonctionner mod_proxy avec mod_cas. En effet, mod_cas a les défauts qu'on lui connait mais surtout il n'appréci pas du tout que des <Location> avec mod_proxy. C'est à dire que l'on ne peut pas tout virtualiser sous forme de URL virtuel (<Location>) comme l'exemple suivant :

http://esup.univ-avignon.fr <-- notre esup
/authcasproxies <--la zone mod_cas
/larousse <-- et la sous zone géré par mod_proxy pour le reverse proxy larousse par exemple

Cette exemple ci-haut ne fonctionne pas si l'on accède pas _d'abord_ à une page contenu (index.html par exemple) dans /authcasproxies (donc un <Directory> et non pas <Location> :). Pourquoi ?
Parce que le fait d'accèder a une vraie page HTML permet de positionner le cookie de mod_cas (MODCASID) sans quoi rien ne fonctionnerait et pour chaque URI du site larousse une demande de ticket et un passage par CAS seraient effectués. En résumé, si on accède directement au site Larousse, sans faire une pause dans /authproxies/index.html, rien ne se charge a part la page HTML du site larousse, toutes les images et CSS ne sont pas lus, sauf si on le demande explicitement. Bref ca marche pas.

Voici la solution finale:
Nous avons opter pour l'utilisation de virtualhost contenant chacun la configuration reverse proxy (et eventuellement mod_proxy_html) d'une base de données payante (larousse pour garder le meme exemple). Seulement, il ne faut tout de meme pas accèder directement a ce virtualhost sans quoi on a le meme effet de bord de cookie MODCASID non positionné et une page explosée. C'est pourquoi il y a un virtualhost particulier qui lui initie la première connexion/auth. mod_cas. C'est à dire que nous allons mettre dans bases-esup.univ-avignon.fr une page HTML qui regroupera tous les liens vers nos bases de données payantes à reverseproxifier. A partir de là, un clic sur le lien larousse rediregera vers le virtualhost larousse-bases-esup.univ-avignon.fr. Et la ca fonctionnera car le cookie a été positionné lors de l'accès a l'index.html de bases-esup.univ-avignon.fr. De plus cette technique evite de balader la donnée GET : ticket=ST-XX-ZYJQJQJS vers le site larousse qui lui de toute facon y comprendra rien.

En résumé, les avantages des VH au lieu d'utiliser des URI sous http://esup.univ-avignon.fr/ sont :
- positionnement du cookie MODCASID via un VH particulier
- pas besoin de reecrire les liens absolus /toto/pim/pam/poum du site larousse en /authcasproxies/larousse/toto/pim/pam/poum car on est ds un VH donc a un /
- les VHs de bases sont autonomes (pas de config ds le VH ESUP ou ds l'arborescence de fichiers ESUP).



6. Problèmes rencontrés

6.1 ant esup.moisi

Nous avons remarqué que le ant esup.deploy et ant esup.init ne deploie pas correctement lorsque c'est déja déployé. Pour palier a cela il faut tout nettoyer!! C'est à dire un ant esup.cleanall et des rm -rf des divers repertoires de deploiement (updateEsup, Custom, le rep de distrib, etc) Ce qui est très dommageable lorsqu'on a installer des canaux. Mais au moins vous etes sur que c'est propre.

6.2 concept du realserver

Nous avons perdu du temps avec les proxyurlcallback. Tout d'abord pour bien comprendre le principe et les flux mis en cause. Mais aussi parce que nous avions défini un contexte différent pour le nom d'hote "réel" alors qu'il doit etre associé au meme contexte que le service ESUP.

6.3 architecture CAS 2.0

Il est dommage que la conception de CAS 2.0 soit concu ainsi car du coup il est impossible de répartir la charge. Mais surtout, ESUP & CAS sont tellement liés qu'il a été difficile de rendre hermetique les contextes applicatifs ESUP de CAS. Enfin, le principe de CasKouil? est simpliste mais nous permet de pas dédié de machine a CAS mais de rester sur la plate-forme mutualisé. De plus je ne suis pas 100% sûr que nous n'avons pas d'effet de bord (hormis les pertes de toutes ls sessions CAS en cours) au niveau des tomcat ou apache. Des tests plus approfondi de la plate-forme nous le dirons.

6.4 les accents

Ca c'était facile, il faut faire un :

export LANG=fr_FR.UTF-8
ant esup.trucbidulepourcompiler


6.5 web.xml d'ESUP différent par serveur

Comme déja annoncé plus haut, le concept de proxycallback nécessite une url pointant sur un le serveur qui a fait la demande de PGT. Or cette URL de proxycallback est défini dans le web.xml. Cependant, nous avons décidé de mettre nos données sur NFS. Cela implique que chaque tomcat lit le meme fichier web.xml. Or cela pose un problème a cause des urls de proxycallback. Pour palier a ce probleme, nous avons une solution un peu cracra (à la hauteur de la conception :) qui est le lien symbolique web.xml sur le NFS pointant vers un fichier web.xml se trouvant sur chaque serveur tomcat. En schématisé ca donne ca :
web.xml (NFS) --> /var/www/_local_/esup/web.xml (LOCAL)

Mais en soit créer un lien n'etait pas un probleme, le plus "ennuyant" a été de dire à tomcat de suivre les liens car sinon il ne faisait rien, plus de ESUP, belle erreur tomcat.
Voici le code a rajouter dans le Vhost tomcat :

Rajoutez le param : allowLinking="true" dans la balise <Context> et la ligne suivante dans la zone balisée par <Context>
<Resources className="org.apache.naming.resources.FileDirContext?" allowLinking="true" />


7. Conclusion


ESUP est une application qui a le mérite d'être open source et donc de mutualiser les efforts dans le domaine des ENT au sein des universités. Mais elle souffre encore de beaucoup de problèmes de conception et de bugs que nous devons remonter. Le plus gros reproche que nous avons à formuler est le manque d'un système de sessions partagées entre les serveurs applicatifs, et donc le concept de proxycallback mais ausis le fait qu'ESUP pense être « seul au monde » lorsqu'on l'installe sur une machine.
En résumé, formater ESUP et CAS sur une plate-forme mutualisée appelée à supporter d'autres services applicatifs java/webapps n'a pas été une mince affaire et nous pensons que nous ne sommes pas au bout de nos surprises. Le temps de travail de mise en place de la plate-forme a été de 2,5 semaines au lieu d'une semaine.



8. TODO

A Documenter
* génération du server.xml via le script init.d/tomcat et les reps /etc/tomcat/site-*
* pourquoi il y a un rep authcasproxies, a coz de mod_cas et mod_proxy il faut un documentroot,
* CA, bien préciser de ne pas ajouter notre CA dans le keystore général de la JVM !
* expliquer manager : différence entre docBase et appBase et principe de context. /manager/html
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]