Discussion :

[aldus_85]

Intitulé précis : «[PDOException] could not find driver »
lors de l'exécution de la commande PHP app/console doctrine:schema:update –dump-sql

Je suis novice en Unix, configuration PHP, serveur Apache, mais j'ai « de la bouteille » sur d'autres softs et là, franchement je cale !

J'ai écumé tous les forums divers et variés: j'y ai notamment trouvé la piste de configurations PHP « web » et CLI différentes, ce qui m'a permis de comprendre pourquoi je peux accéder à MySQL en web mais pas de trace de pdo_mysql en CLI.

Mais je n'ai pas réussi à charger pdo_mysql dans la version CLI de PHP, alors même que pdo_mysql est chargé en version web et que le php.ini utilisé par le web et en CLI semble être les mêmes …!?. La seule différence que j'ai pu repérer c'est le user loggé entre la version web (Administrateur) et la version CLI (admin) qui est différente : est-ce que cela a un impact quelconque ? J'ai essayé de me logger en CLI sous «Administrateur» pour voir mais sans succès (access denied alors que j'ai bien entré le bon password).

J'y ai passé des heures , qui m'ont permis d'apprendre des trucs sur Unix, PHP, Apache, le serveur NAS Synology diskstation, etc. mais là, j'en peux plus, j'implore vos compétences !! Je ne sais même plus bien quelle est la compétence requise, probablement une expertise dans la configuration de PHP.

Merci d'avance !


Les faits :
1 - Cela («PHP app/console doctrine:schema:update –dump-sql») a déjà marché dans le passé.récent (→ pas a priori de pb de syntaxe)
2 - Evènement pertinent intervenu depuis que le temps où çà marchait : une mise à jour la station Synology ->DSM 3.2 ?
3 – A partir de la version web, je peux accéder sans problème à ma base MySql
4 – Dans le phpinfo : on voit que le pdo_mysql est bien requis mais on voit aussi en CLI que pdo_mysql ne fait pas partie des modules chargés/compilés.
5 – pourtant le php.ini utilisé semble être le même …

6 - Éléments du dossier :

La configuration PHP montre que pdo_mysql est bien requis

System Linux DiskStation 2.6.32.12 #1944 Mon Oct 24 18:50:26 CST 2011 armv5tel Build Date Oct 24 2011 18:36:04 Configure Command './configure.syno' '--host=armle-unknown-linux' '--target=armle-unknown-linux' '--build=i686-pc-linux' '--enable-intl=shared' '--with-icu-dir=/source/icu-4.4.1' '--with-ldap=shared,/usr/syno' '--with-ldap-sasl=/usr/syno' '--prefix=/usr/syno/php' '--with-apxs2=/usr/syno/apache/bin/apxs' '--disable-cgi' '--with-config-file-path=/usr/syno/etc' '--with-config-file-scan-dir=/usr/syno/etc/php' '--with-libxml-dir=/usr/syno' '--with-bz2=/usr/local/arm-none-linux-gnueabi' '--with-zlib=shared,/usr/local/arm-none-linux-gnueabi' '--enable-bcmath=shared' '--enable-syno_compiler=shared' '--enable-calendar=shared' '--with-curl=shared,/usr/syno' '--enable-dba=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-jpeg-dir=/usr/local/arm-none-linux-gnueabi' '--with-png-dir=/usr/local/arm-none-linux-gnueabi' '--with-freetype-dir=/usr/syno' '--enable-gd-native-ttf' '--with-gettext=shared' '--with-iconv=shared,/usr/syno/libiconv' '--with-imap=shared,/source/imap-2007e' '--enable-mbstring=shared' '--with-mcrypt=shared,/usr/syno' '--with-mysql=shared,/usr/syno/mysql' '--with-mysqli=shared,/usr/syno/mysql/bin/mysql_config' '--with-openssl=shared,/usr/syno' '--with-pdo-mysql=shared,/usr/syno/mysql' '--with-pdo-pgsql=shared,/usr/syno/pgsql' '--with-pgsql=shared,/usr/syno/pgsql' '--disable-phar' '--enable-shmop=shared' '--enable-soap=shared' '--enable-sockets=shared' '--enable-wddx=shared' '--with-xmlrpc=shared' '--enable-zip=shared' '--with-sqlite3=static,/usr/syno/sqlite3' '--with-pdo-sqlite=static,/usr/syno/sqlite3'

–> de fait, le module apparaît bien parmi les modules chargés dans la version php web :

Pilotes SGBD disponibles : sqlite, sqlite2, mysql, pgsql
(via exécution serveur web de « echo 'Pilotes SGBD disponibles : ' . implode(', ', PDO::getAvailableDrivers()), PHP_EOL; »)

Liste des modules compilés et chargés: Array ( [0] => Core [1] => date [2]

=> ereg [3] => libxml [4] => pcre [5] => sqlite3 [6] => bz2 [7] => ctype [8] => dom [9] => fileinfo [10] => filter [11] => hash [12] => json [13] => SPL [14] => PDO [15] => pdo_sqlite [16] => posix [17] => Reflection [18] => session [19] => SimpleXML [20] => SQLite [21] => standard [22] => tokenizer [23] => xml [24] => xmlreader [25] => xmlwriter [26] => apache2handler [27] => apc [28] => bcmath [29] => calendar [30] => curl [31] => dba [32] => exif [33] => ftp [34] => gd [35] => gettext [36] => iconv [37] => imap [38] => intl [39] => ldap [40] => mbstring [41] => mcrypt [42] => mysql [43] => mysqli [44] => openssl [45] => pdo_mysql [46] => pdo_pgsql [47] => pgsql [48] => shmop [49] => soap [50] => sockets [51] => wddx [52] => xmlrpc [53] => zip [54] => zlib )
(via exécution serveur web de « echo "<BR/>\n Liste des modules compilés et chargés: ";print_r(get_loaded_extensions());echo "<BR/>\n";»)

Chemin du fichier php.ini chargé :

/usr/syno/etc/php.ini
(via exécution de «echo "<BR/>\nChemin du fichier php.ini chargé : ".php_ini_loaded_file();»)

Utilisateur en service web de php: «Administrateur»
(via «print_r(get_current_user ());»)


Dans la version CLI (petit nom pour Command Line Interpreter pour les débutants dont je fais partie):

Liste des modules compilés en mode CLI: pas de pdo_mysql (entre autre car bien des modules ne sont pas présents:pourquoi??)

(commande : php -m)
[PHP Modules]
bz2
Core
ctype
date
dom
ereg
fileinfo
filter
hash
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter

[Zend Modules]

Fichier .ini utilisé en CLI : apparemment on utilise le même fichier php.ini en CLI qu'en version serveur

(commande php –ini)
Configuration File (php.ini) Path: /usr/syno/etc
Loaded Configuration File: /usr/syno/etc/php.ini
Scan for additional .ini files in: /usr/syno/etc/php
Additional .ini files parsed: /usr/syno/etc/php/user-setting.ini

Utilisateur entré en log in: admin

[aldus_85]

Re-bonjour,

J'ai (quand même) poursuivi mon enquête en cherchant où pouvait bien se trouver l'extension pdo_mysql.so.

Elle ne se trouvait pas dans le php.ini ... mais en fin de fichier, il était indiqué que les extensions était dans le fichier extension (path/chemin fourni en prime).

J'ai cherché à vérifier la présence de pdo_mysql.so dans ce fichier et, surprise, je n'y avais pas accès en tant qu'administrateur ! Bigre, le début d'une rébellion ??

Les droits de extension.ini étaient -rw------- root root (autrement dit pour les novices dont je suis : accès en lecture et écriture au seul utilisateur "root" : même admin n'était pas autorisé à voir son contenu ).

Evidemment j'ai changé de cape pour endosser celle de "root", et là j'ai eu accès au contenu (via "vi extension.ini") et j'ai pu vérifier la présence du fameux pdo_mysql !

J'ai autorisé le groupe "other" (c'est-à-dire ceux qui ne sont ni le propriétaire "root" ni le groupe propriétaire "root") à lire le fichier. (de manière temporaire, il ne faut sûrement pas laisser les choses en état).

Et là comme par miracle, la fonction php app/console doctrine:schema:update a bien fonctionné.

Je ne sais pas quel est le c.. qui a mis ces autorisations restrictives sur extension.ini (plus restrictives que sur php.ini, çà me paraît idiot, non ?) mais sûrement un bug lié à la mise à jour de la station Synology de 3.1 à 3.2.

Par contre le c.. qui a donné un nom de user différent de "root" pour le serveur, c'est probablement moi.

Question : pour remettre les choses en ordre, je me propose de dupliquer les droits et propriétaires du fichier php.ini sur le fichier extension.ini.

-> est-ce la bonne chose à faire ?


La piste d'une différence d'utilisateur pour le web et pour les commandes en ligne (CLI), était donc pertinente !


P.S.1 si j'ai mis le détail de mes pérégrinations, c'est dans l'espoir que d'autres novices ne galèrent pas comme moi pour résoudre ce problème ou un problème équivalent. En effet, les infos sur le net étaient souvent incomplètes pour un non initié et ouvrait à chaque fois des portes sur PHP, les paramètres d'installation, sur Apache, sur l'édition de fichier en Unix, sur les droits UNIX, etc.

P.S.2 si un pro voit une grosse bévue (ou une bévue tout court) notamment côté sécurité, qu'il n'hésite pas à faire le nécessaire, je modifierai le texte en conséquence.

Hope this helps !

[kenny.kev]

Bonjour,

Je ne suis pas un expert Unix, je suis sur linux en revanche. Ces fichiers pour moi sont parfaitement configurer, car normalement c'est le root qui lance et configure le service apache, php, etc ... et non un autre compte.

Bonne soirée

[aldus_85]

Merci Kenny,

Je veux donc mettre "root" comme utilisateur pour PHP/Apache version web au lieu de mon "Administrateur" actuellement.

Où et comment cela doit-il se faire ?

Bonne soirée !

P.S. pour moi linux = unix ; je dois être en linux sur ma diskstation et tout ce que j'ai lu sur unix marchait. Il ya peut-être des difféences, mais jene les ai jamais rencontrées !!

[kenny.kev]

Bonjour,

Les différences tu les rencontres par exemple sur les options des commandes par exemple le tar de solaris qui est un système Unix n'a pas les mêmes options que sur debian ou redhat.

Je crois qu'il y a aussi une différence dans la gestion des droits.
Je ne connais pas ta distribution et je ne trouve pas d'infos dessus. Si ta distribution ne te permet pas d'exécuter un script php c'est qu'il y a de bonne raison, soit parce que ton compte administrateur (le nom ne signifie pas que tu es tous les droits) n'a pas les bons groupes, soit seul le root peu l'exécution. Mais en aucun cas tu ne change les droits des services.