Utiliser Git comme outil de sauvegarde et d’infonuagique

Git est une forge, c’est-à-dire un outil collaboratif qui permet à des développeuses (ou des développeurs) de travailler sur un projet commun et de le versionner. Ce système, doté de nombreux outils annexes, est très pratique car il permet d’isoler facilement les bugs et de les traiter. Git garde la trace de toutes les modifications. On peut utiliser Git pour développer un logiciel ou pour écrire un roman. Si vous modifiez un chapitre et que trois semaines plus tard, vous avez des regrets, pas de problème! Vous pouvez retrouver la version et ressusciter un personnage qu’entretemps vous avez assassiné pour les besoins de l’intrigue.

Lire la suite de « Utiliser Git comme outil de sauvegarde et d’infonuagique »

À l’assaut de Linux From Scratch (partie 3)

Pour ce troisième chapitre, je ne saurais trop vous conseiller de travailler avec le livre en version anglaise plutôt qu’avec sa traduction française. Cette dernière est bien faite mais on y trouve quelques approximations qui compliquent le processus. En ce qui concerne la mise en page de la version PDF, elle n’est pas toujours soignée. Donc, je vous suggère de travailler avec la version HTML du manuel, qui est bien plus aérée.

Lire la suite de « À l’assaut de Linux From Scratch (partie 3) »

À la découverte de Linux From Scratch (partie 2)

2. Le partitionnement

Pour installer Linux From Scratch, il faut commencer par créer des partitions sur un disque dur. Ce dernier peut être vierge ou bien déjà partitionné. S’il reste suffisamment d’espace libre pour pouvoir accueillir notre petite distribution moulée à la louche, ça fera l’affaire. Personnellement, j’ai choisi le deuxième disque dur de mon ordinateur, d’une capacité de 80 GB, ce qui est largement suffisant pour:

Lire la suite de « À la découverte de Linux From Scratch (partie 2) »

À la découverte de Linux From Scratch (partie 1)

La semaine dernière, tandis que je baguenaudais sur le web, j’ai découvert Linux From Scratch couramment abrégé en LFS. J’ai longtemps cru qu’il s’agissait d’un langage de programmation destiné aux enfants. Mais ce dernier s’appelle Scratch tout court et il ne faut pas le confondre avec LFS qui est un projet complètement différent.

Lire la suite de « À la découverte de Linux From Scratch (partie 1) »

DWService, une application de télémaintenance originaire d’Estonie

DWService est une application de télémaintenance qui nous vient d’Estonie. C’est une alternative libre à TeamViewer. Elle permet entre autre de prendre le contrôle d’un ordinateur à distance.


Lire la suite de « DWService, une application de télémaintenance originaire d’Estonie »

Lancer plusieurs processus sans utiliser de threads (Labortablo – 3ème partie)

Mon ordinateur est équipé de deux écrans. Par conséquent, j’ai fait en sorte que mon interface de bureau moulé à la louche, prenne en compte ce cas de figure. Dans un premier temps, j’ai utilisé le module multiprocessing. Cela me semblait être la solution idéale pour lancer simultanément un process sur chaque écran.

Seulement, il y a un léger problème. threading et multiprocessing rentrent en conflit avec des interfaces graphiques telles que tkinter. Le résultat final présente des signes d’instabilité qui ne sont pas du meilleur effet. En théorie, on peut utiliser multiprocessing avec tkinter mais toutes les interactions avec l’interface graphique doivent se faire par un seul et unique thread. Le module multiprocessing peut traiter des données et faire des calculs dans plusieurs threads, mais il ne peut pas « multithreader » tkinter! Les deux processus doivent être séparés.

Donc, dans un souci d’amélioration continue, je me suis mis en quête d’une solution alternative, et je pense avoir codé quelque chose qui comble mes attentes en terme de stabilité. Alors comment ai-je procédé? En fait, je suis parti de l’idée toute simple que pour deux écrans, il faut avoir non pas deux threads d’un même programme mais deux programmes! Et je voulais que tout le processus se déroule de manière automatique. Pas question pour l’usager, d’ouvrir un fichier de configuration pour en modifier le contenu. L’objectif était vraiment de coder quelque chose qui s’installe tout seul et qui vit sa vie sans intervention de maintenance. Mais comment faire pour donner l’illusion de lancer et d’arrêter deux threads?

  1. Situation initiale

Voici la configuration initiale avec multiprocessing.

2. Suppression de multiprocessing, modification du code et explications détaillées

