PROJET AUTOBLOG


NullPointerException

Site original : NullPointerException

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Stockage chiffré intégral sur serveur distant

samedi 22 juillet 2017 à 00:00

Vous n’aurez pas ma liberté de chiffrer (ni mes données) !

Suite à une petite mésaventure qui m’est arrivée à la mi-mai (je rédigerai peut-être un post-mortem un jour, tiens), j’ai dû encore plus renforcer ma paranoïa sur mes serveurs, et j’en suis dorénavant arrivé à devoir chiffrer intégralement mes disques durs, y compris pour mes serveurs distants.

Le problème est qu’autant chiffrer son téléphone, son PC de bureau et son PC portable est relativement simple, autant chiffrer une machine distante est une autre paire de manches ! En effet, au démarrage, vous n’aurez aucune possibilité d’avoir à disposition un écran et un clavier pour saisir votre phrase de passe ! Il va donc falloir ruser un peu et embarquer un serveur SSH dès le démarrage (avant même le déchiffrement des disques !) pour avoir un accès suffisant pour déverrouiller le reste et lancer le reste du système.

Personnellement, je reste chez Online malgré ma petite déconvenue, et donc j’ai repris le tutoriel initial d’installation d’une machine chez eux pour l’adapter à une version intégralement chiffrée des disques durs.

Histoire de corser un peu le tout, j’ai en plus décider de passer tout mon système sous LVM, et en prime de faire du thin provisionning, ce qui permet un meilleur usage des ressources sur le disque.

Les tutoriels sur le sujet disponibles sur le net ont tendance à un peu trop bidouiller le système, surtout que Debian a (presque) fait le nécessaire pour que tout fonctionne nativement.

Donc voici ma recette personnelle.

Procédure

Comme pour l’ancienne procédure, tout va se passer en mode secours Online. À défaut d’avoir du Debian de disponible, choisissez une version récente d’Ubuntu (à l’heure actuelle, la 16.04).

Étant donné qu’on va faire du chiffrement de disque, je préconise de faire au moins une passe complète d’écriture aléatoire sur vos disques, afin de minimiser encore plus les informations accessibles par un attaquant. Vous pouvez utiliser shred ou pour aller plus vite, un petit outil que j’ai commis en ruby.

Une fois connecté en SSH, on commence par installer les outils nécessaires. Il va y avoir des erreurs à l’installation, c’est « normal » et ça ne bloquera pas la suite.

apt update
apt install -y dialog
apt dist-upgrade -y
apt install -y cryptsetup lvm2 thin-provisioning-tools debootstrap debian-archive-keyring

On passe ensuite au formatage proprement dit. J’ai choisi de faire une partition (nécessairement) en clair de 1G pour mon /boot, puis tout le reste du disque en tant que physical volume LVM. Si vous faites du LXC, vous pouvez faire deux PV LVM, un pour le système et un pour vos machines virtuelles. Vous pouvez bien entendu adapter les logical volumes à vos besoins.

swapoff -a
vgchange -a n

/sbin/parted -a optimal --script /dev/sda mklabel msdos
sfdisk /dev/sda <<EOF
/dev/sda1 : size=1G, type=83, bootable
/dev/sda2 : type=e8
EOF

cryptsetup -q luksFormat --verify-passphrase --hash sha256 --key-size=512 --cipher aes-xts-plain64 /dev/sda2
cryptsetup luksOpen /dev/sda2 crypt_system

pvcreate /dev/mapper/crypt_system
vgcreate system /dev/mapper/crypt_system
lvcreate -l 100%FREE --type thin-pool --thinpool system system
lvcreate --thin --virtualsize 10G  -n root system/system
lvcreate --thin --virtualsize 20G  -n var  system/system
lvcreate --thin --virtualsize 10G  -n log  system/system
lvcreate --thin --virtualsize 10G  -n home system/system
lvcreate --thin --virtualsize 100G -n srv  system/system
lvcreate --thin --virtualsize 1G   -n swap system/system

mkfs.ext4 -F /dev/sda1 -L boot -m 0
for d in root var log home srv; do mkfs.ext4 "/dev/system/${d}" -L "${d}" -m 0; done
mkswap /dev/system/swap -L swap

On monte ensuite tout ça et on lance la création du nouveau système Debian.

mount /dev/system/root /mnt
mkdir -p /mnt/{boot,var,tmp,home}
mount /dev/sda1 /mnt/boot
mount /dev/system/var /mnt/var
mkdir -p /mnt/var/log
mount /dev/system/log /mnt/var/log
mount /dev/system/home /mnt/home
mkdir -p /mnt/srv
mount /dev/system/srv /mnt/srv

debootstrap --arch=amd64 --variant=minbase stretch /mnt http://deb.debian.org/debian/

mkdir -p /mnt/{proc,sys,dev}
for i in proc sys dev; do mount -o bind "/${i}" "/mnt/${i}"; done

On est alors prêt à configurer le minimum vital pour un démarrage correct.

chroot /mnt

cat > /usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod +x /usr/sbin/policy-rc.d

rm /etc/apt/sources.list
mkdir -p /etc/apt/sources.list.d
cat > /etc/apt/sources.list.d/debian.list <<EOF
deb http://deb.debian.org/debian/ stretch main contrib
deb http://deb.debian.org/debian/ stretch-updates main contrib
deb http://deb.debian.org/debian/ stretch-backports main contrib
deb http://deb.debian.org/debian-security/ stretch/updates main contrib
EOF
cat >/etc/apt/apt.conf.d/60recommends <<EOF
APT::Install-Recommends "0";
APT::Install-Suggests "0";
EOF
apt update
apt dist-upgrade -y

mkdir -p /etc/network/interfaces.d
echo "source-directory /etc/network/interfaces.d" > /etc/network/interfaces
cat > /etc/network/interfaces.d/lo <<EOF
auto lo
iface lo inet loopback
EOF
cat > /etc/network/interfaces.d/enp0s20f0 <<EOF
auto enp0s20f0
iface enp0s20f0 inet static
	address X.X.X.X/24
	gateway X.X.X.1
iface enp0s20f0 inet6 static
	address XXXX:XXXX:XXXX:100::1/56
	pre-up dhclient -cf /etc/dhcp/dhclient6.enp0s20f0.conf -pf /var/run/dhclient6.enp0s20f0.pid -6 -P enp0s20f0
	pre-down dhclient -x -pf /var/run/dhclient6.enp0s20f0.pid
EOF

echo pony > /etc/hostname
hostname -F /etc/hostname

cat > /etc/hosts <<EOF
127.0.0.1       pony.example.org pony
127.0.0.1       localhost

::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
EOF

mkdir -p /etc/dhcp/
cat > /etc/dhcp/dhclient6.enp0s20f0.conf <<EOF
interface "enp0s20f0" {
	send dhcp6.client-id XX:XX:XX:XX:XX:XX:XX:XX:XX:XX;
	request;
}
EOF

cat > /etc/fstab <<EOF
proc				/proc			proc	defaults			0	0
sysfs				/sys			sysfs	defaults			0	0
cgroup				/sys/fs/cgroup	cgroup	defaults			0	0
tmpfs				/tmp			tmpfs	nodev,nosuid,nodev,noatime,size=1G	0	0
$(blkid /dev/disk/by-label/swap | awk '{print $3}' | tr -d '"')	none	swap	swap	0	0

$(blkid /dev/disk/by-label/root | awk '{print $3}' | tr -d '"')	/			ext4	errors=remount-ro,noatime	0	1
$(blkid /dev/disk/by-label/boot | awk '{print $3}' | tr -d '"')	/boot		ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/var | awk '{print $3}' | tr -d '"')	/var		ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/log | awk '{print $3}' | tr -d '"')	/var/log	ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/srv | awk '{print $3}' | tr -d '"')	/srv 		ext4	defaults,noatime			0	2
EOF

cat > /etc/crypttab <<EOF
crypt_system $(blkid /dev/sda2 | awk '{print $2}' | tr -d '"') none luks
EOF

apt -y install dialog locales
apt -y install localepurge
localepurge
dpkg-reconfigure localepurge
apt -y install bash-completion less rsyslog unbound systemd-sysv kbd console-setup console-data net-tools isc-dhcp-client

Jusque-là, pas grand-chose de très nouveau par rapport à la version non chiffrée. C’est à partir d’ici que les choses vont se gâter un peu.

On va maintenant installer le nécessaire pour que le système embarque un serveur SSH léger, dropbear et réclamer à initramfs d’embarquer tout ça et de monter les interfaces réseau au démarrage histoire qu’on puisse se connecter, alors que nos disques durs ne seront pas accessibles à ce moment-là !
Deux difficultées réelles ici. dropbear ne supporte pas encore toutes les possibilités de SSH. En particulier, il ne tolère pas les clefs ED25519. Vous devez donc utiliser soit une ECDSA, soit une RSA. Et côté Debian, thin-provisioning-tools ne déploie pas nativement de hook sur initramfs, ce qui fait qu’il n’est pas embarqué. Il faut donc penser à patcher un peu à la main.

apt -y install lvm2 thin-provisioning-tools cryptsetup dropbear busybox ifupdown
apt -y install linux-image-amd64 linux-headers-amd64 grub2

cat > /etc/dropbear-initramfs/authorized_keys <<EOF
ecdsa-sha2-nistp521 xxxx you@example.org
EOF

cat >> /etc/initramfs-tools/initramfs.conf <<EOF
IP=X.X.X.X::X.X.X.1:255.255.255.0::enp0s20f0:off
EOF

