INFOS-AREA
  Administration NFS
 

Administration NFS : portmap et les RPC (Remote Procedure Call) 1/5


L'utilisation de NFS est une chose relativement courante dans le monde Unix et Linux. Notre confrère Coredump nous fait découvrir ici l'administration de ce service au travers de 5 tutoriels.

Le premier est consacré à portmap et les RPC (Remote Procedure Call).

Les RPC (développées par sun) permettent l’exécution de procédures sur une machine distante. Autrement dit, elles permettent de concevoir des programmes répartis en fournissant un mécanisme d’appel de procédures distantes. Nombreuses sont les applications ayant recours aux RPC. On trouve notamment NFS, NIS mais également la plupart des r-commandes rusers, rwall, etc …

Les procédures (ou fonctions) RPC sont regroupées en programmes et identifiées par des numéros. Les programmes se voient aussi attribuer un numéro ainsi qu’un numéro de version. C’est par le biais de ce triplet qu’un client peut appeler une procédure particulière.

Les numéros sont attribués d’une façon stricte (idem ports TCP et UDP). Ainsi mountd se voit attribuer le numéro 100005.


1. Les RPC

Les RPC (développées par sun) permettent l’exécution de procédures sur une machine distante. Autrement dit, elles permettent de concevoir des programmes répartis en fournissant un mécanisme d’appel de procédures distantes. Nombreuses sont les applications ayant recours aux RPC. On trouve notamment NFS, NIS mais également la plupart des r-commandes rusers, rwall, etc …

Les procédures (ou fonctions) RPC sont regroupées en programmes et identifiées par des numéros. Les programmes se voient aussi attribuer un numéro ainsi qu’un numéro de version. C’est par le biais de ce triplet qu’un client peut appeler une procédure particulière.

Les numéros sont attribués d’une façon stricte (idem ports TCP et UDP). Ainsi mountd se voit attribuer le numéro 100005.

2. XDR

Conjointement aux RPC et au-dessus (dans le modèle OSI), on utilise le protocole XDR (eXternal Data Representation). XDR gère la mise en forme des données: cryptage, conversion EBCDIC/ASCII. Il définit un standard de représentation des types sur le réseau, afin notamment de palier à la multiplicité des représentations utilisées (big endien, little endien, …).

3. Portmap

Les RPC se trouvent au niveau 5 du modèle OSI au dessus de TCP/UDP, tandis qu’XDR se trouve au niveau 6. Ces appels sont gérés par un standard (le processus portmap) via les numéros vus plus haut. Ces numéros sont recensés dans le fichier /etc/rpc. Ce fichier contient les services constructeurs, ce n’est pas un fichier de configuration, il joue le même rôle que /etc/services dans la correspondance nom d’application/port associé pour la programmation RPC.
On aura sous Linux,

[bob@matrox /]$ more /etc/rpc
# ident "@(#)rpc 1.11 95/07/14 SMI" /* SVr4.0 1.2 */
#
# rpc
#
portmapper..100000 portmap sunrpc rpcbind
rstatd......100001 rstat rup perfmeter rstat_svc
rusersd.....100002 rusers
nfs.........100003 nfsprog
ypserv......100004 ypprog
mountd….100005 mount showmount < --------- mountd 1000005
ypbind……100007
walld…….100008 rwall shutdown
yppasswdd…100009 yppasswd
etherstatd..100010 etherstat
rquotad…..100011 rquotaprog quota rquota

et sous FreeBSD,

[bob@matrox /]$ more /etc/rpc
#
# $FreeBSD: src/etc/rpc,v 1.7.2.4 2002/04/15 00:44:13 dougb Exp $
# rpc 88/08/01 4.0 RPCSRC; from 1.12 99/07/25 SMI
#
portmapper..100000 portmap sunrpc rpcbind
rstatd......100001 rstat rstat_svc rup perfmeter
rusersd.....100002 rusers
nfs.........100003 nfsprog
ypserv......100004 ypprog
mountd….100005 mount showmount < --------- mountd 1000005
ypbind……100007
walld…….100008 rwall shutdown
yppasswdd…100009 yppasswd

3.1. Rôle

