From 27b30ef051a3a971012daffd9665d79e0a90dbfb Mon Sep 17 00:00:00 2001
From: Julien Moutinho <julm@sourcephile.fr>
Date: Tue, 7 Jan 2020 05:16:48 +0100
Subject: [PATCH] ddc8: revamp

---
 ddc/ddc8-logiciellerie-une_infra.md | 386 ++++++++++++++++------------
 1 file changed, 226 insertions(+), 160 deletions(-)

diff --git a/ddc/ddc8-logiciellerie-une_infra.md b/ddc/ddc8-logiciellerie-une_infra.md
index ab1658c..6cda17e 100644
--- a/ddc/ddc8-logiciellerie-une_infra.md
+++ b/ddc/ddc8-logiciellerie-une_infra.md
@@ -3,27 +3,10 @@
 - De: Julien Moutinho (julm)
 - À: Sourcephile
 - Phase: Écriture
-- Révision: 2 (2020-01-05)
+- Révision: 3 (2020-01-07)
 - Licence: Creative Commons BY-SA
 
 # Bilan approximatif
-## Boussoles analytiques
-- [G] compétitive
-  - [G] charge
-    - [G] julm: on est sur une dépense de ~300€ de matériel (~100€ de plus s’il n’y avait pas le réemploi d’un SSD) pour une espérance de fonctionnement et d’usage >5ans, et un récurrent de ~60€/an pour l’hébergement. C’est un prix très correct pour ce que c’est.
-  - [C] produit
-    - [C] julm: aucun service non-lié à la production n’est proposé aux membres.
-  - [T] autonomie
-    - [T] julm: on a la main sur le matériel, le logiciel, mais sur l’hébergement (toutefois 15km, ça reste à portée de vélo).
-- [T] scientifique
-  - [T] julm: on peut mettre du NixOS, mais ce n’est pas une machine avec beaucoup de CPU et de RAM, mais ça devrait largement suffire et me dépanner tant que je n’ai pas d’élec @home.
-- [T] productive
-  - [T] julm: la machine peut suffire pour commencer, l’hébergement aussi mais peut rapidement être limitant (ce n’est qu’une VDSL2+). Côté sécurité on est en open-source, mais que partiellement en matériel ouvert. Mutualiser pleins de services sur une seule machine n’est pas l'idéal mais un cloisonnement LXC (sans virtualisation) devrait suffire puisque tous les services seront sous GNU/Linux et contrôlés par nous. L’hébergement est semi-professionnel, sécurité raisonnable vue les enjeux. Côté maintenance on peut mettre du NixOS ce qui me simplifiera la tâche. L’hébergeur n’offre pas (encore) de seconde connexion via le port série et n'est que semi-professionnel, par contre il est proche.
-- [A] publique
-  - [A] julm: on est en logiciel libre, mais que partiellement en matériel ouvert. Deux raisons bloquantes à cela : le manque de support de NixOS (quid de Guix ? et plus gravement de Haskell pour les architectures ARM.
-- [A] coopérative
-  - [A] Les machines sont fabriquées à l'autre bout de la planète dans des conditions sociales probablement déplorables.
-
 ## Mentions possibles
 - R: « À rejeter »
 - C: « À clarifier »
@@ -31,7 +14,28 @@
 - T: « À tester »
 - G: « À garder »
 
+## Analyses des préoccupations
+### [G] Pour l’indépendance
+#### [G] Concernant les charges
+- [G] julm: on est sur une dépense de ~300€ de matériel (~100€ de plus s’il n’y avait pas le réemploi d’un SSD) pour une espérance de fonctionnement et d’usage >5ans, et un récurrent de ~60€/an pour l’hébergement. C’est un prix très correct pour ce que c’est.
+#### [T] Concernant l’autonomie
+- [T] julm: on a la main sur le matériel, le logiciel, mais par tellement sur l’hébergement (toutefois 15km, ça reste à portée de vélo).
+#### [C] Concernant les produits
+- [C] julm: aucun service non-lié à la production n’est proposé aux membres.
+### [T] Pour la science
+- [T] julm: on peut mettre du NixOS, mais ce n’est pas une machine avec beaucoup de CPU et de RAM, mais ça devrait largement suffire et me dépanner tant que je n’ai pas d’élec @home.
+### [T] Pour la production
+- [T] julm: la machine peut suffire pour commencer, l’hébergement aussi mais peut rapidement être limitant (ce n’est qu’une VDSL2+). Côté sécurité on est en open-source, mais que partiellement en matériel ouvert. Mutualiser pleins de services sur une seule machine n’est pas l'idéal mais un cloisonnement LXC (sans virtualisation) devrait suffire puisque tous les services seront sous GNU/Linux et contrôlés par nous. L’hébergement est semi-professionnel, sécurité raisonnable vue les enjeux. Côté maintenance on peut mettre du NixOS ce qui me simplifiera la tâche. L’hébergeur n’offre pas (encore) de seconde connexion via le port série et n'est que semi-professionnel, par contre il est proche.
+### [A] Pour l’essaimage
+- [A] julm: on est en logiciel libre, mais que partiellement en matériel ouvert. Deux raisons bloquantes à cela : le manque de support de NixOS (quid de Guix ? et plus gravement de Haskell pour les architectures ARM.
+### [A] Pour la coopération
+- [A] julm: les machines sont fabriquées à l'autre bout de la planète dans des conditions sociales probablement déplorables.
+### [A] Pour l’environnement
+- [A] julm: c’est une machine très basse consommation, mais c’est quand même une consommation.
+
+
 # Explications
+
 ## Motivations
 ### S'émanciper d'autogeree.net
 Les logiciels que j'écris sont actuellement hébergés sur `chomsky.autogeree.net`, une machine virtuelle (VM) relativement modeste que me fournie Grésille depuis 2011 (en contre-partie d'un Dell R210 surnommé « chomsky » et acquis dans l'enthousiasme naïf de l'essaimage de FDN, puis resurnommé « rouf » par Grenode). Cette VM m'a longtemps servi de bac à sable pour jouer à l'adminsys, qui sert encore à un copain et moi-même pour avoir du mél et de l'IRC.
@@ -39,6 +43,8 @@ Les logiciels que j'écris sont actuellement hébergés sur `chomsky.autogeree.n
 `chomsky` est une Debian dans une machine virtuelle Xen (1 CPU, 750Mo de RAM, 50Go de stockage **probablement** HDD), dans une machine hébergée professionnellement en datacenter à Grenoble. Cette machine est actuellement reliée à l'Internet par une autre infrastructure de Grenode à Lyon (au Netcenter via l'association Rézopole).
 `chomsky` n’a pas vraiment les ressources d’une machine de développement (nixpkgs c’est déjà 10Go de stockage, stack 5Go, et le REPL de GHC ou de PureScript c’est minimum 0.5Go de RAM).
 
