01janv. 2010

Optimisation de Magento avec la réplication Mysql

magento_logo.jpg
Pour les utilisateurs d'une réplication mysql et de Magento, il faut savoir que tout a été prévu par Magento afin d'optimiser le traitement des requêtes Mysql avec un serveur dédiée à la lecture, et un second à l'écriture.

Voici pour les développeurs la syntaxe à adopter :

       <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                        <host><![CDATA[Mysql_Write:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[bdd_name]]></dbname>
                    <active>1</active>
                </connection>
            </default_setup>
            <default_read>
                <connection>
                        <host><![CDATA[Mysql_ReadOnly:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[bdd_name]]></dbname>
                    <active>1</active>
                </connection>
            </default_read>
        </resources>

Bien entendu, il ne faut pas oublier que je préconise un serveur Mysql dédié au rôle de Read Only, donc une réplication avec des paramètres avancés du type Replicate_Wild_Ignore_Table afin d'éviter une action du type Je me suis trompé de serveur lors de l'insertion et la réplication Mysql sur le serveur RO est donc en erreur

Lien :

Magento Performance Group

23déc. 2009

Attaque DOS PHP < 5.2.12 suite

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

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

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 ?

15sept. 2009

Xen bridge IPv6 support

Xen_logo.png
A chaque mise à jour de Xen je me retrouve confronté à un bug causé par le support IPv6 compilé dans le kernel.
Ce petit bug est présent depuis près d'une année il sera peut être un jour corrigé, en attendant voici le patch à utiliser (ça m'évitera d'avoir à le rechercher la prochaine fois)

--- /etc/xen/scripts/network-bridge~	2008-06-03 14:50:29.000000000 +0100
+++ /etc/xen/scripts/network-bridge	2008-06-03 14:50:29.000000000 +0100
@@ -90,7 +90,7 @@
 tdev=tmpbridge
 
 get_ip_info() {
-    addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e "s/$1//"`
+    addr_pfx=`ip addr show dev $1 | egrep '^ *inet ' | sed -e 's/ *inet //' -e "s/$1//"`
     gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
 }



Patch : xen-vif-bridge-ipv6-225715.diff
Lien : Gentoo Bug 225715

27août 2009

myisamchk error Not enough memory for blob

mysql_logo.gif
Une nouvelle erreur apparu sur une table corrompu suite à un crash Mysql pour manque de RAM (Out of memory).

Tout d'abord un petit rappel sur la façon qu'utilise le moteur MyISAM pour la gestion des tables :

  1. wordpress_postmeta.MYD - la table où tous les enregistrements sont stockés.
  2. wordpress_postmeta.MYI - l'index pour les tables.
  3. wordpress_postmeta.frm - le schéma de la table.


Voici l' erreur rencontrée lors de la réparation de la table :

srv1234 ~ # myisamchk -r /var/lib/mysql/wordpress/wordpress_postmeta.MYI
 
- recovering (with sort) MyISAM-table '/var/lib/mysql/wordpress/wordpress_postmeta.MYI'
Data records: 31769
- Fixing index 1
Wrong block with wrong total length starting at 94358749
myisamchk: error: Not enough memory for blob at 94358800
MyISAM-table '/var/lib/mysql/wordpress/wordpress_postmeta.MYI' is not fixed because of errors

Cela se produit parce que l'entrée de l'index invalide indique que la taille d'un champ BLOB est plus grande que celle spécifié entre parenthèse. La correction a été assez simple, il suffit d'ajouter l'option --max-record-length=0.

srv1234 ~ # myisamchk --max-record-length=0 -r /var/lib/mysql/wordpress/wordpress_postmeta.MYI

Dans le cas présent la valeur --max-record-length=0 permet de ne définir aucune limitation sur la taille du champ BLOB.

20août 2009

Suite de la présentation du datacenter Equinix

Bonjour,

Suite à mon précédent billet sur présentation du Datacenter Equinix, on savait déjà que chez Equinix c'était un endroit dont il faisait bon vivre ...

Après l'incident électrique causé par une erreur humaine Panne Electrique du 02/07/2009, cette fois ci l'incident a impacté les climatisations engendrant au pic de l'incident une température relevée de 41° au 2nd étage, il s'agit donc d'une nuit passée au Datacenter à gérer les pannes provoquées (Pour une fois le parking était complet durant la nuit) ...

Temperature critique

Si on part du principe qu'on choisi un Datacenter pour l'électricité, la climatisation et la sécurité, il ne reste que la sécurité pour laquelle aucun incident majeur n'est à signalé. On verra donc ce qui se passera dans les semaines et/ou mois à l'avenir pour ce point (pourquoi pas un salarié d'Equinix qui pète les plombs et déclenche un incendie ....)

Notre "communiqué de presse" incluant tout les détails de l'événement de cette nuit est disponible à l'adresse suivante : Incident de climatisation à Equinix St-Denis du 19/08/09

22juil. 2009

Xen installation de windows avec support VNC

Xen_logo.png
Je dispose d'un processeur supportant la virtualisation matérielle, je vais donc m'atteler à l'utilisation un système Windows en tant que DomU Xen (Je passe volontairement les pré-requis CPU/BIOS). Pour ce faire je vais devoir activer le support VNC pour Xen, le Dom0 Xen ne disposant que d'un accès SSH.

De nombreux how to 's existent sur la toile néanmoins ces derniers sont rarement à jour, le use flag "vnc" ayant par exemple disparu sous Gentoo.

Enfait rien de bien spécial à faire, le support est inclus nativement, voici la configuration que j'ai adopté :

Informations systèmes :

dom0 ~ # equery l xen
[ Searching for package 'xen' in all categories among: ]
 * installed packages
[I--] [ ~] app-emulation/xen-3.3.1-r1 (0)
[I--] [ ~] app-emulation/xen-tools-3.3.1 (0)
[I--] [M~] sys-kernel/xen-sources-2.6.21 (2.6.21)
[I--] [ ~] sys-kernel/xen-sources-2.6.30-r2 (2.6.30-r2)

Fichier de configuration DomU : /etc/xen/win2k3

import os, re
arch = os.uname()[4]
if re.search('64', arch):
    arch_libdir = 'lib64'
else:
    arch_libdir = 'lib'
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 256
name = "win2k3"
vif = [ 'type=ioemu, bridge=xenbr0' ]
disk = [ 'phy:/dev/500/windows,ioemu:hda,w','file:/root/win2003.iso,hdc:cdrom,r' ]
boot = 'cd'
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
vnc=1
vnclisten="IP_Dom0"
vncdisplay=1
vncunused=0
keymap='fr'
usb='1'
usbdevice='tablet'

Fichier de configuration Dom0 : /etc/xen/xend-config.sxp

(xend-relocation-server yes)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 196)
(enable-dom0-ballooning yes)
(dom0-cpus 0)
(vnc-listen '0.0.0.0')
(vncpasswd 'azerty')

L'accès au serveur crée sur le DomU Xen se fera au travers de VNC le temps de l'installation, le port à utiliser sera alors 5900 + vncdisplay soit dans le cas présent IP_Dom0:5901

Il est à noter que le lancement des DomU Xen sous Windows posait des problèmes lors du 2nd boot (après l'étape de formatage et de copie des fichiers d'installation), un upgrade vers le kernel 2.6.30-r2 a pour ma part résolu le problème.

27mai 2009

dev-util/subversion-1.6.2 Cannot allocate memory

Me voila confronté à une superbe erreur avec ma Gentoo toute neuve :)

/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6628: /bin/sed: Cannot allocate memory
libtool: install: warning: `../../subversion/libsvn_subr/libsvn_subr-1.la' has not been installed in `/usr/lib'
libsandbox:  max_envp_len too big!
/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6669: /bin/sed: Cannot allocate memory
/usr/bin/install -c  /var/tmp/portage/dev-util/subversion-1.6.2/image//usr/bin/svnadmin
libsandbox:  max_envp_len too big!
/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6691: /usr/bin/install: Cannot allocate memory
make: *** [install-bin] Error 126
 * 
 * ERROR: dev-util/subversion-1.6.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_install
 *             environment, line 5883:  Called die
 * The specific snippet of code:
 *       emake -j1 DESTDIR="${D}" local-install || die "Installation of core of Subversion failed";
 *  The die message:
 *   Installation of core of Subversion failed

Tout d'abord je vérifie que ma version de sed est bien à jour, mais c'est le cas.

srv1 tmp #  eix sys-apps/sed
[I] sys-apps/sed
     Available versions:  4.1.5-r1 ~4.2 {acl nls static}
     Installed versions:  4.1.5-r1(14:31:27 08/06/08)(nls -static)
     Homepage:            http://sed.sourceforge.net/
     Description:         Super-useful stream editor

Puis l'erreur libsandbox attire mon attention, je me décide de mettre à jour sandbox qui en avait besoin.

srv1 tmp # emerge -av sandbox
 
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild     U ] app-misc/pax-utils-0.1.19 [0.1.17] USE="-caps" 76 kB
[ebuild     U ] sys-apps/sandbox-1.6-r2 [1.2.18.1-r2] 300 kB

Et voila le problème est résolu, probablement un oubli dans l'ebuild qu'il me reste à remonter ;)

11avr. 2009

Xen creation d'un reseau prive via un bridge

Xen_logo.png
Depuis le début, j'utilise les adresses IPs publique des DomU Xen pour les communications internes comme par exemple Mysql <=> Web.

Je me suis donc enfin penché sur la question de la mise en place d'un réseau privé dédié et facilement déployable entre plusieurs serveurs Dom0.

Voici pour rappel la configuration par défaut en bridge :

dom0: ----------------- bridge -> real eth0 -> the network
                           |
domU: fake eth0 -> vifN.0 -+

En plus du bridge par défaut, le but est de disposer de cette configuration pour eth1 :

dom0: ----------------- bridge -> real eth1 -> Not connect
                           |
domU: fake eth1 -> vifN.1 -+

Ceci me permettra donc en cas d'ajout d'un nouveau Dom0 Xen, de raccorder les interfaces eth1 de mes Dom0 et de laisser mes DomU communiquer entre eux comme si de rien n'était, mais bon je n'en suis pas encore là ;)

Voici donc comment procéder pour la création d'un bridge, c'est très simple :

1) On crée le bridge :

brctl addbr private

2) On ajoute une interface au bridge :

brctl addif private eth1

3) Et enfin on monte cette interface avec une IP :

ifconfig private 192.168.0.1/24 up

Il ne nous reste qu'a configurer le DomU de manière classique et la communication Dom0 <=> DomU ou DomU <=> DomU devrait se faire :)

Cette configuration est par contre volatile, au redémarrage elle sera alors perdu je vous conseil donc de mettre en place un script dans les rc.d ou de modifier le script de démarrage de Xen pour prendre en compte ces commandes au lancement.

- page 3 de 5 -