Pour que l'upgrade se passe de façon sereine, on déplace le nouveau dolibarr sur une nouvelle machine. Cela évite d'être obligé de faire un dist-upgrade sur la machine actuelle qui héberge beaucoup de services critiques. Et en plus, si l'upgrade échoue pour une raison ou une autre, on peut très facilement rétablir l'ancien dolibarr puisqu'on n'y aura pas touché.

Le paquet Debian officiel ayant 2 bugs (que ce soit la version 4 dans testing ou la v5 dans unstable) nous allons donc installer un paquet que nous aurons préalablement patché. Ce paquet patché par mes soins est déjà disponible au téléchargement ici: https://git.franciliens.net/blog/dolibarr_5.0.4+dfsg3-1.1_all.deb

Si par hasard y avait quelque chose à modifier dans ce paquet voici la procédure que j'ai suivie : Patcher le paquet Debian de dolibarr.

Attention, à partir d'ici je n'ai pas testé la procédure de façon complète. C'est du work-in-progress à corriger/compléter.

APT pinning

Nous allons configurer APT pour autoriser l'installation de paquets venant de testing et/ou sid, mais uniquement lorsque l'utilisateur le demandera explicitement. Le reste du temps APT continuera de privilégier les paquets venant de stable et stable-updates.

On déclare d'abord les mirroirs testing et sid. Pour cela créer le fichier /etc/apt/sources.list.d/sid.list :

deb http://ftp.fr.debian.org/debian/ testing main
deb http://ftp.fr.debian.org/debian/ sid main

Puis on spécifie les priorités par défaut pour APT. Pour cela créer le fichier /etc/apt/preferences.d/stability.pref :

Package: *
Pin: release o=Debian,a=stable-updates
Pin-Priority: 900

Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 800

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 90

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 80

Package: *
Pin: release o=Debian
Pin-Priority: -1

Avec cette configuration les commandes APT n'installeront jamais de paquets provenant de sid ni testing à moins que ce ne soit demandé explicitement par l'utilisateur (avec l'option -t par exemple).

Installer les pré-requis

On installe d'abord le paquet Debian officiel.

sudo apt install -t sid dolibarr

On le remplace immédiatement par le paquet patché par nos soins.

sudo dpkg -i dolibarr_5.0.4+dfsg3-1.1_all.deb

Récupérer les données de l'ancien doli

Sur l'ancienne machine, stopper dolibarr (c'est plus prudent), puis :

export workdir=$(mktemp -d dolibarr-XXXX)
pg_dump -U dolibarr dolibarr > ${workdir}/dolibarr.dump.$(date +%Y-%m-%d).sql
sudo tar czvf ${workdir}/dolibarr_data.tar.gz /srv/data/dolibarr/ /etc/dolibarr

Transférer le contenu du dossier ${workdir} vers la nouvelle machine.

Sur la nouvelle machine :

cd /tmp
sudo tar xavf dolibarr_data.tar.gz
sudo mkdir -p /srv/data/dolibarr
sudo rsync -av /tmp/srv/data/dolibarr/ /srv/data/dolibarr/
sudo rsync -av /tmp/etc/dolibarr/ /etc/dolibarr/

Customiser le fichier /etc/dolibarr/conf.php selon les besoins. Notamment les paramètres de connexion à la BDD.

Configuration nginx

Créer une configuration nginx équivalente à celle de l'ancienne machine. Désolé j'ai la flemme de documenter cette partie.

Lancer la procédure de migration

La procédure de migration se fait à travers l'interface Web.

Il suffit de se rendre sur la page d'accueil du virtualhost configuré dans nginx et d'appliquer successivement les migrations suggérées par l'installeur.

Mais à un moment, un des scripts de migration risque d'afficher des erreurs lors de l'insertion de données de départements. Ce n'est pas bien grave, il suffit alors de recharger la page, ce qui aura pour conséquence d'appliquer à nouveau le même script qui cette fois fonctionnera. Cela est dû au fait que le même script insère des données dans une première table qui sont immédiatement référencées pour l'insertion de données dans une autre table.

Ce problème est spécifique à PostgreSQL je pense car les scripts de migration sont conçus et testés pour MySQL et sont transformés à la volée lorsqu'il s'agit de PostgreSQL.