Catégorie : Configuration

Si nut ne détecte pas l’onduleur

En redémarrant mon Pi connecté à l’onduleur, après avoir éteint l’onduleur et le Pi, débranché câbles et alimentations, et déplacé les deux appareils, j’ai constaté à plusieurs reprises que l’onduleur n’était pas détecté après un redémarrage du système.

Je n’ai pour l’instant pas trouvé de meilleur solution que de redémarrer manuellement les services nut-monitor et nut-server, ce qui suffit à résoudre le problème.

$ sudo service nut-monitor status
$ sudo service nut-monitor restart
$ sudo service nut-server status
$ sudo service nut-server start

Par ailleurs, en écrivant ces lignes, je me rends compte que cela pourrait provenir de l’ordre de branchement des câbles, avec un branchement du câble de connexion à l’onduleur, qui arriverait après la tentative d’initialisation des services, car généralement, l’extinction de la machine liée à l’onduleur s’accompagne d’un déplacement de cette dernière et donc d’un débranchement de tous les câbles connectés.

En tous cas, si vous avez trouvé une solution à un problème similaire, n’hésitez pas à la partager, sinon, la solution manuelle est placée ci-dessus pour référence.

Note: Suite à une migration récente, nut-monitor n’est pas installé et tout semble fonctionner. Redémarrer nut-server devrait donc suffire, ou à défaut, nut-client dans le cas d’une machine cliente.

Une histoire de gamma

Depuis un moment déjà, mes écrans avaient pris une teinte rouge très prononcée et les textes de couleurs sombres, en particulier de couleur bleu foncé, été devenu difficile à distinguer. En changeant de système d’exploitation, ou en branchant un autre ordinateur: pas de problème d’affichage de couleur. Ce n’était donc pas un début de vieillissement des écrans, comme j’avais pu le penser par instant. Seul Arch Linux était concerné.

Rien à signaler du côté de redshift, qui ne semblait pas responsable, bien qu’ajoutant un petit effet rouge supplémentaire. Après plusieurs tentatives infructueuses, j’avais fini par m’accommoder de cette balance de couleur plus que douteuse. Et ce n’est que très récemment que j’ai trouvé les éléments permettant de remonter à la source du problème.

Je suis donc allé explorer la configuration de mes écrans du côté de xrandr avec la commande suivante:

xrandr --verbose

Je parcours les lignes, ne voyant rien de particulier, quand tout à coup, je tombe sur la ligne:

Gamma:      1.6:2.5:4.0

Je cherche donc comment rétablir les gammas à des valeurs « neutres ». Toujours avec xrandr et en spécifiant la source concernée avec l’option output, on pourra utiliser l’option dédiée, à savoir: gamma. A noter que j’ai également constaté une remise à plat des gammas avec l’option brightness.

xrandr --output DVI-D-0 --gamma 1:1:1
xrandr --output DP-1 --brightness 1.0

Ce ne fut malheureusement pas suffisant. Au démarrage suivant, réapparition du problème. Après de nouvelles recherches, j’ai fini par trouver que le fichier de configuration pour ma disposition d’ écran par défaut dans autorandr contenait la ligne:

gamma 0.625:0.4:0.25

Après avoir modifié les trois valeurs à 1.0, j’ai donc retrouvé des couleurs correctes et un affichage satisfaisant. Bref, une bête erreur de configuration, qui devait remonter à l’installation et à la première configuration d’autorandr.

Ansible sous macOS: initializeAfterForkError

En exécutant récemment un script ansible, depuis mon ordinateur de travail, un mac (pour disposer simplement d’une base Linux en entreprise), j’ai rencontré l’erreur suivante :

