Configuration – Page 3

Récupération de variables système sur Windows

Aujourd’hui j’ai installé Python et Django sur mon système Windows pour essayer de faire un petit site web rapidement, disons avant la fin de la journée.

Je commence donc ma configuration sur mon système Windows et en parallèle je fais la même chose en SSH sur une console MSYS2,une VM en mode console d’un système linux pour faire simple.

Sur windows je teste alors que sur la console MYSYS je suis connecté à mon serveur dédié de l’autre côté de la France mon serveur de production en quelque sorte.

Arrivé à l’étape d’installation de Django sur mon Windows, j’ai un message qui attire mon attention. Il semblerait qu’il manque un chemin dans PATH.

Pas de soucis. Touche Windows, j’écris « path » et j’appuie sur entrée. Je me retrouve sur les propriétés système.

Un clic de plus sur « Variables d’environnement… » et je me retrouve devant deux choix.

Variables utilisateur pour MonOrdinateur
Variables système

Dans les deux cas j’ai accès à une variable PATH que je peux modifier. Je ne me pose pas plus de questions et je modifie la variable Path dans variables système et y ajoute mon chemin.

Je valide tout, je suis content, tout va marcher et la commande

django-admin --version

devrait enfin m’afficher quelque chose à l’écran. Mais ce n’est pas le cas…

Je retourne dans les propriétés système et je commence vraiment à avoir peur. Plus aucuns chemins n’est accessible dans la liste PATH des variables système. Je pose la question à mon moteur de recherche qui m’indique qu’une restauration est le seul moyen de retrouver mes données perdues. Mais pour cela, il faut un point de restauration.

Je n’ai pas de point de restauration actif, la protection du système semble désactivée.

Je continue les recherches avec de moins en moins d’espoir de pouvoir redémarrer mon système dans de bonne condition. Pour ce qui ne le savent pas, les variables système dans PATH conditionnent beaucoup de chemins vers des exécutables utiles au bon fonctionnement de votre ordinateur.

Plus d’une heure passe, en désespoir de cause je récupère quelques PATH sur un autre ordinateur et un ami m’envoie les siens, mais je vois bien qu’il n’y a pas tous les chemins que j’avais avant de tout casser.

Quand mes recherches prennent un tournant inattendu. Je trouve enfin quelque chose d’intéressant. On peut exécuter la commande set pour lister et modifier les variables d’environnement et système propre à l’exécution d’un interpréteur de commande (CMD). D’ailleurs si on modifie des chemins dans l’interpréteur et qu’on le quitte, les chemins ajoutés ne sont pas sauvegardés. De la même manière si j’ai modifié les variables PATH par l’interface graphique sans relancer l’interpréteur celui-ci connait encore les anciennes valeurs de PATH.

J’ai un sursaut d’excitation. Est-ce que j’ai encore une CMD ouverte ?

Malheureursment non. Je n’ai plus aucune CMD ouvertes dans la barre des tâches. Par contre il y a toujours MYSYS ouvert avec une connexion SSH en cours vers mon serveur.

Se pourrait-il que j’avais la solution pour récupérer mes variables système PATH sous les yeux depuis le début ?

Après avoir mis fin à la connexion ssh avec le serveur. Le verdict. Je tape au hasard la commande Windows « SET » dans l’interpréteur MYSYS Linux. Un résultat ! Peut être que j’ai de la chance après tout ? Je fracasse la molette pour remonter rapidement tout en haut de la sortie affichée, quand enfin j’ai ce que je cherchais !

Toutes mes variables PATH gardées en mémoire par MSYS2. Avec pour seul inconvénient un typage Unix et non Windows. Dix minutes plus tard j’ai mes variables système PATH d’origine. Et en bonus, j’ai même compris mon erreur. J’aurais du mettre mon chemin dans les variables utilisateur et vérifier qu’il était bien écrit. En plus j’aurais pu tester que tout fonctionne en le faisant avec la commande set en console avant de faire la modification réel.

Conclusion

Si vous perdez toutes vos variables système ou variables utilisateur sur Windows vous pouvez les récupérer en dernier recours si il vous reste une console ouverte avant la réalisation des modifications qui ont détruits vos chemins. Pour les trouver il suffit de taper la commande « set » ou « path » dans cette console et de récupérer et mettre en forme les chemins, puis de les réinsérer par l’interface graphique dans PATH en vérifiant si ce sont des variables utilisateur ou système.

Pour la petite astuce, ne faites pas comme moi et pensez à faire des points de restauration système réguliers.

Onduleur – Nut en client direct

Il y a de cela quelques semaines, j’ai fait l’acquisition d’une pièce manquante de mon réseau interne, à savoir: un onduleur. Je n’avais pas, jusqu’à présent, considéré cet élément comme indispensable, mais la perspective d’un déplacement professionnel de plus d’une dizaine de jours m’a poussé à l’achat. J’espère ainsi protéger mes services auto-hébergés d’une éventuelle coupure de courant.