+autogeree.net ne peut donc plus assurer mes besoins, et je n’arrive pas à convaincre qui que ce soit de porter avec moi une énième tentative d’association, nommée « Sourcephile », mais il me faut assurer la continuation du développement des logiciels libres qui me tiennent à cœur, et par conséquent je choisis d’entreprendre unilatéralement ce qu’il faut pour cela : `mermet.sourcephile.fr`, nommée d’après feu Laurent Mermet.
+
 ### S'émanciper de Debian
 Depuis que je me suis mis à NixOS, je ne suis plus enthousiasmé par Debian. En tant que dev il est bien plus facile de faire et de partager de manière reproductible et récente des paquets NixOS que des paquets Debian (dans le cas de paquets Haskell tout du moins). Et en tant qu'adminsys il est bien plus facile de maîtriser ce qu'il se passe sur une NixOS que sur une Debian. Le seul avantage de Debian en ce qui me concerne c'est sa plus grande portabilité sur des architectures basse conso ou OSHW comme certaines ARM ou MIPS. Mais ce n'est **certainement** qu'un avantage temporaire.
 Pour approfondir ces raisons techniques, on peut voir par exemple les tutoriels francophones de Nokomprendo : https://nokomprendo.gitlab.io/
@@ -50,8 +56,11 @@ Cependant, il est **peu probable** que je puisse passer `chomsky` sous NixOS, ca
 - https://nixos.wiki/wiki/NixOS_on_ARM
 
 ## Objectif
+L’objectif principal est de continuer d’habiter sur Internet, en assurant ce qu’autogeree.net ne peut plus assurer ou n’a jamais véritablement assuré.
+
 ### Objectif minimal : infra de publication
-Cette infra adresse en priorité la diffusion au public des logiciels produits : dépôts des sources, dépôts des binaires, pages Web d'informations. Le public n'ya que des accès en lecture seule.
+Cette objectif adresse en priorité les besoins de diffusion au public du travail des membres contributeurs : dépôts des sources, dépôts des binaires, pages Web d'informations. Le public n'y a que des accès en lecture seule.
+
 - Noms de domaine (nsd4, unbound)
 - Shell distant SSH (openssh)
 - Pare-feu (shorewall)
@@ -66,13 +75,14 @@ Cette infra adresse en priorité la diffusion au public des logiciels produits :
 - Monitoring (monit | nagios)
 
 ### Objectif modeste : infra d'équipement interne
-Cette infra adresse en priorité les besoins d'équipement des membres coopérants : stockages sécurisés et connexions sécurisées. Le public n'y a aucun accès d'usage, mais peut avoir des accès en écriture ou lecture selon des interfaces restreintes et contrôlées.
+Cette objectif adresse en priorité les besoins d'équipement des membres contributeurs : stockages sécurisés et connexions sécurisées. Le public n'y a aucun accès d'usage, mais peut avoir des accès en écriture ou lecture selon des interfaces restreintes et contrôlées.
+
 - Adresses méls (postfix, dovecot2, rspamd)
 - Listes méls internes (aliases postfix)
 - Écriture collaborative en ligne en temps réel (gobby | etherpad-lite | prose)
 - Messagerie instantanée (prosody | matrix)
-- Chiffrement du stockage (dm-crypt, dropbear)
-- Gestion des accès (unix | openldap | ad hoc)
+- Chiffrement du stockage (ZFS, dm-crypt, dropbear)
+- Gestion des accès (unix | openldap | intégré aux applications)
 - Partages volumineux en ligne (nextcloud)
 - Partages textuels jetables (pastebin)
 - (optionnel) Calendriers en ligne (davical | nextcloud)
@@ -83,25 +93,44 @@ Cette infra adresse en priorité les besoins d'équipement des membres coopéran
 - (optionnel) Partages binaires jetables (coquelicot)
 
 ### Objectif honorable : infra de contribution publique