Au démarrage de l’ordinateur, le programme se lance grâce au fichier start.py dont le chemin se trouve dans ~/.config/openbox/autostart.

Examinons, si vous le voulez bien, ce script. La première opération qu’il exécute, consiste à détruire tous les fichiers et répertoires antérieurs qui ne correspondent pas à la configuration par défaut (en monomoniteur, si vous me permettez ce néologisme). Il est nécessaire de partir sur une base propre:

Version standard monomoniteur

Pourquoi détruire la configuration multi-écrans à chaque démarrage? Eh bien parce que l’utilisateur peut très bien décider, un beau matin, de suppprimer un écran ou d’en rajouter un troisième. Je ne suis pas dans sa tête et je ne connais pas ses intentions.

Ensuite, vient le moment de déterminer le nombre de moniteurs. Plutôt que de compter avec ses doigts, confions cette tâche à la commande suivante:

xrandr --listactivemonitors

Résultat:

Monitors: 4
 0: +*HDMI-1 1920/698x1080/392+1920+0  HDMI-1
 1: +VGA-1 1920/477x1080/268+0+0  VGA-1
 2: etc...
 3: etc...

Je crois que c’est clair… Maintenant, le programme va créer autant de répertoires qu’il y a de moniteurs supplémentaires, et il va copier le contenu de labortablo dans chacun d’entre eux. Si vous avez quatre écrans, il va donc créer en sus de labortablo (qui est en quelque sorte le « répertoire zéro« ):

  • labortablo_1
  • labortablo_2
  • labortablo_3

Nous nous retrouvons donc avec cette configuration:

Version quadrimoniteur

Voici la ligne de code qui effectue cette opération:

if i > 0:
    shutil.copytree(
        f'{self.cwd}/labortablo',
        f'{self.cwd}/labortablo_{i}'
        )

De cette manière, si je veux apporter des modifications au code avant de le pousser dans mon dépôt Git, il me suffit de modifier labortablo, le « répertoire zéro ». Je sais qu’au prochain démarrage, les modifications seront prises en compte pour tous les autres programmes.

Ensuite le script start.py se charge de traiter les informations relatives aux écrans. Puis, il créé un fichier coords.txt pour chaque interface de bureau. Ce fichier est construit de telle sorte qu’il puisse se transformer très facilement en dictionnaire. Je trouve que cette syntaxe facilite bien la vie.

w:1920   # largeur
h:1080   # hauteur
x:0      # abscisse
y:0      # ordonnée

Ainsi, je peux passer rapidement ces paramètres aux classes qui en ont besoin. Tous les éléments graphiques vont récupérer ces informations pour configurer l’interface de bureau sur chaque écran.

args = dict()
with open('coords.txt', 'r') as rfile:
    for line in rfile.readlines():
        args[line.split(':')[0]] = int(line.strip().split(':')[1])

Le moment est venu de créer le fichier start.sh. Il va contenir tous les programmes à lancer et il sera détruit au prochain démarrage. Donc, dans le cas de figure ou il y a quatre écrans, voici à quoi ressemble ce script:

#!/bin/bash

/home/miamondo/chemin/vers/labortablo/taskbar.py &
/home/miamondo/chemin/vers/labortablo/categories.py &
/home/miamondo/chemin/vers/labortablo_1/taskbar.py &
/home/miamondo/chemin/vers/labortablo_1/categories.py &
/home/miamondo/chemin/vers/labortablo_2/taskbar.py &
/home/miamondo/chemin/vers/labortablo_2/categories.py &
/home/miamondo/chemin/vers/labortablo_3/taskbar.py &
/home/miamondo/chemin/vers/labortablo_3/categories.py &

Alors, vous allez me dire qu’il ne s’agit pas d’un script Python. Par conséquent, je ne devrais pas affirmer que Labortablo est une interface de bureau entièrment codée en Python. C’est vrai. Je le reconnais. Mais je n’ai pas d’autres choix si je veux lancer mon métaprogramme. On peut très bien lancer des fichiers *.py à partir d’un fichier Python mais j’ai ouï-dire que ce genre d’hérésie conduisait tout droit au bûcher.

Avec Python, on lance des modules, pas des fichiers, et à ce stade des opérations, je ne peux pas car il faudrait que j’utilise threading ou multiprocessing. C’est le python qui se mord la queue!

Enfin, dernière opération, je rend le fichier start.sh exécutable. Il faut le faire à chaque fois car il est détruit à chaque démarrage. Puis start.sh est lancé par start.py.