cat > /etc/initramfs-tools/hooks/thin-provisioning-tools <<EOF
#!/bin/sh

PREREQ="lvm2"

prereqs() {
	echo "$PREREQ"
}

case \$1 in
prereqs)
	prereqs
	exit 0
	;;
esac

[ ! -x /usr/sbin/cache_check ] && exit 0

. /usr/share/initramfs-tools/hook-functions

copy_exec /usr/sbin/thin_check
copy_exec /usr/sbin/thin_dump
copy_exec /usr/sbin/thin_repair
copy_exec /usr/sbin/thin_restore
copy_exec /sbin/dmeventd

manual_add_modules dm_thin_pool
EOF
chmod +x /etc/initramfs-tools/hooks/thin-provisioning-tools

update-initramfs -uk all

On finit par tout nettoyer et préparer pour le reboot.

systemctl enable getty@ttyS1.service
systemctl disable dropbear

rm -f /usr/sbin/policy-rc.d

cat > /etc/resolv.conf <<EOF
search example.org
domain example.org
nameserver ::1
nameserver 127.0.0.1
nameserver 62.210.16.6
nameserver 62.210.16.7
EOF

mkdir -p /root/.ssh
cat > /root/.ssh/authorized_keys <<EOF
ssh-ed25519 xxxx you@example.org
EOF

passwd

exit

On démonte tout ça, et hop, reboot !

for i in dev sys proc var/log var home srv boot ""; do umount "/mnt/${i}"; done
vgchange -a n
cryptsetup luksClose crypt_system

reboot

« Normalement », vous devriez pouvoir vous connecter à votre serveur en cours de démarrage en SSH, puis pouvoir lancer le déchiffrement des disques avec cryptroot-unlock. Vous saisissez votre phrase de passe et votre machine va continuer son processus de boot normal (ça peut prendre un peu de temps, soyez patient !).

En cas de problème

Cette procédure est particulièrement galère à debugger quand ça ne fonctionne pas. Parce que votre serveur n’est plus capable de rien et risque même de ne pas booter du tout.

Il est donc conseillé de redémarrer votre machine en gardant un œil sur son KVM IP ou sa console série.

Pour corriger une erreur, vous devrez redémarrer en mode secours, déchiffrer vos disques et les monter.

apt install -y cryptsetup lvm2 thin-provisioning-tools
cryptsetup luksOpen /dev/sda2 crypt_system
vgchange -a y
mount /dev/system/root /mnt
for i in proc sys dev; do mount -o bind "/${i}" "/mnt/${i}"; done
chroot /mnt
mount -a
…
umount -a
exit
for i in dev sys proc ""; do umount "/mnt/${i}"; done
vgchange -a n
cryptsetup luksClose crypt_system
reboot

En piste de trucs qui peuvent merder sur l’initramfs :

Bon courage à vous !

Réflexion autour de l’auto-hébergement et des CHATONS

vendredi 21 juillet 2017 à 00:00

Après ma grosse réflexion autour du logiciel libre, une nouvelle réflexion autour de l’hébergement. Une nouvelle fois, elle a été initiée suite à la publication d’un billet de blog et d’un flux twitter

L’(auto-)hébergement est-il trop compliqué ?

Dans l’article initial, l’auteur fait le constat que les solutions actuelles de cloud personnel (Own/NextCloud & CozyCloud) sont complexes à installer et qu’il faut des connaissances en administration système si on souhaite héberger ça à la maison.

En pratique, on ne peut pas lui donner tort. C’est effectivement compliqué. Voire beaucoup. Et même des personnes plutôt compétentes se prennent régulièrement les pieds dans le tapis.

Mais à la réflexion, cette complexité est en réalité normale.

Un éco-système de facto complexe et unique

On parle d’installer des systèmes complexes, composés de beaucoup de sous-composants. Outre l’application en elle-même, il y a quasiment toujours besoin d’un serveur de courriel, d’une base de données, d’un serveur web, de gérer des certificats X.509, un nom de domaine, de mettre les mains dans le réseau… Certains morceaux sont même d’un niveau tel que même les « experts » du domaine se prennent régulièrement des claques et commettent des erreurs (le courriel, TLS ou DNS, si vous m’écoutez…).

En fait, il est même quasiment impossible d’avoir une recette miracle qui va s’adapter au contexte de l’hébergement final. Les configurations sont trop diverses, en particulier sur tout ce qui touche au réseau (FAI différents, box ADSL ou fibre différents…), pour espérer pouvoir gérer un service sans un minimum de configuration différentes.

Vous êtes chez Free ? Vous avez peut-être seulement une demie-IP à disposition. Vous êtes chez Bouygues ? Vous ne pouvez juste pas envoyer de courriel. Chez OVH le réseau local est en 192.168.1.0/24 mais en 192.168.0.0/24 chez Free voire en 10.0.0.0/24 sur certaines configurations Bouygues. Et je ne parle même pas des manipulations complètement différentes dépendantes du modèle du modem et de la version de son firmware pour configurer le NAT et ouvrir les ports nécessaires à l’utilisation du service. Ouverture de port qui nécessite d’assigner une IP fixe au périphérique, ce qui est déjà hors de portée d’un utilisateur lambda. On pourrait aussi parler de la gestion d’un nom de domaine histoire de pouvoir taper autre chose que des IP pour accéder à son service. Ou encore du problème d’hairpinning qui empêche sur certaines configurations d’accéder aux ressources internes d’un réseau à partir de son adresse externe si on est à l’intérieur du réseau.

Bref, on n’a pas le cul sorti des ronces… Parce qu’on n’a même pas commencé à effleurer le problème en fait…

Un nécessaire besoin de compétences et de connaissances

Une fois qu’on aura le bagage nécessaire pour comprendre l’environnement dans lequel va évoluer son service (notions de TCP, DNS…), il va falloir maintenant comprendre comment interagir correctement avec lui (qui doit communiquer avec qui, comment et pourquoi). Comment emboîter toutes les briques pour que tout fonctionne. Comment debugger en cas de problème (et les problèmes dans le monde réseau sont toujours très difficiles à cerner). Y intégrer des notions de sécurité, de mises-à-jour régulières, etc.

Bref, sans compétence, ça va être difficile et complexe. Très.

Prenons un exemple « simple ». Il existe un outil, ZMap, capable de scanner tout Internet (en fait tout IPv4) en quelques heures. Oui, vous avez bien lu. Tout Internet. J’ai déjà joué avec pour lister les serveurs VNC accessibles par exemple. Des chercheurs font tourner cet outil en permanence pour analyser comment Internet est construit. Et ont même créé des outils très accessibles pour rechercher parmi les données récoltées, comme Censys ou Shodan. Le rapport avec la choucroute me direz-vous ? Et bien qu’il devient très facile de lister les instances YunoHost publiques, ou celles de OwnCloud, de NextCloud ou de CozyCloud. En cas de faille de sécurité sur une de ces solutions, il se pose alors deux problèmes :

Comment éviter ces problèmes ? Facile ! Très facile même. Ne pas apparaître dans Shodan et associés. Comment fait-on en pratique ? Oups… Vous êtes bien assis ? C’est parti !

Il « suffit » d’avoir un hôte virtuel par défaut qui n’indique rien de ce qui tourne réellement sur la machine. Ainsi, quand ZMap va passer et vu qu’il ne se base que sur l’IP de la machine visée, il va tomber sur une page sans information utile. Il faut aussi penser à lui assigner un certificat X.509 neutre, puisque si vous y mettez un certificat avec tous les autres domaines de votre machine (par exemple via du SAN), ZMap utilisera ces informations pour refaire des connexions réseaux correctes et lister les services qui tournent. Du coup, il vous faudra aussi un nom de domaine donc, puisque l’accès par votre IP directe ne mènera à rien. Donc mettre la main dans le DNS, au moins via votre bureau d’enregistrement. Du coup, cela nécessite aussi que l’installeur de votre solution ne soit plus 100% automatique, mais vous pose quelques questions pour pouvoir se configurer, au pif pour connaître votre nom de domaine. Mais alors, comment je fais pour me connecter à l’installeur à la première utilisation ? Zut, il va falloir que je trouve l’adresse IP qui va être assignée par la box. Donc trouver l’interface de gestion fournie par le FAI, comprendre où est le nouveau matériel pour enfin pouvoir s’y rendre via son navigateur web et enfin pouvoir configurer son service.

On récapitule ? Pour corriger ce simple problème qui relève des bonnes pratiques courantes pour un administrateur système, pour un utilisateur lambda il va falloir savoir acquérir un certificat X.509 correct (ce qui est un parcours du combattant à lui tout seul…), maîtriser sa box Internet et son interface d’administration pour trouver l’IP de départ du service et ouvrir les ports nécessaires, savoir répondre à la question « Quelle adresse IP libre de votre réseau souhaitez-vous assigner à votre service ? », trouver l’adresse IP publique de sa connexion (en espérant qu’elle soit statique et non dynamique…), savoir acquérir un nom de domaine, configurer son nom de domaine pour l’associer à l’IP publique, pour enfin avoir son service opérationnel… Et tout ça n’est absolument pas automatisable, puisque dépendant de bouzillions de contextes différents (OVH, Free ou Bouygues en FAI ? Let’s Encrypt ou Gandi pour X.509 ? OVH, Gandi ou Online pour votre nom de domaine ?).

Et en cherchant à simplifier le processus, on le complexifie encore plus… Exemple ? On simplifie la vie de l’utilisateur en installant ZeroConf pour éviter qu’il n’ait à chercher le service via l’interface de sa box mais directement en tapant mon-service.local. Problème ? ZeroConf se retrouve exposé sur Internet…