-Cette infra adresse en priorité les besoins de la communication en ligne : sites Web de présentation et réseaux sociaux en ligne.
+Cette objectif adresse en priorité les besoins de communication en ligne entre les membres contributeurs et le public : sites Web de présentation et réseaux sociaux en ligne.
 - Rapports de bugs (gitlab | gitea)
 - Messagerie instantanée (salon IRC type #sourcephile@irc.geeknode.net | prosody interne | serveur Jabber externe)
 - GitLab
-- Site Web des (futures) démonstrations (judgmentphile, docuphile, ledgerphile, relotophile)
+- Site Web des (futures) démonstrations (judgmentphile, docphile, ledgerphile, relotophile)
 - Listes méls publiques (discourse)
 - Forums publics (discourse)
 
 ### Objectif ambitieux : infra de mise en commun
-Cette infra adresse en priorité les besoins de la mise en commun en ligne : 
+Cette objectif adresse en priorité les besoins de la mise en commun en ligne.
+
 - (optionnel) Microblogging (mastodon | serveur externe)
 
 ### Objectif maximal : infra de services
 
-# Actions
-## Machine de services : APU2D4 de PCengines
+
+## Études
+### Hébergement
+#### PTT
+PTT est une association qui tient un (tiers-)lieu à Tarnac en Corrèze.
+Il est possible d’y héberger de petites machines à basse consommation pour 2€/mois (plus 3€/IPv4), dans une salle dédiée aux serveurs.
+Tarnac est au milieu du plateau de Millevaches, autrement dit en périphérie d’Internet.
+Le réseau est une VDSL2 fournie par Ilico/Grenode/Ielo-Liazo/Orange, soit environ 40Mbps descendant et 12Mpbs montant (mais pour l'ensemble de l'hébergement !).
+
+#### Tetaneutral
+Tetaneutral est une association à but non-lucratif basée à Toulouse.
+Tetaneutral est bien établie et active dans le portage de la cause de l’Internet libre.
+Il est possible d’y héberger de petites machines à basse consommation pour 5€ à 10€ par mois, dans une salle du squat artistique Mix'art Myrys :
+http://tetaneutral.net/adherer/
+Le réseau est une fibre optique directement reliée à centre de données Cogent voisin :
+https://tetaneutral.net/historique/
+
+
+### Machines
+#### APU2 de PCengines
 L’APU2 est un routeur conçu par une entreprise suisse (PCengines) et fabriqué à Taïwan. Le CPU est un AMD, dont l'architecture « x86_64 » est officiellement supportée par GHC, NixOS et ses caches binaires. Ce n'est pas complètement en matériel ouvert car certains composants clés comme le CPU ne le sont pas, mais PCengines publie ce qu'elle fait elle pour sa part (schémas et code source des modifications à Coreboot).
 
-PCengines a une renommée et une maturité certaine dans la conception de machines (ce n'est pas leur première), il ne s'agit donc de produits issus d'une random startup d'amateur.rices, ou autres personnes davantage préoccupées par le time-to-market plutôt que par le long-time-support.
+PCengines a une renommée et une maturité certaine dans la conception de machines (ce n'est pas leur première), il ne s'agit donc de produits issus d'une random startup d'amateur.rices, ou autres personnes davantage préoccupées par le time-to-market plutôt que par le long-time-support. L’APU2 est explicitement vanté, et ses composants choisis, pour assurer sa disponibilité sur le « long-terme ».
 
 L’APU2 est généralement utilisé comme routeur, mais peut aussi servir de petit (en terme de services peu gourmands côté serveur) serveur, voire de petit (en taille de stockage) « NAS » (Network Attached Storage), voire de petite (en puissance de calculs) machine de développement pour dépanner.
 
@@ -114,12 +143,12 @@ Ressources :
 - https://blog.linuxserver.io/2016/12/17/review-pcengines-apu2-c4-prebuilt-by-linitx/#vpnperformance
 - https://teklager.se/en/knowledge-base/
 
-### Caractéristiques
+##### Caractéristiques
 - Processeur : AMD G series GX-412TC (Turbo Core), 4x 1GHz Jaguar core with 64 bit support
   - Specs :
     - http://www.cpu-world.com/CPUs/Puma/AMD-G-Series%20GX-412TC.html
     - http://support.amd.com/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf 
-  - 170€HT, http://store.clemanis.com (PCE-APU2D4)
+  - 170€HT, http://store.clemanis.com (PCE-APU2E4)
   - 148€HT, https://teklager.se/en/products/router-components/pc-engines-apu2d4
   - 128€HT, https://www.wispmax.com/pc-engines-apu2b4-system-board.html
 - Coprocesseur : AMD CCP avec AES-NI
@@ -141,31 +170,29 @@ Ressources :
 - Conception : Suisse
 - Fabrication : Taïwan
 
-### Micrologiciel (firmware)
-Un disque avec des secteurs de 512B est utilisé mais si un disque avec des secteurs de 4KB est utilisé, un coreboot supportant UEFI devra être installé car GRUB ne supportera BIOS pour les disques 4KB : http://savannah.gnu.org/bugs/?46700
-La taille physique des secteurs est donnée par fdisk -l ou /sys/block/sd*/queue/physical_block_size .
-
-### Mémoire (RAM)
-4GB de RAM ce n’est pas énorme, c'est trop peu pour une machine de dév (surtout si elle n'est pas dédiée) ou de build, mais pour un serveur hébergeant des services de base c'est pas mal. D’un point de vue sécurité, il semble d'ailleurs préférable d'avoir plusieurs petites machines physiques distinctes qu’une grosse machine blindée hébergeant des machines virtuelles. Machines blindées qu'on ne trouvera d'ailleurs probablement pas de si tôt en matériel ouvert.
+##### Mémoire (RAM)
+4GB de RAM ce n’est pas énorme, c'est trop peu pour une machine de dév (surtout si elle n'est pas dédiée) ou de build, mais pour un serveur hébergeant des services de base c'est pas mal. D’un point de vue sécurité, il me semble d'ailleurs préférable d'avoir plusieurs petites machines physiques distinctes qu’une grosse machine blindée hébergeant des machines virtuelles. Machines blindées qu'on ne trouvera d'ailleurs **probablement** pas de si tôt en matériel ouvert.
 La RAM a de l’ECC (Error Correcton Code), supportée depuis peu dans le firmware de l’APU2.
+La RAM est soudée donc il faudra malheureusement changer toute la carte mère si elle vient à avoir des défaillances (testables en 2 heures avec Memtest86++).
+Le micrologiciel d’usine permet de faire un Memtest86+. Au préalable il faut installer deux dissipateurs de chaleur et la carte-mère dans le chassis, pour refroidir comme il faut le CPU. Dans une salle à vivre, la température affichée par Memtest86+ ne dépasse pas 52°C.
 
 4Go de RAM permet de rester en 32 bits, mais ZFS recommande 64 bits : https://github.com/zfsonlinux/zfs/wiki/FAQ#32-bit-vs-64-bit-systems
-
 Il faudra faire attention à bien configurer ZFS pour qu'il ne consomme qu'une part contrôlée de la RAM. Il est fort probable qu'activer de la déduplication ZFS soit trop gourmande en RAM : https://wiki.freebsd.org/ZFSTuningGuide#Deduplication
 
-### Réseau
-À PTT le réseau est une VDSL2, soit environ 40Mbps descendant et 12Mpbs montant (mais pour l'ensemble de l'hébergement !).
+##### Stockage
+Il est possible de mettre facilement deux disques SSD avec un APU2 dans la RMT-CASE-S1 : un sur le port mSATA et un sur le port SATA. Le port d'alimentation à 2 broches est un peu atypique et peut poser des problèmes (mauvaise connexion sur un modèle reçu par Franciliens). Globalement, le format de port mSATA est entrain d'être remplacé par le port M.2, ce qui pose la question de pouvoir trouver de bons SSD mSATA dans un futur proche, mais Clemanis vend un adaptateur mSATA-SATA laissant toujours la possibilité de n’utiliser que des disques SATA. Il est aussi possible de mettre une extension PCIe pour rajouter 4 ports SATA : https://pcengines.ch/howto.htm#add_on_cards
+Il est également possible de mettre une carte SD, mais les cartes SD tendent à mourrir plus vite et sont plus lentes.
+
+##### Réseau
 PCEngines note que :
 > The throughput depends very much on the OS, Linux based distributions perform much better than BSD based. Under Linux forwarding packets without filtering etc. a throughput of about 900-950Mbps can be achieved. Under BSD based OS, like pfSense, OPNSense, etc the max. throughput is about 600-650Mbps.
 
-Quelques commentaires signalent que l’APU2 sature à 45Mpbs avec OpenVPN en AES, OpenVPN ne pouvant utiliser qu'un seul coeur de CPU (single thread). L'APU2 aurait un horloge CPU trop lente et un cache L2 trop petit. Mais ici le VPN n'est pas un objectif.
+Quelques commentaires signalent que l’APU2 sature à 45Mpbs avec OpenVPN en AES, OpenVPN ne pouvant utiliser qu'un seul coeur de CPU (single thread). L'APU2 aurait une horloge CPU trop lente et un cache L2 trop petit. Mais ici le VPN n'est pas un objectif.
 - https://www.reddit.com/r/PFSENSE/comments/4nmuu4/my_pc_engines_apu2c4_experience/
 
-Comme AES peut également être utilisé lors de connexion en HTTPS, on peut peut-être s'attendre au même genre de performances.
-
-### Maintenance
+##### Maintenance
 La présence d’un port série permet un accès de maintenance plus simple et plus sécurisé que de l’IPMI (qui est un second OS en parallèle).
-Cependant PTT n'a pas de switch de ports série ou USB pour le moment.
+Mais il faut que l’hébergement propose un accès secondaire via un port série, ce qui n’est plus usuel.
 
 Câbles utiles :
 - USB to serial port
@@ -174,8 +201,54 @@ Câbles utiles :
   - 20€HT, http://store.clemanis.com/en/cables/566-kit-usb-to-serial-db9-female-for-alix-apu-3700667301720.html
 - null-modem "DB9" serial cable, 5€HT, https://www.ldlc.com/fiche/PB00170050.html
 
+Pour se connecter :
+> picocom -b 115200 -f h /dev/ttyUSB0
+
+##### Enclosure
+Il existe de nombreuses enclosures, mais essentiellement deux modèles.
+Les noires dissipent mieux la chaleur : https://openwrt.org/toh/pcengines/apu2
+La RMT-CASE-S1 de Clemanis (pour APU2 ou APU3 seulement !) est 15€ plus chère que d’autres enclosures plus petites, mais permet de stocker deux disques 2.5" dans l'enclosure et un sur le dessus pour un total de 4 disques avec le mSATA, ou de mettre une extension : http://store.clemanis.com/en/cases/324-pc-engines-alix-2d22d32d13-apu1apu2-case-with-hdd-wifi-black-3700667301379.html
+
 ### Stockage
-Le stockage choisi assure du cache (ZFS swap), du chiffrement (ZFS encryption), de la réplication (ZFS mirror), de la déduplication (ZFS dedup), de la réversibilité (ZFS snapshots), de la sauvegarde (ZFS send) et de la base de données (LUKS+ext4).
+#### SSD (Solid State Disk)
+##### Fiabilité
+Bien que rendant le Gio plus cher à l'achat, utiliser du disque à état solide (SSD) est plus fiable, plus rapide et consomme moins que du disque mécanique : https://arstechnica.com/gadgets/2014/06/consumer-grade-ssds-actually-last-a-hell-of-a-long-time/
+Tellement fiable qu'il ne semble pas raisonnable de répliquer en temps réel le disque mais juste de sauvegarder régulièrement ailleurs (zfs send) le disque. La réplication apporterait tout de même une tranquilité d'esprit importante. Surtout que les SSD pour particuliers n’ont généralement pas de condensateur interne contre les coupures de courant : https://insights.samsung.com/2016/03/22/power-loss-protection-how-ssds-are-protecting-data-integrity-white-paper/
+
+##### Vitesse
+Les petits SSD ont une vitesse d'écriture plus lente, dans la mesure où il y a plus de puces pour paralléliser les écritures (mais cela ne marche que pour des opérations parallélisables, cela ne s'applique à priori pas quand on a un seul processus) : https://www.tweaktown.com/reviews/5993/samsung-840-evo-128gb-msata-ssd-review/index.html
+Ainsi un 128Go écrira séquentiellement à 320Mo/s (Kingston) ou 410Mo/s (Samsung). Mais un 250Go écrira séquentiellement à 500Mo/s (Kingston) ou 520Go/s (Samsung).
+En outre, côté ordinateur tous les connecteurs SATA ne sont pas créés égaux, le concepteur de la carte-mère peut mettre des connecteurs bons marchés mais peu performants, auquel cas pouvoir rajouter une carte SATA peut améliorer la situation.
+
+Pour benchmarker :
+> dd if=/dev/zero of=/path/to/disk/tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
+> fio --name=seqread --rw=read --direct=1 --iodepth=32 --ioengine=libaio --bs=1M --numjobs=1 --size=10G --runtime=60 --group_reporting /path/to/disk/tempfile
+
+##### Endurance
+Les fabricants de SSD annonce une espérance de vie en Terabytes Written (TBW) ou Drive Writes Per Day (DWPD).
+Les disques fournissent des attributs SMART :
+> smartctl -a /dev/sda
+
+Après plus de 5 ans d’usage laptop relativement intensif, mon SSD Samsung 128G affiche encore 75% de santé.
+
+##### Cache
+Réserver une partie du SSD pour le swap est utile, notamment pour faire des tmpfs.
+Mettre dans ZFS semble le plus propre mais il existe encore un bug connu sévère qui le déconseille : https://github.com/zfsonlinux/zfs/issues/7734
+Il ne servirait à rien de le mettre dans le RAID, il suffit juste de mettre le swap dans un LUKS dédié pour le chiffer (avec une nouvelle clé éphémère à chaque boot) et d’ajouter les devices déchiffrés à la liste des swaps gérés par le noyau Linux.
+
+Benchmark :
+> stress --vm 10 --vm-keep --vm-bytes 512M
+
+Configuration du noyau Linux :
+> vm.swappiness = 10
+
+##### Secteurs
+Si un SSD 4KB est utilisé pour le boot, un coreboot supportant UEFI devra être installé car GRUB ne supportera BIOS pour les disques 4KB : http://savannah.gnu.org/bugs/?46700
+La taille physique des secteurs est donnée par fdisk -l ou /sys/block/sd*/queue/physical_block_size
+
+##### Modèles
+- https://www.fnac.com/mp37714266/Transcend-ts128gmsa230s-ssd-interne-msata-iii-128-go-sata-iii-6-gbps-3d-tlc/w-4
+- https://www.ldlc.com/fiche/PB00253086.html
 
 #### ZFS
 Bien que je n’ai aucune expérience avec (ZFS n’est pas exotique, mais n’est pas non plus le défaut sous Linux), je choisis d’utiliser ZFS plutôt que le stack RAID+LUKS+LVM+ext4+rsync que je connais bien, car il me semble que l'approche intégrée de ZFS permet une configuration moins complexe, plus granulaire, plus évolutive, tout aussi mature, plus fiable contre la corruption des disques, et plus sécurisée du point de vue des sauvegardes.
