Apache : résoudre l'erreur

Apache : résoudre l’erreur “421 Misdirected Request”

Après la mise à jour d’Apache et HTTP/2, il est apparu un nouveau type d’erreur : l’erreur 421 Misdirected Request.

Erreur 421 : erreur de configuration mod_ssl entre Virtual Hosts

Ce type d’erreur arrive lorsque:

  1. HTTP/2 est activé,
  2. les paramètres SSL de plusieurs Virtual Hosts diffèrent du serveur responsable du handshake SSL/TLS.

En analysant le changelog d’Apache 2.4.18, je me suis rendu compte que si les paramètres SSL et notamment la liste des ciphers utilisables ne sont pas équivalentes entre les différents Virtual Hosts, alors l’erreur 421 est déclenchée.

Solution : harmoniser la configuration mod_ssl

La solution est donc toute simple, il suffit de comparer la configuration mod_ssl des Virtual Hosts et l’harmoniser de manière à lisser les différences. Je vous recommande un outil comme Meld pour comparer les différences entre vos fichiers.

Meld est disponible dans les dépôts de base, vous pouvez l’installer sur votre machine de dév avec un simple:

apt-get install meld

Le domain sharding ou servir les ressources statiques sur un sous-domaine

Sur le site, cela est dû à la mise en place du domain sharding que j’avais mis en place il y a quelques années pour charger plusieurs fichiers ressources en parallèle et accélérer les temps de chargement.

HTTP/2 promet beaucoup de choses et apparemment le domain sharding serait maintenant devenu inutile. J’attends un peu de voir comment vont évoluer les choses avant de changer toute ma configuration et éditer tous mes liens.

PHP : solution pour l'erreur

PHP : résoudre l’erreur “Redefining already defined constructor for class …”

php-logo

Il vous est peut-être déjà arrivé d’obtenir l’erreur PHP suivante en mode strict sous PHP 5.4 et versions ultérieures:

Redefining already defined constructor for class {nom_de_la_classe}

Cela arrive lorsque – dans le code d’une classe -, le code PHP4 précède le code PHP5 avec le constructeur de classe.

Le problème : une fonction PHP4 précédant le constructeur PHP5

Voici un petit exemple pour bien comprendre, avec une classe SkymindsExampleClass, une fonction qui s’appelle SkymindsExampleClass() et donc porte le même nom, et la fonction constructeur __construct().

L’exemple suivant produit l’erreur Redefining already defined constructor for class parce que la fonction PHP4 SkymindsExampleClass() se trouve avant la fonction PHP5 __construct() :

<?php
// This example outputs a PHP error in strict mode
class SkymindsExampleClass {
	//PHP4
	function SkymindsExampleClass()
	{
		$this->__construct();
	}
	//PHP5
	public function __construct()
	{
		$this->admin_page();
	}
}

La solution : placer le code PHP5 avant le code PHP4

Pour supprimer l’erreur PHP stricte, il suffit de placer la fonction PHP5 avant la fonction PHP4.

Lire la suite

PHP : résoudre l'erreur

PHP : résoudre l’erreur Apache “child pid xxxx exit signal Segmentation fault (11)”

php-logo

J’ai découvert dernièrement qu’après une mise à jour du module php-apc, mes logs Apache étaient emplis de message d’erreur comme ceux-ci :

[Sun Nov 02 09:15:11 2014] [notice] child pid 5937 exit signal Segmentation fault (11)
[Sun Nov 02 09:17:36 2014] [notice] child pid 5586 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:50 2014] [notice] child pid 6230 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:51 2014] [notice] child pid 6388 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:52 2014] [notice] child pid 6228 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:53 2014] [notice] child pid 6235 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:54 2014] [notice] child pid 6392 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:55 2014] [notice] child pid 6385 exit signal Segmentation fault (11)

Cela en fait des erreurs !

Augmenter la taille de la limite de mémoire PHP

Sur le serveur, APC est configuré pour utiliser un unique segment de 128 Mo. Le problème, c’est que la directive memory_limit de PHP est elle aussi à 128 Mo. Par conséquent, il convient d’augmenter cette dernière :

1. On édite notre fichier de configuration PHP :

nano /etc/php5/apache2/php.ini

2. On recherche (Ctrl + w) le mot clé memory_limit et on remplace:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = -1

par

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
; memory_limit = -1
memory_limit = 256M

3. On enregistre la nouvelle configuration et on relance Apache :

service apache2 restart

Vérifiez maintenant les logs Apache. Cela peut ne pas être suffisant.

Désinstaller APC

Dans mon cas, avec PHP 5.4.x, APC semble générer ces erreurs de manière aléatoire. J’ai donc désactivé APC avec :

apt-get remove php5-apc

Après relance du serveur Apache et analyse des logs, la situation est revenue à la normale :

Apache PHP/5.4.34 configured -- resuming normal operations

Le problème viendrait donc d’APC et de PHP 5.4 – il est important de noter que PHP 5.5 contient déjà un optimiseur de code intégré (Zend) donc à la prochaine mise à jour majeure de PHP, il sera inutile d’installer APC.

Linux : résoudre l'erreur

Linux : résoudre l’erreur “failed to execute /lib/udev/socket:@/org/freedesktop/hal/udev_event”

linux-logo

Après une mise à jour de votre installation Linux, et après avoir rédémarré votre machine, il est possible que vous obteniez des dizaines de messages d’erreur au moment du boot du système.

Le problème : des messages venant de Hal