mDNS
mDNS ouvert sur un YunoHost

Et du coup l’installeur devrait en plus réclamer que l’utilisateur soit en mesure de lui indiquer le sous-réseau et le masque de réseau utilisé par le réseau local histoire de mettre un bon pare-feu devant tout ça, ce qui nécessite encore plus de compétences par l’utilisateur…

Bilan : ce n’est pas de la mauvaise volonté si c’est compliqué de proposer un service en auto-hébergement, c’est réellement compliqué. Même pour ceux dont c’est le métier, il n’existe aucune recette de cuisine à dérouler pour obtenir le résultat souhaité. Il faut avoir des connaissances minimal en réseau, savoir réfléchir, prendre des décisions, tester, improviser…

Quelles stratégies d’hébergement adopter ?

Pour traiter cette complexité, on a vu apparaître plusieurs stratégies autour de l’hébergement d’un service :

Chacun possède ses avantages et ses inconvénients.

Prestation de service : plus de prise de tête, mais plus de liberté non plus…

Pour la prestation de service, ce mode a transféré toute la complexité précédente au niveau de votre prestataire, puisque plus rien n’est réellement chez vous et que vous ne faites que consommer des ressources externes (généralement web) situées sur son propre réseau, qu’il maîtrise pour le coup à 100%.

Vous êtes par contre très dépendant de votre prestataire, qui va souvent vous voler vos libertés au passage (difficulté de sortie, logiciel privateur…). Vous avez peu sinon pas de prise sur ses décisions et son infrastructure. Où sont vos données ? Quid si ses CGU/CGV changent du tout au tout du jour au lendemain ?

Le boulot est fait et même plutôt bien fait, sans que vous n’ayez besoin de mettre les mains dans la technique à un moment, mais en échange vous avez perdu votre âme…

Objets connectés : fuyez pauvres fous !

Sauf très très rares solutions (comme Lima a priori), les choix techniques des objets connectés sont très criticables. En fait, il n’y a aucune prise en compte des difficultés présentées, qui sont juste contournées le plus salement possible…

Les problèmes de réseau sont « réglés » en faisant tout sortir sur Internet via un « cloud » géré par votre prestataire. Par exemple dans le cas d’une caméra connectée, vous ne vous connecterez jamais directement à elle, mais elle au « cloud » du fabriquant (le NAT ou le réseau ne pose pas de problème pour les flux de sortie) et vous aussi.

La sécurité y est trop souvent inexistante et les mises-à-jour fabriquant impossibles (matériel pas pensé pour). Vous avez donc un truc pas cher, plug & forget (branchez & oubliez), mais une catastrophe en terme de bonnes pratiques. C’est ce qui a conduit à la création de botnets géants tel que Mirai. Ce qui donne ça et ça en pratique…

L’auto-hébergement : accompagnement nécessaire et ne passe pas l’échelle

Héberger ses services sur ses propres machines, on l’a vu, c’est (très) compliqué si on souhaite faire les choses proprement et ne pas devenir un danger pour les autres machines du réseau. Cela nécessite de solides compétences pour parvenir à un résultat acceptable qui ne transformera pas votre service en Mirai 2.0 à plus ou moins long terme.

Les solutions actuelles (YunoHost, CozyCloud, Own/NextCloud, La Brique Internet…) tentent de faire du mieux qu’elles peuvent pour fournir des images simples à installer. Mais le manque de compétence côté utilisateur associé à la complexité de l’environnement d’accueil font que malheureusement, ces images sont souvent perfectibles en termes de bonnes pratiques et de sécurité.

Ces lacunes techniques, induites par l’impossibilité de réclamer un master en informatique aux utilisateurs, sont compensées par un accompagnement et une sensibilisation des utilisateurs à la problématique de l’auto-hébergement et aux devoirs et risques associés. Vous ne repartez jamais réellement seul avec votre Brique Internet, vous pouvez compter sur la communauté de Franciliens ou de FDN en cas de problème. Idem sur les autres solutions, les forums de support sont là pour aider les utilisateurs.

Malheureusement, l’auto-hébergement ne passerait pas l’échelle.

Niveau sécurité, les lacunes techniques constatées sont peu dangereuses parce qu’il n’y a que peu d’utilisateurs en réalité. Même si une faille était constatée, les machines infectées ne se compteraient que par dizaines ou centaines, et non par centaines de milliers comme pour les CCTV de Mirai. Il en serait certainement autrement si on comptait des millions d’utilisateurs de Brique Internet ou de CozyCloud auto-hébergé.

Pour la sensibilisation, on peut se permettre de prendre du temps pour les utilisateurs parce qu’on en forme 10 ou 20 sur un week-end. On ne pourrait très clairement pas tenir la cadence s’il fallait en gérer 1 000 ou 10 000 par jour.

Bref, l’auto-hébergement ne tient la route que parce qu’il reste anecdotique. S’il prenait de l’ampleur, on finirait très rapidement par finir dans la catégorie « IoT », avec des milliers de bidules oubliés dans un coin à la merci du premier botnet qui passe. Pour démocratiser l’auto-hébergement, il faudra donc obligatoirement passer par une formation plus que poussée des utilisateurs.

Les CHATONS : la solution idéale, mais des choses à inventer

Sur l’hébergement communautaire à la CHATONS, la complexité est gérée par ceux qui savent la gérer : les administrateurs système. L’informatique a l’énorme avantage qu’il suffit de peu de personnes compétentes pour gérer des services pour beaucoup de monde. Via une association et des bénévoles, on peut donc proposer des services à grande échelle (1 000 à 10 000 personnes), gérés par quelques techniciens, sans pour autant tomber dans les travers précédents.

La charte des CHATONS empèche l’enfermement, vous pouvez facilement passer d’un CHATON à un autre (même si parfois le travail est toujours en cours pour y parvenir). La même charte impose la transparence, ce qui permet de contrôler ce qui est fait de vos données et l’orientation générale du projet est décidée collégialement. Le risque de dérive ou de perte de liberté sont donc plus que minimes.

Ça semble être une solution idyllique, pourtant ce nouveau type de projet va devoir innover dans plusieurs domaines pour être réellement intéressant à long terme.

Il est fort peu probable que tous les CHATONS se mettent à proposer l’ensemble de tous les services existants sur la planète. Les ressources techniques ou financières nécessaires calmeront rapidement les ardeurs. Les CHATONS vont du coup entrer en compétition les uns avec les autres, et de plusieurs manières.

Un utilisateur aura naturellement tendance à aller vers les CHATONS proposant le plus de services possibles, ne serait-ce que pour réduire le coût global (beaucoup de chatons risquent de ne pas être gratuits) ou la « paperasse » nécessaire (comptes à gérer, adhésions…). Ce qui risque de tuer dans l’œuf les petites solutions avec peu de moyens, à l’avantage des gros, en plus de recréer des silos de données. Ce problème existe déjà dans le domaine de la presse en ligne : on ira plutôt s’abonner chez un ou deux journaux généralistes (le Monde, Next Inpact, Mediapart…), plutôt que chez de multiples petits journaux spécialisés. Par définition les CHATONS vont devoir se limiter en nombre d’utilisateurs pour ne pas devenir un nouveau Google, les conflits et frustrations n’en seront que plus violents (un service généraliste allant rapidement saturer, il ne laissera que le choix de services spécialisés).

Un utilisateur risque aussi d’être fort peu content d’avoir à payer plusieurs fois un même service auprès de CHATONS différents, juste parce que chacun propose un service spécial. Et en plus d’avoir à payer pour des services qu’il n’utilise pas ! Si par exemple je souhaite un service de courriel, un de pad, un de stockage et un de calendrier, mais que les seules offres disponibles sont « courriel + pad », « pad + stockage » et « courriel + calendrier + voip », je vais devoir m’abonner à tous ces services, me retrouver avec un doublon sur le pad et le courriel et un service de voip dont je n’ai pas besoin… En pratique, on risque même de se heurter à des limitations financières et donc à des utilisateurs se restreignant sur les services parce qu’ils n’ont pas les moyens de tout payer, tout comme beaucoup doivent aujourd’hui se retreindre à certains médias en ligne. Niveau frustration, ça risque donc d’être assez rigolo.

Côté opérateurs de CHATONS, il risque aussi d’y avoir des stratégies bizarres. Les services les plus utilisés au quotidien (pad, sondage…) sont aussi généralement les moins onéreux et complexes à mettre en œuvre alors qu’ils vont être considérés comme à forte plus-value par les utilisateurs. À l’inverse, les services pourtant utilisés plus ponctuellement dans la tête des utilisateurs (hébergement de vidéo, voip, minecraft…) sont des services extrêmement complexes à gérer et coûtant vraiment très cher en permanence (ce n’est pas parce que vous ne regardez pas une vidéo HD qu’il ne faut pas stocker ses 4Go quelque part tout le temps). On risque donc de se retrouver avec des services très rentables d’un côté avec quasiment tout le monde qui les propose, et des services clairement difficiles à rentabiliser proposés par peu de monde.

Sans grand gourou pour réguler un peu tout ça et mettre en place des vases communicants en particulier financiers (à-la-FFDN), la loi de la jungle risque d’être rapidement la règle.

(Merci à Framasky et Regar42 pour la relecture ! ❤️️)

Bienveillant et safe ? Mon cul !

vendredi 26 mai 2017 à 00:00

