Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.
La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:
- Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
- Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.
Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.
Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.
Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.
Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)
Je lis parfois que l'environnement de bureau MATE va mourir parce qu'on ne peut pas faire vivre indéfiniment une vieille techno et parce qu'en face il y a KDE, GNOME et Cinamon qui sont beaucoup plus modernes, etc etc. Mais d'où vient cette idée ? Le projet est toujours vivant et si on en croit les notes de version de la 1.18, le portage vers GTK3 a même été terminé. Et puis qu'y a-t-il besoin de moderniser ? MATE est un fork de GNOME2 donc 15 ans d'expérience et de peaufinage, ça tourne au poil et il ne manque vraiment pas grand chose. Allez en cherchant on va dire que MATE supporte mal le hidpi mais je n'en ai pas besoin.
Après 11 ans d'utilisation de Linux les bureaux qui réinventent la roue sans arrêt me laissent de marbre. Regardons ce qu'on a en face de MATE :
- GNOME3 et ses utilisateurs qui se masturbent sur les nouvelles fonctionnalités à chaque version même s'il ne s'agit que de réimplémentation de choses qui ont été supprimées avant parce que les développeurs ont décidé que c'était mieux pour vous.
- KDE qui repart de zéro presque tous les ans mais subit les mêmes tares, qui considère que LTS = 1 an et qui s'en-tête à coder des milliers de logiciels que personne n'utilise : KMail, KOffice, Konqueror et la liste pourrait s'allonger.
- LXDE déclaré mort au profil de LXQT. Sauf que LXQT c'est vraiment pas stable ni même proposé sur toutes les distributions contrairement à LXDE. C'est un environnement moins austère qu'il n'y parait et il constitue une bonne solution de secours quand même Xfce se révèle trop lourd pour votre machine.
- Xfce dont on annonce la mort chaque année mais qui vit toujours. Il constitue une excellente alternative à MATE même si je regrette un peu le manque d'homogénéité des logiciels. Xubuntu est l'une des meilleures distributions desktop, à mon sens.
Ayant fait le tour des environnements j'en reviens toujours à MATE, Xfce et LXDE que je trouve stables, efficaces et léger. Leur ancienneté ne constitue pas une dette technique, un poids dont on essaie de se débarrasser, ils sont au contraire une solide base pour tous les vieux cons comme moi.
Mageia 6 est sortie et Sebastien C, ceinture noire de troll et de changement de distribution nous livre un avis assez acide. Très peu d'évolutions sur cette version, une distribution qui se veut à la hauteur de debian sans en avoir les moyens, de trop nombreux bureaux, etc.
Je suis assez d'accord, car si on regarde Mageia quelle est sa force ? Sa communauté, son accessibilité et son centre de configuration. Concernant la communauté, je n'ai pas grand chose à en dire car je n'en fais pas partie mais je ne peux que supposer qu'elle se limite au desktop. En effet je n'ai jamais vu de Mandriva, Mandrake ou Mageia sur les serveurs, c'est 90% de debian/ubuntu et 10% de centos/rhel, le reste est anecdotique. Et si on parle de taille de communauté rien ne battra jamais celle de ubuntu/debian car on trouve énormément de ressources sur le web : forums, mailinglist, stackexchange, wiki, irc...
Concernant l'accessibilité aux débutants je suis assez réservé. Je n'ai jamais compris pourquoi Mageia continue de proposer son propre outil de gestion du réseau au lieu d'utiliser Network-manager comme tout le monde d'autant que ce dernier est bien meilleur pour ce qui touche par exemple au wifi ou aux VPNs. Ensuite je note souvent des comportements pouvant dérouter les débutants, par exemple cette manie du gestionnaire de paquet de vous demander de choisir parmi plusieurs dépendances disponibles lorsque vous souhaitez installer un paquet. Je rajoute qu'à chaque fois que j'ai testé cette distribution dans Virtualbox, après la première mise à jour il devient impossible de booter ce qui est quand même problématique.
Le centre de contrôle, je garde le meilleur pour la fin. Sur papier, c'est l'équivalent du Panneau de configuration de Windows, en pratique c'est totalement obsolète. La configuration du matériel n'est plus nécessaire car automatique (par exemple le pilote vidéo), la configuration des imprimantes fait doublon avec cups ou les interfaces proposées par KDE/Gnome, etc. Au final à part le gestionnaire de paquets il n'y a rien de pertinent en 2017. Pourquoi vouloir tripatouiller un centre de contrôle alors qu'à côté un simple Live CD de ubuntu fonctionne out-the-box ?
Si j'étais utilisateur de Mandriva, à sa mort j'aurai plutôt migré sur debian, opensuse ou fedora qui sont des distributions vivantes, actives avec beaucoup de moyens. Mageia me semble plus proche de l'acharnement thérapeutique, une volonté de conserver des outils et modes fonctionnements qui sont là pour rassurer les utilisateurs sans vraiment avoir une utilité ou une pertinence réelle. Les retards à répétition et l'absence de communication pour la 6e version ont d'ailleurs bien failli confirmer mes dires.
Note : c'est mon avis, il ne constitue pas une vérité absolue mais je l'assume. Vous pouvez m'insulter dans les commentaires si vous le souhaitez.
Systemd est un système d'init "moderne" qui remplace le vieillissant sysvinit. L'init c'est le premier process qui démarre après le boot et qui va "orchestrer" le lancement des services : réseau, logs, ssh ... Mais wikipedia explique cela mieux que moi.
Dire que systemd a provoqué de nombreuses polémiques et levées de boucliers de la part des utilisateurs est un euphémisme, c'est un beau bazar dans lequel des troll s'affrontent au lance-flammes. On lui reproche de nombreuses choses : réinventer l'eau chaude alors que sysvinit marche bien, être monolithique et donc contraire à la philosophie UNIX, être le cheval de troie de Red Hat pour à terme remplacer de plus en plus de composants dans Linux, ne pas être portable sur les autres OS, etc. Je pense que la plupart des critiques sont vraies et que dans quelques années nos distributions ne seront plus GNU/Linux mais SystemD/Linux. Néanmoins il est intéressant d'observer qu'après 6 ans d'existence, systemd s'est imposé partout à l'exception de Gentoo (+et Slackware) et ce n'est pas par hasard.
Je ne vais pas énumérer point par point les fonctionnalités de systemd, je vais me contenter d'en présenter deux aspects que je trouve intéressants : création d'un service et d'un containers (nspawn).
Création d'un service
Avez-vous déjà écrit des scripts d'init pour un logiciel sur Linux ? Moi oui. Et entre sysvinit et systemd, c'est le jour et la nuit. Prenons pour exemple Nginx :
C'est quand même beaucoup plus simple avec systemd puisqu'une grosse partie du boulot est faite nativement, par exemple la gestion du pid et des logs. Pour sysvinit par contre c'est au développeur du script de prévoir tous les cas, de coder la vérification du pid, des logs, bref c'est long et pas forcément utile puisque même sur Windows on ne fait plus ça depuis 20 ans.
Création d'un container
Systemd est très lié à Linux et aux cgroups, il est possible d'isoler des processus dans leur propre contexte, de là à créer des containers avec une application ou un système entier il n'y a donc qu'un pas qui a été franchit. Pour l'exemple on va créer un container ubuntu-server-16.04 à partir d'une image cloud (pour nous épargner les étapes debootstrap qui n'ont pas vraiment d'intérêt dans cet article) :
root@localhost:~# wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
root@localhost:~# mkdir /srv/containers/xenial01
root@localhost:~# tar -xf xenial-server-cloudimg-amd64-root.tar.gz -C /srv/containers/xenial01
Note : sur les versions plus récentes de systemd (non disponible sur Debian Jessie), l'utilitaire machinectl permet de télécharger et déployer une image automatiquement. Voir la section Examples de la documentation machinectl.
Puis démarrer un shell dans le container afin de pouvoir créer un mot de passe root :
root@localhost:~# systemd-nspawn -D /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
root@xenial01:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@xenial01:~# exit
Maintenant on peut - si on veut - démarrer complètement le container :
root@localhost:~# systemd-nspawn -bD /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ
-LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.
Welcome to Ubuntu 16.04 LTS!
Ensuite la séquence de démarrage s'affiche et il est possible de se loguer, puis d'arrêter le container avec la commande poweroff :
Ubuntu 16.04 LTS ubuntu console
ubuntu login: root
Password:
Last login: Mon May 23 09:12:29 UTC 2016 on console
run-parts: /etc/update-motd.d/98-fsck-at-reboot exited with return code 1
root@ubuntu:~# poweroff
Si on ne spécifie aucune option au niveau du réseau, le container utilisera l'interface de l'hôte. Attention donc aux services qui écoutent sur les mêmes ports, typiquement SSH, le mieux est encore d'utiliser une interface réseau virtuelle. Je ne rentre volontairement pas dans les détails afin de ne pas faire un article indigeste, mais il est possible d'aller plus loin notamment au niveau des interfaces réseau (bridge, macvlan, veth), des limitations du système (mémoire, cpus...) ou encore de l'intégration avec SELinux. On peut aussi utiliser debootstrap, dnf ou pacstrap pour créer un container (pas besoin d'une image cloud). Pour cela voir la documentation systemd-nspawn et systemd.resource-control (elles ne sont pas si indigestes que ça).
Systemd-nspawn est une alternative intéressante à LXC permettant de gérer des containers thin (on lance uniquement une application) ou thick (on lance tous les services) sans avoir à installer quoi que ce soit.
BONUS : sous debian, ça ne change rien pour les utilisateurs
Si je peux comprendre que beaucoup de gens n'aiment pas systemd et ne souhaitent pas l'utiliser, en revanche je ne comprends pas pourquoi cette grogne est focalisée chez les utilisateurs de debian au point de créer le fork devuan. Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous. Tout d'abord le boulot est fait par les mainteneurs des paquets, vous n'avez jamais touché à un système d'init de votre vie, et avec systemd vous n'y toucherez pas non plus. Ensuite, si vous faites un peu de sysadmin, là encore rien ne change pour la majorité des opérations.
Voici pour comparer la manière dont on démarre apache :
root@localhost:~# service apache2 start # avec sysvinit
root@localhost:~# service apache2 start # avec systemd
C'est pareil, parce que debian est une distribution pour fainéants (comme moi) très bien foutue. Même chose pour le réseau, ça se gère toujours dans /etc/network/interfaces rien ne change.
Sous Archlinux par contre tout change par exemple le fichier /etc/rc.conf a disparu au profil de fichiers éclatés pris en charge par systemd. Ce n'est pas méchant mais il a fallu réapprendre certaines choses. Malgré une grogne passagère la chose semble avoir bien été acceptée par les utilisateurs, en tous cas ils ne sont pas partis forker leur distribution.
Conclusion
Au final, après avoir lu tant de troll, tant de FUD sur systemd, je trouve que c'est plutôt bien. C'est simple à utiliser et c'est puissant puisqu'on peut imaginer un jour remplacer LXC et cela ouvre plein de possibilités au niveau des serveurs, par exemple avoir des instances apache et nginx isolées dans les containers thin, ou encore des applications portables à la manière de Snap ou xdg-app. Pour 99% des utilisateurs de Linux la transition est transparente puisque prise en charge en amont par les mainteneurs.
Je prends donc le risque d'invoquer une armée de troll dans les commentaires mais moi j'approuve systemd.