@@ -187,14 +260,25 @@ ZFS aurait une taille de son code source équivalente à 10 fois celle d’EXT4,
 ZFS ne peut légalement pas être intégré directement au noyau Linux mais cela est bien géré par NixOS.
 
 Quelques fonctionnalités / concepts de ZFS :
+- CoW (copy-on-write) : consiste à ne pas écraser un enregistrement lorsqu'il y q besoin de le modifier, mais d'écrire un nouvel enregistrement, de changer des pointeurs et de laisser le ramasse-miette (garbage-collector) de ZFS libérer l’ancien si il n’est plus référencé.
 - ZIL (ZFS Intent Log) : Utile si il y a beaucoup d’écriture synchrones ou servir des fichiers qui changent fréquemment.
-- SLOG (Separate Intent Log) : ZIL sur disque (de préférence répliqué par RAID, car le perdre serait dramatique), généralement de quelques Gio, rapide pour les écriture séquentielles et les fsync().
+- SLOG (Separate Intent Log) : ZIL sur disque (de préférence répliqué par RAID avec write-back, car le perdre perdrait serait dramatique), généralement de quelques Gio, rapide pour les écriture séquentielles et les fsync().
 - ARC (Adjustable Replacement Cache)/ : cache de ZFS sur la RAM. Utile pour servir des fichiers qui changent fréquemment.
 - L2ARC (Level 2 ARC) : cache ZFS optionnel sur disque, de préférence SSD, qui stocke les données balayées de l’ARC. Un système avec moins de 8Gio de RAM n’a pas besoin de L2ARC, qui ne ferait que réduire les performances en imposant une pression sur l’ARC. jgreco : « Do not add L2ARC to an 8GB system. Period. Probably not to 16 either. Maybe at 24 or 32GB, but you have to remember that L2ARC stresses out the ARC and that you shouldn't exceed maybe a 4:1 ratio of L2ARC:ARC. »
 - Scrubing (self-healing) : Si plus d’une copie (copies= strictement supérieur à 1) est disponible et qu’une des copie est détectée comme corrompue, ZFS retournera seulement la copie valide et réparera les enregistrement endommagés. Cela peut être déclenché manuellement avec la commande scrub.
 - Send/Receive : ZFS permet d’envoyer et de recevoir entièrement ou incrémentalement des captures instantannées (snapshots) vers d’autres machines.
 - Réplication : mirror, raidz-1, raidz-2, …, équivalents de RAID1, RAID5, RAID6, …. L’équivalent de la reconstruction du RAID s’appelle ici « resilvering ».
 - Déduplication : ZFS peut découvrir que des fichiers ou enregistrements sont similaires et éviter leur duplication, mais cela demande beaucoup de RAM.
