Differentes versions de PHP

Support Debian
#1

Bonjour à tous,
j’ai un souci de versions de PHP.
J’ai fait une mise a jour de ma debian pour passer sur une version 10.10

root@www:~# cat /etc/debian_version
10.10
root@www:~# uname -a
Linux www 4.19.0-17-amd64 #1 SMP Debian 4.19.194-1 (2021-06-10) x86_64 GNU/Linux

sur ma précedente version, j’avais PHP 7.0, et je voulais passer en 7.3.
Suite à l’upgrade, j’ai 2 versions de PHP qui cohabitent.
en cli, j’ai la version 7.3 :

root@www:~# php -v
PHP 7.3.27-1~deb10u1 (cli) (built: Feb 13 2021 16:31:40) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.27, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.27-1~deb10u1, Copyright (c) 1999-2018, by Zend Technologies

mais si je regarde les infos du phpinfo, j’ai toujours la version 7.0 sur le serveur web.
j’ai donc tenté de désactiver le module php 7.0 et d’activer le module PHP7.3

root@www:~# a2dismod php7.0 ; a2enmod php7.3 ; service apache2 restart
Module php7.0 disabled.
To activate the new configuration, you need to run:
  systemctl restart apache2
Considering dependency mpm_prefork for php7.3:
Considering conflict mpm_event for mpm_prefork:
Considering conflict mpm_worker for mpm_prefork:
Module mpm_prefork already enabled
Considering conflict php5 for php7.3:
Enabling module php7.3.
To activate the new configuration, you need to run:
  systemctl restart apache2

Mais à ce moment la, le PHP Semble désactivé sur mon serveur apache, et mon code devient visible.
Est ce que quelqu’un a une idée de ou cela peut venir ?
Merci pour votre aide !

#2

salut,

essaye de voir avec ce lien, il permet de faire marcher deux site avec deux versions différentes de PHP, il y a peut etre moyen de trouver ton bonheur.

#3

@Zargos : je ne pense pas que ce soit le problème qui se pose à @franck67. Qui plus est l’ajout des dépôts sury est un bon moyen pour que les débutants cassent leur distribution.

@franck67

Assure-toi que le paquet libapache2-mod-php est bien installé :

sudo apt install libapache2-mod-php

Vérifie ensuite la liste des modules Apache activés :

sudo apache2ctl -M
#4

Bonjour et merci !
libapache2-mod-php n’était pas installé, du coup je l’ai fait, mais cela ne résout pas le souci malheureusement.
dès que j’active php7.3, le php n’est plus interprété :

root@www:~# apt install libapache2-mod-php
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
  libapache2-mod-php
0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 6 120 o dans les archives.
Après cette opération, 16,4 ko d'espace disque supplémentaires seront utilisés.
Réception de :1 http://ftp.u-strasbg.fr/debian buster/main amd64 libapache2-mod-php all 2:7.3+69 [6 120 B]
6 120 o réceptionnés en 0s (31,8 ko/s)
Sélection du paquet libapache2-mod-php précédemment désélectionné.
(Lecture de la base de données... 54351 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../libapache2-mod-php_2%3a7.3+69_all.deb ...
Dépaquetage de libapache2-mod-php (2:7.3+69) ...
Paramétrage de libapache2-mod-php (2:7.3+69) ...
root@www:~# apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 dav_module (shared)
 dav_fs_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 headers_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php7_module (shared)
 proxy_module (shared)
 proxy_connect_module (shared)
 proxy_http_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)
 userdir_module (shared)
#5

Ok je suppose que tu as encore des traces d’installation de la version 7.0. Il faudrait vérifier avec :

apt list \*php\* --installed

Si tu vois apparaître des paquets avec 7.0 il va falloir les désinstaller puis réinstaller sans préciser le numéro de version (par exemple libapache2-mod-php et non libapache2-mod-php7.3, ou php-xml et non php7.3-xml)

1 J'aime
#6

Bonjour franck67,

Il me semble qu’effectivement Bruno1 a raison: désinstaller toute trace de PHP 7.0. puis re-installation des modules manquants sans préciser les numéros de versions me semble bien être la bonne solution.
Je rajoute cependant la précaution suivante auparavant: Stopper le serveur pendant la manip. On ne sait jamais!.. si ça se trouve, c’est peut-être ça qui a manqué lors de la mise-à-niveau vers 10.10, ce qui fait que celle-ci ne s’est pas faites correctement.

#7

Non, le problème classique c’est que les paquets PHP ont été installés avec leur numéro de version.
Ainsi le paquet libapache2-mod-php7.0 est marqué comme installé manuellement et ne sera donc pas supprimé lors d’une mise à niveau et Apache continue a tourner avec PHP 7.0.

