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 humbles de nos prédictions technologiques passées

Notre histoire technologique est remplie de prédictions erronées. En 2010 je prédisais que les tablettes informatiques étaient inutiles, n’étant ni de véritables smartphones ni de véritables ordinateurs. « Elles disparaîtront d’ici 3 ans », affirmais-je avec conviction.  Pourtant, l’expérience nous enseigne de ne jamais présumer qu’une technologie ne saura trouver sa place dans un domaine spécifique [1]. À l’inverse, ignorer les limites inhérentes à ces nouvelles technologies est tout aussi risqué : cela pourrait mener à des comportements d’adhésion aveugle, loin de la prudence scientifique nécessaire pour évaluer les risques et nous préserver des dérives potentielles.

La blockchain, révolution et obstacles

La blockchain est une technologie conçue pour assurer l’inscription immuable de données, sans intermédiaires, accessible à tous et offrant une garantie d’authenticité. C’est ainsi qu’elle est devenue le socle de crypto-monnaies comme le Bitcoin et Ethereum. Cependant, cette technologie n’est pas exempte de limites : impact environnemental, anonymat non garanti, et résilience incertaine face au déchiffrement futur…. La révolution de la blockchain est indéniable, mais lui attribuer toutes les vertus serait aussi absurde que de nier l’ampleur de son impact disruptif.

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

Certains enthousiastes de la blockchain (voire blockchain-idolâtres) affirment qu’elle rendrait possible un vote électronique totalement dématérialisé, anonyme et et vérifiable (donc sécurisé). L’affirmer aujourd’hui revient hélas à nier le principe de réalité car cette vision semble ignorer plusieurs réalités techniques et scientifiques.

  • L’illusion de l’anonymat : La blockchain ne garantit pas l’anonymat mais plutôt une pseudonymisation, où les identités sont remplacées par des pseudonymes. Dans le cadre du vote, il est nécessaire de lier les identités des votants à des adresses spécifiques. Cette liaison nécessaire entre les identités réelles et les pseudonymes de la blockchain crée une faille dans le système, compromettant la promesse d’un anonymat absolu. Nous ne sommes donc pas dans une anonymisation mais dans une pseudonymisation.
  • Incompatibilité entre anonymat et vérifiabilité : 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 qu’il existe une incompatibilité fondamentale entre la vérifiabilité universelle des votes et l’anonymat dans le vote dématérialisé [2].
  • Introduction du doute sur la sincérité : À l’instar d’un vote par procuration, la blockchain ne garantit pas à l’électeur la transparence et n’a donc 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.
  • Vulnérabilité des maillons du processus : Même parée de toutes les vertus, la blockchain ne constitue qu’une partie de la chaîne de traitement. Même si l’on supposait son usage comme fiable et vérifiable, cela ne protégerait quand même pas les autres maillons du processus. Par exemple, le poste client utilisé pour le vote pourrait être compromis par des logiciels malveillants (de type man-in-the-browser, tel Zeus) qui peuvent manipuler l’interface en temps réel.
  • Risques de future révélation des votes : 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 fort probablement brisée un jour, compromettant alors la confidentialité des votes. 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. Une question cruciale reste : êtes-vous prêt à prendre le risque que vos votes soient dévoilés un jour, même dans dix 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.