Quel est le meilleur système de fichier RAID 1 sous Linux?

Mes stations et petits serveurs sont généralement montés avec deux disques durs en miroir (RAID1) pour les données et permettant une redondance en cas de défaillance brutale de l’un d’eux. Actuellement en format Ext4 sur du une volume RAID 1 Linux (mdadm), je veux savoir si j’ai à gagner à changer ce système de fichier. Je ne me suis intéressé qu’aux systèmes réputés très stables.

Voici donc cette petite étude faite en toute subjectivité mais où j’ai tout de même veillé à multiplier les conditions de test pour vérifier qu’il n’y ait pas trop de variabilité dans les données. Spoiler, cette étude m’a convaincu que basculer mes stations en BTRFS compressé et de lancer des tests de montée en charge en BTRFS sur des gros serveurs de 10 disques en RAID 6.

Les inconvénients du RAID 1 classique sont-ils dépassables?

Les disques en miroir ont deux inconvénients que je souhaite dépasser au moins partiellement :

  • Ils ralentissent nettement l’écriture (mais accélèrent la lecture).
  • Ils gâchent beaucoup d’espace disque car par définition les données sont dupliquées.

Les conditions du test

Ma station de test ne dispose de deux disques Western Digital modèle « Rouge » 6To pour serveurs NAS qui sont assez lents. Ils sont branchés sur une carte contrôleur SATA PCI-e. Le flux de données est donc de base assez ralenti et vous devez prendre en compte cela dans les résultats.

Sur les différents systèmes de fichiers, j’ai utilisé trois types de données de test:

  • 3 Go d’un gros fichier vidéo (MKV) non compressable.
  • 3 Go de fichiers MBOX, boites aux lettres de Thunderbird. Ce sont des gros fichiers (~100Mo) texte très facilement compressables.
  • 10Go de fichiers systèmes (mon /usr/share) de taille moyenne 19ko. Il y a des fichiers binaires et textes.

J’ai testé BTFS en miroir natif, qui est réputé très stable, mais le lecteur doit bien avoir en tête que ce système reste expérimental quand il gère du RAID 5 ou 6. Pour faire du RAID5 ou 6 en BTRFS, il vaut mieux l’utiliser sur un RAID 5 Linux (mdadm), puis formater son volume RAID en BTRFS.

Vitesse d’écriture des différents systèmes

Taille des données

Conclusions

Voici les conclusions relatives aux conditions de mon test (disques lent, bon CPU) :

  • Les systèmes de fichiers compressés ne sont pas vraiment plus lent que les systèmes natifs voire sont parfois bien plus rapides.
  • BTRFS compressé est le système le plus rapide et plus compact.  Il l’est tout autant en miroir natif (c’est lui qui gère le RAID), ou en RAID délégué à Linux (mdadm).

Les fonctionnalités bonus de BTRFS

Les instantanés (snapshots)

Avec BTRFS j’utilise les snapshots pour faire instantanément des sauvegardes de l’état de mes données et garder un historique tout en minimisant l’espace disque. La magie du Copy On Write permet ne ne stocker qu’une seule version d’un fichier, tant que celui-ci ne diffère pas de sa version archivée dans un instantané. C’est d’une simplicité déconcertante :

btrfs subvolume snapshot -r /dossier /.snapshots/date-du-jour

L’option -r rend le snapshot non modifiable.

La déduplication pour gagner encore plus d’espace disque!

J’utilise en plus l’utilitaire duperemove qui fait de la déduplication « offline » et permet d’augmenter de beaucoup le taux de compression. C’est assez impressionnant de réaliser à quel point nous stockons des données redondantes. J’obtiens facilement 5% de gain supplémentaire et dans certaines configurations j’obtiens même aux alentours de 50% sur mes archivage de données. Cet utilitaire, qui peut être lancé la nuit, va chercher les bouts de fichiers identiques pour ne les stoker qu’une fois. Je l’utilise en créant une base de donnée qui lui permet de ne pas avoir à recalculer à chaque fois les empreintes. Là aussi l’usage est très simple:

duperemove -rdh --hashfile=/dossier/hashfile.dupremove --skip-zeroes /dossier/

Enfin, pour savoir combien d’espace disque vous avez gagné l’outil compsize vous permet de calculer automatiquement cela.

Blockchain et vote électronique

Les leçons humiliantes de nos prédictions technologiques passées

Notre vie est pleine de mauvaises prédictions. En 2010 je prédisais d’un ton assuré que les tablettes informatiques étaient inutiles car elle n’étaient ni des vrais smartphones, ni des vrais ordinateurs. « Elles disparaîtront d’ici 3 ans ».  L’expérience nous invite donc à devoir nous méfier des cadres présents qui nous feraient penser qu’une nouvelle technologie ne marcherait jamais pour une application donnée [1]. À contrario, les limites de ces nouvelles technologies ne sont pas imaginaires et les nier, comme le feraient certains, devient mécaniquement une attitude de croyant aux antipodes d’une démarche scientifique prudente qui pourrait nous protéger des dérives potentielles que toute technique sans cadre peux entraîner.