Une coupure de courant reste un événement relativement exceptionnel, du moins dans mon environnement géographique, puisqu’après plusieurs années d’auto-hébergement, je n’ai jamais eu d’arrêt de service provoqué par un défaut d’alimentation. Après avoir considéré ces facteurs, un onduleur a donc trouvé sa place dans mon logement, à proximité du routeur, du switch, etc… N’ayant pas noté d’interruption de service durant mon déplacement, je peux en déduire que l’onduleur a rempli son rôle…, ou que le réseau électrique est resté stable, comme à son habitude.

Bref, après m’être contenté du raccordement électrique des périphériques à l’onduleur, je me suis intéressé à la configuration d’un service de surveillance de l’état de l’onduleur. Le but étant de détecter un état de batterie faible subséquent à une coupure de courant, et d’être ainsi en mesure de procéder proprement et automatiquement à l’extinction des composants critiques du réseau, serveurs et routeur en particulier.

Voici donc, à la suite, la configuration déployée sur la machine chargée de la surveillance de l’onduleur. Les deux éléments sont connectés via le cable USB fournit avec l’onduleur. Une dernière chose, mon onduleur est de marque Eaton. Entrons maintenant dans le vif du sujet.

Après avoir connecté l’onduleur, un petit tour du côté du contenu de dmesg, me permet de vérifier que celui-ci est détecté. Je procède également à l’installation de nut via aptitude install nut.

[238029.826593] hid-generic 0003:0463:FFFF.0001: hiddev96,hidraw0: USB HID v1.10 Device [EATON Ellipse PRO] on usb-3f980000.usb-1.5/input0

Avant d’aller plus loin et pour pouvoir commencer à configurer nut, il est nécessaire de déterminer le driver à utiliser pour l’onduleur. Pour trouver cette information, il est conseillé de s’aider de la page « Hardware compatibility list« . Pour ma part, je n’ai pas trouvé mon modèle dans la liste (Eaton Ellipse Pro), mais les modèles présents les plus récents et les plus proches de la gamme « Ellipse Pro », indiquent de choisir usbhid-ups.

Munis de cette information, je peux donc passer à l’édition du fichier /etc/nut/ups.conf, afin de déclarer l’onduleur dans nut.

[nom_onduleur]
        driver = usbhid-ups
        port = auto
        desc = "EATON UPS"

A ce stade, il est déjà possible d’effectuer un premier test de fonctionnement.

$ sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39

Après avoir vérifié avec la commande ci-dessus que notre déclaration de l’onduleur est correct, c’est-à-dire, que nut communique bien avec l’onduleur, je passe à l’édition du fichier /etc/nut/upsd.conf, afin de n’autoriser que les connexions provenant de la machine locale.

LISTEN 127.0.0.1

Il convient ensuite de définir un utilisateur qui sera ensuite autorisé à accéder à l’état de l’onduleur. Cette fois, les modifications sont apportées au fichier /etc/nut/upsd.users.

[nom_utilisateur]
     password = PASSWORD_HERE
     upsmon master

Pour la suite, je modifie /etc/nut/upsmon.conf, pour configurer la surveillance de l’onduleur. A noter qu’il est possible de configurer la commande d’extinction, en modifiant la propriété SHUTDOWNCMD. J’ai de mon côté configuré la propriété NOTIFYCMD, en précisant le chemin vers un script relativement simple ayant pour rôle de m’envoyer un mail pour les événements ONLINE, ONBATT et LOWBATT, comme l’indique la présence de l’instruction EXEC pour chacune des trois lignes NOTIFYFLAG.

MONITOR nom_onduleur@localhost 1 nom_utilisateur PASSWORD_HERE master

NOTIFYCMD /path/to/script/notif-ups.sh
NOTIFYFLAG ONLINE       EXEC+SYSLOG+WALL
NOTIFYFLAG ONBATT       EXEC+SYSLOG+WALL
NOTIFYFLAG LOWBATT      EXEC+SYSLOG+WALL

Enfin, le dernier fichier à modifier est /etc/nut/nut.conf, pour déterminer le mode de fonctionnement de nut. L’utilisation se limitant à une seule machine pour le moment, j’utilise donc le mode client seul.

MODE=standalone

Maintenant que l’ensemble est configuré, il est possible de récupérer les informations de l’onduleur par appel à la commande upsc nom_onduleur@localhost. Ayant réussi à obtenir les informations d’état de l’onduleur, il reste à effectuer un dernier test, en simulant une situation nécessitant l’arrêt de la machine connectée à l’onduleur.

sudo upsmon -c fsd

