cluster

Replication mysql – Configuration maitre-esclave

Schema replication maître esclave mysqlConfiguration de la réplication avec mysql, dans un modèle maître esclave.

Voilà un petit post qui va expliquer en suivant en gros la documentation de mysql (http://dev.mysql.com/doc/refman/5.0/fr/replication-howto.html), comment mettre en place la réplication, de manière pragmatique et fonctionnelle.

Comme toujours, avant toute opération, assurez vous d’avoir une copie de sauvegarde de l’ensemble des éléments modifiés avant d’appliquer quoi que ça soit, afin de pouvoir revenir en arrière en cas de soucis (fichiers de configuration, données etc.).

J’ai pour cette opération un serveur sous Fedora 8 (qui date mais qui fait le job) équipé de mysql-server 5.0.45 en production et standalone (qui travaille tout seul comme un grand) jusqu’ici; et, un serveur sous Fedora 13 (utilisé pour du stockage uniquement jusqu’ici) équipé de mysql-server 5.1.56 fraichement installé avec un petit :

yum install mysql-server
chkconfig --level 345 mysqld on

L’idée étant de mettre en place la réplication du premier qui deviendra « master » (maître), sur le second, qui deviendra « slave » (esclave). A mon sens l’utilité de la réplication avec MySQL est principalement valable pour 2 points :
– Avoir une copie des données, lisible en production
– Répartir la charge sur plusieurs serveurs (un serveur exclusivement pour les requêtes en écriture – le maitre, un autre dédié aux requêtes en lecture – le ou les esclave(s)).

Attention cependant, la réplication MySQL ne dispense pas de mettre en place une stratégie de sauvegarde ! Car, par exemple, un effacement accidentel de données sur le maître entraîne la modification quasi immédiate sur les machines répliquées ! Dans une telle situation, seule une sauvegarde « traditionnelle » (façon mysql dump) vous permettra de récupérer vos données.

Un article évoquant plusieurs configurations et usages de la réplication MySQL est disponible sur cette page http://bertrand.letous.fr/replication-mysql/ qui évoque notamment la réplication RING (multi-master replication) permettant la réplication combinée à l’écriture sur les esclaves propageant la modification en chaine et ainsi permettant d’ajouter autant de serveurs que nécessaire pour absorber une montée en charge. Une documentation détaillée est disponible ici : http://onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html

Revenons donc à nos moutons, avec pour objectif, basculer l’installation actuelle d’un simple serveur MySQL tout seul, en maître avec l’ajout d’un esclave répliqué.

=> Serveur maitre :

Sur le serveur maître, nous allons créer un compte utilisateur dédié à la réplication. Soit en passant par une interface d’administration style Webmin, soit en passant par la ligne de commande mysql (requête).
Je vais donc créer un utilisateur « replication » sur mon master, avec un mot de passe, et autoriser pour le host « ip_du_slave » (sur vpn pour mon cas) avec pour permission « Slave replication ».

Ce qui donne donc en commande SQL sur le maître :

mysql> GRANT REPLICATION SLAVE ON *.* TO replication@'ip_du_slave' IDENTIFIED BY '<mot de passe>';

Si vous n’avez jamais utilisé la réplication, il y a des chances que votre serveur mysql n’ait pas de log binaire activé !
Afin de s’assurer de ceci, vous devez éditer votre fichier my.cnf (généralement dans /etc/my.cnf) et vous assurer qu’il contient dans la section « mysqld » les lignes suivantes :

log-bin
server-id=1

La valeur de serveur-id doit être un entier positif entre 1 et 2^32 − 1, mais doit être unique pour chaque serveur (maitre ou esclave).
Si les valeurs ne sont pas présentes, ajoutez les, puis relancez votre serveur mysql.

On va vérifier que la modification est bien active en se connectant en local en root au serveur mysql :

mysql -u root -p

Puis on contrôle qu’il y ait bien un log binaire (après avoir saisi votre mot de passe root mysql) :

show master status;
+---------------------+------------+---------------------+--------------------------+
| File                | Position   | Binlog_Do_DB        | Binlog_Ignore_DB         |
+---------------------+------------+---------------------+--------------------------+
| mysql-bin.000001    | 729        |                     |                          |
+---------------------+------------+---------------------+--------------------------+
1 row in set (0.00 sec)

Nous avons maintenant un serveur MySQL avec un utilisateur qui détient les privilèges de réplication, et, un fichier de log binaire qui va contenir la chaine des transactions/modifications réalisées sur les bases.

Afin de lancer la réplication, nous allons devoir (1) verrouiller la base (READ LOCK), (2) noter le « status » du fichier binaire afin d’indiquer à l’esclave d’où il repart quand on le lancera (comme vu à l’instant), (3) arrêter mysql sans déverrouiller et faire un backup afin de pouvoir transférer les données en l’état sur l’esclave, (4) et relancer mysql et déverrouiller (unlock tables), DANS CET ORDRE PRÉCIS.

L’impact pour votre système actuel va être un blocage des écritures pendant que vous notez le « status » des transactions et réalisez le backup.

En avant donc :

(1)
On se connecte au serveur (maitre) en local et on bloque les transactions :

mysql -u root -p
mysql> FLUSH TABLES WITH READ LOCK;

ok, les transactions sont maintenant bloquées.

(2)
On affiche le « status » et on le copie pour pouvoir le lire plus tard (faites la copie de VOS infos afin d’en disposer plus loin) :

show master status;
+---------------------+------------+---------------------+--------------------------+
| File                | Position   | Binlog_Do_DB        | Binlog_Ignore_DB         |
+---------------------+------------+---------------------+--------------------------+
| mysql-bin.000001    | 729        |                     |                          |
+---------------------+------------+---------------------+--------------------------+
1 row in set (0.00 sec)

(3)
On arrête mysql bloqué et on sauvegarde les fichiers de données (dans /var/lib/mysql chez moi):

mysqladmin -uroot -p shutdown
cd /var/lib
tar -cvzf mysql_full.tgz mysql

Le backup est fait avec les données non modifiées depuis que l’on a noté le master « status ».

(4)
On va maintenant relancer mysql et débloquer les transactions :

/etc/rc.d/init.d/mysqld start
mysql -u root -p

Puis on débloque :

mysql> UNLOCK TABLES;

Nous avons maintenant nos bases dans un fichier de sauvegarde et l’état des transactions à ce moment là. C’est fini pour le serveur maître MySQL qui est opérationnel comme avant.

Vous devriez voir des informations relatives à l’activation de log-bin dans les logs de mysqld (ici /var/log/mysqld.log).

Note : Il faut autoriser l’accès au port 3306 depuis l’esclave dans votre firewall si vous en avez un actif sur le maître, sinon l’esclave ne pourra pas communiquer avec le maître et la réplication ne pourra s’effectuer.

################################################################
=> Serveur Esclave :

On arrête le serveur mysql (vierge jusqu’ici car tout fraîchement installé).

/etc/rc.d/init.d/mysqld stop

Il faut configurer le serveur mysql en éditant le fichier /etc/my.cnf comme pour le maître en ajoutant le server-id dans la configuration (c’est le numéro unique du serveur, qui doit être différent du serveur maître) et les informations permettant la synchronisation :

[mysqld]
server-id=2
master-host = ip_du_master
master-user = utilisateur_replication
master-password = mot_de_passe_replication
master-port = 3306

On va ensuite replacer les données sur l’esclave (attention aux droits sur les fichiers, généralement tout appartient à l’utilisateur « mysql »), ceci en copiant l’archive mysql_full.tgz créée sur le serveur maître, dans le serveur esclave.
Je me positionne dans /var/lib (qui contient le dossier mysql également), qui appartient à l’utilisateur mysql et je décompresse l’archive :

tar xvzf mysql_full.tgz

Ceci va sauvagement écraser les fichiers en place au profit de la copie conforme du maître.

On peut maintenant relancer le serveur mysql :

/etc/rc.d/init.d/mysqld start

Puis on active la synchronisation (qui va également rattraper les modifications depuis la reprise de l’activité du maître) :
Connection en root à mysql en local sur l’esclave :

mysql -u root -p

On arrête le (service) slave :

mysql> STOP SLAVE;

On applique les modifications :

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='<master host name ou ip>',
    ->     MASTER_USER='<replication user name>',
    ->     MASTER_PASSWORD='<replication password>',
    ->     MASTER_LOG_FILE='<recorded log file name>',
    ->     MASTER_LOG_POS=<recorded log offset>;

Note : ce sont les informations définies plus haut, saisie entre apostrophes, sauf pour la dernière valeur numérique saisie directement (et sans les < >).

On lance enfin le processus esclave qui démarre effectivement la synchronisation :

mysql> START SLAVE;

Dans les log de /var/log/mysqld.log vous devriez voir quelque-chose du genre :
« Slave SQL thread initialized, starting replication in log ‘mysql-bin.000001’ at position xxx… etc. »
« Slave I/O thread: connected to master ‘replication@ip_du_maitre:3306’,replication started in log ‘mysql-bin.xxx…etc. »

Maintenant consultez les données dans les tables du serveur esclave, toutes les modifications apportées au maître doivent être automatiquement appliquées à l’esclave.

Vous pouvez aussi consulter l’état sur l’esclave par exemple en vous connectant au serveur :

mysql -u root -p

Puis en tapant la commande suivante :

mysql> SHOW SLAVE STATUS\G;

et celle ci pour voir l’etat des processus :

mysql> SHOW PROCESSLIST;

Maintenant, si vous arrêtez le serveur mysql esclave, et que vous le relancez, il reprendra la synchronisation là où il s’est arrêté ! 😀 cool.

################################################################
=> En cas de plantage (perte des données sur une des machines) :
– Si le maitre plante :
On verrouille l’esclave (FLUSH TABLES WITH READ LOCK;), on « dump » (copie) les données de l’esclave sur le maître, et on relance la synchronisation après avoir relancé le maître.

-Si l’esclave plante :
On recommence la mise en place à partir des étapes 1,2,3,4 dans la section « maître » de ce post, sur le maître, comme ci on réalisait à nouveau cette mise en place.

=> Vous pouvez ajouter autant d’esclaves que vous le voulez, pour répliquer autant de fois que nécessaire l’infrastructure (et donc augmenter la puissance de l’ensemble en répartissant la charge sur plusieurs serveurs).

Autres ressources pertinentes :
http://www.system-linux.eu/index.php?post/2009/09/10/R%C3%A9plication-Mysql
http://km.azerttyu.net/Replication-Mysql-ou-comment.html
http://www.howtoforge.com/mysql_database_replication

Tags: , , , , , , , ,

mercredi, mai 4th, 2011 GNU - Linux, Reseau, Technologie Un commentaire

Installation de GFS pour utilisation avec volume DRBD sous Centos 5.5 ou redhat

Pour faire suite à la mise en place de DRBD dans mon post précédent (http://blog.inforeseau.com/2011/03/installation-drbd-sur-centos-5-5-ou-redhat), nous allons voir la mise en place de GFS, un système de fichier supportant les accès concurrentiels, et permettant ainsi à 2 systèmes (dans le cas présent) d’accéder à un support de stockage simultanément.

A réaliser sur les deux machines concernées (les machines qui partagent le volume DRBD et qui vont constituer notre cluster) :

Il nous faut tout dabord, CMAN (cluster manager) et le support GFS2 :

yum install gfs-utils gfs2-utils cman
yum groupinstall Clustering

Pour configurer le fichier de configuration de base du cluster, j’ai utilisé l’interface graphique « system-config-cluster » pour avoir un modèle, mais on peut créer le fichier à la main directement et définir les éléments du cluster (Ce fichier permet de définir les éléments du cluster pour CMAN qui va gérer les verrous).

<?xml version="1.0" ?>
<cluster config_version="3" name="mon_cluster">
        <fence_daemon post_fail_delay="1" post_join_delay="6"/>
        <clusternodes>
                <clusternode name="pcmsi" nodeid="1" votes="1">
                        <fence/>
                </clusternode>
                <clusternode name="pchp" nodeid="2" votes="1">
                        <fence/>
                </clusternode>
        </clusternodes>
        <cman expected_votes="1" two_node="1"/>
        <fencedevices/>
        <rm>
                <failoverdomains/>
                <resources/>
        </rm>
</cluster>

(man cluster.conf ou man fenced pour plus d’infos sur les paramètres du fichier ci dessus, j’ai augmenté le post_fail_delay à 1 seconde qui est à 0 par défaut à cause de latence sur mon réseau d’expérimentation qui est loin d’être performant! Plus d’infos sur les paramètres notamment liés au quorum (système d’élection dans le cluster) : http://sourceware.org/cluster/wiki/FAQ/CMAN#cman_quorum).

A noter également, la possibilité de modifier le délai de coupure considéré comme étant une rupture de liaison, entrainant le blocage du service (fence = ejection du noeud qui ne répond pas, bloquant l’accès au système GFS avec seulement 2 noeuds dans le cluster) : http://sourceware.org/cluster/wiki/FAQ/CMAN#cman_deadnode_timer

On autorise le trafic dans le firewall entre les noeuds du cluster (attention ici en réseau protégé, limitez les connexions aux machines de confiance, idéalement sur un réseau dédié au cluster).

ATTENTION SI VOUS AVEZ DEJA UNE CONFIGURATION IPTABLES SAUVEZ LE FICHIER AVANT D’UTILISER CE SCRIPT (EN CAS DE DOUTE, PRÉFÉRER LA MÉTHODE MANUELLE EN AJOUTANT LES RÈGLES IPTABLES A LA MAIN COMME INDIQUÉ JUSTE APRÈS).

Avec Iptables, on va utiliser un petit script pour configurer iptables afin d’autoriser le trafic pour le cluster.
Le fichier qui va bien (source : http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/ports-being-in-use-by-the-red-hat-cluster-software) :

#!/bin/bash

IPTABLES=/sbin/iptables
CLUSTER_INTERFACE=eth0
TCP_PORTS="41966 41967 41968 41969 50006 50008 50009 21064"
UPD_PORTS="50007 5405"

echo -n "Applying iptables rules"
for port in $TCP_PORTS; do
  $IPTABLES -I INPUT  -i $CLUSTER_INTERFACE -p tcp -m tcp --sport $port -j ACCEPT
  $IPTABLES -I INPUT  -i $CLUSTER_INTERFACE -p tcp -m tcp --dport $port -j ACCEPT
  $IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p tcp -m tcp --dport $port -j ACCEPT
  $IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p tcp -m tcp --sport $port -j ACCEPT
done
for port in $UPD_PORTS; do
  $IPTABLES -I INPUT  -i $CLUSTER_INTERFACE -p udp -m udp --sport $port -j ACCEPT
  $IPTABLES -I INPUT  -i $CLUSTER_INTERFACE -p udp -m udp --dport $port -j ACCEPT
  $IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p udp -m udp --dport $port -j ACCEPT
  $IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p udp -m udp --sport $port -j ACCEPT
done
echo "[OK]"
echo -n "Saving new rules"
(/etc/init.d/iptables save && \
 echo "[OK]") || echo "[FAILED]"

On l’exécute évidemment pour appliquer les règles qui permettent le trafic. Attention encore, cette configuration ne filtre rien, et considère que vous utilisez une carte réseau dédiée (la CLUSTER_INTERFACE eth0 ici) pour le cluster, sans interception de trafic possible, un câble réseau dédié en gros (pas utilisable sur un réseau ouvert).

Note : on peut sauver la configuration iptables de manière permanente comme suit (recommandé pour le relancement du cluster en cas de reboot) :

/sbin/iptables-save>/etc/sysconfig/iptables

SI LE SCRIPT AU DESSUS VOUS POSE PROBLEME – METHODE MANUELLE (ce qui a été le cas sur une machine pour moi) :
Voici simplement les lignes à ajouter dans /etc/sysconfig/iptables avant les 2 lignes du bas (REJECT et COMMIT) pour permettre la communication du cluster, si vous utilisez ETH0 pour la communication du cluster :

-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp --dport 5405 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp --sport 5405 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp --dport 50007 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp --sport 50007 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 21064 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 21064 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 50009 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 50009 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 50008 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 50008 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 50006 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 50006 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 41969 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 41969 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 41968 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 41968 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 41967 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 41967 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 41966 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --sport 41966 -j ACCEPT

Après avoir ajouté ces lignes, relancez iptables et c’est réglé.

Puis on active les services au démarrage :

chkconfig cman on
chkconfig gfs2 on

On lance les services :

service cman start
service gfs2 start

On crée le système de fichier gfs2 sur le volume géré par DRBD (uniquement sur la machine principale) :

mkfs.gfs2 -p lock_dlm -t mon_cluster:vbox /dev/drbd1 -j 2

On passe les 2 machines en primary sur DRBD si ça n’est pas le cas (nécessaire pour le montage simultané des ressources):

drbdadm primary resource

On monte le volume une fois créé sur les deux machines :

mkdir /mnt/drbd
mount -t gfs2 /dev/drbd1 /mnt/drbd

Voilà, c’est opérationnel, les deux machines peuvent lire et écrire sur le volume /dev/drbd1 grâce à la gestion du verrou par le cluster.

Quelques références utilisées pour la réalisation de ce post :
http://www.redhat.com/gfs/
http://www.cyberciti.biz/faq/linux-cluster-suite-software/
http://securfox.wordpress.com/2009/08/11/how-to-setup-gfs/
http://sources.redhat.com/cluster/wiki/FAQ/CMAN#two_node
http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/ports-being-in-use-by-the-red-hat-cluster-software
http://www.sourceware.org/cluster/wiki/DRBD_Cookbook
http://www.drbd.org/users-guide/ch-gfs.html
Ici un autre tuto complet et très clair avec Debian, GFS2 et DRBD :
http://gcharriere.com/blog/?p=73
et à lire un commentaire très pertinent sur la procédure qui s’applique également à mon post :
http://gcharriere.com/blog/?p=73#comment-15
Un article assez complet sur la haute disponibilité chez Redhat :
http://docs.redhat.com/docs/fr-FR/Red_Hat_Enterprise_Linux/5/html-single/Cluster_Suite_Overview/index.html#fig-intro-cluster-CSO

Tags: , , , , , , , ,

vendredi, mars 11th, 2011 Bash, GNU - Linux, Innovation, Reseau, Technologie 5 Comments

 
octobre 2018
L M M J V S D
« Juin    
1234567
891011121314
15161718192021
22232425262728
293031  
 

 
Suivez moi sur twitter - follow me on twitter
[FSF Associate Member]
 
Free Software, Free Society
VIRTUALISATION :
Compacter une image virtualbox VDI
Bon petit tutoriel esxi
Marche d'appliances vmware
Installer ESXi sur un disque IDE
Installer ESXi 3.5 sur un disque USB
Installer proxmox avec DRBD et migration / réplication à chaud
Installer OSSEC avec VMware
Information sur le VDI
SECURITE - FIREWALL :
Ouvrir des ports dynamiquement iptables - knockd
Autre tres bon tuto knockd
Docs Arp poisoning - Anglais
Metasploit test de pénétration
Zone H - sites piratés en temps réel
Blog invisible things
Tips protection sécurité wordpress
Pfsense - distribution firewall opensource - adsl internet failover
Iproute 2 mini how to - linux advanced routing
ClearOS - la passerelle sécuritaire lan - wan
HAUTE DISPONIBILITE :
CDN - Accélération de la distribution de données
drbd iscsi ocfs2 dm multipath tutoriel
Load balancing LVS
Load balancing opensource list
HA-Proxy :
HAproxy - http load balancer
Simple tutoriel HAproxy
HAproxy - debian tutoriel
Centos - Ip failover
Configuratoin DM-Multipath Redhat
VMware Doubletake - continuité
Quelques liens sur la réplication MySQL : Manuel MySQL, chapitre sur la réplication
Manuel MySQL, Tutoriel clair sur la mise en place
Autre tuto sur la mise en place de la réplication MySQL
Références pour optimisation du serveur MySQL
Utilisation de EXPLAIN mysql pour optimiser vos bases
optimiser vos bases - requetes et index
STOCKAGE RESEAU :
Un outil de clonage disque en reseau
Internet NAS 250Go 250 accès VPN
Server ISCSI avec Ubuntu tuto
ISCSI centos redhat tutoriel
Gérer et étendre un LVM
Créer sa piratebox ! trop cool
Deaddrops, les clés USB dans les murs, aussi cool !
OPTIMISATION WORDPRESS :
Télécharger Xenu
Comment utiliser Xenu
optimisation hébergement wordpress
Super howto wordpress (En)
Test de charge serveur web - Load impact
VPN - ROUTEUR - LAN:
Zeroshell - le mini-routeur wifi tout en un
Retroshare, votre réseau d'échange crypté!
Openvpn sur centos redhat
Intégrer Linux dans active directory
Routage inter-vlan avec Linux
Routage avec OSPF
Network Weathermap
TENDANCES - WEB:
Boutons twitter
Analyser les tendances des recherches Google
Protocole sitemap - robots.txt
Creer des animations CSS3
Code php pour interagir avec twitter
E reputation
Jquery
TRUCS ET ASTUCES GNU/LINUX :
Tuxmachines.org - Actus et tips linux
Configurer GRUB2 et grub2 ici
Panoet - en anglais - tips & tricks
Readylines tips and trick pertinents
Squid Clamav - proxy antivirus
Apprendre Unix en 10 minutes
13 tips sur les expressions régulières
IE Sous linux IES
LDAP 2.4 Quickstart guide
Tutoriel LDAP
Installation annuaire LDAP
Serveur Mail Postfix - Dovecot - LDAP - MDS
Créer un linux personnalisé en ligne - custom linux
Super site sur linux - en
Capistrano - déploiement automatisé
MONITORING :
Nagios tutoriel et doc
Nagios plugin NRPE tuto
Nagios plugin NRPE autre tuto
Nagios plugin NRPE officiel
Zabbix - fonctionnalités
Zabbix - installation
Guide MRTGsys - grapher la charge locale
MRTGsys - ajouter des graphs
MRTGsys - interpréter les données
Shinken - Monitoring
Thruk Monitoring webinterface
Shinken - Tutoriel
Shinken - Référence chez Nicolargo
AUTRES LIENS :
RemixJobs IT jobs
USB Multiboot
Reset mot de passe windows
Java python et autres tips, intéressant !
Forum inforeseau
Open Clipart
Excellent comic en ligne
Inforeseau.fr
 
Contrat Creative Commons
This création is licensed under a Creative Commons Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à l'Identique 2.0 France License.