Bonsoir,

Très bien.
Je pense avec toutes ces informations que la configuration de php chargée dans le setup apache et nginx sont différents. Il est clair que le dossier de configuration /etc/php7/ n'est pas chargé dans le cas du setup apache.

Je te suggère de vérifier dans le phpinfo (dans le setup apache) les informations suivantes :
* Version PHP
* "Loaded Configuration File" et "Additional .ini files parsed" (c'est à dire la liste des fichiers de configuration chargés)
* extension_dir (c'est à dire le dossier dans lequel PHP va chercher les modules d'extension à charger)

Lors de l'exécution d'un script PHP, le fonctionnement est le suivant :
* PHP se charge, soit en tant que démon Unix PHP-FPM (couramment utilisé pour nginx), soit en tant que module intégré au serveur HTTP (couramment utilisé pour apache)
* PHP va lire les fichiers de configuration listés dans les dossiers mentionnés dans le phpinfo (soit définis à la compilation, soit définis par configuration)
* Dans ces fichiers de configuration, lorsque tu lis extension=....so dans un fichier de configuration, il s'agit d'une librairie à charger dynamiquement au démarrage de PHP. Ces modules vont implémenter des composants optionnels (sessions, mysql, PDO, etc), ils ne sont pas intégrés de base afin d'éviter de surcharger le binaire de base, et offrir les meilleures performances pour les sites web basiques.

A noter que les fichiers qui se terminent par .so sont des librairies chargées dynamiquement dans les systèmes Unix (Linux, BSD, etc), quelque soit le programme considéré. Il y a donc des .so pour les modules PHP, mais aussi des .so pour les modules Apache. Les modules mod_session.so, mod_session_cookie.so et mod_session_dbd.so sont d'ailleurs des modules Apache et non des modules PHP, et n'ont aucun impact sur le problème que tu rencontres.

Si certaines extensions ne sont pas chargées, la source du problème est donc probablement sur l'un des éléments listés tout en haut de mon post, d'où la question des variables à vérifier dans le phpinfo.

Cordialement

la version php est 7.2.11

loaded configuration file (php.ini) Path /etc/nginx


Loaded Configuration File extension_dir /usr/lib/php/extensions/no-debug-zts-20170718 /usr/lib/php/extensions/no-debug-zts-20170718

alors que je viens de regarder le dossier si dessus , et je ne le trouve pas , je m arrête a /usr/lib/php/

du coup je vais regarder au fichier de configuration pour vérifier le chemin d’accès et soit je le modifie ou je place les fichiers dans le bon dossier ?

et malgré l utilisation du dossier nginx c est bien le serveur sur le port 80 donc apache

dans le fichier php.ini du dossier nginx j ai extension_dir=/usr/lib/php du coup pourquoi le path est plus long dans le phpinfo?

Bonsoir,

extension_dir /usr/lib/php/extensions/no-debug-zts-20170718 /usr/lib/php/extensions/no-debug-zts-20170718

alors que je viens de regarder le dossier si dessus , et je ne le trouve pas , je m arrête a /usr/lib/php/

Ok, je vois. Effectivement je pense que nous touchons la source du problème !

et malgré l utilisation du dossier nginx c est bien le serveur sur le port 80 donc apache

Ok, tu fais bien de le préciser.

dans le fichier php.ini du dossier nginx j ai extension_dir=/usr/lib/php du coup pourquoi le path est plus long dans le phpinfo?

Je pense qu'il peut s'agir d'un bug, d'un problème de configuration, d'une fonction non-testée, d'une mise à jour non contrôlée d'un composant du NAS, etc. La fonction site Web sur un NAS n'est pas forcément la plus importante et ne fait probablement pas l'objet de la même validation que les fonctions principales.

du coup je vais regarder au fichier de configuration pour vérifier le chemin d’accès et soit je le modifie ou je place les fichiers dans le bon dossier ?

Alors, déjà je te déconseille fortement de déplacer les .so. S'ils sont placés dans le dossier en question, il est possible qu'ils soient utilisés (par exemple par nginx).

En premier lieu, le plus étonnant est effectivement que la configuration php soit configurée dans le dossier nginx. Avant de tenter les solutions ci dessous, je te conseillerais de vérifier si par hasard il n'y aurait pas un fichier php.ini ou une directive de configuration relative à php dans le dossier de configuration de apache (/etc/apache2 ou /etc/httpd). Si c'est le cas, le plus simple sera probablement de demander à PHP d'utiliser ce fichier (qui est probablement le bon s'il est présent).

