Journal Le principe KISS appliqué à la gestion des sauvegardes.

Posté par  .
Étiquettes :
22
3
sept.
2012

Je ne parlerai pas dans ce journal de la simple sauvegarde indépendante d'un poste de travail. Il existe de nombreuses solutions telles rsync, ou encore Unison ou Back In Time qui possèdent une interface graphique assez réussie.

Ce dont je souhaite vous parler c'est de la sauvegarde managée d'un parc de machines, à l'aide d'un serveur dédié.

Dans ce domaine, le logiciel libre incontournable est sans doute Bacula. Vous trouverez la liste impressionnante de ses fonctionnalités par ici. Bacula ça fonctionne, c'est robuste, le développement est toujours actif.

Alors quoi ? On a l'outil ultime pour répondre à nos besoins. C'est beau la vie.

Oui mais non. Pas pour tout le monde, en tous cas pas pour Graham Keeling qui trouve que Bacula est une usine à gaz et a quelques problèmes.

Cette personne a donc créé burp (BackUp and Restore Program). Bien que stigmatisant les personnes souffrant d'éructation maladive, ce nom est assez drôle je trouve.

Même si ce programme a une liste de fonctionnalités bien fournie, l'auteur a su rester simple, dans le plus pur esprit KISS. Un seul binaire fait client et serveur (selon les options), il y a deux fichiers de configuration (à la syntaxe simple), un pour le client, un pour le serveur et basta.

Dans l'esprit Unix, burp se repose sur cron (ou un autre scheduler) pour la planification.

Tout comme Bacula, le développement de burp est actif (dernière version du 28/08/12). Il n'y a pas de package pour Debian Squeeze. Il faudra donc peut-être compiler cet outil vous même, il s'agit d'un simple ./configure, ./make, make install je n'ai pas rencontré de problème particulier pour ma part.

Pour Windows il y a un installer ici. Pour vous faire une idée, le manuel est disponible ici.