Ce post de blog pour exprimer mon sentiment de manière plus posée et réfléchie sur ce qui a pu se passer sur Mastodon et l’affaire « witches.town ». Vous en penserez ce que vous voudrez, et si vous voulez me considérer comme la pire raclure de l’Univers suite à ça, c’est votre droit, et je pense qu’on n’aurait du coup rien en commun à partager, donc autant s’éviter.

De l’affaire Mastodon

Tout a commencé quand un utilisateur de l’instance witches.town, une instance se réclamant « bienveillante, safe et inclusive », est venu me voir parce qu’il ne recevait plus mes notifications alors qu’il était pourtant abonné à mon profil au départ.
Après avoir éliminé les causes techniques, on en est arrivé à la conclusion que mon compte était tout simplement complètement bloqué au niveau de l’instance par un des administrateurs. Plus personne là-bas n’était en mesure de recevoir mon contenu et pourtant le ban n’était a priori pas connu, tout du moins pas par tout le monde.
J’ai donc demandé à ce que ce ban soit documenté, afin qu’un nouvel arrivant sur Mastodon puisse choisir son instance de manière éclairée et ne puisse pas regretter par la suite d’avoir choisi une instance qui ne lui corresponde pas.
Cela correspond en particulier à la position que je porte depuis les premiers jours de Mastodon : les administrateurs d’instances ont de grands pouvoirs, donc de grandes responsabilités, ils peuvent y faire ce qu’ils veulent, mais ils ne doivent pas prendre en traître les utilisateurs et donc avoir des politiques de modération ou de censure très claires, publiques, correctement appliquées, de manière impartiale, etc.
J’ai donc contesté non pas le ban lui-même (l’administratrice fait ce qu’elle veut sur son instance), mais la manière de gérer le ban (les administrateur·ices devraient, pour moi, avoir des comptes à rendre au fediverse).

L’administratrice a alors tenu des propos diffamants à mon encontre, m’accusant d’incitation au viol et à la séquestration et d’anti-féminisme, ce qui je le rappelle sont des propos diffamatoires, donc pénalement répréhensibles, alors qu’elle est incapable de fournir le moindre pouet d’origine justifiant de ces faits ou du blocage, ne fournissant que de vagues souvenirs ou autres téléphones arabes. Un simple motif neutre, du style « publie du porn sans CW sur le flux public, en désaccord des règles de cette instance » aurait été suffisant et plus que bienvenu à la place de cette floppée d’injures.
Pire, les seuls threads qui ont été soumis correspondent à une conversation entre adultes consentants avec effectivement du contenu porn ou BDSM, mais correctement labellisé NSFW comme il est de bon ton de le faire sur Mastodon. Thread dont je ne suis même pas l’initiateur mais où j’ai seulement répondu dans le fil. Le seul tord serait donc d’avoir atterri dans le flux public…
Et personne d’autre de ce thread n’a été banni sur witches.town, tout comme de nombreux autres threads du même genre qui fleurissent régulièrement sur le flux public. Il s’agit donc purement et simplement d’un blocage à la tête du client, sur des motifs fallacieux, et uniquement parce que l’administratrice de l’instance m’en veut personnellement, en violation parfaite des règles même de l’instance. Et ce jusqu’à preuve du contraire.

Si un message bien précis avait pu m’être fourni, j’aurais bien entendu cherché à comprendre le malentendu blessant, à l’éviter à l’avenir, et me serait empressé de m’excuser auprès des personnes que j’aurais blessées.

À la limite, ça aurait pu en rester là. Mais non.

Étant dorénavant classé « pire raclûre de l’univers » un peu partout sur le fediverse, forcément, j’ai eu le droit aux tombereaux de shitstorm habituels à me tomber sur le coin du crâne. Bizarrement les mêmes que si vous remplacez « forum 18-25 » par « instances bienveillantes & safes » et « féministes » par « gens hors des communautés pré-citées ». Mastodon est présentement en train de recréer exactement les mêmes conditions malsaines qu’on a pu décrier sur Twitter, simplement en translatant le problème d’un cran (les non-bienveillants Twitter ne sont plus là, remplacés par les revendiqués « bienveillants », eux-mêmes remplacés par ceux en dehors de ces communautés).
Et forcément dans des conditions comme ça, chacun campe sur ses positions et même si 500 caractères sont mieux que 140, la brièveté des messages n’aide pas à faire passer un message intelligible et les prises de raccourcis sont toujours fatales dans ces moments-là.
Sauf que voilà, j’ai une grande gueule. Et c’est un défaut que j’assume, celui-là, même si j’aimerais bien le corriger…

Ça s’est quand même terminé par recevoir des menaces de me dégommer les genoux à coup de 9mm de la part d’administrateur d’instance « safe & bienveillante »…

Des communautés « safe & bienveillante » ni safes ni bienveillantes

Je vais du coup profiter de ce post pour aborder un sujet qui me tient à cœur depuis pas mal de temps, les communautés « safe ». Histoire d’éclairer un peu les gens sur ce qu’il peut bien s’y passer, malgré la devanture « bienveillante » affichée.

Cette communauté « bienveillante » donc, qui te fout plus bas que terre dès que tu t’opposes à elle au motif que tu n’es pas « bienveillant », a aussi la mémoire très courte.

La pire râclure de l’univers, incitant au viol et à la séquestration et anti-féministe harcelant la communauté queer, c’est la seule personne qui a pris sa bagnole à 23h pour traverser toute l’Île-de-France en urgence et passé un bon paquet d’heures à déménager une trans qui venait de se faire foutre à la porte de chez elle. Personne que je ne connaissais ni d’Ève ni d’Adam mais dont j’ai juste vu le message d’appel à l’aide sur Twitter. Et qui avait été lâchée par tout le reste de sa communauté « safe & bienveillante ».
La même trans qui quelques semaines plus tard, me fera juste un gros remerciement sur Twitter en me traitant de « sale propriétaire exploitant les pauvres locataires » quand j’ai osé mentionner que je venais d’acheter un appart. Et qui m’a bloqué dans la foulée.
La même trans qui me conchie encore aujourd’hui dessus sur l’instance witches.town. Et qui s’est bien gardé d’expliquer à cette communauté ce que j’avais pu faire pour elle.

La pire râclure de l’univers, qui accompagne une personne de la communauté LGBTQIIAP+ agoraphobe à aller s’approvisionner dans des sex shops parce qu’elle ne peut pas y aller seule, et qui passe ensuite l’après-midi avec elle histoire de lui changer un peu les idées. Mais qui se fait traîter d’harceleur de la communauté queer en retour.
La pire râclure de l’univers, qui ne compte plus non plus les heures à discuter avec des gens qui ne demandaient que du soutien et de l’aide.

Donc a priori, aider sa·on prochain·e sans se poser une seule question, ce n’est ni safe ni bienveillant, par contre cracher à la gueule de la seule personne qui réponde présent jour et nuit y compris pour un·e parfait·e inconnu·e à 100km de chez lui, ça c’est très safe et très bienveillant, et même encouragé par la communauté safe et bienveillante.
Sauf que oui, ce que je fais pour aider les autres, ça n’est pas visible sur mon front. Je ne l’étale pas sur la place publique et bien peu de personnes sont au courant de tout ça. Et donc on préfère considérer les gens comme la pire des enflures par défaut, plutôt que d’envisager qu’en fait, ils ont peut-être fait bien plus que vous.

J’ai en plus le bon goût d’avoir une histoire personnelle plus que très compliquée. Même en raccourci, j’en aurais pour un bouquin entier à vous raconter tout ce qui m’est arrivé depuis 33 ans. Et c’est plus que possible que vous en pensiez que je suis complètement taré et que j’affabule tellement c’est pas possible qu’une seule personne puisse avoir traversé tout ça.
Pour juste vous donner un petit aperçu. Je suis né avec une malformation congénitale, qui m’a valu de connaître le harcèlement scolaire (moral et physique, sinon ce n’est pas drôle) pendant plus de 15 ans, les balades hospitalières à répétition, les joies du handicap, du fauteuil roulant, des opérations chirurgicales très lourdes, des mois de ré-éducation. J’ai été bouffé par un berger allemand qui fait que j’ai encore aujourd’hui une peur panique des chiens. Mon père a failli perdre la vue, et à peine remis, se prend un cancer de la peau fulgurant avec une espérance de vie qui se compte en jour. Mais survit à tout ça, histoire de bien pouvoir profiter de son licenciement avec 3 gamins et une femme sans emploi. Et puis de découvrir que mon frère est en fait bipolaire et schyzophrène, ça change un peu des maladies physiques. Ma mère passe encore actuellement des mois en hospitalisation pour sauver ses 2 bras d’une maladie professionnelle. Et puis on va finir en beauté avec l’assassinat de mon frère en pleine rue de 13 coups de couteaux. Parce que sinon c’est pas marrant. Et du coup ma mère fait des crises de fibromyalgie atroces à cause de tout ça. Et là ce n’est qu’un très petit aperçu hein…
Tout ça pour dire que le harcèlement, les traumatismes et autres, j’ai suffisamment donné pour ne le souhaiter à personne d’autre et que je suis bien la dernière personne sur Terre à vouloir du mal aux gens. Même au meurtrier de mon frère, j’ai pardonné, c’est dire…
Et comme pour les bonnes actions, tout ce passif n’est pas non plus tatoué sur mon front ni connu de beaucoup de monde. Et donc parce que je suis un cadre supérieur sans problème apparent, c’est que j’ai du avoir une histoire bien facile et plane pour en arriver jusque là.