Conclusion

J’ai bien conscience du fait que cette manière de procéder est loin d’être académique mais d’une part, je m’en fiche un peu, et d’autre part ça tourne comme une horloge. J’utilise cette interface de bureau tous les jours, non pas dans une machine virtuelle mais sur mon PC principal. Il faut encore que je lui rajoute la gestion des catégories et des applications (ajouts/suppressions). Il faut aussi que je fasse le point sur tout ce qu’il y a à installer pour faire tourner le programme (xrandr, wmctrl, xprop etc…)

Voilà… Je n’oublie pas de vous souhaiter un Joyeux Nowouel et une bonne vaccination à toutes et à tous.

La planète Archlinux – Mise à jour du manuel d’installation

Bonjour,

Je viens tout juste de terminer la mise à jour de mon manuel d’installation d’Archlinux. Celui-ci compte cinq chapitres, dont quatre pour l’installation proprement dite. Le cinquième chapitre décrit un processus de post-installation personnalisée, lequel est bien évidemment facultatif.

Lire la suite de « La planète Archlinux – Mise à jour du manuel d’installation »

Chapitre 5 – Post-installation

Version PDF complète : https://miamondo.org/installer-archlinux-pas-a-pas/

5.1. Lancement du script de post-installation

5.2. Analyse des différents scripts de post-installation

5.2.1. Le script principal : archlinux_post-install.sh

5.2.2. La liste des applications à installer: pkglist.txt

5.2.3. le script tint2rc

5.2.4. menu.desktop

5.2.5. menu.xml

5.2.6. rc.xml

5.2.7. Le fichier post-install_yay.sh

5.3. Les gestionnaires de paquets pacman et yay

5.3.1. pacman

5.3.2. yay


Ton nouveau système Archlinux est opérationnel. Cela dit, ta mission n’est pas terminée. Tu dois encore installer un environnement graphique digne de ce nom. Pour l’instant, c’est une console noire qui t’accueille, et même si tu peux dès à présent accomplir beaucoup de choses en ligne de commande, une interface graphique est tout de même plus sympa.

Lire la suite de « Chapitre 5 – Post-installation »

Chapitre 4 – Installer la base du système

Version PDF complète : https://miamondo.org/installer-archlinux-pas-a-pas/

4.1. Démonter et remonter les partitions

4.2. Sélectionner le miroir

4.3. Installer la base

4.4. Configurer le nouveau système

4.4.1. Générer le fichier /mnt/etc/fstab

4.4.2. Chrooter dans le nouveau système

4.4.3. Renseigner le nom de l’ordinateur

4.4.4. Créer un lien symbolique pour le fuseau horaire

4.4.5. Sélectionner la langue du système

4.4.6. Configuration de la locale pour tout le système

4.4.7. Disposition du clavier

4.4.8. Générer l’image du noyau Linux avec mkinitcpio

4.4.9. Définir un mot de passe pour l’utilisateur root

4.5. Installer le chargeur d’amorçage

4.5.1. En mode BIOS

4.5.2. En mode UEFI

4.6. Redémarrage


4.1 Démonter et remonter les partitions

À ce stade de l’installation, tu peux très bien faire une pause-café et éteindre ton ordinateur. Mais il ne faut pas oublier de démonter les partitions au préalable. Pour cela, tu vas utiliser les commandes umount et swapoff.

root@archiso ~# umount -R /mnt
root@archiso ~# swapoff /dev/sda2 (/dev/sda3 pour la variante UEFI)

La première commande démonte de manière récursive (-R), toutes les partitions montées sur /mnt ou sur un de ses répertoires enfants. Dans la version UEFI, C’est le cas par exemple de /dev/sda1 qui est monté sur /mnt/boot/efi. La deuxième commande désactive la SWAP.

Lire la suite de « Chapitre 4 – Installer la base du système »

Chapitre 3 – Le formatage des partitions

Version PDF complète : https://miamondo.org/installer-archlinux-pas-a-pas/

3.1. Les différents systèmes de fichiers

3.2. Les commandes de formatage mkfs et mkswap

3.3. variante UEFI

3.4. Le montage des partitions en mode BIOS

3.5. Le montage des partitions en mode UEFI

Le formatage est l’opération qui convertit une partition en système de fichiers et qui permet donc de classer les données qu’elle contient, dans un ordre logique au lieu de les stocker dans un tas informe.

Lire la suite de « Chapitre 3 – Le formatage des partitions »