Le programme serveur RPC contenant les procédures distantes utilise les ports éphémères, pas les ports bien connus. Ceci nécessite l’existence d’un standard conservant trace des ports éphémères utilisés. Le processus assurant cette fonction, c’est portmap, le translateur de ports. Le translateur de ports est aussi un programme serveur RPC de numéro 100000, de version 2 et écoutant sur les ports 111 TCP et UDP.

3.2. Fonctionnement

Pour qu’un serveur usant des RPC fonctionne, il est nécessaire au préalable que portmap soit lancé.

  1. portmap est lancé et est en écoute passive sur les ports TCP et UDP 111,
  2. le serveur démarre, se met en écoute passive sur des ports éphémères TCP et UDP, un par version,
  3. le serveur enregistre chaque programme, version, protocole et numéro de port par un appel à portmap,
  4. lorsqu’un client veut solliciter le serveur, il contacte portmap (111/UDP ou TCP) avec les paramètres protocole et version,
  5. portmap lui retourne alors le port d’écoute du serveur correspondant pour le protocole et la version précisée,
  6. la communication peut maintenant se faire directement entre le client et le serveur

3.3. Activation de portmap sous Linux

La commande rpcinfo permet de connaître les translations en cours,

[bob@matrox /]$ rpcinfo -p (équivalent à rpcinfo -p localhost)
program.no_version.protocole.no_port
100000......2.........tcp......111 portmapper
100000......2.........udp......111 portmapper
... (éventuellement)

Si la commande rpcinfo -p donne,

[bob@matrox /]$ rpcinfo -p
rpcinfo: ne peut contacter l'aiguilleur de ports: RPC: erreur système sur l'hôte cible - Connexion refusée

Il faut alors activer portmap. Sous RedHat, c’est le script portmap du répertoire /etc/rc.d/init.d qui gère le lancement avec les arguments habituels start et stop.

[bob@matrox /]$ su
[root@matrox /]# /etc/rc.d/init.d/portmap start
Démarrage de portmapper : [ OK ]

3.4. Activation de portmap sous FreeBSD

Dans le fichier /etc/rc.conf l’option suivante doit être présente,

# /etc/rc.conf
...
portmap_enable="YES"
...

On opère ensuite la relecture de /etc/rc.conf,

[root@matrox /]# portmap

ou pour les brutes ;-) ,

[bob@matrox /]$ su
[root@matrox /]# init 1
Enter full pathname of shell or RETURN for /bin/sh:
 
# exit
...

puis on contrôle l’activation de portmap avec la commande rpcinfo,

[bob@matrox /]$ rpcinfo -p (équivalent à rpcinfo -p localhost)
program.vers..proto..port
100000....2....tcp....111 portmapper
100000....2....udp....111 portmapper

si portmap n’est pas actif, on obtient la sortie suivante,

[bob@matrox /]$ rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused





Administration NFS : principes de NFS (Network File System) (2/5)

 L'utilisation de NFS est une chose relativement courante dans le monde Unix et Linux. Notre confrère Coredump nous fait découvrir ici l'administration de ce service au travers de 5 tutoriels.

Cette deuxième partie est consacrée aux principes de NFS (Network File System). Nous découvrirons comment se déroule le montage des systèmes de fichiers distants sur le réseau.

 

NFS fournit un accès transparent aux systèmes de fichiers d’un serveur distant. Toute application travaillant avec un fichier local, peut travailler identiquement sans aucune modification avec un fichier distant via NFS. NFS n’accède qu’aux parties du fichier que référence un processus.

NFS fournit un accès transparent aux systèmes de fichiers d’un serveur distant. Toute application travaillant avec un fichier local, peut travailler identiquement sans aucune modification avec un fichier distant via NFS. NFS n’accède qu’aux parties du fichier que référence un processus.

Le client ainsi que le serveur sont implémentés côté noyau pour deux raisons principales,

  • les accès distants sont complètement transparents, aussi l’OS les prend en charge,
  • par souci de performance, on évite l’étape coûteuse de franchissement de la frontière user/kernel

Lorsqu’un processus client demande un accès à un fichier,

  1. il sollicite le noyau,
  2. le noyau détermine si le fichier est local ou distant,
  3. Si le fichier est distant, le noyau passe au client NFS les références du fichier distant,
  4. le client sollicite le serveur concerné,
  5. portmap sur le serveur opère la translation de ports vers l’application concernée (serveur NFS),
  6. la plupart des implémentations code en dur le port UDP 2049 comme port d’écoute du serveur NFS L’implémentation initiale de NFS utilisait UDP, il existe maintenant des implémentations TCP. On rappelle que UDP est sans états. L’inconvénient étant l’absence de gestion efficace des congestions, d’où l’intérêt d’user de TCP.

  7. le serveur NFS opère la requête via les routines d’accès aux fichiers locaux.
