Title: [FR] Pourquoi j'utilise OpenBSD
Author: Solène
Date: 04 January 2021
Tags: openbsd francais
Description:
Dans ce billet je vais vous livrer mon ressenti sur ce que j'aime dans
OpenBSD.
### Respect de la vie privée
Il n'y a aucune télémétrie dans OpenBSD, je n'ai pas à m'inquiéter
pour le respect de ma vie privée. Pour rappel, la télémétrie est un
mécanisme qui consiste à remonter des informations de l'utilisateur
afin d'analyser l'utilisation du produit.
De plus, le défaut du système a été de désactiver entièrement le
micro, à moins d'une intervention avec le compte root, le microphone
enregistre du silence (ce qui permet de ne pas le bloquer quant à des
droits d'utilisation). A venir dans 6.9, la caméra suit le même
chemin et sera désactivée par défaut. Il s'agit pour moi d'un signal
fort quant à la nécessité de protéger l'utilisateur.
### Navigateurs web sécurisés
Avec l'ajout des fonctionnalités de sécurité (pledge et surtout
unveil) dans les sources de Firefox et Chromium, je suis plus sereine
quant à leur utilisation au quotidien. À l'heure actuelle,
l'utilisation d'un navigateur web est quasiment incontournable, mais
ils sont à la fois devenus extrêmement complexes et mal maîtrisés.
L'exécution de code côté client via Javascript qui a de plus en plus
de possibilité, de performances et de nécessités, ajouter un peu de
sécurité dans l'équation était nécessaire. Bien que ces ajouts
soient parfois un peu dérangeants à l'utilisation, je suis vraiment
heureuse de pouvoir en bénéficier.
Avec ces sécurités ajoutés (par défaut), les navigateurs cités
précédemment ne peuvent pas parcourir les répertoires en dehors de
ce qui leur est nécessaire à leur bon fonctionnement plus les
dossiers ~/Téléchargements/ et /tmp/. Ainsi, des emplacements comme
~/Documents ou ~/.gnupg sont totalement inaccessibles ce qui limite
grandement les risques d'exfiltration de données par le navigateur.
On pourrait refaire grossièrement la même fonctionnalité sous Linux
en utilisant AppArmor mais l'intégration est extrêmement compliquée
(là où c'est par défaut sur OpenBSD) et un peu moins efficace, il
est plus facile d'agir au bon moment depuis le code plutôt qu'en
encapsulant le programme entier d'un groupe de règles.
### Pare-feu PF
Avec PF, il est très simple de vérifier le fichier de configuration
pour comprendre les règles en place sur le serveur ou un ordinateur de
bureau. La centralisation des règles dans un fichier et le système de
macros permet d'écrire des règles simples et lisibles.
J'utilise énormément la fonctionnalité de gestion de bande passante
pour limiter le débit de certaines applications qui n'offrent pas ce
réglage. C'est très important pour moi n'étant pas la seule
utilisatrice du réseau et ayant une connexion assez lente.
Sous Linux, il est possible d'utiliser les programmes trickle ou
wondershaper pour mettre en place des limitations de bande passante,
par contre, iptables est un cauchemar à utiliser en tant que firewall!
### C'est stable
A part à l'utilisation sur du matériel peu répandu, OpenBSD est
très stable et fiable. Je peux facilement atteindre deux semaines
d'uptime sur mon pc de bureau avec plusieurs mises en veille par jour.
Mes serveurs OpenBSD tournent 24/24 sans problème depuis des années.
Je dépasse rarement deux semaines puisque je dois mettre à jour le
système de temps en temps pour continuer les développements sur
OpenBSD :)
### Peu de maintenance
Garder à jour un système OpenBSD est très simple. Je lance les
commandes syspatch et pkg_add -u tous les jours pour garder mes
serveurs à jour. Une mise à jour tous les six mois est nécessaire
pour monter en version mais à part quelques instructions spécifiques
qui peuvent parfois arriver, une mise à jour ressemble à ça :
```liste de commandes shells qui commencent par un # pour préciser que l'utilisateur est root
# sysupgrade
[..attendre un peu..]
# pkg_add -u
# reboot
```
### Documentation de qualité
Installer OpenBSD avec un chiffrement complet du disque est très
facile (il faudra que j'écrive un billet sur l'importance de chiffrer
ses disques et téléphones).
La documentation officielle expliquant l'installation d'un routeur avec
NAT est parfaitement expliquée pas à pas, c'est une référence dès
qu'il s'agit d'installer un routeur.
Tous les binaires du système de base (ça ne compte pas les packages)
ont une documentation, ainsi que leurs fichiers de configuration.
Le site internet, la FAQ officielle et les pages de man sont les seules
ressources nécessaires pour s'en sortir. Elles représentent un gros
morceau, il n'est pas toujours facile de s'y retrouve mais tout y est.
Si je devais me débrouiller pendant un moment sans internet, je
préférerais largement être sur un système OpenBSD. La documentation
des pages de man suffit en général à s'en sortir.
Imaginez mettre en place un routeur qui fait du trafic shaping sous
OpenBSD ou Linux sans l'aide de documents extérieurs au système.
Personnellement je choisis OpenBSD à 100% pour ça :)
### Facilité de contribution
J'adore vraiment la façon dont OpenBSD gère les contributions. Je
récupère les sources sur mon système et je procède aux
modifications, je génère un fichier de diff (différence entre
avant/après) et je l'envoie sur la liste de diffusion. Tout ça peut
être fait en console avec des outils que je connais déjà (git/cvs)
et des emails.
Parfois, les nouveaux contributeurs peuvent penser que les personnes
qui répondent ne sont vraiment pas sympa. **Ce n'est pas vrai**. Si
vous envoyez un diff et que vous recevez une critique, cela signifie
déjà qu'on vous accorde du temps pour vous expliquer ce qui peut
être amélioré. Je peux comprendre que cela puisse paraître rude
pour certaines personnes, mais ce n'est pas ça du tout.
Cette année, j'ai fait quelques modestes contributions aux projets
OpenIndiana et NixOS, c'était l'occasion de découvrir comment ces
projets gèrent les contributions. Les deux utilisent github et la
manière de faire est très intéressante, mais la comprendre demande
beaucoup de travail car c'est relativement compliqué.
(HTM) Site officiel d'OpenIndiana
(HTM) Site officiel de NixOS
La méthode de contribution nécessite un compte sur Github, de faire
un fork du projet, cloner le fork en local, créer une branche, faire
les modifications en local, envoyer le fork sur son compte github et
utiliser l'interface web de github pour faire un "pull request". Ça
c'est la version courte. Sur NixOS, ma première tentative de faire un
pull request s'est terminée par une demande contenant six mois de
commits en plus de mon petit changement. Avec une bonne documentation
et de l'entrainement c'est tout à fait surmontable. Cette méthode de
travail présente certains avantages comme le suivi des contributeurs,
l'intégration continue ou la facilité de critique de code, mais c'est
rebutoire au possible pour les nouveaux.
### Packages top qualité
Mon opinion est sûrement biaisée ici (bien plus que pour les
éléments précédents) mais je pense sincèrement que les packages
d'OpenBSD sont de très bonne qualité. La plupart d'entre eux
fonctionnent "out of the box" avec des paramètres par défaut
corrects.
Les packages qui nécessitent des instructions particulières sont
fournis avec un fichier "readme" expliquant ce qui est nécessaire, par
exemple créer certains répertoires avec des droits particuliers ou
comment mettre à jour depuis une version précédente.
Même si par manque de contributeurs et de temps (en plus de certains
programmes utilisant beaucoup de linuxismes pour être faciles à
porter), la plupart des programmes libres majeurs sont disponibles et
fonctionnent très bien.
Je profite de l'occasion de ce billet pour critiquer une tendance au
sein du monde Open Source.
* les programmes distribués avec flatpak / docker / snap fonctionnent
très bien sur Linux mais sont hostiles envers les autres systèmes.
Ils utilisent souvent des fonctionnalités spécifiques à Linux et les
méthodes de compilation sont tournées vers Linux. Cela complique
grandement le portage de ces applications vers d'autres systèmes.
* les programmes avec nodeJS: ils nécessitent parfois des centaines
voir des milliers des libs et certaines sont mêmes un peu bancales.
C'est vraiment compliqué de faire fonctionner ces programmes sur
OpenBSD. Certaines libs vont même jusqu'à embarquer du code rust ou
à télécharger un binaire statique sur un serveur distant sans
solution de compilation si nécessaire ou sans regardant si ce binaire
est disponible dans $PATH. On y trouve des aberrations incroyables.
* les programmes nécessitant git pour compiler: le système de
compilation dans les ports d'OpenBSD fait de son mieux pour faire au
plus propre. L'utilisateur dédié à la création des packages n'a pas
du tout accès à internet (bloqué par le pare-feu avec une règle par
défaut) et ne pourra pas exécuter de commande git pour récupérer du
code. Il n'y a aucune raison pour que la compilation d'un programme
nécessite de télécharger du code au milieu de l'étape de
compilation!
Évidemment je comprends que ces trois points ci-dessus existent car
cela facilite la vie des développeurs, mais si vous écrivez un
programme et que vous le publiez, ce serait très sympa de penser aux
systèmes non-linux. N'hésite pas à demander sur les réseaux sociaux
si quelqu'un veut tester votre code sur un autre système que Linux. On
adore les développeurs "BSD friendly" qui acceptent nos patches pour
améliorer le support OpenBSD.
### Ce que j'aimerais voir évoluer
Il y a certaines choses où j'aimerais voir OpenBSD s'améliorer. Cette
liste est personnelle et reflète pas l'opinion des membres du projet
OpenBSD.
* Meilleur support ARM
* Débit du Wifi
* Meilleures performances (mais ça s'améliore un peu à chaque
version)
* Améliorations de FFS (lors de crashs j'ai parfois des fichiers dans
lost+found)
* Un pkg_add -u plus rapide
* Support du décodage vidéo matériel
* Meilleur support de FUSE avec une possibilité de monter des
systèmes CIFS/samba
* Plus de contributeurs
Je suis consciente de tout le travail nécessaire ici, et ce n'est
certainement pas moi qui vais y faire quelque chose. J'aimerais que
cela s'améliore sans toutefois me plaindre de la situation actuelle :)
Malheureusement, tout le monde sait qu'OpenBSD évolue par un travail
acharné et pas en envoyant une liste de souhaits aux développeurs :)
Quand on pense à ce qu'arrive à faire une petite équipe (environ 150
développeurs impliqués sur les dernières versions) en comparaison
d'autres systèmes majeurs, je pense qu'on est assez efficace!