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.

Asus UX31E – Changement de clavier

Il y a de cela sept années environ, j’avais fait l’acquisition d’un ordinateur portable de marque Asus, à savoir le modèle UX31E. Celui-ci m’a accompagné pendant mes études et dans les pérégrinations qui ont suivi les années suivantes, lorsque le besoin d’emmener un ordinateur portable se faisait sentir.

Dernièrement, plusieurs touches du clavier ont commencé à dysfonctionner sérieusement, jusqu’à rendre quasiment impossible le processus de connexion et compromettant donc une utilisation apaisée de l’ordinateur. Résistant à l’envie de balancer le tout par la fenêtre après une vingtaine de tentative de connexion ratée, je me suis donc mis en tête de remplacer le clavier défectueux.

A l’aide d’une série de tournevis de précision, je me suis donc attelé au démontage pièce par pièce de l’ordinateur, afin de dégager le clavier des composants qui le recouvrent. L’opération en soi n’est pas spécialement compliquée, pour peu que l’on prenne son temps, que l’on note l’ordre de démontage et que l’on classe les vis retirées.

Pour avoir une idée des différentes étapes, j’ai pris connaissance du guide « Replacing an Ultrabook (Asus UX21E) keyboard« , qui ne correspond pas à 100%, mais dont les similitudes sont suffisantes pour être d’une aide précieuse. L’essentiel étant de ne surtout pas forcer pour le démontage des composants et autres câbles de connexion. Sur mon modèle en particulier, l’une des vis de la carte mère est cachée par la carte SSD elle-même vissée à la carte mère.

Une fois le clavier remplacé, on remonte tout en sens inverse, en prenant soin de ne pas oublier une quelconque connexion et on croise les doigts pour que ça démarre correctement. Après quelques secondes d’attente, le terminal apparaît, me demandant d’entrer mon login. Quelques appuis sur le nouveau clavier et les touches autrefois défectueuses, me confirme rapidement que la réparation est un succès.

Bref, une vingtaine d’euros, quelques tournevis, et un peu d’huile de coude m’auront permis de prolonger la vie de mon ordinateur. Si ce n’est pas forcément le modèle que je choisirais, si le choix était à refaire, il aurait été dommage de mettre l’ensemble de la machine au rebu, pour un simple problème de clavier. Cette petite réparation me permet donc de donner une deuxième vie à cet ordinateur; qui ne soit pas statique, un clavier externe pour prothèse, ni celle d’une reconversion en serveur. C’est sur ces quelques lignes que je vous laisse : j’ai 2GB de mises à jour à appliquer.

[ArchLinux] Problème de DHCP avec NetworkManager

La semaine dernière, j’ai quelques problèmes de récupération de la configuration DHCP à partir de mon système ArchLinux. Cela provient d’un changement effectué du côté du client DHCP interne de NetworkManager. Le bug est connu et tracé dans le ticket 64880. Si l’erreur est à priori corrigée dans le code de NetworkManager, le correctif n’est pas encore disponible au moment où j’écris ces lignes; ou bien celui-ci n’est pas suffisant. Bref, afin de retrouver une connexion fonctionnelle, j’ai donc installé un client DHCP externe: dhclient et édité le fichier /etc/NetworkManager/conf.d/dhcp-client.conf pour y ajouter les lignes suivantes:

[main]
dhcp=dhclient

Redémarrage du service NetworkManager et retour de la connexion!

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 :

[Nextcloud] Mise à jour

En ce qui concerne la mise à jour de mon instance Nextcloud, fonctionnant sur un Pi 3, avec des performances acceptables, étant le seul utilisateur, je constate à l’usage qu’il est préférable de déclencher la mise à jour en passant par la ligne de commande.

Pour référence, une fois dans le dossier de Nextcloud, on exécutera la commande suivante pour déclencher l’intégralité de la procédure de mise à jour, comprenant, sauvegarde préalable, récupération de la nouvelle version, etc.

sudo -u www-data php updater/updater.phar

On pourra aussi utiliser l’option --no-interaction afin d’enchaîner toutes les étapes conduisant à la mise à jour sans demander la validation de l’utilisateur.

Référence : Upgrade via built-in updater