+[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

Après quelques recherches, il suffit d’ajouter la variable d’environnement OBJC_DISABLE_INITIALIZE_FORK_SAFETY à la valeur YES et de relancer le script, pour que celui-ci se termine correctement.

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

Source : StackOverflow

Restreindre les actions d’une clé ssh

Petite découverte qui mérite d’être notée, il est possible d’appliquer des restrictions à une clé SSH sur la machine cible. Dans le fichier authorized_keys, on pourra en particulier restreindre la clé à une IP source, une plage d’IP, ou encore un domaine avec le paramètre from (Voir la documentation pour la syntaxe). Le paramètre command, permet quant à lui de restreindre les possibilités d’exécution de commande en forçant l’exécution de la commande configurée une fois l’authentification réussie. Le résultat de la commande est renvoyé en retour immédiat de la commande ssh. Il existe également un certain nombre d’autres options, par exemple no-port-forwarding ou no-x11-forwarding comme précisé dans le manuel. Voir aussi « Configuring authorized_keys for OpenSSH ».

from="192.168.10.42",command="/bin/date",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa xxxx exemple@unicoda.com

Onduleur – Surveillance sur le réseau

Dans un article précédent, nous nous étions quitté avec une connexion directe par USB entre l’une des machines connectée à l’onduleur et l’onduleur lui-même. Aujourd’hui, retour sur la configuration du service de surveillance de l’état de l’onduleur, cette fois pour que la machine connectée partage l’information sur le réseau. Le but étant que les autres machines connectées à l’onduleur soit elles aussi capable de connaître son état, de déclencher un arrêt en cas de batterie faible et ainsi, de pouvoir s’éteindre avant de subir une perte de courant totale.

Je repars ici de ma configuration déjà en place. Comme la première fois, plusieurs fichiers sont à modifier, mais en nombre plus réduit. Je commence par éditer le fichier /etc/nut/upsd.users, sur la machine déjà configurée en mode client et connectée à l’onduleur, pour y ajouter un utilisateur « esclave » qui servira à mon autre ordinateur pour l’authentification des demandes d’état.

[slave]
  password = PASSWORD
  upsmon slave

Je modifie ensuite /etc/nut/upsd.conf pour que le serveur nut soit accessible sur le réseau et non plus seulement en localhost; en considérant que l’IP de ma machine est statique.

LISTEN 192.168.24.42 3493

J’enchaîne ensuite avec /etc/nut/nut.conf, où je précise que nut devra désormais fonctionner en mode serveur.

MODE=netserver

Enfin, pour terminer la configuration de la machine principale, je redémarre ups-monitor et nut-server.

Passons maintenant à la machine cliente, où, après avoir installé nut, je définie la manière dont nut va récupérer les informations d’état de l’onduleur, en modifiant /etc/nut/upsmon.conf. J’utilise ici l’utilisateur « slave » configuré précédemment.

MONITOR eaton@192.168.24.42 1 slave PASSWORD slave

Ensuite, édition du fichier /etc/nut/nut.conf afin de préciser le mode de fonctionnement de nut, à savoir ici, client du réseau.

MODE=netclient

Pour finir sur cette machine cliente, redémarrage de ups-monitor et nut-client.

Dernier point de configuration important, mais non lié à nut, au démarrage, j’ai constaté que nut n’était pas capable d’écouter sur l’IP définie dans la configuration, cela étant due, au fait que la récupération de l’IP était encore en cours d’acquisition (statique côté DHCP), au moment du démarrage de nut. Pour palier au problème, j’ai configuré mon RPI pour attendre la connexion au réseau avant de continuer plus avant dans la procédure de boot. Sur un RPI, la configuration s’effectue comme suit :

  • sudo raspi-config
  • 3 Boot Options
  • B2 Wait for Network at Boot
  • « Yes ».
  • Sauvegarder et quitter.

Une fois ces configurations réalisées sur mes deux machines, je suis en mesure de consulter l’état de l’onduleur sur chacune des machines. Un test d’arrêt forcé, m’a permis de vérifier que l’extinction de la machine cliente a bien lieu avant l’extinction de la machine ayant le rôle de serveur, et de m’assurer que l’ensemble redémarre sans assistance au retour du courant.