Dans le cas contraire, pour régler le problème et avoir les extensions php, je vois deux solutions alternatives :
* Fixer dans la configuration apache la valeur de la variable extension_dir
* Linker les modules inexistants vers leur emplacement effectif


Solution 1 : Fixer dans la configuration apache la valeur de la variable extension_dir

Cela fait plusieurs années que je n'ai pas utilisé apache, mais de mon souvenir, si (et seulement si) php est exécuté en tant que module apache, tu peux définir des variables de configuration PHP directement dans la configuration apache. C'est décrit sur cette page : https://www.php.net/manual/fr/configuration.changes.php

La directive ressemblerait à cela :

Solution 2 : Linker les modules inexistants vers leur emplacement effectif

Il s'agit d'une version moins intrusive que le fait de déplacer ou copier les fichiers. Les liens symboliques sous les systèmes Unix permettent de rediriger l'adresse d'un fichier ou un dossier vers un autre fichier ou dossier.

Les commandes sont les suivantes (connecté dans un terminal root) : La première crée le dossier de modules. La seconde crée un lien symbolique de /usr/lib/php/extensions/no-debug-zts-20170718/ vers /usr/lib/php/ pour chaque fichier .so contenu dans /usr/lib/php/.


Ces deux solutions supposent que la version php utilisée dans le module apache et sur le serveur nginx est la même. Dans le cas contraire, les modules ne seront pas compatibles et ne se chargeront pas ou feront planter le chargement des pages. Il faudra alors explorer une autre solution.

Cordialement

Ne serait-il pas possible aussi de changer directement extension_dir dans le php.ini pour mettre /usr/lib/php ?

j ai appliquer la solution 2 (linker les fichier)
j ai reboot le serveur mais ça n a pas l air de fonctionner

j ai toujours
j essayerais les deux autre proposition demain soir , aujourd'hui je n aurais pas le temps

encore merci

après avoir essayer les 3 possibilité rien n a changé , j'ai toujours les mêmes erreurs
(j ai essayé de changé le extention_dir dans le php.ini)

vers ou puis je chercher d autre ? j ai déjà envoyé un mail au centre d aide du NAS mais je n ai pas encore reçu de réponse (pourtant la première fois en 24h je l avais eu ...)

Bonsoir

Dans ce cas, je pense qu'il va être nécessaire que tu nous partages les 2 phpinfo :
* du setup nginx
* du setup apache

Pense aussi à vérifier les logs de tous les composants impactés (probablement dans /var/log/).

Cordialement

désoler du retard quelque contretemps
je vais essayé de trouvé le dossier "www" ou htdoc de nginx pour lui placer un phpinfo() car de base il ne sert que pour les modules du serveur ...
je relance le serveur du nas pour le php info complet de apache

pour apache
mais c est un peux le bordel en mode"code" sinon j ai en direct
: http://serry.myftp.org/phpinfo.php

je vais essayé de trouvé le dossier "www" ou htdoc de nginx pour lui placer un phpinfo() car de base il ne sert que pour les modules du serveur ...

Pour nginx normalement tu as les sites déclarés dans la configuration dans /etc/nginx/sites-enabled/
Par contre php n'est pas activé partout mais uniquement lorsque spécifié explicitement.

Par un bloc de ce type : Ou : Il faut créer ton phpinfo en conséquence pour qu'il soit interprété. Dans le cas contraire, il sera considéré comme un simple fichier texte.

Cordialement