...

• Java 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 9 17 ou > : le mieux est de l'installer via le système de paquets de votre linux.
• Tomcat 10 ou Jetty 10 (éventuellement 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/documentation/guides-installation/index#installer_un_sp_shibboleth [la documentation ci-avant reprend également cette partie]
• Git

...

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.

...

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;

...

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 à chaque redémarrage, de modifier src/main/resources/META-INF/persistence.xml : create-> update - cf ci-dessous.

Ajoutez éventuellement la contrainte postgresql supplémentaire :

...

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 cependant (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 faut faudra effectuer (après coup) des commandes de mises à jour supplémentaires.

Pour rappel debian propose en effet 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
1315  main    5432 online postgres /var/lib/postgresql/1315/main /var/log/postgresql/postgresql-1315-main.log
1517  main    5433 online postgres /var/lib/postgresql/1517/main /var/log/postgresql/postgresql-1517-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 15 17 (non utilisé) et migrer de version le cluster en version 13 15 vers la version 1517.

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

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

pg_dropcluster --stop 1517 main

• mettre à jour le postgres 13 15 (vers 1517)

pg_upgradecluster --method=upgrade --link 1315 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 15 17 a dû automatiquement prendre le relais sur PostgreSQL 13 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
1315  main    5433 down   postgres /var/lib/postgresql/1315/main /var/log/postgresql/postgresql-1315-main.log
1517  main    5432 online postgres /var/lib/postgresql/1517/main /var/log/postgresql/postgresql-1517-main.log

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

...

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

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

pg_dropcluster 1315 main

Une telle mise à jour d'un postgresql 13 15 vers un postgresql 15 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.

Paramétrage mémoire JVM :

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

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

Pour maven :

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

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

...

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

...

• Logs : src/main/resources/logback.xml
• 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)

...

git pull origin  esup-sgc-3.02.0

mise à jour depuis un tag

...

N'oubliez pas alors de repackager et redéployer esup-sgc (cf ci-dessus packagin et déploiement)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