Mot-clé - cluster

Fil des billets

16oct. 2009

suPHP 0.7.1 SecurityException in Application.cpp:511

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 ?

30mar. 2009

Centralisation des sessions Magento en cluster

magento_logo.jpg
Après avoir effectué quelques recherches sur la centralisation des sessions Magento en cluster, 2 modes ont retenu mon attention.

Le premier mode avec une centralisation par base de données, et le second via un serveur Memcached.

Voici pour les développeurs la syntaxe à adopter pour l'utilisation d'un serveur Memcached via Magento :

<session_save><![CDATA[memcache]]></session_save>
 <session_save_path><![CDATA[tcp://XXX.XXX.XXX.XXX:11211?persistent=1&weight=2&timeout=10&retry_interval=10]]></session_save_path>
 <session_cache_limiter><![CDATA[]]></session_cache_limiter>
 <cache>
     <backend>memcached</backend>
     <memcached>
  <servers>
      <server>
   <host><![CDATA[XXX.XXX.XXX.XXX]]></host>
   <port><![CDATA[11211]]></port>
   <persistent><![CDATA[0]]></persistent>

Je ne suis pas du tout développeur donc si vous avez des améliorations, des conseils n'hésitez pas ;) Par ailleurs je rappel que Magento est une vraie usine à gaz et qu'il existe sur la toile une foule de conseils afin de l'optimiser.

Lien :

Session-cache-limiter

page 2 de 2 -