Mais en fait, tout ça, les communautés « safe & bienveillantes », elles s’en tamponnent le coquillon. Parce qu’elles oublient de dire un truc : elles ne sont « safe & bienveillantes » qu’envers leurs propres causes. Tu es LGBTQIIAP+ ? On va être bien safe avec toi. Tu ne l’es pas ? Va creuver sale pourriture de capitaliste communiste ! J’vais même t’aider avec un gros coup de grôle dans ta face tient. Pour mériter leur protection, il faut te faire tatouer ta gender unicorn sur le front, passer un entretien d’entrée, voir l’ensemble de ta vie exposée à des gens qui vont unilatéralement décider si tu mérites ou non cette protection. Bref des gens pas bienveillants du tout quoi.

En prime, guess what ? Ben ma gender unicorn à moi, elle n’est pas « normale ». Vraiment pas. J’ai même bien du mal à la définir moi-même tellement elle est bordélique. Sauf que ce n’est pas écris sur mon front justement. Ni connu par la majorité du grand public. Je suis même sur des trucs qui seraient plus dans le « + » que dans « LGBTQIIAP ».
Et donc je me retrouve conchié à la fois par la communauté standard, qui me considère « anormal », et par la communauté « bienveillante » qui me considère comme « normal ». On va te refuser l’entrée d’une safe-zone, parce que forcément, tu paraîs très HBVCH (homme-blanc-valide-cis-hétéro), donc tu n’as rien à y faire et que tu es forcément à l’abri avec les « autres » HBVCH. On va bien te rappeler, sur un ton loin d’être bienveillant, qu’en tant que sale HBVCH, t’as intérêt à te tenir à carreau si tu viens dans un lieu alternatif, chose qu’on ne rappelera jamais à un LGBTQIIAP+ affiché. Et puis c’est bien entendu interdit de se moquer des LGBTQIIAP+ sous peine d’exclusion, mais la vache, qu’est-ce que ça va tailler les HBVCH en permanence. Je ne sais pas, ce n’est pas parce qu’on n’est pas dans les mêmes groupes qu’on est obligé d’être ennemis et de se chier dessus en permanence ? Et enfin, quand tu signales que la discussion est en train de partir vers un terrain glissant psychologiquement pour toi (du genre te rappeler la disparition de ton frangin), tout le monde va bien exploser de rire que « non mais ça va hein, tu vas pas te plaindre non plus, tu veux qu’on te parle de ce que c’est le trauma trans peut-être ? ».

Les communautés « safe » sont tellement pas safe qu’en 2016, une conférence sur le sujet aurait du être tenue à PSES, mais les conférencier·ères ont préféré se rétracter par peur des représailles de la part des-dites communautés. C’est vous dire un peu le niveau de bienveillance qu’on peut y trouver. Elles ne sont finalement qu’un ghetto communautariste ne tolérant aucune idée différente de celles imposées par la bien-pensée de plomb qui s’y trouve.

« Que faut-il pour XXX ? » « Du logiciel libre ! » Non, une gouvernance éthique !

mardi 21 février 2017 à 00:00

Ce billet risque d’en surprendre plus d’un. Et pourtant.

Je commence à être légèrement saoulé d’entendre certains brandir le logiciel libre comme la solution à la plupart des maux de la terre, de la libération de l’Éducation Nationale à la priorité dans l’administration en passant par la protection de la vie privée, le retour de l’être aimé et la guérison du cancer. Et en particulier durant les cafés-vie-privée.

Je suis pourtant un fervent défenseur du logiciel libre, mais je pense qu’il va aussi être temps de se mettre au goût du jour. Nous ne sommes plus en 1980 avec les problèmes d’imprimante de rms, les problématiques ont beaucoup évolué alors que le discours autour du Libre non.

Le Logiciel Libre a gagné.

Oui, le Logiciel Libre a gagné. Je pense que personne ne dira le contraire.

Certes, sa victoire ne se mesure pas à son taux de pénétration sur le marché de l’OS pour ordinateur personnel où GNU/Linux, *BSD et compagnie peinent à décoller du 1% de parts de marché. Mais aujourd’hui, on entend parler du Logiciel Libre partout. Certes souvent sous sa forme « open-source » utilisé pour mieux vendre son produit et sans réelle volonté éthique derrière, mais quand même.

Bref, le Libre, il y en a partout, et ça devient dorénavant difficile de faire sans.

Il reste effectivement quelques points durs qui limitent la diffusion du Libre, comme la grosse problématique de la vente forcée ou l’impossibilité d’avoir accès à des pilotes libres pour le matériel courant.

Mais on a oublié de regarder autour de nous.

Alors qu’on se battait becs et ongles sur le plan juridique pour justement faire tomber ces points handicapants, ou à diffuser nos outils et idées de 1980, le monde lui, a continué à se transformer.

On n’est jamais sortis du problème de la vente forcée sur PC et on se retrouve encore aujourd’hui à épuiser toutes nos forces sur ce sujet quand tout le monde ne jure plus que par les tablettes ou les téléphones intelligents, qui représentent aujourd’hui plus de 50% des ventes, en progression constante depuis une décennie. Et donc même si on arrivait à obtenir la mise à mort de la vente forcée d’ici 5 ou 10 ans, les seules personnes réellement touchées seraient les 2 ou 3 geeks dans un garage qui continuent à acheter des PC (et qui en plus ont à disposition de plus en plus d’alternatives, même en grande distribution). Et qu’il faudra aller se battre encore plus durement pour obtenir la même chose pour nos smartphones ou tablettes, problème qui sera ô combien plus difficile puisque ne concernant plus uniquement du logiciel mais aussi du matériel.

On en est encore à s’arracher la tête en permanence pour obtenir une priorité au logiciel libre pour notre administration, nos écoles ou notre armée. Alors que le « cloud » est en train de tout grignoter au grand galop. Et que le jour où la priorité sera actée, on ouvrira les yeux pour découvrir que tout ce petit monde tourne sur des versions « cloudisées » de LibreOffice ou Microsoft Office, et que l’un ou l’autre pose les mêmes problèmes d’enfermement dans ce mode de fonctionnement. Voire que Microsoft aura lancé une offre à base de LibreOffice Online d’ici-là pour contrer une éventuelle loi sur le sujet et ainsi pouvoir continuer à voler remporter tous les marchés publics et à siphonner les données personnelles de ses utilisateurs tout en faisant de l’évasion fiscale massive.

On continue à se faire mal avec nos outils « desktop » du siècle passé alors que 90% de la population utilise totalement autre chose, entre les applications mobiles, les applications web, le « cloud », ou a besoin de mobilité, de la gestion des machines multiples, de synchronisation… Même moi qui cherche à fuir cette « hype » du moment, je suis bien content de trouver un LastPass intégré à mon navigateur, multi-machines et multi-profils plutôt qu’un veillissant KeepassX resté bloqué au monde de la mono-machine de bureau et non-web…

Et du coup on a tout perdu.

On se retrouve aujourd’hui avec du libre partout mais pourtant de la liberté nulle part.

Nos données sont dans des silos de données type Facebook ou Google. Stockées physiquement dans des outils libres (Cassandra initié par Facebook) ou basés exclusivement sur du libre (GoogleFS), mais gérés par des entités totalement opaques.

Android, pourtant un projet 100% libre est devenu le premier violeur de notre liberté individuelle et de notre vie privée, via à la fois les composants non libres des versions commerciales (Google Services) mais aussi la saleté des applications (y compris libres) installées par la plupart des utilisateurs.

Amazon, proposant en très grande majorité du GNU/Linux à ses clients et possédant une infrastructure interne quasiment exclusivement libre, représente actuellement plus de 31% de parts de marché du secteur, nécessitant même que l’IETF revoie un des protocoles les plus anciens d’Internet (RFC7626 & RFC7816) afin de protéger la vie privée des internautes.

Les gens écoutent de la musique sur SoundCloud, regardent des vidéos sur NetFlix, stockent leurs données sur DropBox ou leurs vidéos sur Youtube. Et devinez quoi ? Ces outils pourraient être libres que l’utilisateur n’y gagnerait pas grand-chose. Ils n’ont ni les compétences ni les moyens financiers ou matériels de remonter l’équivalent chez eux.
Des objets connectés, basés exclusivement sous GNU/Linux, sont déployés par milliards sur le réseau. Et devinez quoi ? Ça ne protège en rien ses utilisateurs.

Le Logiciel Libre n’apporte finalement plus grand chose.

On brandit en permanence le logiciel libre à bout de bras comme étant THE solution, le Graal, la balle en argent ou le marteau doré. Alors que cette propriété n’apporte en réalité plus aucune protection.

Dans les nouveaux usages d’Internet du web, peu d’utilisateurs seront capables de se lancer dans l’auto-hébergement. Parce que c’est compliqué (ça sera l’objet du billet suivant d’ailleurs) si on ne veut juste pas préparer le futur Mirai. Parce que les usages modernes demandent de « l’intelligence artificielle » qu’on ne pourra pas remonter à la maison (stockage, puissance de calcul…) ou qui sera quasiment sans intérêt si la « big data » n’est faite que sur un seul utilisateur.

La fameuse poupée espionne, même en 100% libre risque fort de nécessiter un serveur central pour fonctionner correctement. Et même si un utilisateur propose un patch pour sécuriser la ligne, il ne sera pas intégrable avant que la société qui la commercialise ne se décide à sécuriser sa propre infrastructure et à modifier aussi son API et son back-office.

Ou tout simplement parce que les systèmes deviennent tellement complexes que les seules personnes à même d’en monter un correctement sont administrateurs systèmes.

