Magento et IPv6 ?

magento_logo

Magento et IPv6 ?

De prime à bord, on pourrait se dire que Magento est une application sur une plateforme LAMP, et qu'ainsi la question ne se pose pas. Néanmoins, Magento utilise à certains endroits des IP (comme par exemple dans la possibilité de définir les IP des développeurs pour réduire le champ d'application des aides aux développeurs), et donc il est quand même intéressant de vérifier si l'on trouve ou non des incompatibilités. Ma démarche s'est divisée en trois temps : maquetter un environnement IPv6, passer les services Mysql et Apache en IPv6, puis essayer de voir les points qui pourraient poser problème lors de l'utilisation de Magento en IPv6.

Environnement IPv6

La mise en œuvre d'un environnement IPv6 est assez analogue à celle d'un environnement IPv4 : on définit son plan d'adressage, puis on met en place un système de configuration d'IP, puis de résolution de nom.

En ce qui concerne le plan d'adressage, on commence par définir le préfixe réseau que l'on va utiliser. Comme je cherche à faire une infrastructure type qui pourrait être réellement exploitée, je me base sur la RFC 4193 qui précise la notion de Unique Local Adress et la notion d'id global sous-jacente.

En pratique, le global id est le hash de la concaténation d'un timestamp NTP de l'heure courante, et de l'EUI 64 d'une carte réseau locale. Le timestamp s'obtient facilement en faisant une capture de trame sur une interrogation de serveur (S)NTP (par exemple via NTP date). L'EUI-64 s'obtient très facilement en consultant l'adresse de lien local d'une carte réseau du système. On peut ensuite utiliser par exemple hexdump pour préparer le fichier concaténant les deux chaînes, puis sha1sum pour calculer le hash, dont on prend les 40 derniers bits.

C'est ainsi que j'ai obtenu le préfixe que j'ai utilisé pour mes tests : fd18:d035:84bb ::/48, qu'en pratique j'ai subnetté en /64 en utilisant le subnet 0000. J'utilise l'adresse se terminant par 1 pour le routeur (qui fait aussi serveur BD Mysql, Apache, et DNS), c'est à dire que j'ai lancé la commande

ip addr add dev eth1 fd18:d035:48bb::1/64

pour assigner cette adresse.

Il s'agit ensuite de diffuser sur le réseau ce préfixe, via des annonces de routeur : c'est justement le but du daemon radvd, qui supporte en particulier l'option rdnss qui permet de spécifier des IP de serveurs DNS à utiliser par les clients.

La configuration de radvd est assez simple :


interface eth1
{
AdvSendAdvert on;
prefix fd18:d035:48bb::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
RDNSS fd18:d035:48bb::1 {};
MinRtrAdvInterval 5;
MaxRtrAdvInterval 10;

};

Pour que RADVD daigne s'activer, il ne faut pas oublier d'activer le routage IPv6.


echo 1 >/proc/sys/net/ipv6/conf/all/forwarding

En faisant des captures de trames des Router Advertisements, on constate néanmoins que l'IP du routeur n'est pas présente, alors qu'on a l'habitude de fournir aux systèmes une ip de passerelle. Néanmoins, ceci n'est pas un problème, car la MAC du routeur est présente dans les options de l'annonce, et il faut se souvenir que c'est justement le fait de placer comme adresse mac de destination la MAC d'un routeur qui permet d'envoyer un paquet à un routeur.

En ce qui concerne l'exploitation de l'option rdnss, pour indiquer un service DNS récursif utilisable, j'ai installé sur les machines clientes le daemon rdnssd, qui modifie /etc/resolv.conf pour configurer les serveurs DNS à utiliser, ce qui permet par exemple de se passer d'un serveur DHCPv6 ou de multicast DNS.
Au niveau du serveur de nom, bind fait tout à fait l'affaire pour l'expérimentation. J'ai utilisé le domaine « test. » avec une configuration telle que suit :


