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 :)
Ceph fait du stockage distribué. Il permet de répartir des données sur plusieurs machines avec réplicas, assurant ainsi une certaine sécurité et résilience.
Sauf que ça c'est la théorie, en pratique mon expérience a été assez mauvaise et non seulement source d'interruptions de service mais aussi d'un niveau de stress très important (jusqu'à ne plus dormir la nuit). Parce que oui perdre un serveur de prod n'est déjà pas agréable, mais quand il s'agit du stockage c'est encore pire.
Un admin qui bosse avec Ceph
Problème 1: l'usine à gaz
Ceph est gros, très gros, pour le compiler prévoyez au minimum 8GB de ram (sous peine de faire exploser votre machine) et plusieurs heures.
Ensuite pour être à l'aise prévoyez des machines bien dimensionnées (Xeon), beaucoup de RAM (1GB par TB) et du stockage SSD pour la journalisation. A l'usage ne vous étonnez pas de voir la RAM et la swap proche de la saturation, c'est le rythme de croisière.
Et puis l'architecture n'est pas simple il y a les OSD, les PGs, les différents services, et les logs parfois pas très clairs qui vous disent que la reconstruction est bloquée sans vraiment donner de raison.
Problème 2: les bugs
Sur la version Kraken (11.2) il existe une fuite de mémoire avec le service ceph-mgr. La solution est donc de le couper. Sauf que son rôle est justement de contrôler l'utilisation de la mémoire, donc le serveur va naturellement gonfler au fil des mois jusqu'à finir par exploser en vol. Il faut donc régulièrement lancer ceph-mgr puis le couper.
Le hic, c'est que dans le cas où votre serveur est déjà bien chargé (RAM + swap), le lancement de ceph-mgr ajoute un poids supplémentaire ce qui peut amener des lag sur le cluster le temps que la mémoire baisse... et ça c'est très mauvais. Dans mon cas cela a fait basculer plusieurs machines virtuelles en readonly.
Problème 3: ceph-deploy
Avec la mouvance devops il est de plus en plus courant de vouloir installer les choses sans devoir mettre les mains dans le cambouis, faire du sysadmin sans rien connaître en sysadmin quoi. Et c'est problématique. Certes c'est rapide et facile, mais en cas de panne on ne sait pas quoi faire car on ne sait pas comment marche le système.
Ceph-deploy fait le boulot à votre place, et dans le cas où ce n'est pas vous qui avez monté l'infra, si vous ne disposez pas du répertoire contenant les clés et la configuration, bon courage pour manipuler le cluster (ajout ou retrait de nodes). De plus ceph-deploy réserve des surprises en installant pas forcément la version qu'on lui demande...
Problème 4: les performances
Même avec un setup assez costaud (plein de RAM et de SSD) les I/O des VM qui sont stockées dessus sont décevantes. C'est un ressenti, mais à l'aire du SSD et/ou du stockage en RAID10, une installation d'une VM debian stockée sur cluster Ceph parait interminable.
Problème 5: résilience
Dans un cluster de 3 nodes on se dit qu'on est tranquilles car on peut en perdre 2 et continuer à fonctionner, un peu comme avec un RAID1 de 3 disques. Sauf qu'en pratique, il faut au minimum 2 nodes actives... Et oui, j'ai testé sur un cluster Ceph 0.96 et 11.2, dans les deux cas les données ne sont plus accessibles s'il ne reste qu'une seule node en vie.
Problème 6: targetcli
C'est le daemon iscsi de Ceph. Le problème ? Il perd sa conf partiellement ou totalement à chaque reboot. Prévoyez un targetctl restore systématique et un downtime possible si vous devez effectuer cette opération.
Conclusion: abandon
Alors que Ceph est censé apporter une continuité de service et donc un sérénité pour les admin, j'ai expérimenté le contraire. Les nombreux downtimes et les fois où j'ai été à deux doigts de perdre l'intégralité du stockage (et donc des machines virtuelles) m'ont causé des nuits blanches d'angoisse.
Les VM sont en cours de migration vers un SAN artisanal à base de Debian + iscsitarget. Il n'est peut-être redondé mais il est fiable, il n'y a pas de fuite de RAM, et s'il y a le moindre pépin nous connaissons les couches de A à Z pour pouvoir diagnostiquer.
En ce qui me concerne Ceph est une usine à gaz qui n'est pas production ready et j'espère ne plus avoir à y toucher de ma vie.
Attention ceci n'est un comparatif entre backuppc et borg mais une courte réflexion. Je cherche à me débarrasser de backuppc pour les raisons suivantes:
Sous le capot c'est l'usine à gaz et c'est un enfer à installer surtout avec le webui quand votre distribution ne le propose pas ou pas complètement (genre FreeBSD).
Je n'aime pas du tout la planification des backup qu'on ne peut pas définir à des horaires (sauf avec des crons).
Il n'est pas disponible dans Nix alors que je migre vers NixOS (j'ai songé à le packager, mais cela me semble trop hardcore pour débuter).
Du coup j'examine les solutions alternatives de backup et tout le monde ne parle que de borg. Ce logiciel a l'air intéressant mais il semble plus adapté à la sauvegarde d'une machine individuelle qu'à l'utilisation dans un parc de centaines de serveurs. En effet les sauvegardes avec Borg se font en "push", il faut l'installer sur chaque serveur qui va ensuite pousser ses sauvegardes vers un repo distant. Avec Backuppc c'est du "pull", un unique serveur se charger d'aller chercher les données de vos serveurs distants.
Je pense que les deux solutions se défendent. L'avantage du pull (backuppc) c'est qu'on centralise la gestion, la surveillance et le stockage en un point, il n'y a rien à faire sur les serveurs. L'inconvénient est que votre serveur de sauvegarde doit disposer des accès root à l'intégralité de votre parc, ce qui peut constituer une faiblesse en terme de sécurité. Le push (Borg) est beaucoup plus sécurisé, par contre il faut l'installer et le gérer sur chaque machine ce qui ne doit pas être évident quand on en a des centaines.
La question est de savoir qui a raison. Faut-il faire ses sauvegardes en push et privilégier la sécurité ou en pull et privilégier la facilité de gestion ?
Lorsque que Canonical a annoncé l'abandon de Unity, j'ai dit que c'était dommage car cette interface était intéressante et proposait une alternative à ce qui existe à côté. Mais à côté de cela j'ai cru comprendre qu'il était facile de refaire la même chose avec GNOME 3 et quelques extensions. Et en effet, c'est possible:
Il s'agit d'une capture d'écran réalisée sur openSUSE Tumbleweed en version GNOME bien entendu, avec les modifications suivantes:
Extension Alternatetab (aperçu des fenêtres lors du ALT+TAB, de base on ne voit que l'icône).
Extension Dash to dock (le dock, personnalisable).
Gnome tweak (inclus dans GNOME) pour remettre les boutons de miniaturisation et maximisation sur les bordures de fenêtres.
Nemo qui remplace Nautilus, un peu plus personalisable.
(et le wallpaper mais vous l'avez déjà remarqué).
Il manque encore certains éléments mais je pense qu'il est possible d'y remédier:
Un thème d'icônes et de fenêtres plus colorés.
Un gestionnaire de bureaux virtuels visible directement permettant de switcher rapidement sans devoir entrer dans le menu activités.
Des bordures de fenêtre moins épaisses.
L'orientation de Canonical vers GNOME permettra donc à Ubuntu de conserver son identité visuelle tout en s'épargnant énormément de développement redondant avec ce qui existe déjà (une habitude pour la firme). J'attends avec impatiente de voir ce que va donner Ubuntu 17.10.
Pour la rigolage, installons Trinity Desktop, continuation de KDE3, sur Debian :
Ça fonctionne plutôt bien, les paquets ont été correctement renommés pour ne pas entrer en conflit avec ceux de KDE5, par exemple konqueror-trinity donc la cohabitation se passe bien. Cette capture d'écran nous rappelle à quel point KDE3 était une usine à gaz et un foutoir, avec un sous-menu "Internet" déjà saturé lors de l'installation ou encore la présence d'éléments redondants: est-il nécessaire d'avoir des sous-menu Settings, System, Utilities, Trinity Control Center, System Menu ? Naviguer dans mes fichiers avec Konqueror, c'est pas la joie, Dolphin (arrivé avec KDE4) est bien meilleur.
Il est amusant de noter que MATE, continuation de GNOME2 est un projet vivant et fournit dans quasiment toutes les distributions alors que TDE est clairement mal aimé. Le projet n'est certes pas abandonné mais aucune distribution ne l'intègre, probablement parce que la transition de KDE3 à KDE4 fut assez logique et naturelle pour les utilisateurs, contrairement à GNOME3.
Passer de KDE3 à KDE4 c'est un peu comme échanger le bureau de Windows XP par celui de Windows 7, certes on peut râler parce que c'est un peu plus lourd, mais c'est aussi plus moderne et surtout on l'utilise quasiment de la même façon, nos habitudes ne sont pas brisées.
Je suis curieux de savoir s'il y a des utilisateurs de TDE... si c'est le cas manifestez-vous ;)