Et c’est là bien tout le problème… L’intelligence s’est massivement déplacée de la périphérie vers le centre du réseau. On le déplore tous et ça a des conséquences dramatiques à l’heure actuelle (neutralité du net, silo de données, vie privée…). C’est certes un état de fait et même si on peut regarder à long terme et se battre pour faire changer la chose, il est aussi important de prendre des actions à plus court terme pour protéger les utilisateurs actuels.

Et malheureusement, le logiciel libre n’a plus d’effet à ce niveau.

Mozilla, pourtant logiciel 100% libre (ou presque), repose sur des logiciels côté serveurs, par exemple pour la gestion des extensions disponibles, qui eux ne sont pas nécessairement libres. Et même s’ils l’étaient, ils échappent totalement à l’emprise de l’utilisateur final. Et ça peut du coup donner ceci :

Mozilla
Google Analytics sur Firefox

J’ai beau être développeur, savoir modifier et recompiler Firefox, je ne peux pas empêcher Mozilla d’embarquer Google Analytics sur ses serveurs… J’ai pu trouver une parade via µMatrix (du coup attention, trackers violeurs de vie privée !), certainement pas parce que Firefox était libre.

À l’inverse, Qwant, logiciel pourtant privateur (bien que libérant beaucoup de morceaux), respecte ma vie privée. Idem pour ProtonMail, qui n’est pas non plus libre (mais publie aussi beaucoup).

Le Logiciel Libre est mort. Vive la Gouvernance Éthique.

Le détail qui fait la différence ? La gouvernance et la confiance. Certainement pas la licence libre du logiciel.

J’ai confiance en Qwant parce que des gens bien y travaillent. J’ai confiance en ProtonMail parce que les morceaux qu’ils publient me semblent corrects, même si je n’ai absolument aucune preuve que c’est exactement ceux qui tournent sur leur production. J’ai confiance en Mailden parce que quand tu leur tapes dessus à leur lancement, ils viennent t’expliquer leur infra autour d’une fondue.

En fait avec les infrastructures modernes, les libertés d’étudier et de modifier ne sont plus réellement possibles. Parce que personne de sensé ne vous donnera les clefs de sa baie et son mot de passe root pour que vous puissiez aller voir ce qui tourne réellement dans son système. Et vous autorisera encore moins à y faire des modifications.

La gouvernance des projets devient alors la clef.

La naissance du projet CHATONS, même s’il impose pour le coup du logiciel libre dans sa charte, en est une belle illustration. La transparence de qu’est-ce qu’on fait réellement, comment ça tourne, qui a accès, où sont les données, comment on se fait mal pour se débarrasser des GAFAM partout.

La gouvernance devient le véritable enjeu du XXIe siècle.

L’usage imposé de logiciels libres dans la charte des CHATONS y est finalement plutôt anecdotique puisque d’une part le libre s’est plus qu’imposé dans le monde du serveur et donc va de soi et d’autre part des entités qui auraient utilisé du logiciel privateur n’auraient pas été plus problématiques que ça, le logiciel libre simplifiant « uniquement » la portabilité ou l’interopérabilité, un logiciel privateur pourrait les permettre aussi.

Hormis dans le contexte des OS pour PC ou des applications lourdes, qui est un contexte du passé, le Logiciel Libre n’est plus ni une condition nécessaire (Qwant) ni une condition suffisante (Mozilla) pour respecter les libertés de l’utilisateur. Dans le monde moderne de la mobilité et des applications légères, c’est la Gouvernance Éthique qui devient ce facteur nécessaire et suffisant.

La bataille pour la Gouvernance Éthique sera bien plus difficile à remporter.

Le problème de la Gouvernance Éthique est que contrairement au Logiciel Libre, elle n’est pas un avantage pour ceux qui souhaiteraient s’y mettre. Au contraire.

Le Logiciel Libre peut être gratuit, fait faire des économies d’échelle via l’absence de coûts d’entrée ou récurrents (achats de licence), permettant à de petites structures de se lancer sur le marché à égalité avec les grosses.
La Gouvernance Éthique, elle, sera un caillou permanent dans votre chaussure par rapport à la concurrence ayant moins de scrupules que vous.

Déjà, en termes d’infrastructure.
Vous ne pouvez plus avoir en 3 clics un système de statistique comme Google Analytics, il va vous falloir gérer un Piwik. Vous ne pourrez plus gérer vos retours d’erreur via New Relic, il va aussi falloir investir dans du Sentry. Finies les joies de claquer des doigts pour héberger tout ça via EC2, il va falloir gérer votre propre ferme OpenStack sur des machines physiques vous appartenant. C’était bien pratique le stockage S3, pas de bol, il va vous falloir monter un cluster Ceph. Vous pouvez aussi dire adieu aux Google Fonts, à l’usage des CDN, vos sauvegardes vont devenir un enfer, votre « big data » ou votre « intelligence artificielle » aussi.

Pour les fonctionnalités, vous allez aussi bien patauger.
La portabilité des données ou l’intéropérabilité par exemple. L’usage du Logiciel Libre vous garantit une certaine intéropérabilité pour un format donné, mais hormis les usages bureautiques personnels du passé, ils ne garantissent aucunement la portabilité. Une instance GNU/Social complète se transporte « facilement » d’une machine à une autre, mais en sortir un utilisateur particulier pour faire une migration vers une autre instance ne va pas être une sinécure… Cozy a le même souci. Chaque composant libre est techniquement intéropérable, mais l’ensemble (même libre) ne l’est pas nativement et on doit investir dans des développements coûteux pour le mettre en place.

Enfin votre modèle commercial s’oppose à la tendance moderne du tout gratuit.
Les points précédents font que vous aurez en plus du mal à trouver un tarif viable, celui-ci allant être tiré vers le haut par les challenges à remporter mais vers le bas pour être compétitif face à la concurrence. Sans parler qu’une personne lambda n’aura pas les moyens d’investir dans 20 services différents à 3€/mois et donc que la compétition va être rude, y compris entre des projets ne proposant pas du tout les mêmes services…

Tout ça cumulé fait qu’un projet à Gouvernance Éthique sera très certainement plus coûteux et donc moins attractif, en tout cas sur le court/moyen terme, qu’un équivalent sans éthique. Les concurrents peu scrupuleux n’auront pas à utiliser des pratiques illégales comme ils le font actuellement avec le Logiciel Libre (lobbying, marché public truqué, partenariat caché…) pour s’imposer, il leur suffira de présenter légalement une réponse à un appel d’offre donné, réponse qui sera par nature moins chère, avec plus de fonctionnalités et moins de délais… Et donc la Gouvernance Éthique est vouée à l’échec si on ne l’aide pas.

Les solutions comme les CHATONS permettront sûrement de lancer la machine, de montrer qu’une autre voie est possible, mais il faudra des décisions juridiques fortes, comme la GDPR pour rétablir l’équilibre et espérer une adoption réellement massive des solutions éthiques via des offres commerciales (ou non) pérennes qui toucheront bien au-delà du milieu geek et libristes.

Bref, il est plus qu’urgent de faire le bilan du monde actuel pour recentrer nos combats, plutôt que de persister contre la muraille construite il y a 30 ans et qui a fini par nous obséder complètement depuis au moins 10 ans. Pendant que de l’autre côté l’ennemi a conquis tout le reste du monde et ne fera qu’une bouchée de nous le jour où on parviendra enfin à traverser l’enceinte. Parce ce qu’on aura toujours nos bons vieux boucliers quand lui aura fabriqué des armes nucléaires :)

Le Logiciel Libre restera une brique importante d’un écosystème sain, mais ne doit pas occulter tous les problèmes qu’il ne résout pas ou plus. Et ne doit certainement pas être brandi de manière quasi dogmatique, d’autant plus quand il n’est justement pas une réponse adaptée à la question posée.

(Merci à @btreguier et @goofy_fr pour la relecture :))

Docker et la tendance de la conteneurisation : a-t-elle vraiment été en production ?

dimanche 9 octobre 2016 à 00:00

Docker. Une technologie si jeune (2013) et pourtant dorénavant vendue un peu partout comme la technologie miracle qui va résoudre tous les problèmes de déploiement, vous rendre riche et vous ramener l’être aimé.

Et pourtant, en pratique cette technologie me pose pas mal de problèmes et de cas de conscience. Revue de détails.

Objectif : portabilité

Le but initial est un peu dans le prolongement de ce qu’a fait Java : construire une fois, déployer partout (« build once, deploy everywhere »). On ne peut nier que l’idée initiale soit bonne tellement le problème du déploiement est un véritable parcours du combattant en pratique.

Un logiciel est rarement un morceau totalement isolé. Il vient avec son interpréteur, ses bibliothèques, nécessite un moteur de base de données, des fichiers de configuration, un serveur web et tout un tas d’autres choses. Cet écosystème va être à gérer tout au long de la chaîne de fabrication, que ça soit en développement, en phase de validation/qualification, en recette ou encore en production.

Avant Docker, chaque étape nécessitait de remonter l’ensemble de l’environnement, d’y installer le logiciel (parfois à partir des sources via compilation), de le lancer… Et c’était un gros bordel, puisque la moindre déviation entre deux environnements pouvait conduire à des bugs non reproductibles en fonction de l’endroit où l’on lançait le logiciel, d’où l’apparition du trop fameux « Ça marche chez moi ™ ».