$TTL 604800
@ IN SOA test. root.test. (
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS mag6.test.
@ IN AAAA fd18:d035:84bb::1
mag6.test. IN AAAA fd18:d035:48bb::1
db.test. IN AAAA ::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.b.8.4.5.3.0.d.8.1.d.f.ip6.arpa IN PTR mag6.test.

On devine à la vue de ce fichier que mon instance Magento va utiliser le FQDN mag6.test. Même si on pourrait reprocher l'enregistrement db.test, cet enregistrement va être fort utile par la suite pour n'avoir qu'une résolution v6 du localhost et ainsi exclure la possibilité qu'une connexion se fasse via de l'IPv4, sans pour autant spécifier l'IP::1.

De là, on a le nécessaire pour qu'une machine cliente s'auto-configure en IPv6. On peut maintenant s'atteler à la préparation de Mysql et d'Apache.

Mysql et Apache

L'adaptation de la configuration des deux logiciels est extrêmement simple. En ce qui concerne mysql, j'utilise une version 5.5, et il m'a suffit de modifier la bind-address dans my.cnf et de relancer mysql :

bind-address = ::1

J'ai mis l'adresse de loopback v6 car mysql et Apache sont sur la même machine dans mon maquettage. J'ai ensuite simplement besoin de préparer une BD et un utilisateur ne pouvant se connecter qu'en IPv6 (et pas en v4).


mysql> create database mag6 ;
Query OK, 1 row affected (0.00 sec)

mysql> create user 'mag6'@'::1' identified by 'XXXXXXXX';
Query OK, 0 rows affected (0.01 sec)

mysql> grant all on mag6.* to 'mag6'@'::1';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

Au niveau d'Apache, j'ai cette fois-ci besoin de rendre le service disponible sur le réseau, donc j'utilise par simplicité l'IP du routeur dans ma définition de VirtualHost.


Listen [fd18:d035:48bb::1]:80
<VirtualHost [fd18:d035:48bb::1]:80>
DocumentRoot /var/www/mag6/magento
ServerName mag6.test
<Directory /var/www/mag6/magento>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

On constate qu'on arrive à séparer correctement le port du reste de l'IP grâce à la notation entre crochets de l'IP.

De là, on est maintenant prêt à installer Magento et à tester son fonctionnement.

Test de Magento sous v6

Le test va commencer tout d'abord son installation. J'utilise la version 1.9.1.0, avec les données d'exemple associées.

L'installation des données de test dans la BD avec le client mysql se passe sans heurt, tout comme la mise en place des fichiers. En revanche, le premier problème arrive lorsqu'il faut indiquer le serveur de BD à utiliser dans le processus d'installation depuis le site web : en effet, aucune des trois écritures ::1, ::1:3306, et [::1]:3306 n'est validée par Magento. C'est là que j'ai utilisé le nom db.test, de sorte que la résolution de nom se passe par la suite correctement en utilisant une connexion IPv6. Cette étape passée, l'installation se déroule alors normalement.

On arrive ensuite à un site Magento qui semble entièrement fonctionnel : on arrive à naviguer sur le site en front office et en back office, de même qu' à passer des commandes. D'ailleurs, l'IP indiquée dans le BO pour la commande passée est bien l'IP de mon routeur, car j'ai essayé depuis un browser de la même machine. Cela semble donc assez bien parti.

J'essaye ensuite de tester les restrictions d'IP pour définir quand Magento doit afficher les aides pour développeur. A première vue, en indiquant l'IP du routeur dans la restriction, cela semble fonctionner. J'arrive depuis le client local à avoir l'affichage de l'aide, tandis que je n'ai pas l'affichage d'aide développeur sur une autre machine. Je décide ensuite de modifier quelque peu l'IP que j'ai indiqué : fd18:d035:48bb::1 pour une autre forme : fd18:d035:48bb::0:1. Même si cette forme n'est pas la forme la plus compacte, c'est une forme autorisée par la RFC 4291. Et c'est là que le bât blesse : cette écriture ne permet plus d'afficher sur la machine locale les aides de développeur.

Je décide ensuite de faire une recherche avec grep sur le code source, pour vérifier l'utilisation des fonctions PHP inet_pton ou inet_ntop . Je n'ai pas trouvé l'emploi de ces fonctions dans le code source, qui auraient peut-être pu régler cette problématique en passant à une notation in_addr (ce serait à tester dans le cadre d'un éventuel patch pour régler le problème).
On constate donc que même si globalement le site semble fonctionner, il y a quand même encore des points où il reste encore du travail pour améliorer la compatibilité avec IPv6.

Je décide donc de faire un tour dans la BD pour essayer de trouver où et comment sont stockées les adresses IP : je cherche donc la chaîne « ip » dans les descriptions des tables. Pour me faciliter la vie, je fais mes recherches avec du less sur


select table_name,column_name,data_type,character_maximum_length from columns where table_schema='mag6' order by table_name,column_name;

Je constate alors que l'on a vraisemblablement l'utilisation d'IP dans plusieurs tables :

  • poll_vote : ip_address : bigint
  • rating_option_vote : remote_ip varchar 16 et remote_ip_long bigint
  • sales_flat_order: remote_ip varchar 255
  • sales_flat_quote : remote_ip varchar 32
  • sendfriend_log : ip bigint

Et là, on voit que ces représentations d'IP ne conviennent pas toujours : en effet, sous mysql, le type de données bigint fait 8 octets, soit 64 bits, alors qu'une IPv6 fait 128 bits. De plus, dans une représentation textuelle d'une adresse v6, on utilise jusqu'à 128/4=32 hexadécimaux, groupés par 4, soit 8 groupes, séparés par sept doubles points : on en arrive donc à utiliser jusqu'à 39 caractères pour une IPv6 ce qui est supérieur aux valeurs 16 et 32 utilisées dans certains varchar.

Afin d'être plus complet, je décide également de faire une recherche sur les codes des attributs pour voir s'il n'y a pas d'IP dans les attributs des EAV, mais je n'ai pas vu d'attribut susceptible de contenir une IP.

En conclusion, on constate qu'il y aura encore un peu de travail à fournir pour adapter Magento par rapport à IPv6. Cependant, il ne faut pas oublier que je n'ai inspecté qu'une instance Magento de démonstration, et qu'une installation traditionnelle de production utilise souvent des modules tiers de la communauté. Ce qui signifie qu'il faudra également inspecter ces modules particuliers à chaque instance Magento lors d'un passage en IPv6. Et de manière générale, il faudrait sensibiliser les programmeurs à cette problématique pour éviter que du code non compatible IPv6 soit encore produit.

Un commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.