La demande d’exécution de l’arrêt forcé est particulièrement intéressante, puisqu’elle m’a permit de vérifier la bonne extinction de la machine surveillant l’onduleur. J’ai été un peu surpris, car l’onduleur, simule également une coupure complète et un retour du courant sur toutes les prises. Quelques appareils ont donc subi un arrêt un peu rude, mais cela m’a permis de vérifier que tout le système est capable de revenir à un fonctionnement normal automatiquement.

Il faudra néanmoins que je prévois un test de coupure complète en débranchant l’onduleur, afin de tester le comportement de l’ensemble dans cette situation. Par ailleurs, il me reste à modifier cette configuration de surveillance de l’onduleur, afin de passer à un modèle client-serveur et d’être en mesure de partager les informations d’état avec les autres composants branchés à l’onduleur et que ces derniers soient en mesure de déclencher leur arrêt avant une coupure totale du courant.

Source :

Mise à jour du système sans avoir besoin de saisir un mot de passe.

En déclenchant dernièrement la mise à jour de l’une de mes machines sous GNU/Linux à la main, j’ai été confronté, comme d’habitude, à la nécessité de saisir le mot de passe de l’utilisateur que j’utilisais pour me connecter. Après récupération du mot de passe dans mon gestionnaire, j’ai pu effectuer la mise à jour et je me suis donc interrogé quant à la possibilité de déclencher la commande de mise à jour sans avoir à renseigner systématiquement le mot de passe.

Après quelques recherches, il est possible d’arriver au fonctionnement voulu en ajoutant la configuration adéquate dans la configuration de sudo, via visudo. J’ajoute donc la ligne suivante pour mon utilisateur victor :

victor ALL=(root) NOPASSWD: /usr/bin/aptitude update, /usr/bin/aptitude upgrade

Avec cette configuration, je suis désormais en mesure d’exécuter les deux commandes suivantes sans avoir à fournir le mot de passe associé à l’utilisateur.

# sudo aptitude update
# sudo aptitude upgrade

Pratique étant donné que le seul moyen de me connecter à la machine concernée passe par l’utilisation de ma clé PGP stockée sur ma YubiKey. Plus besoin d’aller faire un tour par mon gestionnaire de mot de passe pour mettre à jour le système !

dotfiles, git et rcm

Dans un billet récent sur le thème des dotfiles, j’évoquais ma migration prochaine de stow vers rcm comme programme de gestion de mes fichiers de configuration. C’est désormais chose faite et j’utilise à présent rcm à la place de stow.

Parmi les améliorations notables apportées par rcm, la principale est la possibilité de déployer l’ensemble de mes dotfiles en une commande, et non plus en exécutant une commande stow par dossier, ou programme. Je l’avais évoqué, l’organisation de mon dépôt git a également gagné en clarté, la seule différence étant l’absence de point devant les fichiers ou dossiers à la racine du dépôt.

La migration d’un système vers l’autre s’est déroulé sans grande difficulté. Comme souvent, la première étape consiste à installer le programme. Pour une fois, celui-ci n’est pas disponible par défaut dans les paquets d’Arch Linux. Je passe donc par yaourt pour récupérer le paquet dans le dépôt AUR.

yaourt -S rcm

L’installation du paquet rcm mets à disposition quatre utilitaires: rcup, rcdn, mkrc et lsrc. Je ne rentre pas dans les détails de chacun des programmes; le programme principal à utiliser est rcup, programme responsable de l’installation et de la mise à jour des dotfiles. Avant d’exécuter la commande de déploiement, j’ai commencé par changer la structure de mon dépôt git dans une branche dédiée. Une fois la structure satisfaisante, j’ai fusionné l’ensemble dans la branche master. Avant d’effectuer la fusion, il faut s’assurer de garder un terminal ouvert, car en ouvrir un avant d’avoir effectuer le redéploiement va conduire à l’ouverture d’un terminal non configuré, dans mon cas, ouverture sur l’interface de première configuration de oh my zsh.

Revenons à nos dotfiles. Après fusion de mes branches, tous mes fichiers dotfiles existants sont désormais des liens cassés vers l’ancien emplacement des fichiers. Il est donc plus que temps de rétablir les liens pour coller à la nouvelle structure du dépôt. Pour cela, j’utilise donc rcup avec les paramètres :

x pour exclure un fichier
d pour spécifier l’emplacement du dossier dotfiles
f pour forcer l’installation (supprime le fichier existant et le remplace par un lien vers le fichier dans notre dossier dotfiles).

Ce qui donne donc quelque chose comme cela :

rcup -x README.md -x LICENSE -d /chemin/vers/dossier/dotfiles -f

J’ai eu quelques erreurs à l’exécution, étant donné que stow avait mis en place des liens symboliques directement sur certains répertoires. Les répertoires ayant changé d’emplacement, rcup n’arrive pas à y accéder pour créer le lien symbolique du fichier de configuration dans le dossier.

