Si vous êtes familier avec l'écosystème des distributions Linux, vous avez probablement levé un sourcil (comme Teal'c) en lisant ce titre car vous les connaissez toutes, vous avez touché à tous les gestionnaires de paquet, vous avez utilisé debian et gentoo, en bref vous avez fait le tour et plus rien ne nous surprend.
Et pourtant, bien que NixOS soit une distribution assez ancienne (2003) elle dispose de nombreux atouts inédits passés plutôt inaperçus jusqu'à présent.
La configuration déclarative centralisée
Ce que je trouve le plus intéressant dans NixOS, c'est la configuration centralisée dans un unique fichier. En effet si vous avez déjà travaillé sur des routeurs ou diverses appliances, vous avez remarqué que l'on peut souvent importer et exporter la configuration sous forme de texte assez facilement, cela rend la maintenance très facile. Sous NixOS c'est le même principe, mais en plus puissant puisqu'on peut rollback voire booter sur une ancienne configuration depuis grub. Exemple de configuration d'un serveur MariaDB :
/etc/nixos/configuration.nix
{ config, pkgs, ... }:
{
imports =
[ # Include the results of the hardware scan.
./hardware-configuration.nix
];
# Use the systemd-boot EFI boot loader.
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
networking = {
hostName = "mariadb";
nameservers = [ "192.168.0.31" ];
defaultGateway = "192.168.0.254";
interfaces.enp0s3.ip4 = [
{
address = "192.168.0.41";
prefixLength = 24;
}
];
};
# Select internationalisation properties.
i18n = {
consoleFont = "Lat2-Terminus16";
consoleKeyMap = "fr";
defaultLocale = "fr_FR.UTF-8";
};
# Set your time zone.
time.timeZone = "Europe/Paris";
# List packages installed in system profile. To search by name, run:
# $ nix-env -qaP | grep wget
environment.systemPackages = with pkgs; [
git
htop
sudo
tree
vim
];
# Services
services = {
openssh = {
enable = true;
permitRootLogin = "yes";
};
mysql = {
enable = true;
package = pkgs.mysql;
extraOptions = ''bind-address=0.0.0.0'';
};
};
# Open ports in the firewall.
networking.firewall.allowedTCPPorts = [ 22 3306 ];
# networking.firewall.allowedUDPPorts = [ ... ];
# Define a user account. Don't forget to set a password with ‘passwd’.
users.extraUsers = {
utux = {
isNormalUser = true;
extraGroups = [ "wheel" ];
};
};
# The NixOS release to be compatible with for stateful data such as databases.
system.stateVersion = "17.03";
}
/etc/nixos/hardware-configuration.nix
# Do not modify this file! It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations. Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, ... }:
{
imports = [ ];
boot.initrd.availableKernelModules = [ "virtio_pci" "ahci" "xhci_pci" "sr_mod" "virtio_blk" ];
boot.kernelModules = [ ];
boot.extraModulePackages = [ ];
fileSystems."/" =
{ device = "/dev/disk/by-uuid/78634ba0-11d1-4f91-85ae-ac2ee247c387";
fsType = "xfs";
};
fileSystems."/boot" =
{ device = "/dev/disk/by-uuid/019A-1A05";
fsType = "vfat";
};
swapDevices =
[ { device = "/dev/disk/by-uuid/075a27eb-5656-4b57-b186-73a6d86e5e5c"; }
];
nix.maxJobs = lib.mkDefault 1;
}
Comme vous le voyez, le fichier configuration.nix contient toute la configuration, incluant les services tiers tels que mariadb dans notre cas. Cela va donc encore plus loin que le /etc/rc.conf sur FreeBSD/NetBSD/OpenBSD qui centralise déjà pas mal de choses. Le fichier hardware-configuration.nix lui est généré automatiquement il n'y a pas besoin d'y toucher et il est plus ou moins unique par serveur.
Pour générer et appliquer la configuration :
nixos-rebuild switch
Pour mettre à jour le système :
nixos-rebuild switch --upgrade
Puis un petit mysql_secure_installation la première fois pour préparer notre SGBD.
Ce qu'il reste à faire en dehors du configuration.nix, c'est la définition des mots de passe, avec passwd et bien sûr la gestion des données persistantes (les bases de données pour mariadb par exemple).
Nix, gestionnaire de paquets fonctionnel
Je vais être un peu plus prudent sur ce point, car étant encore en phase de découverte de NixOS, je ne connais pas encore très bien le gestionnaire de paquets Nix. Cependant, à la différence des gestionnaires classiques tels que apt, yum ou pacman, il ne se contente pas d'aller chercher des paquets pour les décompresser. Chaque version de chaque paquet est installé dans une arborescence /nix/store/{identifiant unique}, du coup plusieurs versions peuvent cohabiter ensemble et les mises à jour n'écrasent rien. Il est possible également pour les utilisateurs d'installer des paquets pour leur environnement (non-root) uniquement.
Mon avis
J'ai mis un serveur NixOS en test et il est trop tôt pour en tirer des conclusions. Mais j'aime l'idée de configuration centralisée déclarative, car la configuration classique des systèmes Linux n'est pas toujours simple à maintenir : Docker, Ansible, NixOS : le savoir (re)faire.
Si je dois citer deux inconvénients à NixOS : elle prend de la place (1,6GB à l'installation avec MariaDB) et elle nécessite au moins 1GB de RAM pour s'installer sous peine de voir oomkiller tuer nixos-install... elle peut cependant tourner avec 256MB par la suite.
NixOS nous montre qu'une distribution Linux ce n'est pas seulement un éinième fork de Ubuntu avec un wallpaper personalisé, ou encore une guerre de gestionnaire de paquets (dnf/apt), il existe encore de l'innovation et rien que pour cela elle mérite le coup d’œil.
L'informatique, comme tous les métiers, demande un savoir-faire, celui-ci vient avec l'expérience et la pratique. Mais s'il y a un autre point qui est important et souvent négligé, c'est de savoir refaire. Je vais expliquer.
Imaginez-vous administrateur système dans une entreprise, on vous charge d'installer un serveur web pour afficher une simple page html. Vous allez alors installer Debian + Apache puis placer le fichier html à la racine, rien de difficile jusque là.
Imaginez ensuite qu'au bout de 2 mois ce fichier html soit remplacé par un fichier php un peu plus avancé, vous allez alors installer libapache2-mod-php5 là encore c'est facile. Par la suite le fichier évolue encore et vous oblige à installer des modules, par exemple php5-gd et php5-curl.
Puis le serveur vit sa vie et au bout de 2 ans on vous demande d'en mettre en place un deuxième avec exactement le même rôle. Et là ça se complique car 2 ans c'est long et vous avez probablement oublié tout ce que vous et vos collègues avez fait pour configurer ce serveur au fur et à mesure. S'il est facile d'identifier que apache2 et php5 sont présents, en revanche les modules sont beaucoup moins évidents, surtout si vous avez utilisé des gestionnaires tiers tels que pecl, cpan, pip.
L'une des grandes problématiques est donc de trouver un moyen pour garder une trace et refaire rapidement toutes les étapes qui ont accompagné la vie du serveur. Alors bien sûr le grand classique est d'utiliser un wiki, mais qui vous garanti que ce qu'y s'y trouve représente bien ce qui est en production ? Personne n'est à l'abri d'une modification "urgente" en prod non rapportée sur le wiki.
Une solution que l'on retrouve souvent et qui est appliquée dans Ansible, Docker et NixOS, c'est d'éliminer toutes les manipulations sur la prod. On y touche plus, à la place on travaille sur un fichier de recette, que l'on va ensuite deployer et jouer. Sur Ansible ce sont les playbook, sur docker les Dockerfile, et sur NixOS le fichier configuration.nix.
Cela parait beaucoup plus propre et ça l'est, c'est une rigueur pas forcément naturelle qui paye sur le long terme. Néanmoins ce n'est pas toujours évident, une manipulation rapide à faire sur un serveur peut se transformer en plusieurs minutes voire heures de devops dans Ansible. Let's Encrypt est un exemple, son automatisation n'est pas simple car vous allez devoir gérer deux cas différents selon la présence ou non d'un certificat. En effet certbot peut soit utiliser le mode standalone et donc couper Nginx (car nécessité du port 80) ou alors utiliser le mode webroot et justement passer par Nginx + vhost de votre site, or ce dernier a justement besoin du certificat pour démarrer. Et quid du cas de Docker où vous devez créer un nouveau container et le relier à l'existant juste pour renouveler vos certificats.
En conclusion le boulot de sysadmin, développeur ou devops n'est pas seulement de faire ou réparer les choses mais également de prévoir l'avenir, s'imposer une rigueur même si elle parait contre-productive sur le moment. J'aurai probablement l'occasion de parler de plus en détail de Docker et de NixOS dans de prochains articles, restez branchés.
Je ne comprends pas trop la hype qui a propulsé Mastodon sur le devant de la scène, ce n'est pas le premier réseau social libre, il y en a eu un bon paquet avant : identi.ca, gnu social, diaspora, ... et beaucoup d'autres que je ne connais pas. Peut-être que ces logiciels ont pris trop de libertés par rapport à l'interface alors que les utilisateurs voulaient juste un clone de Twitter ou Facebook. Je suis quand même curieux de savoir pourquoi Mastodon a décollé et pas les autres.
Côté technique, Mastodon fait un peu peur : node + ruby c'est pas très friendly avec les hébergements mutualisés, c'est un casse-tête pour les sysadmin qui doivent maintenir un serveur avec des milliards de dépendances de plusieurs sources, et puis c'est plutôt lourd. Mais en fait c'est pas si mal puisque le projet fourni un Dockerfile et un docker-compose.yml tous deux très propres et bien découpés, c'est du porn pour les yeux, ce qui montre que les gars savent ce qu'ils font. Vagrant et Heroku sont également supportés, mais je ne connais quasiment pas ces plateformes.
Côté utilisateur par contre, comme je le dis dans le titre, je suis trop vieux pour ces conneries. En fait le problème ne vient pas de Mastodon, mais de l'ergonomie façon Twitter que je n'aime pas. Je trouve que rien n'a de sens, je ne comprends pas à quoi correspondent les messages qui apparaissent, comment suivre les conversations, je m'y perds. Le problème vient clairement de moi, le vieux con qui n'a jamais rien compris aux réseaux sociaux, un peu comme ces gens de mauvaise foi qui n'ont jamais voulu apprendre l'informatique parce qu'ils ont grandi sans.
En résumé je dirai donc ceci :
Point de vue utilisateur, je ne peux rien dire d'intéressant, je ne sais pas utiliser Twitter donc je ne sais pas utiliser Mastodon. Essayez-le pour vous faire un avis.
Point de vue sysadmin ouais, ça a l'air bien fichu, c'est pas fait par des branlots, je valide.
Point de vue geek, je suis assez content qu'un truc libre et décentralisé réussisse enfin à convaincre les utilisateurs lambda après toutes ces années, j'avais perdu tout espoir. Et en prime la FSF n'a pas encore tenté de torpiller le projet, c'est un signe.
La croissance de Mastodon ne sera pas facile et s'accompagnera d'obstacles de plus en plus importants qui mettront à l'épreuve la viabilité d'un service décentralisé : je pense notamment à la modération, car on sait ce qui se passe quand on attire trop d'utilisateurs lambda : ça fini comme les commentaires Youtube avec de la connerie et même de la haine qui sort du cadre légal, une vraie décharge qui est tout sauf une évolution. En parlant de cadre légal, quid des demandes des services de renseignement des États, des demandes de retrait de contenus illégaux, comment réagiront les administrateurs des pods ?
C'est la première fois que je participe à une épreuve de ce type, je ne savais vraiment pas à quoi m'attendre. 4000 personnes étaient présentes sur la ligne de départ, c'est beaucoup, et donc on commence en douceur pour ne pas se marcher sur les pieds. Au bout du 4e km ça va un peu mieux et on peut courir à son rythme.
Les 15 premiers km ont été plutôt aisés, d'autant que la météo fut moins pire que prévu car on aurait du avoir de la pluie voire de l'orage, on a juste eu un ciel noir. Au delà de ces 15km, la fatigue commence à se faire sentir, la soif aussi, et c'est là que le mental devient important car on sait qu'il reste 6km et qu'il n'est pas question d'abandonner.
Au 18/19e km la fatigue fait place à la souffrance, on ne sent plus vraiment ses jambes, on a plus d'énergie pour continuer, et pourtant il le faut car ce serait dommage de laisser tomber aussi près du but. Encore une fois c'est le mental qui prend le dessus, on fait abstraction de la souffrance, on salue la foule qui vous encourage (en criant votre nom puisqu'il est écrit sur le dossard), on donne tout ce qu'on a.
Une fois la ligne d'arrivée franchie c'est la victoire, la libération, une belle revanche pour un ancien gros comme moi qui ne pouvait pas courir 1min il y a quelques années.
Au final si mon temps a été bien moins bon que ce que j'espérais (je visais 1h50), je suis tout de même content d'avoir terminé l'épreuve sans rien lâcher et j'annonce même mon intention de faire mieux l'année prochaine en continuant l'entraînement sans relâche.
Note : si /media/cdrom est vide, essayez d'ouvrir le CD-ROM VBOXADDITIONS apparu sur votre bureau ou dans votre gestionnaire de fichiers (selon l'environnement). Vous pouvez aussi essayer la commande suivante :
$ sudo mount cdrom
Pensez à redémarrer la machine virtuelle.
Résumé :
build-essential : Méta-paquet qui installe les outils nécessaires à la compilation, c'est la boîte à outils de base pour Debian.
dkms : Framework qui permet de compiler des modules pour le noyau. Non seulement c'est plus propre qu'un make install (automatisation et suivi des versions) mais aussi et surtout il recompilera automatiquement les modules en cas de mise à jour du kernel.