Avec Docker, point de tout cela. Les développeurs construisent une image du logiciel qui va contenir tout ce qui lui faut pour fonctionner, depuis l’OS jusqu’au logiciel lui-même en passant par toutes les autres briques. S’ils ont satisfaction de ce qu’ils ont obtenu, ils livreront à l’étape suivante cette image, qui n’aura pas bougé d’un iota et pourra être lancée à l’identique, et ainsi de suite jusqu’à la très attendue mise en production.

Ça c’est la théorie. Maintenant, la pratique :D

Besoins de dev ≠ besoin de la prod

Le premier rempart à l’usage de Docker est que les besoins entre la production et le développement sont assez différents.
Un développeur va vouloir accéder facilement aux journaux, si possible en mode debug, alors que la prod préférera les envoyer à un Logstash et en mode info voire warn ou error. Un développeur préférera utiliser directement le serveur d’application léger de son choix comme Jetty, Thin ou Gunicorn, alors que la production configurera un backend Nginx devant ou utilisera des serveurs d’application plus puissant tel que Tomcat ou Passenger. Un développeur préférera sûrement compiler en mode debug pour avoir des retours utilisables en cas de problème alors que la production insistera pour le faire en mode release. La production voudra mettre en place un pare-feu, ou ses outils de supervision de parc, dont le développement n’a même aucune idée de l’existence puisque ça ne fait pas partie de ses compétences ! J’évite même de parler d’intégrer ses outils de développement à un environnement Docker, par exemple lancer son projet Java présent sur son Eclipse local sur le Tomcat présent sur l’image Docker, ça ferait trop mal.
Bref, en pratique, c’est compliqué… On peut quand même s’en sortir pour certains morceaux, surtout grâce à certaines fonctionnalités de Docker, mais l’intérêt en devient limité.

Pour les environnements différents, il « suffit » que les devs travaillent hors Docker à l’ancienne, puis une fois parvenus à quelque chose de satisfaisant, s’attaquent à la construction d’une image Docker. Ça implique une espèce de mini-chaîne complète (dev/test/validation/qualification/production) faite uniquement par les développeurs, afin de s’assurer que l’image finale est à peu près conforme à ce qui est attendu (quel logiciel fournir, quelles dépendances disponibles…). Parce que du coup ça n’implique plus que si ça tourne sur leur environnement de dev, ça tourne sur l’environnement Docker. Pas forcément très folichon niveau processus sinon avoir ramené toutes les considérations des autres étapes sur celle de développement.

Pour les besoins propres à la production (pare-feu, monitoring…), Docker permet de créer une image à partir d’une autre. La production repartira donc de l’image fournie par les développeurs pour refaire sa propre image incluant tout le nécessaire. Ça casse aussi l’intérêt de Docker qui garantit que ça tournera en production, étant donné que la production peut elle aussi introduire des bugs. Par exemple l’installation d’un pare-feu va peut-être installer une bibliothèque utilisée par l’application mais dans une version différente. La production devra donc aussi repasser une bonne partie des étapes précédentes (test/validation/qualification) avant la mise en production réelle. Pas folichon non plus.

Dans les deux cas il aurait été plus intelligent que le dev et la prod travaillent ensemble dès le départ (qui a dit Devops ?) pour fournir une image Docker à la QA qui partira en production telle quelle une fois approuvée. Mais alors qu’on utilise Docker ou n’importe quelle autre technologie (virtualisation classique, automatisation d’installation via un outil comme Chef, Puppet, Ansible ou Salt) on aurait obtenu le même résultat.

Quid de la sécurité ?

LE gros point noir selon moi.

Docker repose sur le principe d’immuabilité des images. Une fois une image livrée, on n’y touche plus et au prochain changement nécessaire, on refait une image depuis zéro.

Ça pose un problème assez énorme en termes de sécurité. Le jour où vous avez une faille dans le logiciel livré, on comprend bien qu’on n’échappera de toute façon pas à un correctif, une regénération, un passage intégral de toute la chaîne de qualification et une nouvelle mise en production. Mais si c’est une bibliothèque utilisée par le logiciel, par exemple OpenSSL qui connaît au moins une faille critique de sécurité par jour ?

Dans une infrastructure sans Docker, les gentils administrateurs systèmes se seraient sagement connectés en SSH aux machines impactées, auraient simplement fait un apt update && apt upgrade et basta.
Un patch de sécurité n’introduisant pas de changement de fonctionnalités et les développeurs de OpenSSL faisant bien leur travail, ils livrent des versions patchées assurant la rétro-compatibilité avec les versions précédentes. Les admins peuvent donc appliquer le patch assez rapidement sans avoir besoin de consulter les développeurs. Et la faille est rapidement corrigée avec un risque de régression négligeable (qu’on a parfaitement su accepter et maîtriser pendant des décennies, et même Docker ne pourra jamais garantir le 0 bug). En prime, le logiciel final, lui, n’a pas changé de version.

Dans une infrastructure dockerisée, c’est une autre histoire…
Les conteneurs devant être immuables, il est interdit aux administrateurs de se connecter aux machines pour les mettre à jour. Un changement de sécurité sur une bibliothèque réclame donc de redérouler l’intégralité de la chaîne : on met à jour la bibliothèque, on construit une nouvelle image Docker (qui change donc de version), on repasse toute la QA, on met en production. La mise en production nécessite un arrêt de l’ancienne image, la migration des données sur la nouvelle image et le redémarrage du système. Bref, vous allez tourner un long moment avec votre image trouée avant d’avoir pu fixer le problème…

Quand on évoque ce problème avec la communauté Docker, ils avancent alors leur recette miracle : l’intégration continue.
Certes, si vous réussissez à intégrer l’intégralité de la QA (tests unitaires, tests fonctionnels, tests d’intégration, tests de validation, tests de qualification, tests de recette) dans une suite de tests automatiques, c’est peut-être envisageable de faire une modification dans le code, de cliquer sur un bouton et d’avoir automagiquement la nouvelle version en production.
En pratique, on a déjà du mal à atteindre 100% de couverture sur les tests unitaires, et plus on monte dans les étages plus c’est compliqué. Les tests fonctionnels doivent simuler des humains presse-boutons, les tests d’intégration sont un enfer à réaliser vu le nombre de composants en jeu, les tests de qualification sont souvent longs (tests de performance, de tenue de charge…), etc.
Sauf à investir un budget colossal en automatisation de tests, l’intégration continue revient finalement à se restreindre à un sous-ensemble des tests (on se limite aux cas principaux et on laisse tomber les cas dégradés par exemple) et donc à potentiellement laisser passer des bugs lorsque les administrateurs pousseront le bouton « Déployer » après une modification rapide pour fixer une faille de sécurité. Seuls les grands comme Google ou Amazon peuvent se permettre l’outillage de détection d’un problème en production (du test A/B par exemple) et donc d’alléger ou de supprimer toutes les phases de test : on déploie plus ou moins à l’arrache, si ça merde, on revient en arrière immédiatement !

Les plus perspicaces d’entre vous auront noté que tout ce qui précède repose sur une hypothèse très forte : on doit être mainteneur de l’image Docker utilisée !
En pratique, beaucoup utilisent des images pré-construites qu’ils assemblent selon leurs besoins. Il existe des dépôts d’images, dont le plus connu est le Hub Docker. Du coup, en cas de faille, il va vous falloir attendre une mise-à-jour. L’unique mainteneur est passé sous un bus ? Vous êtes mal…
En termes de sécurité, c’est même encore plus gore dans ce cas, puisque vous n’avez pas beaucoup de moyens de vous assurer que l’image de 600Mo (n’oublions pas que ça intègre un OS complet) que vous allez utiliser n’intègre pas une porte dérobée ou une version obsolète d’une bibliothèque, surtout quand l’image est réalisée avec les pieds et ne permettent aucune vérification a posteriori. Les paquets Debian sont par exemple construits en compilation reproductible et vous pouvez facilement vous assurer que le nginx que vous utilisez est bien le même que celui du paquet Debian officiel alors que sous Docker, je vous souhaite bien du courage ne serait-ce que pour connaître le numéro de version utilisé. Sur chaque image Docker, il faudrait faire une revue assez poussée de ce qui se trouve sur l’image, au moins pour lister les différents composants et bibliothèques intégrés et ainsi connaître les impacts réels sur votre parc d’un correctif de sécurité.

Mono-processus : ma vie, mon œuvre

L’humanité s’est battue pendant des décennies pour mettre en place le multi-processus, puis le multi-thread… Mais ça c’était avant ! Avec Docker, vous ne pouvez lancer qu’un seul et unique processus dans une image. Pas plus.
Ça n’a l’air de rien, mais c’est très handicapant en pratique. Vous ne pouvez pas avoir cron à tourner régulièrement par exemple. Donc pas de logrotate. Vous ne pouvez pas avoir de serveur SSH pour vous connecter à distance sur l’image. Pas de serveur de mail non plus, par exemple pour les rapports journaliers de logwatch (de toute façon on n’a pas cron pour les lancer…). Rien. La seule et unique chose que vous allez pouvoir lancer sera donc votre application. Et c’est tout.

Le problème est que comme on l’a vu précédemment, une application se suffit généralement assez peu à elle-même. Elle nécessite par exemple une base de données, un frontal web, de pouvoir envoyer des courriels… Et donc de lancer plusieurs processus !

En méthode quick & dirty, vous pouvez contourner le problème en lançant un bête script bash qui lancera tout en arrière-plan, ou plus malin un gestionnaire de processus comme supervisord ou pups qui se chargera lui-même de lancer tout le reste de ce que vous avez besoin. C’est tout de même assez galère à faire puisque votre distribution adorée vous fournira des scripts de démarrage pour le système d’init habituel (sysv, systemd, upstart…) et non pour supervisord ou pups, il vous faudra donc faire un travail de portage pour chaque composant nécessaire.