NFS

1. Montage d’un système de fichiers distants

Pour qu’un serveur exporte une partie de ses systèmes de fichiers, il doit

  1. démarrer portmap (puisque mountd utilise les RPC),
  2. démarrer ensuite mountd, le démon de montage, sur un port non privilégié
  3. mountd s’enregistre alors auprès de portmap.

Pour qu’un client monte un système de fichiers distants appartenant à un serveur NFS en service,

  1. mount doit faire une requête auprès du portmap distant,
  2. le portmap distant retourne le numéro de port à contacter pour joindre mountd,
  3. mount contacte ensuite mountd pour opérer le montage,
  4. mountd retourne à mount un handle de fichier dans le cas favorable
  5. la consultation du système de fichiers distants est maintenant possible

2. Autres démons

NFS fonctionne grâce à plusieurs démons, certains effectuant des opérations côté client, d’autres côté serveur,

  • nfsd (qui s’appelle rpc.nfsd sous Linux), côté serveur, traite les requêtes d’accès aux fichiers des clients,
  • mountd (qui s’appelle rpc.mountd sous Linux), côté serveur, traite les requêtes de montage de systèmes de fichiers des clients,
  • rpc.lockd, côté serveur & client, gère les verrous sur les fichiers (les clients font des requêtes pour obtenir des verrous, le serveur traite ces requêtes),
  • rpc.statd, côté serveur & client, permet l’observation du réseau (nécessaire à rpc.lockd, traite l’initialisation des verrous après plantage),
  • rpc.rquotad, côté serveur, gère les quotas. Les quotas ne sont pas activés, par défaut, dans le noyau GENERIC (noyau par défaut), sous FreeBSD. Leur emploi nécessite donc la recompilation du noyau et l’activation de l’option correspondante.

Note : le système de verrouillage des fichiers ne fonctionne pas très bien.

3. Remarques

Sous Linux, le noyau doit avoir été compilé avec l’option CONFIG_NFS_FS. Si tel est le cas, la commande suivante nous le confirmera,

[root@matrox /]# grep nfs /proc/filesystems
nodev nfs

Sous freeBSD, le noyau doit avoir été compilé avec les options NFS et NFS_ROOT. Si tel est le cas, la commande suivante nous le confirmera,
[root@matrox /]# grep NFS /usr/src/sys/i386/conf/"fichier de configuration du noyau"
options...NFS.........#Network Filesystem
options...NFS_ROOT....#NFS usable as root device, NFS required



Administration NFS : configuration du serveur (3/5)

L'utilisation de NFS est une chose relativement courante dans le monde Unix et Linux. Notre confrère Coredump nous fait découvrir ici l'administration de ce service au travers de 5 tutoriels.

Cette troisième partie est consacrée à la configuration du serveur NFS. Nous apprendrons à configurer le fichier /etc/exports pour définir les différents systèmes de fichiers que nous allons exporter afin de les monter sur une machine cliente.


Pour le détail du fonctionnement de portmap, voir plus haut.
NFS étant construit au-dessus des RPC, il est nécessaire en premier lieu de démarrer portmap.

1. Le fichier de configuration /etc/exports

mountd et nfsd partagent une unique base de données de contrôle d’accès, qui indique les systèmes de fichiers qui peuvent être exportés, et les clients qui ont le droit de les monter. Le fichier /etc/exports est cette base de données au format texte, aisée à manipuler.

Une fois une modification effectuée, pour que celle-ci soit prise en compte, sous Linux, il faut appeler la commande suivante,

[root@matrox /]# exportfs -r

alors que sous FreeBSD, mountd doit relire le fichier /etc/exports. via la commande suivante,

[root@matrox /]# kill -HUP `cat /var/run/mount.pid`

Sous Linux, il existe une version de cette base de données, qui est utilisée pour les diverses opérations, et qui est généralement conservée dans un fichier binaire xtab. La commande suivante permet de consulter le contenu de cette base de données,

