Traduction...

Le 20/10/2010 08:59, Pascale a écrit :

[...] La modification
qui sera faite fera en sorte que PHP s'exécutera en tant qu'utilisateur
normal et non plus en tant que "serveur web". »

A priori, ça voudrait dire que PHP sera exécuté en tant que script CGI
(ou FastCGI) au lieu de se placer en tant que module du serveur web
(Apache, le plus souvent).
Voir : [http://www.php.net/manual/fr/install.general.php]
Je ne sais pas ce qu'il en est maintenant, mais à une époque ce choix
impliquait de sérieuses baisses de performance.

--
Cordialement,
Pascal

Le 20/10/2010 08:59, Pascale a écrit :

Notre hébergeur (hébergement mutualisé) nous envoie un courriel où il est
dit entre autres :
« La prochaine étape aura lieu cette semaine et aura pour but de corriger
deux problèmes fréquemment rencontrés par nos clients : le safe_mode et
les conflits de permissions entre PHP et l'utilisateur FTP. La modification
qui sera faite fera en sorte que PHP s'exécutera en tant qu'utilisateur
normal et non plus en tant que "serveur web". »

J'avoue que je ne comprends pas la dernière phrase, quelqu'un aurait la
gentillesse de traduire pour moi ?

Bonjour Madame

Le serveur de votre hébergeur est probablement sous un système Linux
ou Unix.

Dans ces systèmes, chaque fichier ou répertoire, a trois droits
d'accès, de propriétaire, de groupe, ou des autres ( others ).

Ces trois droits peuvent être, le droit en lecture, en écriture, ou
en exécution.

D'autre part, les scripts php ont comme propriétaire, le propriétaire
( et le groupe ) du processus php, dont la valeur dépend de savoir si le
serveur Apache s'exécute comme module, ou en suexec.

Dans le premier cas, le processus php aura pour propriétaire, le
propriétaire du processus du serveur ( Apache 2 probablement, c'est le
plus fiable et sécurisé ). Dans le deuxième cas, le processus php, aura
comme propriétaire, celui de votre compte ftp correspondant à votre
hébergement.

D'autre part, le propriétaire ( et donc groupe ) des fichiers ouverte
écriture par vos scripts php ( de votre site ), sera le même que celui
du processus php, donc de votre compte ftp, si php est en mode suexec.

Ce que dit votre hébergeur, c'est qu'il vont faire en sorte, que php
s'exécute avec comme propriétaire, celui de votre compte ftp, donc en
suexec, ce qui veut dire que les fichiers écrits par vos scripts php,
auront le même propriétaire, que celui de votre compte ftp.

Celà fera, que vous n'aurez plus aucune difficulté, pour charger ou
supprimer par ftp, ces fichiers créés par vos scripts php, puisque par
définition, leurs permissions dépendront du même propriétaire, donc que
leurs droits d'accès seront les mêmes, donc au moins: lecture et
écriture pour le propriétaire, puisque ces fichiers auront été écrits
par vos scripts php.

Cà, ce sont les droits d'accès des fichiers et répertoires.

Pour le Safe Mode, ce mode, s'il est activé dans la configuration php
dans le fichier de configuration php.ini, fait qu'il y a une
vérification, au moment de lecture, écriture ou exécution d'un fichier
ou script par php, que le fichier ou script, a des droits d'accès
conformes aux normes du Safe Mode, sinon l'accès est refusé.

Ces normes, je ne m'en souviens pas, mais d'autres que moi pourront
vous les indiquer.

Le commentaire de votre hébergeur, ne dit pas si le Safe Mode sera
activé ou non, mais qu'il sera "adapté".

Je vous conseille de vous renseigner auprès de votre hébergeur sur ce
point.

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Jean-Francois Ortolo <ortolo.jeanfrancois_nospam@free.fr.invalid>
écrivait news:4cbeaefc$0$12767$426a74cc@news.free.fr:

Bonjour Madame

Bonjour Monsieur (un peu cérémonieux pour un niouzegroupe, mais après
tout...) (:

En fait, j'aurais peut-être dû citer l'intégralité du message :

« Nous travaillons actuellement sur des mises à jour de la plate-forme
d'hébergement mutualisé afin de la rendre plus performante et sécurisée.

La semaine dernière nous avons modifié le système de répartition de charge
pour faire la distinction entre les requêtes statiques (images, html) et
dynamiques (PHP). Chaque type de requête est redirigé vers des serveurs
optimisés ce qui nous a permis de diviser par 5 le nombre de requêtes sur
les serveurs classiques tout en multipliant la vitesse de traitement des
requêtes statiques. Avec ces modifications les sites hébergés sont
sensiblement plus rapides. Le seul inconvénient est que les règles des
.htaccess ne sont plus respectés pour les fichiers statiques.

La prochaine étape aura lieu cette semaine et aura pour but de corriger
deux problèmes fréquemment rencontrés par nos clients : le safe_mode et
les conflits de permissions entre PHP et l'utilisateur FTP. La modification
qui sera faite fera en sorte que PHP s'exécutera en tant qu'utilisateur
normal et non plus en tant que "serveur web".

Début 2011 nous commencerons la migration vers PHP 5.3 qui apportera encore
plus de fonctionnalités et performances, malheureusement tous les sites ne
seront pas compatibles avec cette version et il faudra les adapter.
Comme pour la migration PHP 4 > PHP5, nous mettrons en place une
plate-forme de test.

Enfin, fin 2010 ou début 2011, nous changerons les serveurs MySQL par des
machines plus fiable, plus performantes et offrant plus de sécurité en
cas de panne. »

Du coup, je me demande aussi ce que va devenir mon .htaccess

php_flag register_globals Off
php_flag display_errors On
php_flag include_path Off
php_flag magic_quotes_gpc Off
ErrorDocument 404 http://www.la-grille-verte.net/404.html

Est-ce que ça veut dire par exemple que le renvoi vers la page 404 ne sera
plus actif pour les pages en html ? (ou alors j'ai rien compris, ce qui est
plus probable).

Et quid des incompatibilités éventuelles avec PHP 5.3 ?

Le serveur de votre hébergeur est probablement sous un système
Linux
ou Unix.

Un serveur Apache, oui (je cite) :
* Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
* Version du client MySQL: 5.0.51a
* Extension PHP: mysqli

[je me permets de couiquer le texte]
Ce que dit votre hébergeur, c'est qu'il vont faire en sorte, que
php
s'exécute avec comme propriétaire, celui de votre compte ftp, donc en
suexec, ce qui veut dire que les fichiers écrits par vos scripts php,
auront le même propriétaire, que celui de votre compte ftp.

Celà fera, que vous n'aurez plus aucune difficulté, pour charger ou
supprimer par ftp, ces fichiers créés par vos scripts php, puisque par
définition, leurs permissions dépendront du même propriétaire, donc
que leurs droits d'accès seront les mêmes, donc au moins: lecture et
écriture pour le propriétaire, puisque ces fichiers auront été écrits
par vos scripts php.

Je n'avais pas de difficulté jusque là, pourvu que ça dure...

Cà, ce sont les droits d'accès des fichiers et répertoires.

Pour le Safe Mode, ce mode, s'il est activé dans la configuration
php
dans le fichier de configuration php.ini, fait qu'il y a une
vérification, au moment de lecture, écriture ou exécution d'un fichier
ou script par php, que le fichier ou script, a des droits d'accès
conformes aux normes du Safe Mode, sinon l'accès est refusé.
Ces normes, je ne m'en souviens pas, mais d'autres que moi pourront
vous les indiquer.

Le commentaire de votre hébergeur, ne dit pas si le Safe Mode sera
activé ou non, mais qu'il sera "adapté".

Pour l'instant il est désactivé...

Je vous conseille de vous renseigner auprès de votre hébergeur sur
ce
point.

Merci, je vais le faire.

Et merci d'avoir pris le temps de me faire une réponse détaillée... et
compréhensible même pour moi !

--
Pascale
http://www.la-grille-verte.net

Le 20/10/2010 23:35, Pascale a écrit :

Jean-Francois Ortolo<ortolo.jeanfrancois_nospam@free.fr.invalid>
écrivait news:4cbeaefc$0$12767$426a74cc@news.free.fr:

Bonjour Madame

Bonjour Monsieur (un peu cérémonieux pour un niouzegroupe, mais après
tout...) (:

Peut-être devais-je dire Mademoiselle ;)

Du coup, je me demande aussi ce que va devenir mon .htaccess

php_flag register_globals Off
php_flag display_errors On
php_flag include_path Off
php_flag magic_quotes_gpc Off
ErrorDocument 404 http://www.la-grille-verte.net/404.html

Est-ce que ça veut dire par exemple que le renvoi vers la page 404 ne sera
plus actif pour les pages en html ? (ou alors j'ai rien compris, ce qui est
plus probable).

Je ne suis pas sûr.

Une page html est de type entièrement statique, théoriquement.

Si le caractère statique/dynamique est détecté en amont au moment de
la requête http reçue par le serveur ( d'après le suffixe de la page
demandée .html ), il se pourrait que le fichier .htaccess ne soit pas
pris en compte.

Je pense, que le moment venu, vous pourrez tester pour voir, avec une
requête sur un script html inexistant.

Et quid des incompatibilités éventuelles avec PHP 5.3 ?

Cà, faut voir un site décrivant ces nouveautés, et faire un audit de
votre site.

J'ai fait la requête suivante sur Google.fr : php5.3 nouveautés

Il y a beaucoup de réponses, dont celle-ci :

http://g-rossolini.developpez.com/tutoriels/php/5.3/

Ce que vous pourriez faire, c'est survoler les descriptions de ce
site, en catégorisant les nouveautés par types technologiques de
programmation, puis regarder tous les scripts php de votre site, en
vérifiant si les technologies employées ne sont pas incompatibles, et si
nécessaire, adapter vos scripts.

Vous avez intérêt, évidemment, à tester votre site sur votre
ordinateur en local, donc à disposer ( ou installer ) un serveur Apache
+ PHP 5.3.

C'est ce que j'ai fait pour mon site, qui est maintenant compatible
PHP 5.3, mais j'ai pensé qu'il valait mieux migrer des fonctions
mysql_*() de la base de données MySQL, à l'interface objet PDO d'accès à
MySQL.

J'ai fait celà, ( je crois ), dans l'optique d'être prêt au moment du
passage à PHP 6, puisque ces fonctions mysql_*() , ne seront
théoriquement plus supportées du tout, par PHP 6.

PHP 5.3 offre la possibilité de tester les fonctions qui seront
obsolètes ( = non supportées ) par PHP 6, et de donner des warnings en
cas d'incompatibilité.

Il suffit d'activer l'affichage des erreurs, et de positionner le
reporting d'erreurs, avec les instructions :

ini_set('display_errors', true);
error_reporting(E_ALL|E_STRICT|E_DEPRECATED);

La constante E_DEPRECATED est nouvelle dans PHP 5.3, et permet
d'afficher des warnings quand ces fonctions obsolètes, sont utilisées,
ou ( je crois ), quand il y a des problèmes d'incompatibilité.

Vous pouvez éventuellement mettre ces instructions dans un script
dédié de configuration ( par exemple display_errors.php ), et inclure ce
script dans votre script de configuration habituel, pour peu qu'il soit
situé avant toute exécution d'autres instructions éventuellement obsolètes.

Ainsi, vous aurez la possibilité de visualiser in situ, sur votre
ordinateur, les problèmes d'incompatibilité avec PHP 6, donc à fortiori,
avec PHP 5.3. Ceci, avec les quelques petites modifications ci-dessus.

Et merci d'avoir pris le temps de me faire une réponse détaillée... et
compréhensible même pour moi !

C'est la moindre des choses... ;)

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Jean-Francois Ortolo <ortolo.jeanfrancois_nospam@free.fr.invalid>
écrivait news:4cc00197$0$1075$426a74cc@news.free.fr:

[couic]

Je ne cite pas vos explications, mais je conserve votre message et vous
remercie de m'avoir donné ces informations.

--
Pascale
http://www.la-grille-verte.net

Le 04/11/2010 23:04, Pascale a écrit :

Jean-Francois Ortolo<ortolo.jeanfrancois_nospam@free.fr.invalid>
écrivait news:4cc00197$0$1075$426a74cc@news.free.fr:

[couic]

Je ne cite pas vos explications, mais je conserve votre message et vous
remercie de m'avoir donné ces informations.

Bonjour Mademoiselle ;)

En PHP 6, les fonctions de type posix ( ereg_replace() , split() ,
ereg() , etc... ) ne seront plus non plus disponibles.

Il faudra les remplacer par leurs équivalents pcre : (
preg_replace(), preg_split(), preg_match() , etc... ) avec tout ce que
celà implique comme migration des expressions rationnelles de type posix
que ces fonctions contiennent, vers les expressions rationnelles de type
pcre.

Ces nouvelles fonctions pcre étant disponibles dès maintenant, vous
avez intérêt à migrer vers elle, dès maintenant.

Il y a d'autres pratiques obsolètes en PHP 6, par exemple je crois,
le fait quand on a une chaîne de caractères, de pouvoir sélectionner un
caractère de la chaîne, avec un indice.

Par exemple, dans la chaîne $chaine = "abcd"; $chaine[2] est bien
égal à la lettre "c" en PHP 5.3, mais en PHP 6 cette pratique ( je crois
), est interdite.

D'ailleurs... ;( Je n'ai pas encore corrigé mon site, de ce point de
vue. Va falloir que je fasse des efforts. ;)

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Bonjour Mademoiselle ;)