+- Instantanés : ZFS permet de prendre à très peu de frais des snapshots, tout comme Git permet de faire des branches. Ces snapshots sont plus rapide en activant le prefetch scan.
+- Compression : ZFS permet de compresser les données selon divers algorithmes (LZ4 usuel, GZIP recommandé parfois par exemple sur les données séquentielles comme des logs, ou certaines bases de données), cette compression est généralement considérée comme un gain de performances et d’espace, surtout quand le temps que cette (dé)compression prend au CPU est moindre que le temps d’accès au disque.
+- Chiffrement : ZFS permet (en version officielle depuis seulement mai 2019) de chiffrer et authentifier les données, ce qui permet notamment :
+  - la compression (contrairement à ecryptfs).
+  - de faire des sauvegardes de dossiers spécifiques sans déchiffrer les données.
+  - de faire du chiffrement de bout en bout (end-to-end) avec (zfs send).
+  D’après man zfs, sont chiffrées : zvol data, file attributes, ACLs, permission bits, directory listings, FUID mappings, and userused / groupused data.
+  Ne sont pas chiffrées : metadata related to the pool structure, including dataset and snapshot names, dataset hierarchy, properties, file size, file holes, and deduplication tables.
+  Le chiffrement peut être activé en cours de route, mais ne concernera que les données qui seront écrite par la suite.
+  Il est important d’avoir un support des instruction AES-NI, qui en plus d’améliorer le SSH, le VPN, le HTTPS, améliore le chiffrement du stockage lorsque de l'AES est utilisé.
 
 ##### Ressources
 - https://wiki.debian.org/ZFS
@@ -203,25 +287,54 @@ Quelques fonctionnalités / concepts de ZFS :
 - https://nixos.wiki/wiki/NixOS_on_ZFS
 - https://wiki.freebsd.org/ZFSTuningGuide
 
-#### Disques : 1x 250GB SSD
-Bien que rendant le Gio plus cher à l'achat, utiliser du disque à état solide (SSD) est plus fiable, plus rapide et consomme moins que du disque mécanique : https://arstechnica.com/gadgets/2014/06/consumer-grade-ssds-actually-last-a-hell-of-a-long-time/
-Tellement fiable qu'il ne semble pas raisonnable de répliquer en temps réel le disque mais juste de sauvegarder régulièrement (zfs send) le disque. La réplication apporterait tout de même une tranquilité d'esprit importante, surtout comme là quand l'hébergement est semi-pro et peut subir des coupures d'électricité lorsque les arbres tombent sur les lignes et qu'ERDF n'amène pas un groupe électrogène avant la fin des batteries de secours. Cependant les SSD pour particuliers n’on généralement pas de condensateur interne contre les coupures de courant : https://insights.samsung.com/2016/03/22/power-loss-protection-how-ssds-are-protecting-data-integrity-white-paper/
+#### RAID (Redundant Array of Inexpensive Disks)
+La réplication entre deux disques ou plus que permet de se prémunir contre la défaillance matérielle d'un des deux disques. Le coût à payer est d’acheter un deuxième disque (pas forcément d'emblée) et de supporter un temps de lecture qui peut aller jusqu'à la somme de celui de chaque disque, et un temps d'écriture qui égal à celui du disque le plus lent. 
+RAID est une solution de réplication matérielle ou logicielle bien établie.
+RAID permet d’appliquer la réplication en dessous du chiffrement LUKS, alors que la réplication ZFS intervient en dessus du chiffrement LUKS, causant un chiffrement par disque de toute écriture. Toutefois, l’APU2 ayant un coprocesseur pour les AES-NI, en utilisant --cipher aes-xts-plain64 pour LUKS ces chiffrements supplémentaires n’auraient probablement pas d’un impact significatif sur les performances justifiant d’abandonner la flexibilité de ZFS.
 
-Il est possible de mettre facilement deux disques SSD : un sur le port mSATA et un sur le port SATA. Le port d'alimentation à 2 broches est un peu atypique et peut poser des problèmes (mauvaise connexion sur un modèle reçu par Franciliens). Le port mSATA est entrain d'être remplacé par le port M.2, ce qui pose la question de pouvoir trouver de bons SSD mSATA dans un futur proche.
+Le RAID logiciel peut être contrôlé par mdadm ou LVM (--type=raid), le backend mdraid est le même mais ce n'est pas compatible, mdadm est plus établi et abouti que LVM.
 
-Il est aussi possible de mettre une extension PCIe pour rajouter 4 ports SATA : https://pcengines.ch/howto.htm#add_on_cards
-Il est également possible de mettre une carte SD, mais les cartes SD tendent à mourrir plus vite et sont plus lentes.
+Si cette pénalité devient trop importante, un RAID5 (ou raidz) pourra être envisagé : https://serverfault.com/questions/830708/raid-1-to-raid-5-using-mdadm .
+Voire plutôt RAID6 qui n'a pas qu'un seul disque de parité, car le remplacement d'un disque est facteur de défaillance des autres disques. 
+RAID (surtout RAID-5) a des problèmes lors de l’écriture : http://www.raid-recovery-guide.com/raid5-write-hole.aspx . Cependant comme les disques sont des SSD et non des HDD, en arriver là semble très improbable vu l'usage actuellement souhaité, une surveillance de l’usure des disques et des sauvegardes régulières peuvent suffire.
 