[root@matrox /]# exportfs -v

la prise en compte est immédiate, les fichiers /var/lib/nfs/xtab et /etc/exports sont synchronisés.

2. Format du fichier /etc/exports sous Linux

Il se compose d’une succession de lignes au format suivant,

FS host1(options) ... hostn(options)

Les options sont séparées par des virgules, et la parenthèse ouvrante des options est collée à l’hôte auquel se référent les options.

FS représente un système de fichiers complet ou un sous-arbre de ce dernier
hostXXX peut prendre les formats suivants,

  • nom d’hôte (syntaxe hostname) ou adresse IP, renvoi à un hôte individuel,
  • groupe réseau (syntaxe @groupname), renvoi à un groupe réseau NIS (voir article sur NIS),
  • jokers (syntaxe * ou ?), renvoi à un FQDN avec des jokers, * n’est jamais égal à un ?,
  • network (syntaxe ipaddr/mask), renvoi à une spécification de type CIDR.

Les options disponibles sont les suivantes,

  • ro, pour read only,
  • rw, pour read write (option par défaut),
  • rw=list, permet les exportations en lecture pour tous, list énumère les hôtes ayant un accès en écriture
  • root_squash, associe l’uid 0 et le gid 0 aux valeurs spécifiées par anonuid et anongid (option par défaut)
  • il est préférable que l’utilisateur root d’un client ne puisse pas être assimilé au root du serveur. Par cette option, il prend l’identité nobody.

  • no_root_squash, autorise les accès normaux depuis le compte root (dangereux),
  • all_squash, associe tous les uid et les gid à leur version anonyme, autrement dit, tous les clients accédant au système exporté utilisent l’UID/GID de nobody,
  • anonuid=xxx, précise l’uid auquel doivent être associés les roots distants l’utilisateur nobody dispose maintenant de l’UID transmis par cette option,
  • anongid=xxx, précise le gid auquel doivent être associés les roots distants, l’utilisateur nobody dispose maintenant du GID transmis par cette option,
  • secure, oblige les accès distants à provenir d’un port privilégié,
  • insecure, lève l’obligation ci-dessus,
  • noaccess, interdit les accès à ce dossier et à ses sous-dossiers (utile pour les exportations imbriquées).

Exemple

# /etc/exports
...
/home 192.168.10.0/24(ro, root_squash) icraa(rw)
...

3. Format du fichier /etc/exports sous FreeBSD

Il se compose d’une succession de lignes au format suivant,

FS [ FS1 ... ] [ -option1 [ =valeur ] ] ... -optionN [ =valeur ] ] ] hostA ... hostX

Les options sont séparées par des espaces, les hôtes aussi.

FS représente un système de fichiers complet ou un sous-arbre de ce dernier
hostXXX peut prendre les formats suivants,

  • nom d’hôte (syntaxe hostname) ou adresse IP, renvoi à un hôte individuel,
  • groupe réseau, renvoi à un groupe réseau NIS (voir article sur NIS),
  • network (syntaxe -network xxx.xxx.xxx.xxx -mask xxx.xxx.xxx.xxx).

Les options disponibles sont les suivantes,

  • ro, pour read only,
  • -alldir, permet de monter tout sous-dossier, le comportement par défaut ne permettant de monter que les dossiers spécifiés,
  • -maproot=user, associe root (sur le client) au user spécifié (sur le serveur) qui peut être un uid ou un nom, la valeur par défaut est nobody,-2 (pour autoriser un accès root, utiliser -maproot=root),
  • -mapall=user, associe tous les uid (sur le client) à l’utilisateur spécifié.

Exemple

# /etc/exports
...
/usr/home -maproot=root icraa
/usr/home -ro -mapall=nobody peacock paqib phenix
/usr/share/man -ro -network 192.156.0.0 -mask 255.255.255.0
...

4. Démarrage des démons sous Linux

Le strict nécessaire (en plus de portmap) pour un bon fonctionnement de NFS est le démarrage de rpc.mountd et de rpc.nfsd. Il est néanmoins préférable d’activer les autres démons collaborant à NFS. Il est de bon ton de les démarrer dans l’ordre suivant,

  1. rpc.rquotad
  2. rpc.mountd
  3. rpc.nfsd
  4. rpc.lockd