À l’inverse lorsque c’est le méta-paquet libapache2-mod-php qui est installé, sa dépendance libapache2-mod-php7.x est marqué comme installée automatiquement. Il sera donc désinstallé lors d’une mise à niveau et la nouvelle version installée. Et c’est valable pour tous les paquets PHP.

C’est d’autant plus problématique lorsqu’on utilise des dépôts tiers, typiquement le dépôt sury, qui imposent l’installation avec numéro de version puisque les méta-paquets fourni par les mainteneurs Debian ne fonctionnent plus.

1 J'aime
#8

Effectivement le problème d’origine provient surement de cela (installation de PHP en indiquant les numéros de versions). D’ailleurs je le précise:

Il me semble qu’effectivement Bruno1 a raison

Mais rien ne me dit dans le post d’origine que franck67 soit passer par les dépots sury: il indique simplement:

J’ai fait une mise a jour de ma debian pour passer sur une version 10.10

Le premier à faire une allusion indirect à sury n’est pas lui mais Zargos avec une réponse indiquant un lien vers un tutoriel qui utilise justement ces dépôts. Du coup il est tout-à-fait possible que franck67 est commis cette erreur d’installer PHP en indiquant un numéro de version autrement, par exemple en suivant un tutoriel mal fagoté et peu précis comme il en pulule sur le Net.

Du coup je maintiens mon avis: avant de procéder, il doit stopper par précaution le serveur pour éviter que son utilisation ne bloque la désinstallation d’un des paquets incriminés (ou plus surement la modification d’un fichier de configuration durant le remplacement des paquets 7.0 par les 7.3).

Pour ma part, j’ai souvent eu ce genre de surprises de ce genre à l’époque ou j’avais besoin de suivre des tutoriels pour installer un serveur LAMP: lorsque je revenais en arrière, c’était toujours une belle m…rde ce qui se soldait en définitive par une ré-installation total du bazar. Maintenant je fais git à ce genre de détails. (et je n’oublie pas non plus d’utiliser l’option --purge)

#9

Non mais avant de désinstaller il faut basculer vers la version à l’aide d’un update-alternatives.

Une fois tout fonctionnel il sera temps de nettoyer tous ce qui n’est pas php7.3.
Je viens encore de le faire en fin de semaine.

#10

je conseille de faire cette commande
chez moi j’ai du php5 qui est ressorti :slight_smile:

et pour exemple :
libapache2-mod-php5/now 5.6.33+dfsg-0+deb8u1 amd64 [installé, local]
libapache2-mod-php7.0/now 7.0.33-0+deb9u10 amd64 [installé, local]
libapache2-mod-php7.3/stable,stable,stable,stable,now 7.3.27-1~deb10u1 amd64 [installé, automatique]
libapache2-mod-php/stable,stable,stable,stable,now 2:7.3+69 all [installé]

#11

Bon!.. Quand à moi, après renseignements par ci par là, je fais méa culpa sur mon avis et convient qu’en définitif c’est Clochette qui a raison (ce qui n’est guère étonnant si je me fie à son profil qui indique « ingénieur systeme chez Alterway »).

En effet, lorsque je fais une petite vérification sur mon propre serveur je constate la chose suivante: le retour de la ligne de commande ci-dessous donne:

ls -la /usr/bin/ph*
lrwxrwxrwx 1 root root      22 janv. 29 23:15 /usr/bin/phar -> /etc/alternatives/phar
lrwxrwxrwx 1 root root      12 févr. 13 17:31 /usr/bin/phar7.3 -> phar.phar7.3
lrwxrwxrwx 1 root root      27 janv. 29 23:15 /usr/bin/phar.phar -> /etc/alternatives/phar.phar
-rwxr-xr-x 1 root root   14814 févr. 13 17:31 /usr/bin/phar.phar7.3
lrwxrwxrwx 1 root root      21 janv. 29 23:15 /usr/bin/php -> /etc/alternatives/php
-rwxr-xr-x 1 root root 4777720 févr. 13 17:31 /usr/bin/php7.3

D’ou j’en conclue que sur Debian, le passage d’une version de PHP à l’autre passe effectivement par un update-alternatives, action que la mise-à-jour fait automatiquement, du moins quand le serveur a été correctement installé, c’est-à-dire en installant les méta-paquets adequats qui ne précisent pas les numéros de versions ce qui n’a manifestement pas été le cas pour une raison x quelconque qui n’est pas le sujet ici.

Aussi voila ce que je propose à franck67 pour s’en sortir:

1 - tout d’abord, installer correctement les méta paquets PHP via la commande suivante:

sudo apt install php php-cli php-curl php-gd php-gd php-intl php-memcache php-xml php-zip php-mbstring php-json

Bien sûr il devra de faire de même (à savoir pratiquer l’installation sans préciser les numéros de versions) avec tous les autres modules dont il a besoin