-Pour benchmarker :
-> dd if=/dev/zero of=/path/to/disk/tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
-> fio --name=seqread --rw=read --direct=1 --iodepth=32 --ioengine=libaio --bs=1M --numjobs=1 --size=10G --runtime=60 --group_reporting /path/to/disk/tempfile
+#### LUKS (Linux Unified Key Setup)
+dm-crypt avec entêtes LUKS permet un chiffrement au niveau des block devices, et non seulement au niveau du contenu ou des métadonnées des fichiers comme ZFS ou ecryptfs.
+
+LUKS sera utile pour chiffrer le swap (qui ne peut pas encore être mis dans ZFS de manière fiable), et éventuellement le chiffrement complet du disque (c’est-à-dire de l’initrd et du kernel, mais pas du firmware ou du bootloader), auquel cas il faudra utiliser un LUKS1 (et pas LUKS2) tant qu’une version stable de GRUB ne supportera pas LUKS2.
 
-Tous les connecteurs SATA ne sont pas créés égaux, le concepteur de la carte-mère peut mettre des connecteurs bons marchés mais peu performants, auquel cas rajouter une carte SATA peut améliorer la situation.
+Pour benchmarker LUKS : https://unix.stackexchange.com/questions/254017/how-to-interpret-cryptsetup-benchmark-results
+> cryptsetup benchmark
 
-Concernant l'usage, à court et moyen terme les disques n'ont pas besoin d'être particulièrement grands, 64GB ou 128GB seront largement assez. Cependant il faut savoir que les petits SSD ont une vitesse d'écriture plus lente, dans la mesure où il y a plus de puces pour paralléliser les écritures (mais cela ne marche que pour des opérations parallélisables, cela ne s'applique à priori pas quand on a un seul processus) : https://www.tweaktown.com/reviews/5993/samsung-840-evo-128gb-msata-ssd-review/index.html
+Pour de l’AES-128 cela donne :
+> cryptsetup luksFormat --iter-time 2s --hash sha256 --cipher aes-xts-plain64 --keysize 256 /dev/sdX
+XTS est recommandé pour chiffrer des block devices, à noter toutefois qu’XTS sépare la clé en deux, ce qui nécessite de doubler --keysize.
 
-Ainsi un 128Go écrira séquentiellement à 320Mo/s (Kingston) ou 410Mo/s (Samsung). Mais un 250Go écrira séquentiellement à 500Mo/s (Kingston) ou 520Go/s (Samsung).
-J’opte donc pour le réemploi d’un Samsung 840 EVO (mieux que QVO) de 250GB, sans condensateur interne; que je possède mais n’ai que très peu utilisé jusque là (janvier 2020) :
+#### ecryptfs
+Le chiffrement par ecryptfs ne permet ni compression, ni déduplication et rajoute des métadonnées en entête, ce qui prend de la place.
+
+#### LVM (Linux Volume Manager)
+
+
+# Actions
+## Réseau
+Un essai d’hébergement est expérimenté chez PTT, qui est à côté de chez julm.
+
+## Stockage
+Le stockage assure ici :
+- du cache (LUKS+swap)
+- du chiffrement (ZFS encryption)
+- de la réversibilité (ZFS snapshots)
+- de la sauvegarde (ZFS snapshots et zfs send)
+- et de la base de données (ZFS customisé).
+
+Le stockage n’assure pas ici :
+- de la réplication (ZFS mirror)
+- de la déduplication (ZFS dedup)
+
+Puisqu’il s’agit d’un SSD, de données qui seront sauvegardées et de services qui pourront supporter une coupure de quelques jours, il n’y a pas de réplication en temps-réel, mais il faudra avoir un SSD de dépannage et réformer celui en production lorsqu’il sera descendu à 50% de santé.
+
+Réemploi d’un Samsung 840 EVO (mieux que QVO) de 250GB, sans condensateur interne, que je possède mais n’ai que très peu utilisé jusque là (janvier 2020) :
 > % smartctl-tbw /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R 
 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R    Power_On_Hours             1437 hours / 59 days / 0.16 years
 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R    Wear_Leveling_Count        99 (% health)
@@ -238,106 +351,38 @@ J’opte donc pour le réemploi d’un Samsung 840 EVO (mieux que QVO) de 250GB,
 > Disklabel type: gpt
 > Disk identifier: E42083E9-58B2-4CD0-B716-2B923C6B8007
 
-Estimations :
-- 28GB NixOS
-- 20GB Dépôts Git
-- 20GB Boîtes méls
-- 20GB Archives méls
-- 20GB Nextcloud
--  2GB Logs
-- 
-
-#### Swap cache : LUKS
-Le swap est essentiel (sur une machine avec seulement 4G RAM) et pour tmpfs.
-Mettre dans ZFS semble le plus propre mais il existe encore un bug connu sévère qui le déconseille : https://github.com/zfsonlinux/zfs/issues/7734
-Il ne sert à rien de le mettre dans le RAID, il suffit juste de mettre le swap dans un LUKS dédié pour le chiffer (avec une nouvelle clé éphémère à chaque boot) et d’ajouter les devices déchiffrés à la liste des swaps gérés par le noyau Linux.
-
-Benchmark :
-> stress --vm 10 --vm-keep --vm-bytes 512M
+### Partitionnement
 
-#### Chiffrement : ZFS
-Le chiffrement peut être assuré au niveau des secteurs par dm-crypt avec entêtes LUKS, et au niveau du contenu des fichiers par ZFS ou ecryptfs.
-
-Le chiffrement par dm-crypt+LUKS au-dessous de ZFS a pour désavantages d'impliquer que les copies/réplications de ZFS sont chiffrées plusieurs fois, et que les clés doivent toujours être en mémoire. Il est par contre pertinent de l’utiliser pour le swap compte tenu que ZFS a encore un bug ouvert concernant le swap dans ZFS : https://github.com/zfsonlinux/zfs/issues/7734
-
-Le chiffrement par ecryptfs ne permet ni compression, ni déduplication et rajoute des métadonnées en entête ce qui prend de la place.
-
-Le chiffrement par ZFS permet la compression (contrairement à ecryptfs), permet de faire des sauvegardes de dossiers spécifiques sans déchiffrer les données.
-D’après man zfs, sont chiffrées : zvol data, file attributes, ACLs, permission bits, directory listings, FUID mappings, and userused / groupused data.
-Ne sont pas chiffrées : metadata related to the pool structure, including dataset and snapshot names, dataset hierarchy, properties, file size, file holes, and deduplication tables.
-
-Le chiffrement peut être activé en cours de route, mais ne concernera que les données qui seront écrite par la suite.
-
-Le chiffrement complet du disque (c’est-à-dire de l’initrd et du kernel, mais pas du firmware ou du bootloader) peut être envisagé, mais il faut utiliser un LUKS1 (et pas LUKS2) tant que GRUB ne supporte pas LUKS2.
-
-Le coprocesseur AMD CCP (pour cryptographie AES) peut améliorer un peu le VPN, le HTTPS et le chiffrement du stockage lorsque de l'AES est utilisé.
-
-Pour benchmarker LUKS :
-> cryptsetup benchmark
-- https://unix.stackexchange.com/questions/254017/how-to-interpret-cryptsetup-benchmark-results
-
-AES-128 est considéré comme suffisamment sécurisant vu notre niveau de menace et de sécurité physique. https://xkcd.com/538/
-Ce qui donne, pour LUKS (XTS sépare la clé en deux, donc il faut doubler --keysize) :
-> cryptsetup luksFormat --iter-time 2s --hash sha256 --cipher aes-xts-plain64 --keysize 512 /dev/sdX
-Et pour ZFS :
-> aes-128-gcm
-
-#### Réplication : ZFS
-La réplication peut être assurée par RAID (RAID1) ou ZFS (mirror ou raidz).
-
-La réplication entre deux disques ou plus permet de se prémunir contre la défaillance matérielle d'un des deux disques. Le coût à payer est d’acheter un deuxième disque (pas forcément d'emblée) et de supporter un temps de lecture qui peut aller jusqu'à la somme de celui de chaque disque, et un temps d'écriture qui égal à celui du disque le plus lent. Si cette pénalité devient trop importante, un RAID5 (ou raidz) pourra être envisagé : https://serverfault.com/questions/830708/raid-1-to-raid-5-using-mdadm . Voire plutôt RAID6 qui n'a pas qu'un seul disque de parité, car le remplacement d'un disque est facteur de défaillance des autres disques. RAID (notamment RAID-5) a aussi des problèmes lors de l’écriture : http://www.raid-recovery-guide.com/raid5-write-hole.aspx . Cependant comme les disques sont des SSD et non des HDD, en arriver là semble très improbable vu l'usage actuellement souhaité, une surveillance de l’usure des disques et des sauvegardes régulières peuvent suffire.
-
-Utiliser RAID permet d’appliquer la réplication en dessous du chiffrement LUKS, alors que la réplication ZFS intervient en dessus du chiffrement LUKS, causant un chiffrement par disque de toute écriture. Toutefois, l’APU2 ayant un coprocesseur pour les AES-NI, en utilisant --cipher aes-xts-plain64 pour LUKS ces chiffrements supplémentaires ne devraient pas avoir un impact sur les performances justifiant d’abandonner la flexibilité de ZFS.
-
-Le RAID logiciel peut être contrôlé par mdadm ou LVM (--type=raid), le backend mdraid est le même mais ce n'est pas compatible, mdadm est plus établi et abouti que LVM.
-
-#### Réversibilité : ZFS
-La réversibilité peut être assurée par LVM (snapshot) ou ZFS.
-
-#### Sauvegardes : ZFS
-- duplicity : sauvegardes incrémentales requérant un snapshot complet et une liste de différences jusque là.
-- BorgBackup : déduplication.
-- ZFS : 
-
-Contrairement aux autres, ZFS permet de faire des sauvegardes directement lisibles, il n'y a pas besoin de restaurer la dernière version, juste de la déchiffrer.
-
-#### Bases de données : ZFS
-Le copy-on-write (CoW) de ZFS fait que lorsqu’il a besoin de modifier un enregistrement, il ne l’écrase pas. Au lieu de ça il écrit un nouvel enregistrement, change les pointeurs et laisse son ramasse-miette (garbage-collector) libérer l’ancien si il n’est plus référencé. Cela est tout à fait dans l’esprit fonctionnel mais a un impact négatif sur les applications dont le cœur de métier est de modifier des fichiers en place, comme MySQL ou PostgreSQL : https://wiki.freebsd.org/ZFSTuningGuide#Application_Issues
-
-Cependant il y a des atténuations possible à tester, il semble raisonnable à ce stade de ne pas chercher une optimisation prématurée en allouant une partition EXT4 de taille arbitraire et en s’imposant tout ce que ça implique de configuration de RAID/LUKS/LVM alors que ZFS nous permet justement de nous en passer.
-
-Ressources :
-- https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/
-- https://www.percona.com/resources/webinars/zfs-mysql
-- https://www.percona.com/blog/2018/05/15/about-zfs-performance/
-
-#### Partitionnement
 - /dev/sd{a,b}1  500Mio  boot
 - /dev/sd{a,b}2    4Gio  luks-swap
 - /dev/sd{a,b}4  200Gio  luks-zfs
 