On démarre en premier lieu rpc.mountd (après portmap, bien sûr). Alors que portmap ne pouvait être démarrer via inetd, rpc.mountd le permet. Il suffit de décommenter la ligne correspondante dans le fichier /etc/inetd.conf et de relancer inetd,

[root@matrox /]# killall -HUP inetd

inetd permet notamment de mettre en place une meilleure gestion des accès via tcpd. on peut également le lancer directement via la commande,

[root@matrox /]# /usr/sbin/rpc.mountd

On démarre ensuite rpc.nfsd, comme suit,

[root@matrox /]# /usr/sbin/rpc.nfsd

On contrôle la bonne marche des événements par un rpcinfo -p, qui doit faire apparaître les démons référencés par portmap.

La plupart des distributions de Linux mettent en place des scripts qui permettent de faire ceci de manière automatique au démarrage de la machine. Si NFS n’est pas lancé automatiquement au démarrage, agir comme suit, pour un démarrage aux runlevels 3, 4 et 5,

[root@matrox /]# chkconfig --add nfs
[root@matrox /]# chkconfig --level 345 nfs on

Sur Redhat, ce script s’occupe de lancer l’ensemble des démons nécessaires au bon fonctionnement de NFS.

5. Démarrage des démons sous FreeBSD

Le strict nécessaire (en plus de portmap) pour un bon fonctionnement de NFS est le démarrage de nfsd et de mountd.

[root@matrox /]# nfsd -u -t -n 4
 
-u pour écouter sur le port UDP 2049,
-t pour écouter sur le port TCP 2049,
-n 4 pour mettre 4 serveurs en écoute.
 
[root@matrox /]# mountd -r

Pour activer NFS au démarrage, il faut valider les options suivantes du fichier /etc/rc.conf,

# /etc/rc.conf
...
portmap_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"
...

Administration NFS : configuration du client (4/5)


L'utilisation de NFS est une chose relativement courante dans le monde Unix et Linux. Notre confrère Coredump nous fait découvrir ici l'administration de ce service au travers de 5 tutoriels.

Cette quatrième partie est consacrée à la configuration du client NFS. Nous apprendrons comment monter un système de fichier distant exporté sur un serveur Linux ou Unix à l'aide de la commande bien connue mount.

 

 L’accès à un système de fichiers exporté par NFS est directement géré à partir du noyau qui sait comment accéder à des données sur un support physique via les systèmes de fichiers adéquats. Il faut donc uniquement préciser au noyau qu’on souhaite accéder à un système exporté par NFS. La commande mount permet d’accéder à différents systèmes de fichiers. Elle signale au noyau qu’un nouveau système de fichiers est utilisable en indiquant son type, son device et un point de montage. L’option -t permet de préciser le système auquel un client veut accéder. Pour un système NFS, l’argument s’écrit -t nfs.

1. Portmap

L’accès à un système de fichiers exporté par NFS est directement géré à partir du noyau qui sait comment accéder à des données sur un support physique via les systèmes de fichiers adéquats. Il faut donc uniquement préciser au noyau qu’on souhaite accéder à un système exporté par NFS. La commande mount permet d’accéder à différents systèmes de fichiers. Elle signale au noyau qu’un nouveau système de fichiers est utilisable en indiquant son type, son device et un point de montage. L’option -t permet de préciser le système auquel un client veut accéder. Pour un système NFS, l’argument s’écrit -t nfs.

mount dispose d’options propres à NFS,

  • rw, monte le FS en lecture/écriture (doit donc être exporté en rw),
  • ro, monte le FS en lecture seule,
  • bg, si le montage ne fonctionne pas, cette option permet de faire des tentatives ultérieures en tâche de fond et de continuer à traiter les autres requêtes de montage,
  • hard, si un serveur ne fonctionne pas, cette option permet de bloquer les accès à ce serveur jusqu’à ce qu’il fonctionne de nouveau (à utiliser avec modération),
  • soft, si un serveur ne fonctionne pas, cette option permet d’envoyer une erreur en retour évite de bloquer des processus en attente de montage,
  • noexec, ne pas permettre l’exécution des binaires,
  • intr, permet aux utilisateurs d’interrompre les opérations bloquées,
  • nointr, n’autorise pas les interruptions des utilisateurs,
  • retrans=n, précise le nombre de tentatives à faire avant l’envoi d’une erreur,
  • timeo=n, précise la période de timeout (en 1/10 e de secondes) pour les requêtes,
  • rsize=n, précise la taille du tampon de lecture à n octets (pour UDP 8 Ko maximum est préférable - ne gère pas la congestion),
  • wsize=n, précise la taille du tampon d’écriture à n octets (pour UDP 8 Ko maximum est préférable - ne gère pas la congestion).

