Pensées Libres dans un Monde Binaire
Tout ce qui concerne l’installation de logiciel ou service sur serveur ou sur un poste client.
In this article, I will list the steps needed to deploy an Elasticsearch cluster on a private Google Cloud Platform (GCP) Kubernetes cluster using Helm, from creating a docker image with Elasticsearch, to the creation of a private Kubernetes cluster and more.
Let’s begin.
Continuer la lecture de « GCP Private Kubernetes cluster for Helm installation of Elasticsearch »Au début de l’année 2018, j’avais effectué de nombreuses transformation du côté de mon LAN, transformations que j’avais évoqué brièvement dans « Du côté du LAN« , s’en prendre le temps de rentrer dans les détails. A ce moment là, j’avais effectué un changement de firmware sur mon routeur R7000, afin d’utiliser AdvancedTomato. Interface moderne, gain en fonctionnalités et en personnalisation, il m’est difficile d’envisager un retour en arrière.
Petit bémol à l’horizon, il n’y a pas eu de mise à jour effectuée sur ce firmware depuis novembre 2017. C’est pourquoi, en ce début d’année 2019, j’effectue une nouvelle migration, cette fois vers FreshTomato. Le projet est actif depuis plusieurs mois déjà et semble globalement plutôt stable, d’après les retours que j’ai pu lire sur la toile. Le projet est un fork de TomatoByShibby, système qui constituait déjà la base de AdvancedTomato, AdvancedTomato apportant surtout une refonte graphique de l’interface.
Pour l’installation de AdvancedTomato, je m’étais aidé de la vidéo « Netgear R7000 – How to install Tomato-ARM » dont je retiens les étapes d’installation suivantes:
Par ailleurs, j’avais noté cette discussion explorant les moyens de désactiver l’allumage des différentes LEDs du routeur et éviter l’effet sapin de Noël la nuit. Possibilité maintenant offerte directement dans l’interface web du firmware.
Parmi les autres informations à noter, les informations de connexion des deux images « initial » et « AIO » de FreshTomato sont les suivantes :
Ayant eu besoin de davantage d’informations dans les logs, j’ai cherché comment augmenter le niveau de verbosité, la commande à utiliser est donc nvram set mwan_debug=8 suivie d’un nvram commit , 8 étant le niveau maximal et 0 le niveau minimal.
Après maintenant plusieurs jours d’utilisation, je n’ai pas détecté de problèmes particuliers une fois la connexion établie. J’ai toutefois rencontré quelques problèmes à l’établissement de la connexion, car celle-ci ne s’effectue pas correctement lors du premier échange de récupération des paramètres IP auprès du DHCP du fournisseur d’accès. Le routeur reçoit bien une IP (172.16.77.155) et un masque de réseau (255.255.255.255), mais pas de passerelle (0.0.0.0), donc pas de connexion WAN. Déclencher immédiatemment une demande de renouvellement du bail DHCP via le bouton renew de l’interface permet de recevoir une configuration valide. Il me semble donc que la première négociation effectué au démarrage ou après application d’une nouvelle configuration du réseau, n’envoie pas les options d’authentification 77 et 90 requises par le serveur DHCP.
Pour palier à ce problème, j’ai ajouté le script suivant dans l’onglet « WAN Up (main) », qui vérifie la présence d’une passerelle valide une fois la connexion WAN établie. Dans le cas contraire, la connexion est réinitialisée afin de forcer une nouvelle requête DHCP, valide cette fois.
if [ "$(nvram get wan_gateway)" = "0.0.0.0" ]; then service wan restart fi
Afin de parer à toutes éventualités, j’ai également configuré la vérification périodique de l’IP de la passerelle, via le service de cron proposé par le firmware.
[[ "$(nvram get wan_gateway)" = "0.0.0.0" ]] && service wan restart
Reste maintenant à profiter de ce nouveau firmware et à croiser les doigts, pour que celui-ci soit aussi stable que son prédécesseur !
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-config3 Boot OptionsB2 Wait for Network at BootUne 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.
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 :
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 :
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.