Curl php 7.3 sur Debian 10 Buster

Tags: #<Tag:0x00007f46910ea658> #<Tag:0x00007f46910ea310> #<Tag:0x00007f46910ea108> #<Tag:0x00007f46910ea018>

En cherchant sur le net, j’ai trouvé ça : https://www.skyminds.net/linux-resoudre-les-erreurs-communes-de-cle-gpg-dans-apt/

sudo apt-get update 2>&1 | sed -ne 's?^.*NO_PUBKEY ??p' | xargs -r -- sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys

ça fonctionne.

Du coup, je vais voir pour mon problème de curl maintenant.

Voilà ce que ça donne :

sudo apt install php-curl
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :

Les paquets suivants contiennent des dépendances non satisfaites :
 php-curl : Dépend: php7.3-curl mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

Là, le message de réponse à ,cette commande indique que ta demande d’importation a bien été traitée, mais qu’il ne trouve pas la clé de l’équipe debian-security identifiée par les 8 caractéres.
Je ne sais pas trop pourquoi, il est possible que l’équipe sécurité ai changé sa clé ou un truc comme ça.
C’est pénible.

Bon, je viens de penser à une autre manière de faire:
essayes ça:
sudo apt-get --allow-unauthenticated update
puis:
sudo apt-get --allow-unauthenticated install debian-keyring debian-archive-keyring
Ca donne quoi déjà ?
Tu peux installer des choses aprés, ça remet un peu apt d’équerre ?

Salut, du coup, pour ces histoires de clé, c’est réglé, voir ce message : Curl php 7.3 sur Debian 10 Buster

Reste le problème de curl maintenant.

OK

Ben du coup, il te dit quoi quand tu essayes plutôt apt install php7.3-curl ?

Il ne faut pas installer les paquets PHP avec leur numéro de version. Si les mainteneurs Debian s’embêtent à faire des méta-paquets comme php-curl qui dépendent toujours de la dernière version disponible ce n’est pas pour rien !
En installant directement le paquet php7.3-curl celui-ci sera marqué comme installé manuellement et cela empêchera sa suppression lors d’une mise à niveau.
C’est sans doute ce qui est à l’origine des problèmes de mise à niveau vers buster de @Aurelienazerty . Je parierais volontiers que PHP 7.0 est encore utilisé…

Il serait par contre intéressant de voir les différentes solutions proposés par aptitude pour résoudre le problème de dépendances :

sudo aptitude install php-curl

Il me dit ça :

sudo apt install php7.3-curl
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :

Les paquets suivants contiennent des dépendances non satisfaites :
 php7.3-curl : Dépend: php7.3-common (= 7.3.9-1~deb10u1) mais 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c devra être installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

Voilà :

sudo aptitude install php-curl
Les NOUVEAUX paquets suivants vont être installés :
  php-curl php7.3-curl{ab}
0 paquets mis à jour, 2 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 36,7 ko d'archives. Après dépaquetage, 147 ko seront utilisés.
Les paquets suivants ont des dépendances non satisfaites :
 php7.3-curl : Dépend: php7.3-common (= 7.3.9-1~deb10u1) but 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c is installed
Les actions suivantes permettront de résoudre ces dépendances :

     Conserver les paquets suivants dans leur version actuelle :
1)     php-curl [Non installé]
2)     php7.3-curl [Non installé]



Accepter cette solution ? [Y/n/q/?] Y
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.

J’aurais du remarqué cela dès ton second message ! Tu avais déjà installé PHP 7.3 sur ta Debian stretch via des dépôts non officiels. Très certainement ici : https://packages.sury.org/
À voir avec :

apt list \*php\* --installed

Il ne faut donc pas s’étonner que la mise à niveau pose problème. C’est un phénomène récurrent sur les forums : les gens utilisent les dépôts sury (ondrej) et se retrouvent avec un distribution complètement cassée…

Tu as une petite chance de t’en sortir en répondant non (n) aux questions d’aptitude pour voir les différentes solutions qu’il propose. Sinon il faudra désinstaller tous les paquets php puis les réinstaller.

ça donne ça :