Concrètement, dans demsg, on obtient toute une série de messages comme ceux-ci :

 [   12.543288] udevd[2958]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
[   12.548789] udevd[2962]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory

Solution : désinstaller hal

Et bien sachez qu’il suffit de désinstaller Hal avec :

sudo apt-get remove hal

hal était une bibliothèque permettant l’accélération matérielle sous les systèmes GNU/linux et qui servait aux applications à découvrir et utiliser les composants de la machine.

Depuis le kernel 2.65, cette fonctionnalité a été fusionnée avec udev qui gère maintenant tout cela.

PHP : résoudre l'erreur

PHP : résoudre l’erreur “Creating default object from empty value”

php-logo

Suite à la mise à jour de PHP, mon fichier d’erreurs du site a commencé à afficher le message suivant :

PHP Warning: Creating default object from empty value in /wp-content/themes/skyminds/functions.php on line 1213

La ligne en question correspond à :

$posts[0]->comment_status = 'closed';

Le problème réside dans le fait que $posts n’est pas explicitement défini et comme les versions récentes de PHP tournent maintenant avec le mode E-STRICT par défaut, on obtient une erreur. Il existe deux solutions – soit mettre :

$posts = new stdClass();

s’il sagit d’un objet, soit mettre :

$posts = array();

s’il s’agit d’une associative array, juste avant la ligne de code incriminée. Dans mon cas, l’array() est la bonne solution.

PHP : solution pour l'erreur

PHP : résoudre l’erreur “function eregi() is deprecated”

php logo

Il vous est peut-être déjà arrivé de tomber sur ce message d’avertissement :

Function eregi() is deprecated.

En fait, “deprecated” signifie que les versions récentes de PHP considèrent cette fonction comme obsolète, c’est un peu comme si la fonction ereg() n’existait plus.

Par conséquent, mieux vaut dorénavant utiliser la fonction preg_match qui a pris sa place.

La fonction ereg() ou eregi() est donc remplacée par la fonction preg_match() depuis PHP 5.3 :

$is_image = eregi( "jpg|gif",$file_type );

devient donc :

$is_image = preg_match( “~jpg|gif~i”,$file_type );

Voici la liste des fonctions devenues obsolètes sous PHP 5.3 :

call_user_method() (use call_user_func() instead)
call_user_method_array() (use call_user_func_array() instead)
define_syslog_variables()
dl()
ereg() (use preg_match() instead)
ereg_replace() (use preg_replace() instead)
eregi() (use preg_match() with the ‘i’ modifier instead)
eregi_replace() (use preg_replace() with the ‘i’ modifier instead)
set_magic_quotes_runtime() and its alias, magic_quotes_runtime()
session_register() (use the $_SESSION superglobal instead)
session_unregister() (use the $_SESSION superglobal instead)
session_is_registered() (use the $_SESSION superglobal instead)
set_socket_blocking() (use stream_set_blocking() instead)
split() (use preg_split() instead)
spliti() (use preg_split() with the ‘i’ modifier instead)
sql_regcase()
mysql_db_query() (use mysql_select_db() and mysql_query() instead)
mysql_escape_string() (use mysql_real_escape_string() instead)
Passing locale category names as strings is now deprecated. Use the LC_* family of constants instead.
The is_dst parameter to mktime(). Use the new timezone handling functions instead.

Augmenter la mémoire PHP pour WordPress

Il y a quelques jours, mon hébergeur a mis à jour son serveur Apache qui est passé de la version 1.3.37 à la version 2.2.6.

Gros changement donc mais dont je ne me suis réellement rendu compte que lorsque j’ai voulu poster un nouvel article sur le site.

Je me suis trouvé nez à nez avec cette erreur :

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 139816 bytes) in /home/cpanel/public_html/wp-includes/cache.php on line 51

Petit mail au support qui, une fois n’est pas coutume, ne sait pas comment résoudre le problème. Etrange.

On voit bien que c’est un problème de mémoire pourtant : Apache 2 serait-il plus gourmand qu’Apache 1 ? 8 Mo seraient-ils insuffisants ?

Lire la suite

Résoudre l’erreur HTTP 406 Not Acceptable

Depuis que mon hébergeur a mis ses serveurs en cluster et exécute PHP en CGI et non comme module Apache, certaines fonctions de WordPress ne se comportent pas correctement, notamment les éditeurs de fichiers.

En effet, ces derniers semblent être devenus incapables de modifier les fichiers sans provoquer une erreur HTTP 406 :

HTTP Error 406 – Not acceptable
An appropriate representation of the requested resource /XYZ.php could not be found on this server.

Après quelques recherches, il semblerait que ce soit les filtres du mod_security d’Apache qui, trop restrictifs, empêchent les éditeurs… d’éditer !

La solution consiste donc à désactiver mod_security dans le répertoire où se trouvent les éditeurs (/wp-admin/ dans le cas de WordPress) :

  1. Créez un fichier .htaccess
  2. Editez le fichier avec ces instructions :
    
    SecFilterEngine Off
    SecFilterScanPOST Off
    
    
  3. Sauvegardez : vos éditeurs devraient maintenant fonctionner sans aucune erreur.

Notez que j’ai pris WordPress comme exemple mais cela résout les problèmes d’erreurs 406 quelle que soit l’application utilisée (blog, CMS…).

Mieux vaut créer le .htaccess dans le répertoire qui en a besoin : il est inutile voire déconseillé de désactiver mod_security sur l’ensemble d’un domaine pour des raisons évidentes de sécurité.

A utiliser là où il y a besoin donc.