2 - dévalider php 7.0 pour valider php 7.3:

sudo a2dismod php7.0
sudo a2enmod php7.3
sudo service apache2 restart

3 - Enfin faire le fameux update-alternatives qui a manqué pour que la prise en compte de php 7.3 se fasse:

sudo update-alternatives --set php /usr/bin/ php7.3

Normalement, à partir de là, tout devrait rentrer dans l’ordre. Libre à lui de désinstaller tous les modules php 7.0 qui ne sont plus nécessaires.

Bien entendu, je demande humblement à Clochette de me confirmer la manip, histoire de ne pas envenimer la situation.

#12

Oui mais cela ne concerne que l’interpréteur en ligne de commande (php-cli), pas le module Apache.

La bonne façon de faire est de purger les traces d’installation des versions 7.0 :

sudo apt autoremove --purge libapache2-mod-php7.0 php7.0*

Puis de réinstaller les paquets PHP voulus sans le numéro de version.

#13

Moi de ce que j’en dit c’est juste une avis personnel, je n’ai clairement pas les réponses parfaites, mais lors de passage en php-fpm en générale j’installe ce que j’ai besoin, j’active les parties apache et bascule les alternatives et si jamais j’ai un souci je rollback.

Lorsque l’on travaille avec des clients qui maîtrise la partie site, il faut pouvoir être réactif, je ne purge les anciens paquets qu’après que tous soit au vert.

Par contre Bruno1 marque un point c’est plus que certains que certains paquets ont été installé manuellement en dehors du flow habituel et la monté de version dans ce cas est toujours plus délicates, à l’image d’installation de module php compilé manuellement :grimacing:

Maintenant il est possible de faire cohabiter plusieurs versions de php en fonctionnement (même si je ne le recommande pas, hors obligation et cas très particulier).
Dans ce cas sur apache c’est du côté du handler que tu appelle la bonne version de php (dans le vhost en bref).

N’empêche que parfois je me trompe, c’est pas parce que l’on traine un titre ronflant que ça fait de nous une bible, rester humble et curieux est à mon avis la meilleur des choses.

#14

N’empêche que parfois je me trompe, c’est pas parce que l’on traine un titre ronflant que ça fait de nous une bible, rester humble et curieux est à mon avis la meilleur des choses.

Tout-à-fait d’accord avec toi Clochette… Il ne s’agissait pas de te mettre sur un piedestal. Je voulais simplement dire que ton titre indique que tu as certaines connaissances et une expérience de plus que nous autre sur la question qui apprenons sur le tas en manipulant notre système pour le faire fonctionner à peu près correctement. Nous devons donc en tenir compte et apprécier les conseils venant du milieu professionnel.

Par exemple je te remercie grandement pour m’avoir appris ce qu’était un update-alternatives. Je manipule du Debian à titre personnel depuis très longtemps (à peu près 20 ans) et pourtant je ne savais même pas ce que c’était.

Du coup je comprends mieux mes erreurs maintenant lorsque j’installais mon serveur. Je prends note pour la prochaine fois.

PS: je connais pas non plus l’expression « rollback » :thinking:

#15

« Rester humble et curieux » j’essaye d’appliquer tout au moins le second qualificatif. La preuve en est que avant d’écrire mon post j’ai:

1 - Consulter la doc
Mon prof me le disait souvent: RTFM!!.. aussi hop! Soyons moins idiot que la moyenne:

man update-alternatives

2 - vérifié sur ma propre machine comme indiqué ci-dessus:
(laquelle machine a d’ailleurs de grande chances d’avoir été installé à peu près comme celle de franck67 au vu de mes compétences empiriques)

#16

et vérifier ls -la /etc/alternatives/phar /etc/alternatives/phar.phar /etc/alternatives/php
/etc/alternatives/phar -> /usr/bin/phar7.3
/etc/alternatives/phar.phar -> /usr/bin/phar.phar7.3
/etc/alternatives/php -> /usr/bin/php7.3

#17

Oui!.. Je sais. … Mais comme je ne suis pas plus expert que cela c’est exactement ce pourquoi je demandais à clochette de me confirmer vu qu’il avait dit:

Logiquement, s’il l’a fait, c’est qu’il sait comment faire non?.. Moi pour ma part, je suis obligé d’extrapoler avec mes propres connaissances qui sont ce qu’elles sont vu mon profil de « vieux ronchon à la retraîte entouré de ses chiens » :wink:

#18

