Pré-requis

• Java (JDK - JAVA SE 8): http://www.oracle.com/technetwork/java/javase/downloads/index.html
• Maven (dernière version 3.0.x) : http://maven.apache.org/download.cgi
• OpenJdk 17 (jusqu'à 25) : le mieux est de l'installer via le système de paquets de votre linux.
• Maven  : le mieux est de l'installer via le système de paquets de votre linux.
• Postgresql 17 ou > Postgresql 9 : le mieux est de l'installer via le système de paquets de votre linux.
• Tomcat (Tomcat 8)10 ou Jetty 12 : via système de paquets également ;  on recommande d'utiliser tomcat10-user + tomcat10-instance-create au lieu de décompresser un tarball dans /opt
• Apache + libapache2-mod-shib2 : https://services.renater.fr/federation/docsdocumentation/guides-installation/index#installer_un_sp_shibboleth [la documentation ci-avant reprend également cette partie]
• Git

PostgreSQL

L'ensemble des données est stocké dans une base de données, photos comprises, cela nous a ammené à utiliser PostgreSQL (et non MySQLMariaDB) pour ses possibilités de streaming sur les blobs.

Sous debian :

apt-get install postgresql

dans pg_hba.conf : ajout de

host	all	all		127.0.0.1/32	password

Redémarrage de postgresql

Création de la base :

su postgres
psql
create database esupsgc;
create USER esupsgc with password 'esup';
grant ALL ON DATABASE esupsgc to esupsgc;
ALTER DATABASE esupsgc OWNER TO esupsgc;

Cette application a été dévelopée développée en utilisant Spring ROO et donc ses technologies associées.

Comme annoncé ci-dessus, l'application a cependant été développée avec PostgreSQL : lecture/écriture des blobs dans une transaction par streaming ; idexation postgresql (usage de tsvector/tsquery).

Pour une bonne gestion des blob de cette application, il faut ajouter dans PostgreSQL un trigger sur la base de données sur la table big_file. La fonction lo_manage est nécessaire ici.

Sous debian :

apt-get install postgresql-contrib

Puis la La création de l'extension lo se fait via un super-user:

avec postgresql 9 PostgreSQL 17 et supérieur :

apt-get install postgresql-contrib
psql
\c esupsgc
CREATE EXTENSION lo;

Et enfin ajout du trigger (afin que les tables soient préalablement créées, notamment la table big_file sur lequel on souhaite mettre le trigger lo_manage, il faudra avant celà démarrer une fois esup-sgc (avec le paramètre 'create' dans le persistence.xml)) :

CREATE TRIGGER t_big_file BEFORE UPDATE OR DELETE ON big_file FOR EACH ROW EXECUTE PROCEDURE lo_manage(binary_file);

CF https://www.postgresql.org/docs/9.4/static17/lo.html

Vous devez donc démarrer l'application (un mvn jetty:run suffit ici avec en configurations minimales les accès à la base de données postgresql, à configurer dans database.properties) une première fois avec dans src/main/resources/META-INF/persistence.xml, la propriété hibernate.hbm2ddl.autp valuée à create, cela permettra de créer les différentes tables en base de données.

Ne pas oublier ensuite, pour ne pas écraser la base au à chaque redémarrage, de modifier src/main/resources/META-INF/persistence.xml : create-> update - cf ci-dessous.

Ajouter Ajoutez éventuellement la contrainte postgresql supplémentaires supplémentaire :

alter table card_desfire_ids ADD CONSTRAINT unique_desfire_ids_desfire_ids_key UNIQUE (desfire_ids, desfire_ids_key);

Optimisation PostgreSQL

Si les configurations par défaut de PostgreSQL peuvent suffire, il peut être toutefois intéressant de les adapter pour que PostgreSQL puisse mettre à profit les ressources matérielles de votre serveur.

https://pgtune.leopard.in.ua peut vous permettre d'obtenir des paramétrages satisfaisants.

Suivant la distribution utilisée, le stats_temp_directory peut ne pas être monté en RAM. Sous debian stats_temp_directory est bien monté en tmps au travers du répertoire /run, mais ce n'est pas le cas sous centos 7 par exemple.
Cela peut être alors très pénalisant et provoquer énormément d'IO disque ou/et l'usage de 100% d'un cpu par un voir plusieurs vacuum postgresql.
Monter le stats_temp_directory en RAM est une opération rapide, simple et peu coûteuse dont il ne faut pas se priver sur une installation d'un PostgreSQL - la documentation suivante peut aider par exemple : http://hacksoclock.blogspot.com/2014/04/putting-statstempdirectory-on-ramdisk.html

Backup / restauration :

Avec l'utilisateur postgres backup :

pg_dump -b -F d -f /backup/esupsgc-dump esupsgc

restauration :

pg_restore -d esupsgc /backup/esupsgc-dump

Paramétrage mémoire JVM :

Pensez à paramétrer les espaces mémoire JVM :

export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"

Pour maven :

et la conf CRON

11 12,19,23 * * *  postgres  rm -f /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump.bz2 && pg_dump -f /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump esupnfctag && bzip2 /opt/pg-backup/esupnfctag-`date +\%A-\%HH`.dump
21 00 * * *  postgres  rm -rf /opt/pg-backup/esupsgc-dump && pg_dump -b -F d -f /opt/pg-backup/esupsgc-dump esupsgc

Mise à jour de PostgreSQL :

Comme on recommande d'utiliser la version de postgresql de votre distribution (debian par exemple), la mise à jour de PostgreSql se fait simplement via la mise à jour de paquets.

Lors d'une mise à jour de version de votre distribution (apt dist-upgrade), la mise à jour de votre base de données est également opérée et fonctionnera si votre système a assez de place pour dupliquer votre base afin que la migration du cluster postgresql réussisse (vous devez donc avoir un espace libre dans votre point de montage postgresql équivalent à l'espace utilisé par votre base).