+> lsblk
+> [TODO]
+
 La table de partition est au format GPT, qui se retrouve de plus en plus dans les tutos que MSDOS, tout en étant bien supporté par les outils.
 Les UUID sont randomisées (avec ˋsgdisk -Gˋ) et distincts d'un disque à l'autre.
 
 Il ne semble pas nécessaire de faire une partition de secours (rescue), une clé USB, un accès par port série ou un busybox sur /boot devrait suffire.
-La partition /tmp sera un tmpfs utilisant les 4 à 8G de swap.
+La partition /tmp sera un tmpfs utilisant la RAM et les 4 à 8G de swap.
+Les logs sont sur un dataset séparé pour garantir fortement qu'elle ne remplira pas celle des données, et pour que déchiffrer les logs, n'implique pas de déchiffrer les données.
 
-Les logs sont sur une partition séparée pour garantir fortement qu'elle ne remplira pas celle des données, et pour que déchiffrer les logs, n'implique pas de déchiffrer les données.
+### Chiffrement
+AES-128 est ici considéré comme suffisamment sécurisant vu le niveau de menace et de sécurité physique.
+https://xkcd.com/538/
 
-### Enclosure
-Il existe de nombreuses enclosures, mais essentiellement deux modèles.
-Les noires dissipent mieux la chaleur : https://openwrt.org/toh/pcengines/apu2
-La RMT-CASE-S1 de Clemanis (pour APU2 ou APU3 seulement !) est 15€ plus chère que d’autres enclosures plus petites, mais permet de stocker deux disques 2.5" dans l'enclosure et un sur le dessus pour un total de 4 disques avec le mSATA, ou de mettre une extension : http://store.clemanis.com/en/cases/324-pc-engines-alix-2d22d32d13-apu1apu2-case-with-hdd-wifi-black-3700667301379.html
+## Travaux futurs
+### Machine de sauvegardes
+Il est important de bien mettre en place une sauvegarde automatique, d’autant plus qu’il n’y a pas de réplication en temps-réelle mise en place sur un second disque.
+ZFS (zfs send) devrait faciliter cette sauvegarde, en produisant notamment des sauvegardes directement lisibles/vérifiables, sans avoir besoin de restaurer la dernière version, juste de la déchiffrer.
 