Bonsoir a tous, et merci pour vos avis !
Je vais tenter de répondre à toutes vos questions.
J’essaye à la base, de résoudre un problème de davical qui fonctionne mal, et du coup, j’ai pensé à mettre mon LAMP / debian à jour, car pas de debian à jour => pas de paquets à jour
J’ai voulu commencer par PHP, puisque faisant de temps en temps du php, je voyais bien que ma version n’était pas la derniere.
Je suis tombé sur ces dépots alternatifs « sury », mais javais déjà un souci similaire, et en lisant des forums, j’ai vu que ces dépots ramenaient plus de problemes que de solutions.
J’ai donc upgradé ma debian en changeant les dépots officiels, pour passer de 9 à 10, car sur les anciens dépots je ne pouvais monter que jusqu’a php7.0
Je n’ai jamais coupé le serveur apache, au moment d’une mise à jour, pensant que si il a besoin d’être arreté, c’est fait automatiquement.

root@www:~# apt list \*php\* --installed
En train de lister... Fait
libapache2-mod-php7.0/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
libapache2-mod-php7.3/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé]
libapache2-mod-php/stable,now 2:7.3+69 all  [installé]
libawl-php/stable,stable,now 0.60-1+deb10u1 all  [installé, automatique]
php-bz2/stable,now 2:7.3+69 all  [installé, automatique]
php-common/now 2:84+0~20210621.36+debian9~1.gbp28513e all  [installé, local]
php-composer-ca-bundle/stable,now 1.1.4-1 all  [installé, automatique]
php-composer-semver/stable,now 1.4.2-1 all  [installé, automatique]
php-composer-spdx-licenses/stable,now 1.5.0-1 all  [installé, automatique]
php-composer-xdebug-handler/stable,now 1.3.2-1 all  [installé, automatique]
php-curl/stable,now 2:7.3+69 all  [installé]
php-gd/stable,now 2:7.3+69 all  [installé, automatique]
php-json-schema/stable,now 5.2.8-1 all  [installé, automatique]
php-mbstring/stable,now 2:7.3+69 all  [installé, automatique]
php-mysql/stable,now 2:7.3+69 all  [installé, automatique]
php-pear/now 1:1.10.12+submodules+notgz+20210212-1+0~20210228.21+debian9~1.gbpf2b98f all  [installé, local]
php-pgsql/stable,now 2:7.3+69 all  [installé, automatique]
php-php-gettext/stable,now 1.0.12-0.1 all  [installé, automatique]
php-phpseclib/stable,now 2.0.14-1 all  [installé, automatique]
php-psr-log/stable,now 1.1.0-1 all  [installé, automatique]
php-ssh2/stable,now 1.1.2+0.13-4 amd64  [installé]
php-symfony-console/stable,stable,now 3.4.22+dfsg-2+deb10u1 all  [installé, automatique]
php-symfony-debug/stable,stable,now 3.4.22+dfsg-2+deb10u1 all  [installé, automatique]
php-symfony-filesystem/stable,stable,now 3.4.22+dfsg-2+deb10u1 all  [installé, automatique]
php-symfony-finder/stable,stable,now 3.4.22+dfsg-2+deb10u1 all  [installé, automatique]
php-symfony-process/stable,stable,now 3.4.22+dfsg-2+deb10u1 all  [installé, automatique]
php-tcpdf/now 6.2.12+dfsg2-1 all  [installé, local]
php-xml/stable,now 2:7.3+69 all  [installé, automatique]
php-zip/stable,now 2:7.3+69 all  [installé, automatique]
php7.0-bz2/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-cli/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-common/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-gd/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-json/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-ldap/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-mbstring/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-mysql/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-opcache/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-pgsql/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-readline/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-xml/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0-zip/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 amd64  [installé, local]
php7.0/now 7.0.33-50+0~20210604.56+debian9~1.gbpa45c80 all  [installé, local]
php7.3-bz2/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-cli/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-common/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-curl/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-dev/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé]
php7.3-fpm/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé]
php7.3-gd/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-json/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-mbstring/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-mysql/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-opcache/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-pgsql/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-readline/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-xml/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3-zip/stable,stable,now 7.3.27-1~deb10u1 amd64  [installé, automatique]
php7.3/stable,stable,now 7.3.27-1~deb10u1 all  [installé, automatique]
php/stable,now 2:7.3+69 all  [installé, automatique]
phpmyadmin/now 4:4.6.6-4+deb9u2 all  [installé, local]
pkg-php-tools/stable,now 1.37 all  [installé, automatique]

J’ai effectivement pas mal de php 7.0 encore.

#19

J’ai suivi ce que tu as indiqué, mais toujours pareil…
j’hésite beaucoup a tenté la désinstalle de php7, car j’ai peur que cela ne fonctionne pas en php7.3 et que je ne puisse plus revenir en 7.0 après…

#20

Il se peut effectivement que mon « mode d’emploi » soit incomplet (cf. post de dindoun). C’est pourquoi je demandais à Clochette de confirmer puisqu’il avait fait la manip.

On va comparer avec mon serveur qui fonctionne bien avec PHP 7.3. Que te dis la commande suivante:

ls -la /usr/bin/ph*