Il vous est sans doute déjà arrivé d’avoir besoin d’effectuer diverses manipulations plutôt basiques sur une image : découpage, déplacement, ajout de texte, un peu de dessin… Et tout de suite, on pense à des applications telles que GIMP ou Krita. Mais quand on est pas infographiste, on peut vite être découragé par le foisonnement d’options, où tout paraît compliqué.
Des recherches plus approfondies nous donnent bien GNU Paint, gnome-paint et autre KolourPaint, mais soit les applications sont abandonnées depuis de nombreuses années (2007 et 2010 pour les deux premières), utilisent de vieilles technologies (GTK+ 2) et ne respectent pas les bonnes pratiques pour l’IHM de GNOME, soit nécessitent d’installer de nombreuses dépendances relatives à KDE et ne s’intégreront pas correctement dans notre environnement préféré.
Marcin Kolny a donc décidé de prendre le problème à bras-le-corps et de se lancer dans le développement d’une toute nouvelle application, GNOME Paint, qui fera peut être un jour parti des applications GNOME officielles.
Comme vous pouvez le constater sur le capture d’écran, il s’agit d’une version préliminaire et un designer est activement recherché. Mais avec un peu de chance, une première version utilisable sera peut-être disponible fin juillet pour le GUADEC 2017.
Contribuer au Logiciel Libre est une activité très consommatrice de moyens et de temps. Il faut, comme pour chaque projet logiciel, traverser les différentes phases de :
répondre à un besoin par l’utilisation, l’adaptation ou l’écriture complète d’un logiciel
mettre en place la solution
en assurer la maintenance
faire connaître son projet
Quasiment l’ensemble de ces tâches est à assurer pour chacun de vos projets. Et c’est donc ce que je m’efforce de faire pour l’ensemble de mes projets ci-dessous.
Mes projets dans le Libre
Voici les projets par lesquels je contribue au Logiciel Libre.
Fondateur du Journal du hacker
J’ai fondé ce qui est aujourd’hui le Journal du hacker car un outil de ce type manquait à la communauté du Logiciel Libre francophone. Je me suis appuyé sur le code d’un projet existant aux États-Unis mais j’y ai intégré l’internationalisation pour gérer les autres caractères que ceux de l’écriture anglaise, fonctionnalité manquante dans le moteur et j’ai tenté d’intégrer au projet amont ces améliorations.
Nous sommes aujourd’hui une équipe entière (bravo et merci aux modos) mais je travaille encore très régulièrement sur les phases 3 et 4 décrites précédemment. Je suis modérateur et déniche les articles intéressants de la sphères du Logiciel Libre francophone. J’y passe au minimum une heure par jour.
Fondateur de LinuxJobs.fr
J’ai fondé LinuxJobs.fr car je voulais redynamiser l’emploi dans la communauté du Logiciel Libre et Open Source en France. Le site web a rencontré un franc succès, la communauté grandit chaque jour et nous approchons de la 1000ème offre publiée en un an et demi. Je teste actuellement un modèle économique pour tenter d’équilibrer les coûts du service mais la balance est pour l’instant complètement déficitaire.
Je suis toujours dans les phases 2, 3 et 4, de nouvelles fonctionnalités étant régulièrement ajoutées. Je passe également beaucoup de temps à faire connaître le projet, comme l’atteste ma présence aux Journées du Logiciel Libre 2017 le week-end dernier à Lyon. Merci à tout ceux qui sont venus me voir.
Développeur actif de logiciels libres
Comme l’explique l’article sur mon blog Manger ce que l’on prépare, les deux aventures précédentes ont mis en avant le besoin d’outils adaptés à ces projets. De plus, par mon activité d’architecte de systèmes d’information, j’ai également cherché à combler certains manques dans le métier de l’administration système, comme l’absence d’outil automatisé pour contrôler les sauvegardes. J’ai donc écrit les logiciels suivants :
Je suis donc très impliqué dans la communauté du Logiciel Libre et Open Source. J’investis du temps et de l’argent dans mes différents projets. Le projet Liberapay et son système de dons récurrents me paraît une excellente idée pour rémunérer de manière communautaire et peu contraignante les acteurs qui font progresser les choses dans notre communauté.
Je centralise donc le résumé de l’ensemble de mes actions actuelles sur ma page Liberapay et me fixe un ambitieux but de 5€ par semaine. Si vous utilisez l’un des projets décrits ci-dessus, j’espère que vous m’aiderez à l’atteindre, même à hauteur de quelques centimes par semaine Mes adresses Bitcoin et Monero sont également disponibles sur cette page.
Aujourd'hui, ce jeudi 6 avril, est une journée dédiée à un test précis : sur
la nouvelle interface alternative du partitionnement de l'installateur de
Fedora qui est Anaconda.
En effet, durant le cycle de développement, l'équipe d'assurance qualité
dédie quelques journées autours de certains composants ou nouveautés afin de
remonter un maximum de problèmes sur le sujet.
Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit
de les suivre, comparer votre résultat au résultat attendu et le notifier.
Qu'est-ce qu'est cette nouvelle interface ?
C'est une nouveauté pour Fedora 26 de fournir pour le partitionnement deux
interfaces graphique différentes. La nouvelle interface utilise celle de
l'utilitaire blivet-gui qui est plus complète que celle par défaut et
sans doute plus traditionnelle par son approche. L'objectif est de simplifier
au maximum cette étape en tentant de contenter tout le monde concernant
l'approche et la présentation de cette étape. Étape réputée difficile et
fondamentale pour l'installateur.
Vous devriez pouvoir choisir au choix lors de l'installation d'utiliser
l'une ou l'autre interface.
Les tests du jour couvrent :
La création d'un partitionnement personnalisé avec : RAID, BTRFS, LVM,
partitions standards ext2, ext3, ext4 ou xfs et sans swap ;
Chiffrement des partitions (tout ou partie des partitions) ;
Chiffrement de LVM sur un système RAID ;
Installation sur des schémas RAID ou LVM déjà existants ;
Installation sur un disque vierge.
Comment y participer ?
Vous pouvez vous rendre sur la page des
tests pour lister les tests disponibles et rapporter vos résultats. La
page wiki récapitule les modalités de la journée.
Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de
faire un tour sur IRC pour recevoir un coup de main sur les canaux
#fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur
le serveur Freenode.
De plus, si une journée est dédiée à ces tests, il reste possible de les
effectuer quelques jours plus tard sans problème ! Les résultats seront
globalement d'actualité.
Maintenant que Mark Shuttleworth vient d’annoncer l’abandon d’Unity 8 (et probablement celui de Mir), certains se posent la question du choix de GNOME sur les forums, plutôt qu’un environnement plus traditionnel comme peuvent l’être MATE ou Xfce.
Je vais donc profiter de l’occasion pour rappeler qu’un environnement de bureau ne se limite pas à la partie visible, que ce soit avec ou sans panel au bas de l’écran et autre menu principal.
Mais avant toute chose, il est important de rappeler qu’Ubuntu a toujours utilisé GNOME, ne remplaçant finalement que son shell par ce fameux Unity. Mais pour tout le reste, que ce soit les applications de base (gestionnaire de fichiers, éditeur de texte, visionneur d’images, agenda, contacts, terminal…), le centre de contrôle ou les technologies sous-jacentes (GTK+, GVFS, GStreamer, Cairo, D-Bus, dconf…), la majeure partie des différentes briques nécessaires pour pouvoir proposer un environnement complet, homogène, fonctionnel… provenaient du projet GNOME.
Ce même GNOME qui n’a aucun problème à s’appuyer sur des projets modernes tels que systemd, PulseAudio, NetworkManager… qui permettent de construire un environnement robuste et pleinement fonctionnel, parfaitement adapté à notre époque (technologies récentes, informatique dans les nuages, mobilité…), là où d’autres préfèrent partir dans des trolls sans fin, préférant voir l’utilisateur tout configurer par lui-même plutôt que de lui proposer un environnement qui juste marche.
Ensuite, et c’est le plus important, il ne faut pas limiter un environnement de bureau à un panel et un menu principal. Cinq jours avant l’annonce de Mark Shuttleworth, Dustin Kirkland, le chef de projet d’Ubuntu, intervenait sur Hacker News pour interroger la communauté et connaître ses retours et ses attentes quant à la version 17.10 d’Ubuntu. Une intervention suivie avec grand intérêt par Christian Schaller, le responsable de l’équipe Red Hat en charge de l’environnement de bureau GNOME. Deux jours avant l’annonce de Mark Shuttleworth, ce dernier publiait à son tour un long billet de blog pour rappeler que la majeure partie des demandes étaient déjà présentes dans Fedora au travers de GNOME, Wayland, libinput et autres technologies libres nécessaires pour obtenir un bureau pleinement fonctionnel.
Parmi les principaux points soulevés, on peut citer la prise en charge des écrans à haute densité de pixels, qui se trouvent être déjà fonctionnels sous GNOME avec une mise à l’échelle de 2, et dont la mise à l’échelle fractionnée (par exemple, 1.5) devrait arriver dans Fedora 27, voir même dans Fedora 26 s’ils arrivent à tout finaliser dans les temps. Il en profite d’ailleurs pour rappeller qu’en plus de sa prise en charge dans GNOME, Red Hat a employé des développeurs pour que Firefox et LibreOffice puissent utiliser GTK+ 3 et être compatibles avec Wayland.
Pouvoir utiliser les pavés tactiles avec trois doigts ou plus. Pendant longtemps, on ne pouvait utiliser que des gestes utilisant maximum deux doigts. Là encore, dans le but de supprimer une telle limitation, Red Hat a mis des développeurs sur le coup pour créer libinput et améliorer les pilotes comme celui de Synaptics, qui utilisait encore le port de communication PS/2, ce qui limitait les possibilités.
Faire des progrès sur la consommation énergétique en cas d’utilisation d’un ordinateur portable. Là encore, Red Hat a embauché des développeurs pour investiguer, corriger ce qui pouvait l’être, discuter avec les fabricants de matériel en vue d’améliorer leurs pilotes (comme ceux de nVidia, qui ne sont malheureusement pas libres).
GNOME Battery Bench
Corriger les problèmes concernant l’UEFI. Là encore, un employé Red Hat est membre du comité UEFI, ce qui aide grandement à ce que tout se passe bien avec le libre. Tout comme ils ont également embauché des développeurs pour que la mise à jour des firmwares UEFI puissent se faire directement depuis la logithèque GNOME. Christian Schaller en profite d’ailleurs pour annoncer que normalement, d’ici la fin de l’année tous les principaux fabricants devraient fournir des mises à jour au travers du service fwupd qu’utilise la logithèque GNOME.
Wayland. Les utilisateurs d’Ubuntu réclamaient Wayland. Ça tombe bien, c’est le choix par défaut sous GNOME :p Christian Schaller annonce qu’en plus du multi-DPI, on devrait voir arriver la prise en charge du HDR (grande gamme dynamique) ainsi que la prochaine génération de machines hybrides (multi-GPU), en travaillant de concert avec nVidia pour s’assurer que leurs pilotes fonctionnent parfaitement sur des systèmes libres (comprendre, sans avoir à bidouiller).
Quelque chose comme Redshift. Pour rappel, il s’agit d’une application permettant d’ajuster la température de couleur d’un écran en fonction du moment de la journée. Et là encore, ça tombe bien, avant même qu’Apple ne propose son Night Shift avec macOS 10.12.4 ou Microsoft son Mode Nuit avec la Creators Update de Windows 10, GNOME proposait déjà un mode nuit dans GNOME 3.24.
Le mode nuit dans GNOME 3.24
Amélioration du processus de mise à jour des pilotes graphiques. Je ne vais pas le répéter à chaque fois (enfin si, un peu, ça permet de bien réaliser tout ce qu’aurait dû faire Canonical dès le début), mais là encore, Red Hat possède toute une équipe pour travailler sur la pile graphique Linux (Wayland, Mesa, les pilotes…). Et un projet important, aura été le développement avec nVidia du projet glvnd qui permet d’utiliser plusieurs implémentations d’OpenGL en parallèle. Finis le risque de voir le pilote nVidia écraser les fichiers de Mesa ou inversement. Plus besoin non plus d’une bidouille à la Bumblebee pour utiliser son APU au quotidien, puis basculer facilement sur le GPU de la carte dédiée quand on souhaite se faire une petite partie de jeu vidéo.
Amélioration de la prise en charge des imprimantes. Là encore, plusieurs développeurs Red Hat s’assurent que CUPS (qui est un projet Apple, pour l’anecdote) fonctionne parfaitement bien. Et côté GNOME, la version 3.24 offre désormais une gestion des imprimantes bien plus simple et efficace.
Meilleure prise en charge du Bluetooth. Là encore, il y a plusieurs développeurs Red Hat sur le coup. Et parmi les changements à venir (sans doute dans PulseAudio 11), on peut par exemple citer une modification de Christian Kellner qui améliorera le choix du périphérique par défaut. Actuellement, PulseAudio privilégie la carte audio PCI. Viens ensuite une éventuelle carte audio USB, pour finir par un périphérique Bluetooth. À l’avenir, les choix devraient être inversés. La carte audio USB et le Bluetooth devenant prioritaires sur le PCI. Ce qui paraît plus logique. Si on branche une carte audio USB, c’est sans doute que l’on ne souhaite pas utiliser le chipset audio fournit par défaut avec la carte mère :)
Tout ça pour conclure que si l’on regarde honnêtement des bureaux comme MATE ou Xfce, qui ne gèrent pas ou de façon limitée tous les points soulevés (et tous n’ont pas été abordés, comme la prise en charge des services en ligne, la compatibilité Microsoft Exchange nécessaire aux entreprises, de meilleures applications de productivité (agenda, contacts…)), on comprend mieux le choix de Canonical de continuer à privilégier GNOME.
D’autant plus que rien ne les oblige à proposer un GNOME vanilla. Ils pourraient très bien adapter leur dock ou proposer certaines extensions par défaut.
La lecture du rapport de l’incident de base de données Gitlab me semble un cas d’école intéressant pour rappeler à la communauté l’importance de la vérification régulière des sauvegardes.
Rappelons tout d’abord les faits : le 31 janvier 2017 la société Gitlab subit une perte des données de ses utilisateurs due (entre autre) à une erreur humaine du fameux team-member-1 (qui travaille toujours chez Gitlab, information confirmée car de nombreuses personnes s’étaient inquiétées de son avenir professionnelle), erreur à associer à l’incapacité de restaurer une sauvegarde récente.
Kudos à Gitlab pour – comme d’habitude avec cette entreprise – une communication exemplaire et transparente pendant et après l’incident. Tous les détails dans le post-mortem de l’incident.
En tant qu’auteur de l’outil de vérification automatisée de sauvegarde Backup Checker, j’ai lu les différentes communications autour de cet incident avec le plus grand intérêt. Loin de moi l’idée de me réjouir d’un perte de données. C’est surtout que Gitlab était à cette occasion fort rare (je n’en connais pas d’autre en fait) la première entreprise de taille et de renommée importante à reconnaître publiquement une perte de données de ses utilisateurs liée à un défaut de sauvegarde.
Les sauvegardes, tout le monde s’en fout avant l’incident, tout le monde en veut après
Après quelques années de mise en place d’architecture systèmes chez des clients différents (startups, PME, institutions, banques, grands comptes privés, …), j’ai pu arriver à la conclusion suivante : les sauvegardes ne sont une chose sérieuse que pour les hébergeurs et les équipes chargées de sauvegardes de (très) grands groupes. Pour les autres, c’est du temps de perdu. Au pire ils n’en font pas – je l’ai constaté à peu près dans toutes les types d’entreprises citées précédemment – et au mieux, ils les ont un jour mis en place et depuis…
Pourtant en réunion, à peu près tout le monde est d’accord pour dire que les sauvegardes sont primordiales. Mais lorsque vient le moment de les mettre en place, pas ou peu de moyens sont mobilisés pour arriver à une chaîne complète de :
réalisation automatique de la sauvegarde
supervision de la bonne exécution de la sauvegarde
test de la sauvegarde
Je vois ici les administrateurs système chevronnés rigoler. En effet, nous sommes tous sous l’eau, à travailler en parallèle sur de trop nombreux projets. Il est donc illusoire de croire que l’on va pouvoir bloquer plusieurs heures régulièrement pour un sujet aussi peu sexy (en terme de revenu pour l’entreprise) que la vérification des sauvegardes.
Et même si du temps était dégagé pour cette tâche, il est important de comprendre pourquoi cette vérification n’est jamais faite : c’est qu’elle est humainement chiante à mourir ! Aucun intérêt intellectuel, aucun côté plaisant pour l’administrateur qui doit la réaliser. Pour ces raisons 99,99999% du temps, aucune vérification n’est faite.
Vérifier automatiquement vos sauvegardes avec Backup Checker
C’est dans le but de résoudre ce problème et de faciliter la vie des administrateurs système que j’ai écrit Backup Checker, un outil de vérification automatisé de sauvegarde.
Cet outil gère de nombreux formats d’archives (tar.{gz,bz2,xz}, zip, archives de fichiers) et propose d’utiliser de nombreux types de contrôles sur l’archive elle-même (taille de l’archive, droits, somme de hachage, …) ou son contenu (taille, droits, propriétaire, somme de hachage, …). Un coup d’oeil à la documentation officielle du projet vous permettra de trouver le type de contrôle qui correspond à votre besoin.
Un exemple complet d’une configuration possible de Backup Checker
Écrire la configuration d’un outil de sauvegarde consiste à décrire quel devrait être l’état de la sauvegarde au moment du contrôle. Cet état s’incarne dans un fichier de configuration lu par votre outil de vérification de sauvegarde.
Maintenant, 2 minutes de votre temps pour un exemple concret. Nous allons vérifier une archive contenant le dump d’une base de données SQL.
Nous commençons par générer automatiquement la liste complète des caractéristiques de notre archive avec la commande suivante :
Nous supprimons maintenant les paramètres trop précis (par exemple la taille précise, car demain votre dump sera sûrement plus gros) pour réaliser un template de contrôle réutilisable. Nous arrivons au résultat suivant :
Le contenu de ce fichier signifie que notre outil de contrôle de sauvegarde s’attend à trouver dans notre archive un fichier nommé database.sql dont la taille est supérieure à 6 méga-octets, dont l’uid est de 1000, le gid de 1000, les permissions en 644.
C’est simple non ? Maintenant, pour le fun, répliquons l’incident de Gitlab et générons une archive contenant un dump vide qui rendra donc votre sauvegarde strictement inutile.
Maintenant relancons Backup Checker en mode contrôle avec le template de contrôle précédemment créé.
$ backupchecker -C database-dump.conf
$ cat a.out
WARNING:root:1 file smaller than expected while checking /tmp/article-backup-checker/database-dump.tar.gz:
WARNING:root:database.sql size is 0. Should have been bigger than 6291456.
Boum, le résultat ne se fait pas attendre et Backup Checker indique immédiatement que le fichier database.sql contenu dans votre archive est vide, alors que sa taille devrait être supérieure à 6 méga-octets.
Pour aller plus loin
Nous avons donc vu que le contrôle des sauvegardes ne devrait pas représenter un problème car une solution de contrôles automatisés existe et est simple à mettre en place, à travers un fichier de configuration simple à comprendre et à manipuler.
À travers un exemple très simple mais ô combien utile dans cet article, nous avons abordé la puissance de Backup Checker et les très nombreux contrôles à votre disposition. La documentation officielle vous fournira tous les détails sur comment les mettre en place.
Les pertes de données sont des événements terribles dans la vie des entreprises quand elles impactent des données des clients. Essayons d’apprendre de nos erreurs, erreurs qui peuvent arriver à chacun de nous, et de construire des systèmes de sauvegarde plus robustes et donc plus fiables.
Si vous souhaitez soutenir la vérification des sauvegardes et le projet Backup Checker, vous pouvez effectuer un don récurrent pour l’auteur de Backup Checker Carl Chenet auprès de Liberapay. Tous les dons même les plus minimes seront un facteur de motivation important
Mes adresses 