Si cette migration  échoue et que vous souhaitez profiter de la nouvelle version de postgresql, il faudra effectuer (après coup) des commandes de mises à jour supplémentaires.

Pour rappel debian propose nativement et par défaut la gestion des postgresql en cluster via les commandes pg_ ; pg_lsclusters permet par exemple de lister les clusters en place. Aussi lors d'une mise à jour de distribution, la version de PostgreSQL est amené à changer, Debian fait alors cohabiter les deux installations sur le même serveur.

# pg_lsclusters 
Ver Cluster Port Status Owner    Data directory              Log file
15  main    5432 online postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log
17  main    5433 online postgres /var/lib/postgresql/17/main /var/log/postgresql/postgresql-17-main.log

Le cluster lié à la nouvelle version de postgresql est disponible et opérationnel et en écoute en 5433, le cluster utilisé jusque-là écoute toujours en 5432. Si la possibilité de cluster postgresql peut permettre d'utiliser plusieurs postgresql indépendants sur un même serveur, ici souvent on souhaitera simplement migrer le cluster jusque-là utilisé dans sa nouvelle version, càd pour reprendre l'exemple ci-dessus, supprimer ce nouveau cluster 17 (non utilisé) et migrer de version le cluster en version 15 vers la version 17.

Voici les commandes permettant de réaliser cette opération :

• supprimer le cluster postgres 17 créé par défaut :

pg_dropcluster --stop 17 main

• mettre à jour le postgres 15 (vers 17)

pg_upgradecluster --method=upgrade --link 15 main

Cette procédure est très explicite et vous avertira en cas d'erreurs. Si à la fin de la procédure vous n'avez pas d'erreurs, PostgreSQL 17 a dû automatiquement prendre le relais sur PostgreSQL 15 (les fichiers de configurations ont été copiés vers la nouvelle version, la base également) et écoute sur le port 5432 (pas de changement).

# pg_lsclusters 
Ver Cluster Port Status Owner    Data directory              Log file
15  main    5433 down   postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log
17  main    5432 online postgres /var/lib/postgresql/17/main /var/log/postgresql/postgresql-17-main.log

