Simon Vieille

Je viens de publier le code source d'un nouveau projet : Wireguard GUI.

Pour rappel, Wireguard permet de réaliser des VPN rapidement et assez simplement. Il est multiplateforme et très robuste.

Wireguard GUI est quant à lui un logiciel écrit en Go qui pemet de gérer les connexions existantes de Wireguard depuis une application graphique. L'idée derrière cet utilitaire est de faciliter la modification des fichiers de configuration et de gérer le démarrage des interfaces. Wireguard GUI est destiné à Linux.

C'est un projet libre et il vous pouvez télécharger une version compilée depuis la page des releases. Toutes les informations techniques sont disponibles sur le dépot du projet.

Je suis un fervent utilisateur de i3wm et ça dure depuis des années ! Grâce à i3blocks, j'ai pu développer mes propres blocs initialement écrits en PHP, mon langage de prédilection. Dans un but d'apprentissage mais aussi pour gagner de préciseuses ressources (CPU/mémoire/temps d'exécution), j'ai entrepris une refonte en Go.

Ces blocs permettent de récupérer les adresses IP des interfaces réseau, son IP publique, d'activer et désactiver des connexions VPN Wireguard, d'afficher l'usage des disques, créer des lanceurs d'applications, afficher le volume du son et ce qui est joué sur Spotify, générer une barre de tâches, des indicateurs pour RSS et Atom et des messages quand des processus sont détectés.

Toutes la documentation et les liens de téléchargement sont disponibles dans le dépot du projet. Voici un aperçu des blocs en fonctionnement :

En septembre 2018, je publiais un article pour automatiser l'authentification sur Sharepoint Office365 depuis Linux. J'avais développé un outil qui réalisait le parcours d'authentification que propose Microsoft via des pages web. L'interêt de cette méthode d'authentification est de récupérer les cookies de connexion pour les injecter dans Davfs.

Après cette publication, j'ai eu quelques retours qui indiquaient que l'outil ne fonctionnait pas toujours. Les interfaces de connexion peuvent évoluer d'une entreprise à l'autre et je gérais uniquement celles que j'avais. Cette semaine, je me suis confronté à un changement de workflow chez Microsoft et je n'ai pas pu corriger le projet qui est alors devenu inutilisable. J'ai eu besoin de trouver une parade et je me suis tourné vers Playwright qui permet, en autres, de réaliser des tests fonctionnels sur des interfaces web.

Le principe est simple : on lance un navigateur et je simule une saisie utilisateur. À la fin, je récupère les cookies qui ont été générés. Voici la marche à suivre pour installer l'outil qui fonctionne avec NodeJS 16+.

user@host $ git clone https://gitnet.fr/deblan/office365-oauth2-authenticator-2
user@host $ cd office365-oauth2-authenticator-2
user@host $ make setup

Le principe est identique au précédent projet puisqu'il faut déclarer 3 variables d'environnement avec l'adresse du site sharepoint auquel se connecter, l'identifier et le mot de passe puis lancer le script. En retour, vous aurez un json qui contient les cookies et leur valeur.

user@host $ export MS_OFFICE365_SITE="https://foo.sharepoint.com/"
user@host $ export MS_OFFICE365_LOGIN="user@example.com"
user@host $ export MS_OFFICE365_PASSWORD="5eCrEt"
user@host $ node index.js
{"rtFa":"...","FedAuth":"..."}

Ces dernières semaines, j'ai réalisé plusieurs Pull Requests sur des projets écrits en Go. J'ai travaillé sur une fonctionnalité qui permet d'ajouter des informations dans le registre de paquet de Gitea, j'ai corrigé un bug sur l'outil d'intégration continue Woodpecker et j'ai proposé une fonctionnalité pour Codeberg/pages-server que j'utilise pour héberger des pages statiques. Ces contributions étaient mes premiers pas avec Go et j'ai vraiment apprécié ce langage.

Pour en apprendre un peu plus, j'ai décidé de réécrire un projet initialement en PHP. Le use case est très personnel, mais il peut sans doute plaire à d'autres personnes. Il s'agit d'un outil client/server en ligne de commande pour servir des fichiers vidéos distants.

Le projet s'appelle Mugo et les sources sont libres ! Je fourni un unique binaire qui permet de lancer le serveur et le client.

Côté serveur, il suffit de définir quel est le répertoire où se trouvent les vidéos, sur quel port écouter et l'adresse publique du serveur web qui sera démarré (API). Coté client, on définit l'adresse du serveur web (API) et éventuellement les filtres à appliquer.

Une fois le serveur démarré, le client peut s'y connecter et afficher les vidéos disponibles. Les vidéos pourront être sélectionnées interactivement avec leur numéro ou en spécifiant une plage.

Pour démarrer le serveur, la commande est simple : mugo serve. Le répertoire courant sera servi par défaut et il écoutera sur le port 4000. Il est possible de spécifier l'adresse publique du serveur avec l'argument --api-url (si reverse proxy par exemple).
Dans mon cas, l'API exposée par le serveur est accessible via un frontend Apache2. L'adresse du proxy est sous la forme https://videos.example.com. Mes fichiers sont stockés dans le répertoire /srv/videos (sous répertoires inclus). Voilà comment je lance le serveur :

$ mugo serve -d /srv/videos -u https://videos.example.com

Je peux maintenant accéder à l'API via https://videos.example.com/api/list.

Côté client, je peux afficher la liste des vidéos comme suit. Le résultat de chacunes de ces commandes sera une liste de vidéos avec un prompt interactif.

# Lire les fichiers (mpv)
$ mugo play -u https://videos.example.com

# Télécharger les fichiers (wget)
$ mugo download -u https://videos.example.com
$ mugo download -d "$HOME/Videos" -u https://videos.example.com

# Afficher que les fichiers qui contiennent "batman"
$ mugo play -u https://videos.example.com -n batman
# …et les ordonner par nom
$ mugo play -u https://videos.example.com -n batman -o name

Toutes les infos sur le projet son dispos sur Gitnet 🙂

Gitnet est la forge logicielle que je gère depuis quelques années et qui héberge la totalité de mes projets. Elle s'appuie sur l'excellentissime Gitea, un logiciel libre pour faire son propre Github/Gitlab sans dépenser des fortunes en ressources matérielles.

Gitea est un logiciel très complet mais une des fonctionnalités qui peut manquer à certain⋅e⋅s est la publication de pages web statiques via la forge. Codeberg a développé Codeberg/pages-server, un projet écrit en GO qui permet de réaliser cette fonctionnalité. Il lance un serveur web et sert les fichiers qui sont récupérés via l'API. Après l'avoir forké pour le personnalisé, il est à présent déployé sur Gitnet Pages.

Pour commencer à publier, vous devez créer un dépot pages dans lequel vous y déposerez vos fichiers. Le contenu sera accessible via https://votre-login.gitnet.page/{fichier}.

Dans le cas où vous souhaitez intégrer des pages à un dépot existant, ajoutez une branche pages puis accédez à votre contenu via https://votre-login.gitnet.page/le-depot/{fichier} :

dev@project $ git switch --orphan pages
# Si vous avez des fichiers ignorés par git qui existent :
dev@project $ git rm --cached -r .

Et si vous désirez accéder à du contenu qui se trouve sur une autre branche, il faudra la spécifier de cette façon : https://votre-login.gitnet.page/le-depot/@la-branche/{fichier}.

Vous pouvez utiliser un générateur de site static mais il faudra ajouter un CI/CD. J'ai réalisé des tests avec Hugo + Woordpecker et ça marche bien ! On build la branche ou se trouve les sources, on copie le résultat dans la branche pages et on pousse le code sur Gitnet. Voici la configuration utilisée.

Si toutefois le service venait à être pas mal utilisé, alors j'intégrerai des fonctionnalités plus avancées comme le nom de domaine personnalité. Tel qu'il est déployé actuellement, ce n'est pas possible.