Voilà pour cette présentation succincte de burp. Un programme qui mérite d'être connu !

  • # Merci

    Posté par  . Évalué à 5. Dernière modification le 03 septembre 2012 à 10:29.

    Ca fait du bien de voir le retour du KISS, et des principes qui ont fait leur preuve.

    J'avais déjà entendu parlé de Bacula mais je ne l'ai jamais testé, sinon j'imagine que cela s'interfacera facilement dans un bon petit script bash avec du cron du md5 et la sauvegarde est ok :)

    • [^] # Re: Merci

      Posté par  . Évalué à 1.

      Sinon question sauvegarde , il y a aussi un autre principe qui est le principe ActionReplay, ou infinite life , je réserve la question pour mon prochain journal :)

      • [^] # Re: Merci

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 03 septembre 2012 à 12:56.

        Eh, celui là il n'est que second sur ta liste de journaux à écrire !

        Tu va faire mourir tes lecteurs d'impatience si tu suis ta liste à l'envers. :-)

        • [^] # Re: Merci

          Posté par  . Évalué à 2.

          50 journaux en 7 ans c'est quand même pas mal ! C'est mieux que 9 journaux en 4 ans et demi ;) Tes journaux ont néanmoins un meilleur score moyen.

    • [^] # Re: Merci

      Posté par  (site web personnel) . Évalué à 8.

      J'avais déjà entendu parlé de Bacula mais je ne l'ai jamais testé, sinon j'imagine que cela s'interfacera facilement dans un bon petit script bash avec du cron du md5 et la sauvegarde est ok :)

      Bacula ? Non non, bacula est un logiciel de sauvegarde sur bande totalement intégré. Il ne s'interface avec rien du tout et gère lui même ses questions d'intégrité et de résultat des backups.

      Pour bacula tu as :

      • un (des) serveurs gérant le stockage (sur bande ou bande virtuelle sur disque)
      • un serveur gérant la base de données
      • un agent qui tourne sur les serveurs à backuper
      • un backula-director qui donne les ordres aux agents et aux storages pour que tout ce joli monde communique.

      Pour moi le problème majeur est :
      - Du fait de la structure séquentielle des backups (bandes), le temps de restauration est très long.
      - C'est clairement une usine à gaz en particulier à cause du stockage des informations en base de données (Tel fichier de telle machine à telle date est sur telle bande à telle position).

      Pour moi bacula est beaucoup plus adapté à de l'archivage de données qu'à du backup opérationnel. Quand il faut remonter une machine à partir d'un backup bacula, c'est l'angoisse.

      • [^] # Re: Merci

        Posté par  . Évalué à 3.

        Pour moi bacula est beaucoup plus adapté à de l'archivage de données qu'à du backup opérationnel. Quand il faut remonter une machine à partir d'un backup bacula, c'est l'angoisse.

        Aurais tu quelques ressources à ce sujet stp ?
        Etant en pleine gestation de DRP, et utilisant bacula pour la gestion de nos backups, cela m’intéresse au plus au point !

        • [^] # Re: Merci

          Posté par  (site web personnel) . Évalué à 6.

          Aurais tu quelques ressources à ce sujet stp ?
          Etant en pleine gestation de DRP, et utilisant bacula pour la gestion de nos backups, cela m’intéresse au plus au point !

          Non c'est juste ce que je retire de mon experience.

          Quand tes backups te servent sans arrêt pour faire des restaurations partielles ou complètes (Bare Metal), bacula s'avère d'une lenteur exaspérante par rapport à du rsync / snapshot. Le temps qu'il élabore la liste des fichiers, que tu sélectionne ceux qui sont concernés, ton rsync est déjà en train de transferer.

          Par ailleurs :

          • les gros fichiers type bande sont beaucoup plus faciles à corrompre que la tonne de petit fichiers de ton rsync.

          • la base de données est un goulet d'étranglement infernal. Tu passes ton temps à tuner le serveur de bdd et rajouter de la ram.

          • En cas de perte de le base tu en as pour des jours à tout récuperer …

          • Difficile de vérifier la présence des backups avant d'en avoir besoin.

          • De temps à autres, des erreurs inexplicables rendant les backups inexploitables.

          Bref pour moi rien que la structure séquentielle du stockage et la dépendance en un service tiers (base de données) rendent impossible son utilisation en production. Mais le contexte est bien particulier :
          - plusieurs centaines de serveurs
          - du web et des mails (plein de petit fichiers)
          - la plupart des utilisateurs qui tapent directement sur la prod
          - Une GTR qui prévoie la restauration des données.
          - Peu de redondance (beaucoup d'utilisateurs ont un et un seul serveur).

          Ceci dit bacula est un bon produit. Il offre une grande liberté de configuration, une bonne gestion centralisée (mais attention avec le volume il faut de très grosses machines), une interface agréable. Mais il n'est adapté qu'à des environnements calme, bien procédurés et structuré. Bref à la place d'un Amanda ou d'un soft proprio c'est un bon candidat.

          • [^] # Re: Merci

            Posté par  . Évalué à 4.

            les gros fichiers type bande sont beaucoup plus faciles à corrompre que la tonne de petit fichiers de ton rsync.

            Ben il faut faire des sauvegardes :-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Merci

        Posté par  . Évalué à 2. Dernière modification le 03 septembre 2012 à 15:48.

        Pour bacula tu as :

        un (des) serveurs gérant le stockage (sur bande ou bande virtuelle sur disque)
        un serveur gérant la base de données
        un agent qui tourne sur les serveurs à backuper
        un backula-director qui donne les ordres aux agents et aux storages pour que tout ce joli monde communique.

        Il me semble qu'il n'y a que trois composants strictement nécessaires. Dans ceux que tu cites il me semble que c'est le director qui gère la base de données. Je peux me tromper, l'architecture de Bacula est assez complexe en effet.

        • [^] # Re: Merci

          Posté par  (site web personnel) . Évalué à 2.

          Il me semble qu'il n'y a que trois composants strictement nécessaires. Dans ceux que tu cites il me semble que c'est le director qui gère la base de données. Je peux me tromper, l'architecture de Bacula est assez complexe en effet.

          Oui enfin il faut un serveur de base de données (MySQL ou Postgres) après que ce soit sur lq même machine ou pas c'est une autre question. Tu ne peux pas utiliser SQLite en production ou alors sur un volume vraiment faible (C'est déjà lent avec postgres …).

          Tu peux également avoir ton storage sur cette même machine.

  • # Infortuné

    Posté par  (site web personnel) . Évalué à -7.

    « […] simple ./configure, make, make install […] »

    Comment osez-vous présenter une telle procédure comme aisée :-) ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Infortuné

      Posté par  . Évalué à 10.

      Simplement parce qu’il s'adresse a un admin chargé "de la sauvegarde managée d'un parc de machines, à l'aide d'un serveur dédié", pas a Mme Michu

  • # Autre solution

    Posté par  . Évalué à 8.

    Personnellement, je trouve que backuppc a su rester simple dans son fonctionnement tout en offrant quelque chose de fonctionnel et souple.

    • [^] # Re: Autre solution

      Posté par  . Évalué à 2.

      Ça a l'air pas mal, par contre la dernière version date de juillet 2012 et la dernière modification du wiki d'octobre 2011…

      • [^] # Re: Autre solution

        Posté par  . Évalué à 3.

        2012 2010

        • [^] # Re: Autre solution

          Posté par  (site web personnel) . Évalué à 5.

          En effet, mais c'est qu'il avait tellement d'avance et qu'il marche tout seul ;-)

          Il tourne comme une horloge dans mon labo. Par contre, j'aurais effectivement quelques améliorations à proposer…

          • [^] # Re: Autre solution

            Posté par  . Évalué à 1.

            Lesquelles ?

            Le FN est un parti d'extrême droite

            • [^] # Re: Autre solution

              Posté par  (site web personnel) . Évalué à 4.

              • Pour les clients sous Windows, c'est faible. La méthode smb est lente, celle par rsync pas idéale et moisn rapide que pour un Linux. Pas de support du shadow copy de Windows. Un client windows serait je pense une bonne chose.

              • Backuppc a des soucis si la taille des données sur un poste sont trop grosse et puis la restauration se fait sans gestion des droits. Du coup, j'ai fait une moulinette qui à partir d'un fichier YAML génère autant de fichier pour backuppc qu'il y a d'utilisateur. Ainsi chaque utilisateur peut avoir accès a sa seule sauvegarde. J'ai ainsi des machines ayant plus de 1500 fichiers de conf chacune ! backuppc s'en sors très bien mais si on limite a 5 sauvegarde parallèles, il ne voit pas qu'en pratique, il sauve 5 fois la même machine physique mais des dossiers différents. On pourrait avoir un paramètre qui limite le nombre de rsync sur les machines physiques.

              Pour info, mon script YAML me récupère via une requête rsync la liste des sous dossier des home, interroge le LDAP pour savoir si le compte associé est actif et génère alors le fichier de conf. Ainsi, le backup s'arrête tout seul lorsque les personnes partent !

              • Backuppc a le même soucis que pas mal de logiciel, il est basé sur les noms DNS ou quasiment pareil (au DNS dyn près) sur l'IP. Dans un monde en mobilité, c'est plus tout à fait adapté. A noter que ssh, cfengine… ont le même défaut !

              Il y a des batailles pour savoir s'il vaut mieux du push ou du pull ! Moi, je n'aime pas que tous mes clients puissent lancer eux-mêmes leur sauvegardes et donc écrire sur le serveur. Cependant, si une personne est chez elle, plus de backup… Je pense que cette architecture est périmé. Ni push, ni pull sont bon à mon avis.

              Il faudrait un agent sur le poste qui fait acte de présence sur le serveur en donnant son nom (type XMPP) et ouvrirait un port en retour via le tunnel ainsi crée. Le serveur central ferait alors quand il le décide une copie de backup en utilisant le tunnel ouvert par le client. Ainsi, le serveur pourrait faire un backup d'une machine située n'importe ou dans le monde.

              • Rsync, c'est bien mais on voit bien sur des très grosses partitions que la phase initiale est longue. Il faudrait pouvoir faire cela sur un snapshot LVM qui ne duplique pas les inode mais ne conserve que la trace des block modifiés (j'ai vu une fois une personne qui avait fait un patch la dessus). Le backup serait alors bien plus rapide. Autre solution, utiliser lsyncd pour conserver la liste sur le client des fichiers modifiés entre deux sauvegardes. On devrait pouvoir aller encore beaucoup plus vite.

              • Je pense que la notion de backup incrémentale et complète est complètement dépassé lorsqu'on travaille sur disque. On ne veux voir que des complètes tous les jours, voire toutes les heures ! Ce qu'il y a derrière devrait être transparent de nos jours.

              • L'équilibrage sur 400 machines entre les incrémentales et les complètes devrait être transparent. En cas d'arrêt du serveur plus de 7 jours, c'est un peu chiant… (surtout avec ma méthode de découper un serveur en petit morceau. Je m'en suis sortis en triant de manière aléatoire le fichier hosts car backuppc prends les machines dans l'ordre).

              • …

              Voila ce qui me viens de tête. Sur des partitions de plus de 5To que je ne peux découper, j'utilise rdiff-backup qui va bien plus vite mais a d'autres défaut…

      • [^] # Re: Autre solution

        Posté par  . Évalué à -1.

        Ça a l'air pas mal, par contre la dernière version date de juillet 2012

        Autant dire le siècle dernier.

        Le FN est un parti d'extrême droite

  • # Et ?

    Posté par  (site web personnel) . Évalué à 10.

    Finalement il a quoi de mieux ce logiciel ? Parce que "il est kiss" sans plus d'arguments c'est sympa mais bon. Alors ok t'as mis un lien vers la liste des fonctionnalités, bravo, mais t'aurais quand même pu en décrire une ou deux.

    C'était mon commentaire de protestation contre ces journaux qui te présente un logiciel soit disant génial sans vraiment le présenter.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

    • [^] # Re: Et ?

      Posté par  (site web personnel) . Évalué à 3.

      Il y en a un qui a l'air puissant mais que je n'ai aps encore testé, c'est Obnam. Il gère en interne les versions avec des arbres comme ZFS ou BTRFS. Je n'ai plus en tête la raison (avant les vacances) mais il me semble que c'était mieux si le logiciel le faisait lui même.

      http://liw.fi/obnam/

    • [^] # Re: Et ?

      Posté par  . Évalué à 5.

      Finalement il a quoi de mieux ce logiciel ?

      la réponse est dans le journal : "Un seul binaire fait client et serveur (selon les options), il y a deux fichiers de configuration (à la syntaxe simple), un pour le client, un pour le serveur et basta."

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Et ?

        Posté par  (site web personnel) . Évalué à 2.

        Donc ce qui est bien, c'est qu'il soit peu configurable, comme Gnome quoi.

        Oui bon ça va, je sors.

        alf.life

      • [^] # Re: Et ?

        Posté par  . Évalué à 1.

        Un exemple n'aurait alors pas était de trop :)

        Ça marche sur autre chose que linux et BSD ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Et ?

          Posté par  . Évalué à 4.

          Au moins sur Windows aussi.

        • [^] # Re: Et ?

          Posté par  . Évalué à 4.

          Je recommande la lecture des fichiers de configuration fournis qui sont très bien commentés.

          Sans les commentaires ça donne pour /etc/burp/burp.conf (configuration du client) :

          # grep -vE "^#|^$" /etc/burp/burp.conf