Il y a d'autres pratiques obsolètes en PHP 6, par exemple je crois, le
fait quand on a une chaîne de caractères, de pouvoir sélectionner un
caractère de la chaîne, avec un indice.

Par exemple, dans la chaîne $chaine = "abcd"; $chaine[2] est bien égal à
la lettre "c" en PHP 5.3, mais en PHP 6 cette pratique ( je crois ), est
interdite.

D'ailleurs... ;( Je n'ai pas encore corrigé mon site, de ce point de
vue. Va falloir que je fasse des efforts. ;)

Bien à vous.

Amicalement.

Jean-François Ortolo

Je me corrige

Il semble que cette pratique de sélectionner une lettre d'une chaîne
de caractères par son indice, est encore valable en PHP 6.

Cependant, d'après un document pdf traitant de l'Unicode en PHP 6 que
j'ai lu, ce type de traitement est lent, et il faut lui préférer
l'utilisation de la classe Iterator, qui est très rapide.

Pas envie de faire la modification... Suis paresseux... ;(

J'espère quand même, que pour les versions suivantes après PHP 6, il
n'y aura pas trop de problèmes de compatibilité ascendante... ;(

On pourrait difficilement, par exemple, interdire définitivement aux
webmasters, de faire des sites en mode binaire ( iso-8859-1 et autres... )

Je vais quand même jeter un coup d'oeil à mon site dès demain, pour
voir s'il est vraiment compatible PHP 6.

Je crois, qu'il y a aussi le mode d'entrée-sortie de la base de
données MySQL, qui sera en mode UTF-8 par défaut. Il semblerait qu'il
faille ajouter un ordre SQL adéquat, pour que le mode soit en iso-8859-1.

Pas de problème, juste à ajouter une instruction MySQL dans le
fichier de configuration où se trouve les fonctions de connexion et de
déconnexion... ;)

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Jean-Francois Ortolo <ortolo.jeanfrancois_nospam@free.fr.invalid> écrivait
news:4cd48d57$0$9832$426a34cc@news.free.fr:

Je me corrige [couic]

J'ai intérêt à prendre des notes, et à activer mes deux neurones, moi !

Merci beaucoup pour vos explications.

--
Pascale