Aujourd’hui, petite mise à jour mineure de PHP7, en utilisant les dépôts DotDeb.
Le problème : PHP-FPM désactivé par défaut
A la fin de l’installation, j’obtiens ce message d’avertissement :
Setting up php7.0-fpm (7.0.8-1~dotdeb+8.1) ...
Installing new version of config file /etc/init.d/php7.0-fpm ...
NOTICE: Not enabling PHP 7.0 FPM by default.
NOTICE: To enable PHP 7.0 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.0-fpm
NOTICE: You are seeing this message because you have apache2 package installed.
[ ok ] Restarting PHP 7.0 FastCGI Process Manager: php-fpm7.0.Code language: JavaScript (javascript)C’est bien la première fois qu’une mise à jour de PHP désactive PHP-FPM, ce n’est pas vraiment une mise à jour mineure et sans accroc.
On réactive donc les deux modules indiqués et on relance la configuration de PHP-FPM avant de relancer Apache et PHP-FPM :
a2enmod proxy_fcgi setenvif
a2enconf php7.0-fpm
service apache2 restart && service php7.0-fpm restartCode language: CSS (css)Je lance le site : page d’erreur de certificat la première fois, et page blanche ensuite !
Des modules PHP à installer séparément
Après analyse des dernières lignes du fichier log d’Apache, je me suis rendu compte que le site avait besoin des modules mbstring et xml or, cette nouvelle version ne les fournit plus : ce sont maintenant des paquets à installer à part.
Voici le message d’erreur des logs:
[26-Jun-2016 08:39:12 UTC] PHP Fatal error: Uncaught Error: Class 'DOMDocument' not found in /public_html/wp-content/plugins/ginger/front/gingerfront.core.php:171
Stack trace:
#0 /public_html/wp-includes/plugin.php(235): ginger_parse_dom('...')On installe donc mbstring et xml avant de relancer Apache et PHP :
apt install php7.0-mbstring php7.0-xml
service apache2 restart && service php7.0-fpm restartCode language: CSS (css)Cette fois-ci, c’est tout bon. Tous les services sont actifs et le site est de nouveau opérationnel.
Attention donc : c’est une mise à jour mineure que j’aurais pu faire en SSH depuis mon téléphone, sans avoir les moyens de réparer à distance. Cela remet en perspective les mises à jour “on-the-go“.
Rencontrez-vous des défis avec votre site WordPress ou WooCommerce? Laissez-moi les résoudre pour vous.
Perso j’ai quitté les dépôts dotdeb et j’ai passé tout mon serveur sur les sources testing de debian, je sais que c’est pas forcément recommandé mais même avec dotdeb j’avais des problème avec php7, certaines mise à jours nécessitant des dépendances je commençais à avoir de plus de problème tant tous les sens, depuis j’ai bien moins de problème.
Salut Nodokan,
J’ai quelques paquets pour lesquels j’active les sources testing. Est-ce que ton système est stable en testing?
Je pense que dorénavant je me pencherai davantage sur le changelog avant de procéder aux mises à jour dotdeb, même pour les MAJ mineures.
J’ai passé tout le système en testing,
Pour le moment il n’y aucun problème de stabilité et ça fait environ 4 mois, je m’étais confronté à un précédent problème avec OpenSSL et il fallait la dernière version d’apache pour le corriger, comme j’ai pas voulus compiler à côté un paquet aussi important pour un serveur j’ai préféré tout passé en testing, au moins j’ai un serveur bien à jour :D
C’est vrai que la séparation des dépendances c’est pas plus mal ça permet de mieux choisir ce qu’on veut, mais ils auraient au moins pu prévenir.
Les dépôts débian on la même séparation des dépendances d’ailleurs
Merci, cet article m’a permis de me dépanner
Je suis content que cela ait pu t’aider Hugues :)