La blockchain, révolution et limites

La blockchain est une technologie informatique conçue pour garantir l’inscription de données de façon immuables, sans intermédiaires, accessibles à tous, en offrant une garantie d’authenticité. C’est donc le support idéal pour les crypto-monnaies telles que le Bitcoin ou Ethereum. Les limites de cette technologie existent cependant : impact environnemental, anonymat non garanti, résilience incertaine au déchiffrage… La révolution de la blockchain est incontestable, mais lui attribuer toutes les vertus serait aussi absurde que de nier l’impact disruptif de cette technologie.

La blockchain et le vote face au principe de réalité

Je vois beaucoup de blockchain-idolâtres clamer partout que cette technologie va permettre de faire du vote électronique dématérialisé, anonyme, et vérifiable (donc sécurisé). L’affirmer aujourd’hui revient hélas à nier le principe de réalité.

  • D’abord l’anonymat n’existe pas dans la blockchain. Il est obtenu en utilisant un pseudonyme. Ce n’est pas – à mon sens – précisément la technique de la blockchain qui permet de garantir l’anonymat. Pour être plus précis, les organisateurs du vote doivent créer un système qui lie les identités de chacun aux adresses bitcoin ou autre. C’est donc là qu’est la faiblesse. Nous ne sommes donc pas dans une anonymisation mais dans une pseudonymisation.
  • Les travaux de recherche ont démontré que tout vote dématérialisé anonyme est intrinsèquement invérifiable. La blockchain ne peut échapper à cette réalité scientifique qui n’a jamais été infirmée. Les travaux de Chevalier-Mames et al. ont en effet abouti à démontrer pourquoi il y a incompatibilité formelle entre la vérifiabilité des votes dématérialisés et l’anonymat [2].
  • Comme tout système de vote par procuration, la blockchain, n’a pas de moyens de convaincre un électeur de la sincérité des opérations. Cela introduit un doute dans le résultat de l’élection qui sape l’autorité des personnes élues.
  • Même parée de toutes les vertus, la blockchain ne constitue qu’une partie de la chaîne de traitement. Si l’on considérait son usage comme fiable et vérifiable, cela ne protégerait quand même pas les autres maillons du processus (comme le poste client en vote par internet qui peut être attaqué par des chevaux de Troie de type man-in-the-browser tel Zeus qui peuvent même modifier l’interface utilisateur à la volée).
  • Enfin, et c’est le plus problématique, la blochain porte intrinsèquement le danger majeur de révélation du contenu intégral des votes le jour où l’un de ses protocoles de chiffrement est cassé, car elle est conçue pour rester publique à long terme. Or, les experts en sécurité informatiques savent que toute implémentation de protocole sera très certainement cassé un jour. La vraie question est : quand l’implémentation sera-t-elle cassée ? Or, comme il n’y a pas de possibilité de revenir en arrière une fois la blockchain écrite, les données sont donc à la merci d’une future faille. Avez-vous vraiment envie de prendre le risque que vos votes soient révélés un jour ? Même dans 10 ans ?

[1] Les oracles malchanceux sont nombreux. En voici quelques exemples savoureux:

  • « Internet ? On s’en fout, ça ne marchera jamais ! ! » Pascal Nègre, PDG d’Universal – 2001
  • « Il n’y a aucune chance pour que l’Iphone obtienne des parts de marché significatives. Aucune chance. » – Steeve Balmer, PDG de Microsoft – 2007
  • « Théoriquement, la télévision est possible, mais je la considère comme une impossibilité – une percée à laquelle nous ne devrions pas perdre de temps à rêver. » – Lee de Forest, inventeur du tube cathodique, 1926
  • « Je crois qu’il y a un marché mondial pour peut-être cinq ordinateurs. »  – Thomas J. Watson, président du conseil d’administration d’IBM, 1943
  • « Nous ne fabriquerons jamais un système d’exploitation à 32 bits. » – Bill Gates, fondateur de Microsoft, 1983
  • « Je prédis qu’Internet… sera une supernova et qu’en 1996, il s’effondrera de façon catastrophique. » – Bob Metcalfe, fondateur de 3Com, 1995
  • « Les tablettes informatiques sont inutiles car sont ni des vrais smartphones, ni des vrais ordinateurs. Elles disparaîtront d’ici 3 ans. » Hervé Suaudeau, dans son salon, 2010.

[2] Benoît Chevallier-Mames, Pierre-Alain Fouque, David Pointcheval, Julien Stern et Jacques Traoré. On some incompatible properties of voting schemes. Towards Trustworthy Elections, 6000 :191–199, 2010.

  • Bien que la démonstration de leur théorème soit difficile d’accès pour un non spécialiste, la conclusion de l’article scientifique est sans appel (traduction personnelle) : « En conclusion, nous avons montré que les systèmes de vote ayant les caractéristiques habituelles ne peuvent pas vérifier les notions de sécurité fortes toutes en même temps : nous ne
    pouvons pas parvenir simultanément à la vérifiabilité universelle (vérifier même le calcul du décompte par les autorités) du décompte des voix et à la confidentialité inconditionnelle des votes ou à la ‘receipt-freeness’ » (l’absence de preuve de son vote protège l’électeur contre la coercition).