-### Espérance de fonctionnement
-Après plus de 5 ans d’usage laptop relativement intensif, mon SSD Samsung 128G affiche encore 75% de santé.
-Je vais commencer sans réplication en temps-réel, en disant qu’au pire à 50% de santé il faudra réformer le SSD.
-Il est important de bien mettre en place une sauvegarde
-Une redondance en RAID1 logiciel (mdadm) rendra **probablement** le remplacement assez simple.
-La carte de l’APU2 devrait pouvoir durer plus de 10 ans.
-Mais le fait que la RAM soit soudée fait qu'il faudra changer toute la carte mère si elle vient à avoir des défaillances.
+D’autres outils sont pour l’instant écartés :
+- duplicity : sauvegardes incrémentales requérant un snapshot complet et une liste de différences jusque là.
+- BorgBackup : déduplication.
+
+### Machine de compilations
+Il faut préalablement voir les performances que permet cette première machine, qui même si elles ne sont pas remarquables, peuvent suffire dans un premier temps.
 
-## Machine de compilations
 - http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm
 > The intel Core as found in the Core i5 is performing very well, but hyperthreading brings little benefit here (13%). Thus a CPU should be chosen with real cores
 > [...]
@@ -345,17 +390,6 @@ Mais le fait que la RAM soit soudée fait qu'il faudra changer toute la carte m
 > [...]
 > Some tests run with the ramlat utility showed that the build time almost solely depends on the L1 cache speed, then a little bit on the L2 cache speed and then finally on the DRAM speed. It does not exactly depend on the memory bandwidth but rather latency.
 
-## Hébergement chez PTT
-PTT propose de l’hébergement à Tarnac (Corrèze).
-L’hébergement se fait dans une petite salle dédiée et climatisée d’un "tier-lieu" (médiathèque, cyberespace) du village.
-La connexion est derrière une VDSL2+ fournie par l’association Ilico.
-
-- https://www.fnac.com/mp37714266/Transcend-ts128gmsa230s-ssd-interne-msata-iii-128-go-sata-iii-6-gbps-3d-tlc/w-4
-- https://www.ldlc.com/fiche/PB00253086.html
-
-## Travaux futurs
-### Machine de sauvegardes
-### Machine de compilations
 
 # Critiques
 ## Inconvénients
@@ -374,18 +408,50 @@ Problème : pour faire de la virtualisation il est préférable d'avoir des CPU
 
 Réponse : la virtualisation est surtout adaptée lorsque ce ne sont pas les mêmes personnes qui gèrent les services, ou lorsqu'il faut faire tourner des OS différents. Mais dans le cas présent ce n'est pas le cas, donc des containers type LXC devraient suffire du point de vue d'une compartimentation sécuritaire.
 
+### PTT ne propose pas d’accès secondaire par port série
+Problème : l’APU2 n’a pas d’IPMI, seulement un port série, cependant PTT n'a pas de switch de ports série ou USB pour le moment, et ne sait pas trop comment gérer les accès d’un tel switch. Cet accès secondaire est important pour espérer pouvoir redémarrer l’APU2 à distance. Cependant seul une coupure de l’alimentation permet un redémarrage propre (cold-boot).
+
+Réponse : il faudrait probablement étudier et proposer nous même un switch permettant cela.
+
 ### nsd4 et iodined nécessitent tous deux le port 53
 Problème : normalement nsd4 et iodined sont incompatibles sur une seule et même IPv4 (à 3€/mois ici), car ils requièrent tous deux l’écoute sur le port 53 du DNS.
 
-Réponse : ce n’est pas très propre, mais il est possible de mutualiser ce port avec une règle iptables du genre : `-A nat -p udp --dport 53 -m string --algo kmp --from 40 --hex-string |01|i|05|plura|02|fr|00| -j DNAT --to-destination :5353` où iodined écoute maintenant sur le port 5353.
+Réponse : ce n’est pas très propre, mais il est possible de mutualiser ce port avec une règle iptables du genre : `-A nat -p udp --dport 53 -m string --algo kmp --from 40 --hex-string |01|i|0b|sourcephile|02|fr|00| -j DNAT --to-destination :5353` où iodined écoute maintenant sur le port 5353.
 
-### Utiliser des bases de données sous ZFS demande de la customisation
-Problème : les bases de données ont des performances amoindries sous ZFS.
+### ZFS n’est pas (trivialement) adapté aux bases de données
+Problème : les bases de données ont des performances amoindries sous un ZFS qui n’est pas customisé pour.
 
 Réponse : on utilise actuellement du SSD pour tout (donc pour le ZIL) donc ça devrait aller sans L2ARC, et il existe de la documentation pour customiser les options de ZFS. Il restera toujours possible de rajouter un SSD avec LUKS+EXT4 dédié aux bases de données si c’est vraiment trop problématique.
 
+### Le chiffrement de ZFS limite le nombre de copies à 2
+Problème : même sans activer une réplication (mirror ou raidz), ZFS permet de garder plusieurs copies de chaque fichier, mais lorsque ces fichiers sont chiffrés ce nombre est actuellement limité à 2.
+
+Réponse : c’est déjà pas mal.
+
+### ZFS requiert de l’espace de stockage libre
+Problème : ZFS fonctionne par copy-on-write ce qui implique qu’écrire demande beaucoup plus d’espace libre que pour d’autres systèmes de fichiers.
+
+Réponse : ZFS nécessite de veiller à la RAM et au stockage libre, il faut veiller à ce que ZFS ait toujours au moins 20% d’espace libre pour ne pas avoir de pertes de performances et éviter de taper toujours sur les mêmes secteurs du SSD, ce qui diminuerait sensiblement son espérance de vie.
+
+### ZFS et les bases de données
+Problème : le copy-on-write de ZFS peut avoir un impact négatif très significatif sur les applications dont le cœur de métier est de modifier des fichiers en place, comme MySQL ou PostgreSQL : https://wiki.freebsd.org/ZFSTuningGuide#Application_Issues
+
+Réponse : il y a des atténuations possible à tester, il semble raisonnable à ce stade de ne pas chercher une optimisation prématurée en allouant une partition EXT4 de taille arbitraire et en s’imposant tout ce que ça implique de configuration de RAID/LUKS/LVM alors que ZFS nous permet justement de nous en passer.
+
+Ressources :
+- https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/
+- https://www.percona.com/resources/webinars/zfs-mysql
+- https://www.percona.com/blog/2018/05/15/about-zfs-performance/
+
 ## Question non-résolues
+
 ## Alternatives
+
+### RAID+LUKS+LVM+ext4
+La réplication peut être assurée par RAID (RAID1) au lieu de ZFS (mirror ou raidz).
+
+Le chiffrement par dm-crypt+LUKS au-dessous de ZFS a pour désavantages d'impliquer que les copies/réplications de ZFS sont chiffrées plusieurs fois, et que les clés doivent toujours être en mémoire. Il est par contre pertinent de l’utiliser pour le swap compte tenu que ZFS a encore un bug ouvert concernant le swap dans ZFS : https://github.com/zfsonlinux/zfs/issues/7734
+
 ### TLsense
 - Processeur : Intel i3 | i5 | i7
   - i7 : https://teklager.se/en/products/routers/tlsense-i7-4lan
-- 
2.47.2