mode = client
port = 4971
server = ::1
password = burp
cname = box42
pidfile = /var/run/burp.client.pid
syslog = 1
stdout = 0
progress_counters = 1
cross_filesystem=/
cross_all_filesystems=0
ca_burp_ca = /usr/sbin/burp_ca
ca_csr_dir = /etc/burp/CA-client
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-client.pem
ssl_key = /etc/burp/ssl_cert-client.key
ssl_key_password = burp
ssl_peer_cn = burpserver
include = /root
include = /home
include = /var/www
exclude_fs = sysfs
exclude_fs = tmpfs
nobackup = .nobackup

          et pour /etc/burp/burp-server.conf (configuration du serveur) :

          # grep -vE "^#|^$" /etc/burp/burp-server.conf
mode = server
port = 4971
status_port = 4972
directory = /backup/burp
clientconfdir = /etc/burp/clientconfdir
pidfile = /var/run/burp.server.pid
hardlinked_archive = 0
working_dir_recovery_method = delete
max_children = 5
max_status_children = 5
umask = 0022
syslog = 1
stdout = 0
client_can_force_backup = 1
client_can_list = 1
client_can_restore = 1
client_can_verify = 1
keep = 7
password_check = 1
ca_conf = /etc/burp/CA.cnf
ca_name = burpCA
ca_server_name = burpserver
ca_burp_ca = /usr/sbin/burp_ca
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-server.pem
ssl_key = /etc/burp/ssl_cert-server.key
ssl_key_password = burp
ssl_dhfile = /etc/burp/dhfile.pem
timer_script = /etc/burp/timer_script
timer_arg = 20h
timer_arg = Mon,Tue,Wed,Thu,Fri,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21
timer_arg = Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,23

      • [^] # Re: Et ?

        Posté par  . Évalué à 10.

        Un seul binaire fait client et serveur (selon les options)

        En quoi c'est mieux ? On le vante d'être plus KISS, mais un programme qui fait deux tâches, c'est pas très KISS…

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Et ?

          Posté par  (site web personnel) . Évalué à 4.

          Il gère aussi les certificats, le chiffrement, la déduplication, il fait peut être plus que 2 choses :)

        • [^] # Re: Et ?

          Posté par  . Évalué à 2.

          Je ne vois pas ce qu'un seul exécutable, qui va soit passer en arrière plan comme un gentil daemon, ou être interactif (et interroger une autre copie de lui même), selon la première option qu'on lui passe, a de compliqué. On aurait pu faire un seul binaire avec un hardlink (super sous Windows) ou deux binaires différents je m'en tamponne. Ça n'enlève rien au respect global de principes de simplicités dont fait preuve ce projet.

          • [^] # Re: Et ?

            Posté par  . Évalué à 1.

            Je donne une analogie :
            - un seul logiciel qui fait serveur web et navigateur. Je m'en tamponne que ce soit un seul exécutable… sérieux :-)

            Dans le cas de Burp, l'auteur a l'air d'avoir de bons arguments. Il est cependant étonnant (mais pas rédhibitoire) d'avoir le client et le serveur en un seul exécutable. Quelle est la logique sous-jacente ?

            • [^] # Re: Et ?

              Posté par  . Évalué à 1.

              Quelle est la logique sous-jacente

              Probablement une logique de pair à pair, qui rompt d'avec le modèle purement client/serveur.

              • [^] # Re: Et ?

                Posté par  . Évalué à 2.

                À faire ça il faudrait s'orienter vers du vrais paire à paire comme bitorrent.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Backup KISS

    Posté par  . Évalué à 6.

    Bontmia : http://folk.uio.no/johnen/bontmia/
    750 lignes de Bash, ça c'est KISS. :D

    Et perso, j'utilise backupninja, et j'ai codé les plugins qui me manquaient (snapshot lvm pour backupper les domU xen)
    Backupninja : https://labs.riseup.net/code/projects/backupninja

    • [^] # Re: Backup KISS

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      backupninja <3 ;)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Dépêche

    Posté par  . Évalué à 9.

    C'est le bon moment pour citer la dernière dépêche sur la révolution dans le monde de la sauvegarde.

    • [^] # Re: Dépêche

      Posté par  . Évalué à 3.

      Bah oui j'avais déjà parlé de BURP (et de BackupPC) dans ma dépêche…
      Heureusement qu'il y en a qui suivent ! ;-)

      • [^] # Re: Dépêche

        Posté par  . Évalué à 2. Dernière modification le 03 septembre 2012 à 15:03.

        Ha je me disais bien que j'avais déjà vue le nom quelque part :)

  • # rdiff-backup

    Posté par  . Évalué à 2.

    Personnellement, j'utilise rdiff-backup qui est disponible sur mon nas qnap arm. Burp a l'air sympa mais je n'ai pas trouvé de package ipkg.

  • # rsnapshot

    Posté par  (site web personnel) . Évalué à 2.

    Simple,(pas d'interface graphique) et efficace (il utilise des liens pour éviter de consommer inutilement du disque), basé sur rsync : KISS aussi.
    Il y a un package pour la plupart des distributions (au moins debian, ubuntu, mandriva, mageia, fedora).

    • [^] # Re: rsnapshot

      Posté par  (site web personnel) . Évalué à 0.

      J'utilise aussi rsnapshot pour mes archives personnelles. J'en suis assez content et la mise en place est très simple. Pour les systèmes pro un peu plus compliqué j'utilise backuppc.

    • [^] # Re: rsnapshot

      Posté par  . Évalué à 3.

      Simple,(pas d'interface graphique)

      Je ne vois pas le rapport. On peut très bien faire une interface graphique simple, comme celle-ci :
      Titre de l'image

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: rsnapshot

        Posté par  . Évalué à 4.

        Retires le menu et on pourra peut être l'intégrer dans la prochaine version de GNOME avec affichage en plein écran car il ne faut faire qu'une seule tâche à la fois…

      • [^] # Re: rsnapshot

        Posté par  (site web personnel) . Évalué à 2.

        On ne parle pas de la même chose : je voulais dire simple pour le développeur (moins de code) et l'administrateur (moins de dépendances d'installation).
        Pour l'utilisateur, je ne vois pas trop l’intérêt de l'icone "backup" : une sauvegarde devrait être automatique.

  • # Espace de stockage

    Posté par  . Évalué à 1. Dernière modification le 04 septembre 2012 à 13:52.

    Je commence à me dire que je devrais me mettre sérieusement en quête d'une solution de sauvegarde.

    La première question que je me pose est : Où stocker toute mes données ? sur un serveur dédié (cher pour juste quelques Go de données)? sur un PC placé chez mes parents (bande passante de moins bonne qualité) ? sur un espace tel que Hubic (25Go gratuit mais quid de la confidentialité)?

    Comment faites vous ?

    • [^] # Re: Espace de stockage

      Posté par  . Évalué à 2.

      Un peu le bordel

      mes parents font leur backups chez moi (sur mon nas via un vpn entre nous… vivement la fibre ;) )
      mes backups sont sur un volume hubic, et non chiffrés pour 99% des trucs, chiffré pour le reste

      bup ne marche pas sur mon nas ni sur du webdav (comme rsnapshot), du coup j'ai des scripts un peu crade pour avoir un backup à la timevault

      ça marchote, mais ce n'est pas une solution que je recommande

    • [^] # Re: Espace de stockage

      Posté par  . Évalué à 2.

      Chiffrer le tout et l'envoyer sur Amazon Glacier (qui chiffrera une seconde fois mais on est jamais trop sûre) ?

      On dépend du service bien sûre mais j'ai plus confiance en leur solution de stockage qu'un disque dur chez mamie…

  • # limite KISS

    Posté par  . Évalué à 2.

    De base, j'aime bien qu'un logiciel limite ses fonctionnalités et s'appuie sur des standards (plus ou moins de fait) type cron, rsyn, etc.

    Du coup, pour chippoter, je dirai que:
    - Email backup success/failure notifications.
    - A single daily backup summary email.
    - A live ncurses monitor on the server.
    sont de trop ;pourquoi ne pas s'appuyer sur syslog et snmp ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.