Suite à cette mise à jour, le postgresql 15 a été conservé mais éteint (et a pris un nouveau port d'écoute en 5433).

Durant la procédure, une information indique que vous devez passer un script d'optimisation

Pensez effectivement à le lancer en tant qu'utilisateur postgres.

postgres@dgs-13-5912-1752:/usr/lib/postgresql/17/bin/vacuumdb --all --analyze-in-stages 

• supprimer le “backup” PostgreSQL 15 ; une fois que vous avez bien vérifié que tout fonctionne bien avec la version nouvellement mise à jour (17 ici donc):

pg_dropcluster 15 main

Une telle mise à jour d'un postgresql 15 vers un postgresql 17 proposant une base de données esup-sgc avec 100.000 cartes/photos stockées en base de données (~20GB de données) est opérée par ce biais en moins d'1 minute.export MAVEN_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"

Sources https://github.com/EsupPortail/esup-sgc

cd /opt
git clone https://github.com/EsupPortail/esup-sgc

...

Pour les lancer, tapez depuis les sources : 

mvn clean test -DskipTests=false

Vous devriez obtenir dans la console quelque chose comme : 

Results :
Tests run: 1045, Failures: 0, Errors: 0, Skipped: 04
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Vous pouvez également trouver plus de logs dans les fichiers donnés dans le répertoire target/surefire-reports

Le fichier src/test/resources/META-INF/spring/esup-sgc-test.properties vous permet de sépcifier un eppn identifiant un utilisateur sur lequel certaines commandes (de récupération d'information uniquement) seront lancer au travers de certains tests junit.

Packaging (et compilation)

cd /opt/esup-sgc
mvn clean package

...

On copie/colle le répertoire webapp packagé ainsi dans le tomcat : 

rm -rf /opt/tomcat-esup-sgc/webapps/ROOT && cp -rf /opt/esup-sgc/target/sgc-3.0.1.0.BUILD-SNAPSHOT /opt/tomcat-esup-sgc/webapps/ROOT

...

• Logs : src/main/resources/log4jlogback.propertiesxml
• Base de données :
  • src/main/resources/META-INF/spring/database.properties pour paramètres de connexion
  • src/main/resources/META-INF/persistence.xml pour passage de create à update après premier lancement (création + initialisation de la base de données)

• Mails : src/main/resources/META-INF/spring/email.properties

...

Celà peut se faire via une commande de type git pull

mise à jour en suivant le master (ne devrait plus être utile à partie du tag 1.0.0 actuellement en préparation - juin 2018)

Si vous faites des mises à jour sur le master directement, et sans suivre les tags, il peut y avoir des instructions sql issus du import.sql à reprendre ; le plus simple est de le réimporter : les entrées que vous avez déjà (et que vous avez éventuellement modifiées) ne seront pas écrasées grâce au jeu des noms de clefs / fonctions / triggers (des 'erreurs' seront signalés simplement).

: 

git pull origin  esup-sgc-3.2.0

su postgres -c "psql esupsgc < /opt/esup-sgc/src/main/resources/import.sql"

mise à jour depuis un tag

Lors d'une mise à jour majeure de l'application, lancez la commande suivant pour mettre à jour la base :

mvn compile exec:java -Dexec.args="dbupgrade"

repackaging et redéploiement

N'oubliez pas alors de repackager et redéployer esup-sgc (cf ci-dessus packaging et déploiement).

mise à jour debian

Si vous avez suivi la documentation présentée ci-dessus qui propose une installation d'esup-sgc et esup-nfc-tag sous debian, la mise à jour régulière de debian (apt update/upgrade) vous permet de conserver un système à jour.

debian a l'intérêt de proposer des mises à jour de distribution efficaces.

Aussi une montée de version du serveur via update/upgrade puis modification du sources.list pour procéder à un update/dist-upgrade pourra vous permettre des montées de versions efficaces de l'ensemble des briques de votre système (voir plus haut pour la migration bookworm→trixie qui prend en charge au passage la migration de postgresql 15→17) et c'est ce qu'on vous recommande de faire.

Configuration

Configurations ESUP-SGC et ESUP-NFC-TAG-SERVER