mkdir: ~/.config/terminator: Input/output error
ln: ~/.config/terminator/config: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/keychain.zsh: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/security.zsh: No such file or directory

Pour corriger ces erreurs, j’utilise donc unlink pour supprimer les liens symboliques existants et j’exécute une nouvelle fois mon déploiement via rcup.

unlink ~/.config/terminator

Au final, la migration de stow vers rcm m’aura demandé une petite heure environ et n’aura pas présenté de difficulté particulière. Compter également plusieurs dizaines de minutes, quelques heures peut-être, réparties sur plusieurs jours afin de me documenter, de comprendre le fonctionnement des outils et d’arrêter ma décision. La nouvelle structure de mon dépôt dotfiles me convient davantage et je trouve le fonctionnement de rcm plus simple dans son utilisation basique, mais proposant néanmoins des fonctionnalités avancées qu’il me faudra étudier pour éventuellement décider d’en faire usage. Ma préférence va donc à rcm et l’avenir nous dira si mon choix était pertinent. Enfin, il serait malvenu de tirer un trait définitif sur stow, qui doit rester un outil à ma disposition, si un cas d’utilisation adéquat se présente.

dotfiles, git et GNU stow

En septembre 2016, j’avais commencé à écrire l’introduction de cet article. J’expliquais donc que je venais de réinstaller le système d’exploitation de mon ordinateur portable, pour passer de Debian 8 à Arch Linux. À ce moment-là, c’était donc posé la question de la synchronisation de la configuration de l’environnement entre machines. Par configuration de l’environnement, je désigne ici les fichiers de configuration des différents logiciels que j’utilise, plus généralement appelés « dotfiles », car commençant par un point, ou étant stocké dans le dossier .config du répertoire utilisateur.

Pour gérer mes configurations entre machines, j’ai donc utilisé le duo Git et GNU stow depuis lors. Git bien sûr pour la synchronisation entre machines et l’historisation, et GNU stow, pour le déploiement des fichiers à leur emplacement dédié.

Fonctionnement

Par défaut, stow créé un lien symbolique dans le répertoire parent de celui à partir duquel on exécute la commande, pour tous les fichiers concernés par la commande. Ma configuration part du principe que mon dépôt git dotfiles est stocké à la racine de mon répertoire utilisateur, à savoir donc ~/dotfiles, et que toutes les commandes stow sont exécutées depuis ce dossier. L’installation de la configuration s’effectue alors en appelant la commande stow avec pour paramètre le nom du logiciel dont on souhaite déployer la configuration. Au niveau de la structure, mon dépôt git se présente donc sous la forme d’une liste de répertoire contenant chacun le chemin vers la configuration du logiciel concerné, c’est-à-dire :

soit directement le fichier si celui-ci est stocké directement à la racine du répertoire utilisateur: c’est le cas par exemple du fichier .gitconfig.
soit dans une arborescence de répertoire correspondant à son emplacement: par exemple pour i3, la configuration est stockée dans ~/.config/i3, j’ai donc dans mon dépôt un dossier i3 contenant l’arborescence .config/i3.

Voici un extrait de mon dépôt en image pour expliciter la situation.

Ainsi, pour déployer le fichier de configuration de Git, j’exécute la commande suivante, depuis mon dossier dotfiles:

stow git

Ce qui aura pour effet de créer un lien symbolique .gitconfig vers le fichier .gitconfig de mon dépôt git. Si on souhaite modifier le répertoire de destination, on peut utiliser l’option -t. Dans l’image ci-dessus, pour déployer la configuration ansible, j’utiliserai alors:

stow -t / ansible

A noter que stow effectue la création du lien symbolique à la condition que le fichier n’existe pas. Si un fichier de configuration par défaut existe déjà, il sera nécessaire de le supprimer d’abord avant de pouvoir procéder à l’exécution de la commande stow.

Dernier point, si je souhaite re-déployer la configuration git, j’utiliserai alors l’option -R, soit la commande :

stow -R git

Conclusion

Le duo git + GNU stow est plutôt efficace pour ce qui est de la gestion des fichiers de configuration, les fameux fichiers dotfiles, et pour la synchronisation entre machines. Je m’en étais également servi pour stocker et déployer facilement certains fichiers de configuration sur mes serveurs, avant de commencer à automatiser avec ansible. Si je rédige aujourd’hui, cet article sur le sujet, c’est pour garder une trace d’une méthode robuste qui m’a été utile pendant plus de deux ans. Néanmoins, la structure actuelle du dépôt git ne me convient plus autant qu’avant et je souhaiterais passer à une organisation plus proche, ou même identique à l’arborescence présente sur le disque. J’étudie donc les autres solutions de gestion des dotfiles, et m’intéresse en particulier à rcm; mais ceci est une autre histoire, pour un autre article.