Passer son site en HTTPS

Auteur Sean MacEntee (CC-BY-2.0)

Avoir un site en HTTPS est un gage de confidentialité et de meilleure indexation. Peu de choses semblent justifier aujourd’hui de ne pas mettre en place votre site web en https (et désactiver le http).

Je profite donc d’avoir terminé la migration en HTTPS des 13 noms de domaines que j’auto-héberge pour écrire ce petit mémo.

Les exemples utilisés dans cet article seront adaptés à un serveur Debian avec Apache.

Installation d’un certificat HTTPS avec Let’s encrypt

Droits nécessaires: droits root sur le serveur d’hébergement

Let’s encypt est une autorité de certification mise en place par projet porté par l’Electronic Frontier Foundation, Mozilla et d’autres partenaire privés qui veulent généraliser l’usage de connexions sécurisées sur l’internet.  Elle permet d’avoir gratuitement un certificat HTTPS.

Pour ce lancer dans cette étape il faut avoir déjà un site fonctionnel en HTTP.

Ensuite on peut utiliser l’outil très puissant de l’EFF, Certbot. Voici comment l’installer et le lancer pour un serveur apache :

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
mv certbot-auto /mon_dossier/mes_scripts/
sudo /mon_dossier/mes_scripts/certbot-auto --apache

Durant l’installation, indiquer les options par défaut et autoriser certbot à modifier votre configuration apache et de rediriger le trafic http vers https.

On termine en configurant la tache de renouvellement automatique:

sudo crontab -e
0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /mon_dossier/mes_scripts/certbot-auto renew

Migrez tout vos liens en HTTPS

Droits nécessaires: webmaster

Sur votre site, remplacez tous les liens http que vous avez en https.

Sur WordPress il faut intervenir à plusieurs endroits:

  • Modifier l’adresse de votre site dans la page de réglages généraux (menu Réglages→Généraux)
  • Mettre à jour tous les liens de vos anciens articles (notamment les images). Vous pouvez utiliser un plugin Search Regex pour automatiser tout cela.
  • Éventuellement vous devrez intervenir en rééditant vos widget, corriger des liens dans vos menus, et (plus rare) dans le code de votre thème si vous avez rajouté des liens manuellement.

Vous devez avoir un cadenas vert en affichant votre site, ce qui signifie que tout vos éléments sont passés en https:

Si vous n’avez pas ce cadenas vert:

vous pouvez rechercher les éléments manquants en vous aidant par exemple avec le site WhyNoPadlock.

Accélérez le HTTPS

Droits nécessaires: droits root sur le serveur d’hébergement

L’agrafage OCSP permet d’éviter aux navigateurs de faire une requête supplémentaire vers l’autorité de certification. Voici comment le mettre en place:
echo 'SSLStaplingCache shmcb:/tmp/stapling_cache(2097152)' >> /etc/apache2/conf-available/ssl.conf
a2enconf ssl

et ajouter la ligne suivante dans le fichier /etc/letsencrypt/options-ssl-apache.conf :
SSLUseStapling on

Testez et améliorez la sécurité de votre certificat

Le site de Qualys SSL Labs SslTest est excellent pour tester la sécurité de vos certificats.

N’utiliser que des protocoles fiables

Droits nécessaires: droits root sur le serveur d’hébergement ou par défaut droit d’écriture sur le vhost d’apache

Pour améliorer la note au SslTest, il faut modifier les lignes suivantes du fichier /etc/letsencrypt/options-ssl-apache.conf :

SSLProtocol all -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:!DSS

Publier votre autorité de certification

Droits nécessaires: droits de configuration du DNS de votre nom de domaine

Il faut aussi graver dans le marbre de votre DNS le fait que ce soit Let’s Encrypt qui vous procure le certificat. Voici l’entrée DNS à rajouter dans votre interface de configuration de votre registraire de nom de domaine :

example.org. CAA 128 issue "letsencrypt.org"

Le 128 (valeur maximale possible) signifie que le certificat est impératif.

Activer HSTS

Droits nécessaires: droits root sur le serveur d’hébergement ou droit d’écriture sur le vhost d’apache

Enfin il vous faut configurer les headers http en rajoutant ces lignes dans votre fichier de configuration virtual host d’apache:
#Activer HSTS pour le site et les sous-domaines pendant 1 an (pour HTTPS)
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

Puis il faudra soumettre votre site sur https://hstspreload.org/ afin d’empêcher totalement l’accès non https.

Pourquoi ce blog?

J’ai crée ce blog afin de le distinguer de mes autres blogs afin que mes engagements politiques ne perturbent pas les causeries techniques de ce nouveau blog.

Certes, la politique est toujours présente, car je ne me priverais pas de remettre en cause certaines technologies et leurs conséquences sur notre société, et le faire est profondément un acte politique, mais il fallait distinguer les engagements partisans de mes connaissances techniques afin de ne pas risque de parasiter l’argumentation.