Exemple

Pour monter en lecture seule le répertoire /home de l’hôte icraa sur le point de montage /SHARED,

[root@matrox /]# mount -t nfs -o ro icraa:/home /SHARED

2. Montage au démarrage

Il est possible d’automatiser cette opération au démarrage de l’hôte client en ajoutant autant de lignes qu’il y a de systèmes de fichiers distants à monter dans le fichier /etc/fstab

# /etc/fstab
...
remote_host:/repertoire_distant repertoire_local nfs rsize=1024,wsize=1024 0 0
...

Pour le format de ce fichier, consulter le man fstab(5).

3. Pour aller plus loin …

Le daemon NFSIOD fournit côté client un système de cache en mode blocs.
La commande nfsstat(1 ou 8 ) permet de récupérer des statistiques NFS.



Administration NFS : sécurisation (5/5)

L'utilisation de NFS est une chose relativement courante dans le monde Unix et Linux. Notre confrère Coredump nous fait découvrir ici l'administration de ce service au travers de 5 tutoriels.

Cette cinquième et dernière partie est consacrée à la sécurité. Cette étape est probablement la plus importante, nous apprendrons donc comment mettre en place des contrôles élémentaires pour sécuriser un peu plus la configuration mise en place.

 

Un problème fondamental de NFS vient du fait qu’il existe une relation de confiance, par défaut, entre un client et un serveur NFS. Dans ce cas, si le compte root du serveur est compromis, celui du client le sera également. Le NFS-HOWTO décrit un ensemble de mesures élémentaires nécessaires à prendre.



Un problème fondamental de NFS vient du fait qu’il existe une relation de confiance, par défaut, entre un client et un serveur NFS. Dans ce cas, si le compte root du serveur est compromis, celui du client le sera également. Le NFS-HOWTO décrit un ensemble de mesures élémentaires nécessaires à prendre.

1. Le client

Un client ne peut croire aveuglément un serveur, il faut donc préciser des options contraignantes lors de l’utilisation de la commande mount,

  1. la première, nosuid, annule l’effet des bits SUID et SGID. Ainsi, une personne root sur le serveur doit se connecter d’abord en tant qu’utilisateur quelconque sur le client pour ensuite seulement redevenir root,
  2. une autre option, plus contraignante, est noexec. Elle interdit l’exécution des programmes contenus sur le système exporté. Cette option n’est utilisable que pour les systèmes contenant uniquement des données.

2. Le serveur

Du côté du serveur NFS, on peut également spécifier qu’on ne fait pas confiance au compte root des clients. Sous Linux, on doit préciser dans le fichier /etc/exports l’option root_squash. Cette option est active par défaut, mais s’annule par l’option no_root_squash. Sous FreeBSD, c’est également le comportement par défaut, mais on évitera de le désactiver avec l’option -maproot=root.
Ainsi, si un utilisateur avec l’UID 0 (root) sur le client accède au système exporté par le serveur, il se voit attribuer l’UID de nobody pour effectuer les requêtes sur les fichiers.
On peut préciser une plage d’UID pour lesquels l’option s’applique. Les options anonuid et anongid sur Linux et -maproot sur FreeBSD permettent de changer l’UID/GID de l’utilisateur nobody en celui souhaité.

3. Portmap

Certaines mesures sont d’un ordre plus général et concernent plutôt le portmapper. Par exemple, on interdit l’accès à ce service à toutes les machines par la ligne suivante dans le fichier /etc/hosts.deny,

# hosts.deny : interdiction absolue pour tout le monde de se servir du portmap
...
portmap: ALL
...

Ensuite, dans le /etc/hosts.allow, on contrebalance cette interdiction drastique en autorisant l’accès à toutes les machines souhaitées.




 
  Aujourd'hui sont déjà 2 visiteurs (16 hits) Ici! ;  
 
Ce site web a été créé gratuitement avec Ma-page.fr. Tu veux aussi ton propre site web ?
S'inscrire gratuitement