Mot-clé - php

Fil des billets

08mars 2010

Gestion des sessions Magento

20:28 - Par Mohamed YACOUBI - Magento

magento_logo.jpg
Suite à mon article Centralisation des sessions Magento en cluster présentant l'utilisation de Memcached avec Magento, voici également d'autres façons de gérer les sessions.

  1. Utilisation du mode par défaut :

Lors de l'utilisation de ce mode par défaut, les sessions sont sauvegardées dans le répertoire /home/www/domain.com/var/session. Dans le cadre d'un système clusterisé il serait nécessaire de mutualiser ce répertoire.

Dans le cadre de l'utilisation de Magento sur un serveur en StandAlone, je vous conseil de stocker vos sessions (profitez-en pour vous occuper du cache) en RAM afin d'optimiser au mieux les accès.
Par exemple mon /etc/fstab avec 256Mo alloué pour le cache et 64Mo pour les sessions

tmpfs /home/www/domain.com/var/cache tmpfs size=256M 0 0
tmpfs /home/www/domain.com/var/session tmpfs size=64M 0 0

Attention en cas de redémarrage du serveur le cache et les sessions seront intégralement perdus, il conviendra donc de régénérer le cache depuis l'administration.

  1. Utilisation d'une base de données :

Il vous suffit de choisir l'option appropriée lors de l'étape 3 de l'assistant d'installation : Save session data in Database ou d'effectuer la modification suivante dans app/etc/local.xml.

<session_save><![CDATA[db]]></session_save>

Les sessions devraient à présent apparaître dans la table core_session.

  1. Utilisation de Memcached :

Voir le précèdent billet : Memcached et Magento

23déc. 2009

Attaque DOS PHP < 5.2.12 suite

11:55 - Par Mohamed YACOUBI - Php

php_logo.png
Une petite mise à jour du ticket précédent Attaque DOS PHP < 5.3.1

Le 17 Décembre 2009, l'équipe de PHP a releasé PHP-5.2.12 qui corrige également cette vulnérabilité. 

Version 5.2.12
17-December-2009

    * Security Fixes
          o Added "max_file_uploads" INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion. (Ilia)


Le changelog de PHP est disponible : PHP-5.3 Changelog

11déc. 2009

Attaque DOS PHP < 5.3.1

19:16 - Par Mohamed YACOUBI - Php

php_logo.png
Cela fait quelques jours que je voulait ajouter un nouveau billet sur cette faille.

Récemment, une faille a été découverte sur toutes les versions de PHP inférieures à 5.3.1.
Cette faille permet une attaque de type DOS (Denial Of Service), la faille consiste à envoyer via une requête POST plusieurs milliers de fichiers sur le serveur jusqu'à saturer ce dernier.


D'après ce rapport que je vous invite vivement à consulter, chaque système réagit différemment.

Pour l'heure 2 solutions existent afin de palier au problème :

  • Désactiver la directive file_uploads dans le php.ini si vous n'en avez pas besoin (file_uploads = Off)
  • Mettre à jour PHP vers 5.3.1. Une nouvelle directive "max_file_uploads" fait son apparition avec une valeur par défaut de 20 (max_file_uploads = 20)

Le changelog de PHP est disponible : PHP-5.3 Changelog

16oct. 2009

suPHP 0.7.1 SecurityException in Application.cpp:511

18:49 - Par Mohamed YACOUBI - Php

php_logo.png
Le 17 Septembre 2009, suPHP 0.7.1 a enfin été ajouté au portage Gentoo

* mod_suphp-0.7.1 (17 Sep 2009)
 
  17 Sep 2009; Benedikt B <hollow@gentoo.org>
  -mod_suphp-0.6.2-r3.ebuild, +mod_suphp-0.7.1.ebuild:
  version bump wrt #253537


Rappel de son utilité : suPHP est un outil permettant d'exécuter des scripts PHP avec les autorisations de leurs propriétaires (à l'inverse Mod_PHP exécute les scripts PHP avec l'utilisateur apache). Il se compose d'un module Apache (mod_suphp) et un binaire setuid root (suphp) qui est appelée par le module Apache pour changer l'uid du processus d'exécution de l'interpréteur PHP. Cela garanti donc en cas de hack sur l'un de vos hébergements que le hackeur ne puisse pas modifier au moyen d'un script PHP les hébergements appartenant aux autres comptes.

Devant installer un nouveau serveur, j'ai rapidement été tenté d'essayer cette nouvelle version après avoir bien entendu consulté le Changelog.

Or, à partir de la version 0.7.0, il faut modifier le fichier de configuration (/etc/suphp.conf) et ajouter des guillemets aux directives :

--- /etc/suphp.conf.old    2009-10-16 19:05:13.000000000 +0200
+++ /etc/suphp.conf     2009-10-16 18:38:49.000000000 +0200
@@ -38,10 +38,10 @@
 
 [handlers]
 ;Handler for php-scripts
-x-httpd-php=php:/usr/lib/php5/bin/php-cgi
-x-httpd-php5=php:/usr/lib/php5/bin/php-cgi
-x-httpd-php4=php:/usr/lib/php4/bin/php-cgi
-x-httpd-phtml=php:/usr/lib/php5/bin/php-cgi
+x-httpd-php="php:/usr/lib/php5/bin/php-cgi"
+x-httpd-php5="php:/usr/lib/php5/bin/php-cgi"
+x-httpd-php4="php:/usr/lib/php4/bin/php-cgi"
+x-httpd-phtml="php:/usr/lib/php5/bin/php-cgi"
 
 ;Handler for CGI-scripts
-x-suphp-cgi=execute:!self
+x-suphp-cgi="execute:!self"

Sans quoi aucun script PHP ne fonctionnera.

SecurityException in Application.cpp:511: Unknown Interpreter: php
Premature end of script headers: setup.php

A présent je me demande pourquoi la compatibilité de l'ancien fichier n'a pas été conservé ?

Une feature révolutionnaire dans la prochaine mouture ?

10juil. 2008

Segmentation Fault sous Gentoo (PHP 5.2, Mysql 5)

14:27 - Par Mohamed YACOUBI - Php - un commentaire

php_logo.png
Une petite mise à jour de PhP afin de passer en version "dev-lang/php-5.2.6-r2" et plus rien ne fonctionne ...

Grosse galère :

srv78 tad63 # php index.php
segmentation fault
srv78 tad63 #

Une petite recherche me fait rapidement douter sur les CFLAGS utilisaient :

CFLAGS="-O3 -march=prescott -mfpmath=sse -pipe -fforce-addr -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays -funroll-loops"

Une petite recherche plus approfondie m'aide un peu plus à cibler le problème : http://bugs.gentoo.org/show_bug.cgi?id=227373

On retire le flag d'optimisation -funroll-loops dans le make.conf et on recompile PHP :)