Ceci est une ancienne révision du document !
Several months ago, I migrated one of the software packages we use at work to a new server. Getting time to focus on something as large as a server migration is rare for me since I usually have a bit less than 6 hours a week to look into anything new. In this instance, I was familiar with the software package, PCRT (PC Repair Tracker), but the migration was both a change in hardware and updated software - what could possibly go wrong? Our original “Repair Tracker” was running smoothly to this point, but there were several problems: • We were using a fairly outdated version of PCRT (v2.2 when 4.1 was out). • The “server” we were running it on wasn’t in as secure a location as most of our other servers. • We weren’t even sure we had regular backups (we had a “dd” backup that was old, so we could restore the machine if we needed to, but we wouldn’t have recent data). • We’ve started to virtualize more servers and this was another physical machine that could break down.
Il y a plusieurs mois, j'ai transféré l'un des paquets logiciel que nous utilisons au bureau vers un nouveau serveur. Avoir le temps de me concentrer sur quelque chose d'aussi important qu'une migration serveur est très inhabituel pour me, car j'ai généralement un peu moins de six heures par semaine pour regarder des nouveautés. Dans ce cas, je connaissait le paquet logiciel, PCRT (PC Repair Tracker, ou suivi des réparations des PC), mais la migration était à la fois un changement de matériel et une mise à jour logiciel - je n'y voyais aucun problème.
Notre « Repair Tracker » fonctionnait très bien jusqu'ici, mais il y avait plusieurs soucis : • La version de PCRT que nous utilisions était plutôt obsolète (nous avions la 2.2 alors que la 4.1 a été publié). • L'emplacement du « serveur » sur lequel il fonctionnait n'était pas aussi sûr que celui de nos autres serveurs. • Nous n'étions pas même certains de faire des sauvegardes régulières (on avait une vieille sauvegarde « dd » et on pouvait donc restaurer la machine au besoin, mais sans les données récentes). • Nous commençons à virtualiser de plus en plus de serveurs et celui-ci n'était qu'une machine physique qui pouvait tomber en panne.
The plan was to migrate the existing database and v2.2 of PCRT to our newly spun virtual server, do all the necessary upgrades to get to version 4.1, then tackle backups. As it turned out, we were regularly backing up the database and software, but as hinted, the installation didn’t go so smoothly on the new server. The problem? Ubuntu 16.04 server. More accurately, the newer version of PHP on Ubuntu server and PCRT 2.2 didn’t seem to jive well together. Luckily, one of our sysadmins had run into a similar issue with other software. The solution was to run an older version of PHP (we ended up with two versions of PHP installed with the older active). Lorna Jane Mitchell (author of PHP Web Services and PHP Master) also ran into this issue and documented which PPA she used to install both versions of PHP, I just reversed the second last step: https://lornajane.net/posts/2016/php-7-0-and-5-6-on-ubuntu sudo add-apt-repository ppa:ondrej/php sudo apt update sudo apt install php5.6 sudo a2dismod php 7.0 sudo a2enmod php5.6 sudo service apache2 restart
L'idée était de migrer la base de donner existante et la version 2.2 de PCRT sur notre serveur virtuel nouvellement créé, faire toute les mises à niveau nécessaires pour arriver à la 4.1, puis aborder les sauvegardes. Il s'avère que nous sauvegardions la base de données et le logiciel régulièrement, mais, comme vous auriez pu le comprendre, l'installation sur le nouveau serveur ne s'est pas très bien passée.
Le problème ? Ubuntu 16.04 Server. Plus précisément, la version plus récente de PHP sur Ubuntu Server et PCRT 2.2 ne semblaient pas faire bon ménage. Heureusement, l'un de nos administrateurs système avait recontré un problème similaire avec d'autres logiciels. La solution était d'exécuter une version moins récente de PHP (à la fin, deux versions de PHP était installées, mais seule la plus vieille était activée). Lorna Jane Mitchell (l'auteur de PHP Web services et de PHP Master) a aussi rencontré ce problème et a documenté la PPA qu'elle a utilisée pour installer les deux versions de PHP. En fait, je n'ai fait qu'inverser l'avant-dernière étape :
https://lornajane.net/posts/2016/php-7-0-and-5-6-on-ubuntu
sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php5.6
sudo a2dismod php 7.0
sudo a2enmod php5.6
sudo service apache2 restart
Of course this wasn’t the only answer, there were a number of PHP 5.6 dependencies I also needed to install, but they all got sorted out by reading the error logs during the install of PCRT. All of this could have been avoided if we just installed Ubuntu server 14.04 and used the version of PHP default with it, however one of our goals was to be as up-to-date as possible, and, when I took this approach on another development machine, it also didn’t quite work out as expected. On that development machine we wanted to run a number of non-virtualized PHP software packages, one of which was PCRT, the other Owncloud. Because it seemed the simplest route to get PCRT installed, we installed Ubuntu server 14.04. But that turned out to be a mistake because Owncloud wanted a later version of PHP (5.59 was installed; it needed 5.6).
Bien entendu, ce n'était pas la seule solution, il y avait
In this case, I employed the same tactic, but ran a2dismod for version 5.59 and a2enmod for 5.6. Better planning might have foreseen this problem, but often time is precious and I end up having to figure out issues as we go. Two separate virtualized environments would have also solved this problem, and it’s the direction we’re headed, but it just got me thinking that it’s a bit of a pain having to maintain several versions of PHP to run the software we want to run.
Technologies like Docker suddenly seem more viable, even for a smaller organization.