sudo apt list \*php\* --installed
En train de lister... Fait
dh-php5/now 0.2 all  [installé, local]
php-cli/now 2:7.3+70+0~20190814.17+debian9~1.gbp1e7da2 all  [installé, local]
php-common/now 2:70+0~20190814.17+debian9~1.gbp1e7da2 all  [installé, local]
php-geoip/now 1.1.1-4+0~20190828.8+debian9~1.gbp6de4a0 amd64  [installé, local]
php-igbinary/now 3.0.1+2.0.8-2+0~20190814.12+debian9~1.gbpaafd11 amd64  [installé, local]
php-imagick/now 3.4.4-1+0~20190814.12+debian9~1.gbpc5da26 amd64  [installé, local]
php-mbstring/now 2:7.3+70+0~20190814.17+debian9~1.gbp1e7da2 all  [installé, local]
php-memcached/now 3.1.3+2.2.0-2+0~20190814.14+debian9~1.gbp5d60d1 amd64  [installé, local]
php-msgpack/now 2.0.3+0.5.7-2+0~20190814.11+debian9~1.gbpb26058 amd64  [installé, local]
php-pear/now 1:1.10.9+submodules+notgz-1+0~20190808.10+debian9~1.gbp296d25 all  [installé, local]
php-redis/now 5.0.2+4.3.0-2+0~20190814.15+debian9~1.gbp070358 amd64  [installé, local]
php5-common/now 5.6.30+dfsg-0+deb8u1 amd64  [installé, local]
php5-dev/now 5.6.30+dfsg-0+deb8u1 amd64  [installé, local]
php5-gd/now 5.6.30+dfsg-0+deb8u1 amd64  [installé, local]
php5-memcached/now 2.2.0-2 amd64  [installé, local]
php7.3-cli/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-common/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-fpm/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-gd/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-gmp/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-intl/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-json/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-mbstring/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-mysql/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-opcache/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-readline/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-sqlite3/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-xml/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3-zip/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c amd64  [installé, local]
php7.3/now 7.3.9-1+0~20190902.44+debian9~1.gbpf8534c all  [installé, local]

Bon, du coup, j’ai fait le bourrin :

sudo apt-get remove --purge php*

Puis :

sudo apt install php libapache2-mod-php php-mysql php-curl php-json php-gd php-msgpack php-memcached php-intl php-sqlite3 php-gmp php-geoip php-mbstring php-xml php-zip

Comme mon php n’était pas interprété, j’ai dû faire ça :

 sudo a2enmod php7.3
Considering dependency mpm_prefork for php7.3:
Considering conflict mpm_event for mpm_prefork:
ERROR: Module mpm_event is enabled - cannot proceed due to conflicts. It needs to be disabled first!
Considering conflict mpm_worker for mpm_prefork:
ERROR: Could not enable dependency mpm_prefork for php7.3, aborting

Et donc enchainer avec ça :

sudo a2dismod mpm_event

puis :

sudo a2enmod php7.3

Et enfin :

sudo systemctl restart apache2

Et ça fonctionne… Enfin !!!

Merci @anon70622873 pour ta perspicacité, et surtout merci @mattotop pour ta patience et ton aide sur les problèmes annexes.

sudo a2dismod mpm_event
sudo systemctl restart apache2
sudo a2enmod php7.3
sudo systemctl restart apache2
Il y a un peu de redondance, mais fait dans cet ordre là, ça donne quoi ?

Ah ben trop tard, c’était déjà vu…

Tant mieux si cela fonctionne. Mais là tu viens aussi de passer de php-fpm (un interpréteur PHP autonome et performant) à libapache2-mod-php (le module Apache pour interpréter PHP). Tu vas donc perdre en performances et peut-être aussi certains éléments de configuration.

Ah mince. Du coup, je fais comment pour passer sur php-fpm ?

J’ai l’impression qu ce n’est pas toi qui a installé et configuré ce serveur, non ?

Cette séquence de commandes devrait suffire :

sudo a2dismod php7.3
sudo a2enmod mpm_event
sudo apt install php-fpm
sudo apt purge libapache2-mod-php\*
sudo systemctl restart apache2

Après il faudra vérifier la configuration des hôtes virtuels apache, de PHP et des éventuels pools PHP-FPM sous /etc/php/7.3/fpm

En effet. Mais je m’occupe de la maintenance. Je maitrise les bases, après j’avoue que c’est pas mon loisir préféré la conf de serveur. Je préfère coder.

Sinon dans la liste des commandes, j’ai dû rajouter :

sudo a2enmod proxy_fcgi setenvif
sudo systemctl restart apache
sudo a2enconf php7.3-fpm
sudo systemctl restart apache2

Oui bien vu, j’avais oublié le fcgi :wink:
Est-ce que le module fcgid est bien installé et activé ?
Au cas où :

apt install libapache2-mod-fcgid 
a2enmod fcgid

fcgid me fout le brin, l’activer me casse le serveur.

J’ai dû le désactiver.

systemctl status apache2.service
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset:
   Active: failed (Result: exit-code) since Fri 2019-11-01 06:21:07 CET; 11s ago
     Docs: https://httpd.apache.org/docs/2.4/
  Process: 1611 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILU

Ah, désolé. Si ta configuration fonctionne telle quelle, je n’insiste pas :wink:
Mais ce n’est sans doute pas optimisé. La configuration doit certainement dater de plusieurs années.

On a installé notre VPS en 2017.