La méthode recommandée par Docker pour gérer vos environnements est l’utilisation de Docker Compose. Vous allez créer autant de conteneurs que de composants de votre écosystème (un pour l’application, un pour la base de données, un pour le serveur de courriel…) et les assembler entre-eux pour qu’ils communiquent correctement.
Pour certains composants comme la base de données, je trouve ça intéressant de séparer du reste, exactement comme on l’aurait fait dans une infrastructure non virtualisée. Pour d’autres, comme un serveur de courriel dédié pour envoyer 3 courriels au mois, c’est du gaspillage de ressources flagrant. Et pour la majorité, c’est d’une prise de tête sans nom… Par exemple dans une application Ruby-on-Rails utilisant Sidekiq comme ordonnanceur, on va se retrouver à avoir 4 conteneurs :

Alors que tout mettre sur la même machine se justifie largement tant qu’on n’a pas une volumétrie délirante (je tiens les 200.000 vues quotidiennes sur Cryptcheck sans soucis avec 1 seul conteneur), on se retrouve avec 4 machines à gérer et à devoir mettre à jour (les 4 utilisent OpenSSL par exemple) et une duplication de l’environnement Ruby (RoR & Sidekiq). On risque aussi de rencontrer des dégradations de performances, puisqu’on passe de communications sur la boucle locale voire des sockets UNIX à une communication TCP/IP externe. Et la sécurité devient tout autant un enfer, avec de la gestion de pare-feu à mettre en œuvre.

Pour gérer autant de conteneurs, vous allez aussi devoir passer à des outils de gestion de déploiement et d’orchestration, comme Kubernetes. Toujours pareil, quand vous vous appelez Google, Wikimedia, SAP ou Ebay, c’est peut-être gérable. Si vous êtes une petite boîte, ça risque d’avoir un surcoût non négligeable et pas forcément rentable.

De la chasse aux méga-octets à la chasse aux bugs non reproductibles

On a vu juste avant que Docker incite à créer plein de conteneurs pour les assembler entre eux. En interne pour la fabrication de ses propres images, Docker se base aussi sur des images pré-construites qu’il empile les unes sur les autres au travers de OverlayFS. Pour l’image Sidekiq, c’est pas moins de 39 couches empilées.

Déjà, ça n’aide pas à la sécurité non plus, puisqu’une faille corrigée sur une couche réclame la reconstruction de toutes les images situées sur les couches supérieures. Ou alors vous corrigez violemment sur votre couche terminale, mais vous dupliquez alors vos bibliothèques (installées par une couche N mais masquées via overlayfs par la couche N+X) et vous avez le travail à faire sur toutes vos images utilisant la couche faillible.

Ensuite, si on utilisait des images standard, on se retrouverait à consommer plusieurs giga-octets pour pas grand-chose. Du coup, la communauté Docker a commencé à faire la chasse aux méga-octets, et s’est prise de passion pour une distribution présentée comme très légère : Alpine Linux.

Cette distribution vient avec un gros piège… Elle est conçue à la base pour aider à débugger des kernel ! Parce que quand vous développez ce genre de logiciel, vous êtes bien content d’avoir une image de 5Mo qui démarre en 2s, vu le nombre de redémarrages que vous allez faire. Et comme vous ne ferez presque rien côté utilisateur, on peut y mettre des trucs très légers comme musl et busybox au lieu des mastodontes que sont la glibc et les coreutils.

Sauf que musl n’est pas compatible avec la glibc disponible un peu partout.
Ni au niveau binaire, ce qui signifie que vous devez compiler explicitement vos logiciels avec cette libc et donc maintenir à la fois un livrable -glibc pour les gens hors de Alpine et un -musl pour Alpine.
Ni au niveau fonctionnalités, ce qui fait que vous pouvez rencontrer des bugs incompréhensibles et non reproductibles sur d’autres plate-formes plus standard. Ça peut aller jusqu’à l’impossibilité totale de compiler votre logiciel, comme c’est le cas actuellement avec OpenJDK 8 ou Phusion Passenger.

Bref, vous allez vous retrouver à soit utiliser des images du Hub Docker avec une chance non négligeable d’utiliser un conteneur Alpine dans votre chaîne et faire la chasse aux bugs vraiment chiants à comprendre, soit à devoir faire votre propre image personnelle sans Alpine… Le tout en croisant les doigts à chaque construction d’image pour ne pas tomber en plus sur une image contenant une faille de sécurité…

Au final, Docker passe en plus complètement à côté de la plaque en termes de consommation de ressources. À titre d’exemple, la stack précédente RoR/Redis/Sidekiq/Nginx ramène pour 60 overlays Docker et 3.1 Go d’espace disque, quand je m’en tire pour 1.8 Go pour Cryptcheck avec une stack dev/RoR/Redis/Sidekiq/Nginx/Elasticsearch/CryptCheck/données. Un beau gâchis d’espace

Une tendance qui se propage de plus en plus

Cette tendance du « je package tout dans un seul truc » est devenu à la mode et on la retrouve vraiment partout. Même si la complexité induite par ce type de systèmes peut être problématique, c’est vraiment le problème de la gestion de la sécurité qui est très dangereuse en pratique. On a déjà du mal à maintenir nos parcs plus ou moins à jour avec une infrastructure pas trop complexe, ça risque de devenir un véritable carnage une fois des outils comme Docker (mal) utilisé un peu partout…

Go, langage d’ailleurs utilisé par Docker lui-même, compile vos projets sous forme d’un exécutable statique qui embarque donc toutes vos bibliothèques. Ça a l’avantage de ne pas nécessiter leur installation, mais ça pose tous les problèmes de sécurité vus auparavant avec la recompilation nécessaire de tous vos binaires au moindre changement d’une bibliothèque.
Sachant en plus que la gestion des dépendances y est très mauvaise puisque se base par défaut sur les branches master de dépôts GitHub et non sur des tags, c’est une bombe à retardement dans vos systèmes. Par exemple vous êtes actuellement incapable de recompiler d’anciennes versions de pas mal de logiciels puisque des dépendances ont fait des modifications non rétro-compatibles avec les anciennes versions de Go et que les versions des dépendances utilisées à l’époque ne sont mentionnées nulle part. La situation devrait cependant s’améliorer avec l’introduction du vendoring depuis Go 1.5.

Snap, la nouvelle idée à la con le nouveau format de paquets d’Ubuntu/Canonical embarque aussi dans une image statique votre logiciel et toutes ses bibliothèques. La problématique de sécurité devient encore pire puisqu’ici, on parle d’une utilisation en tant qu’environnement de bureau.
Par exemple sur mon PC, je me retrouverais avec 60 versions de libssl, utilisée par postfix, openssl, bind9, gstreamer, virtualbox, isync, ntp, postgresql, nmap, tor, mumble, irssi, xca, openssh, apache2, telnet ou encore socat… Le jour où il faudra mettre à jour tout ça, ça va être une belle tranche de rigolade et on n’aura sûrement pas la réactivité qu’a pu avoir le projet Debian sur Heartbleed par exemple, corrigé en quelques heures et disponible tout aussi rapidement sur l’ensemble des dépôts. Quand je leur ai posé la question, ils ont uniquement réfléchi à la mise-à-jour d’un point de vue « binaires » et n’ont même pas pensé à la problématique des migrations de données.
Encore une fois, transformer les mainteneurs d’une application en mainteneurs d’un écosystème complet est loin d’être anodin ici, et le travail à abattre fera que la sécurité ne pourra plus être assurée.

Comment fait-on alors ?

Utiliser des conteneurs, ça peut quand même avoir du bon.

Je m’en sers beaucoup en développement pour monter un environnement stable et surtout pouvoir gérer des environnements difficiles à mixer proprement dans un même système (gcc 4.9 & 6.1 par exemple) ou avec des dépendances pouvant entrer en conflit avec celles du système (l’enfer ffmpeg/avidemux/audacity…).
Ça permet aussi de revenir rapidement à un état propre et maîtrisé. En phase de développement on a généralement tendance à installer des tonnes de choses à la truelle et à modifier violemment son système pour faciliter le debug ou pour chercher la cause d’un problème. Mais c’est toujours intéressant de recompiler sur une machine vierge pour vérifier qu’on n’a pas oublié un bout.
Et enfin ça peut faciliter la reproductibilité d’un bug si l’utilisateur qui le détecte parvient à vous fournir une image démontrant le problème plutôt que de faire face à des « mais ça ne marche pas chez moi ™ ».

Mais par pitié, arrêtez de vouloir mettre en production des blobs galères à gérer, en particulier en termes de sécurité, qui compliquent le moindre audit pour savoir ce qui tourne là-dedans et qui transforment les infrastructures en plat de spaghetti…

Un petit conteneur LXC tout simple, construit à partir de debootstrap générant une image de maximum 200Mo toute mouillée et dans laquelle vous allez installer vos logiciels au mieux avec du apt/dpkg standard et au pire quelques scripts automatisant l’installation (du bon vieux bash over chroot ou du ansible/salt), ça fonctionne simplement et c’est facile à gérer côté sécurité. Et vous découpez vos conteneurs non plus par logiciel comme sous Docker, mais par besoin : 1 conteneur pour toute la stack Discourse, 1 pour votre serveur de courriel entrant, 1 pour votre serveur DNS faisant autorité, etc.