Confinement !
Seul dans l’appartement que j’occupe.
Seul ?
Non, pas tout à fait.
Pensées Libres dans un Monde Binaire
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 »Quelques points de réflexions concernant la question de l’autonomie énergétique, plus particulièrement en électricité. Autonomie au sens de produire en majorité l’énergie que l’on utilise.
On distingue deux façons d’utiliser l’énergie auto-produite. En premier lieu, on parlera d’auto-consommation, où l’énergie électrique produite (par des panneaux solaires, une éolienne, …) est réinjectée directement dans le réseau, parfois contre rétribution. Dans ce cas-là, l’énergie produite est directement consommée au niveau de l’habitation. En cas de surplus, l’énergie restante profite aux utilisateurs à proximité. La deuxième façon de gérer sa production électrique, consiste à la stocker dans des batteries, afin de pouvoir l’utiliser au moment voulu. Énergie immédiate, ou énergie pilotée, l’un n’excluant pas l’autre. Il doit être possible de faire de l’auto-consommation et de stocker le surplus dans des batteries.
Petit regard sur la norme « RT2020 », à priori en préparation, mais dont je n’arrive pas à mettre la main sur un seul brouillon de texte pour en connaître le contenu exact. De nombreux sites mentionnent l’obligation de passer à la construction de bâtiment « à énergie positive », c’est-à-dire que le bâtiment va produire plus que ce qu’il ne consomme. Pourquoi pas. L’idée ne me semble pas mauvaise à première vue, mais soulève quelques questions. Questions que se posent certainement toutes personnes ayant envisagé la production de courant pour une utilisation à l’échelle d’un logement.
Le problème principal de l’auto-consommation électrique sans stockage qui m’apparaît, réside dans le mode de production des énergies renouvelables et l’organisation de nos sociétés modernes. En effet, dans un monde où le lieux de travail est situé à plusieurs kilomètres, ou dizaines de kilomètres du lieu d’habitation, et donc de production de l’énergie, et en ajoutant à cela des horaires de travail simplifiés de 9h à 17h. Ajouter le temps de trajet domicile – travail et vous obtenez une habitation majoritaire vide au moment des pics de production de la dite habitation (moins vrai avec l’éolien et pour le cas du travail de nuit). Bref, si je prends une situation hypothétique inspirée de ma situation personnelle, en gros, il y a production d’énergie lorsque je suis absent, et lorsque je suis présent dans mon logement et que j’utilise donc de l’énergie, il n’y a pas, ou peu de production.
Pour utiliser l’énergie produite en journée et injectée dans le réseau car non consommée, il faut des centrales nucléaires, ou hydrauliques afin de me fournir de l’énergie lorsque j’en ai besoin et que je n’en produit pas. Si on liste les points de dépenses électriques continues dans un foyer classique, je trouve réfrigérateur/congélateur, chauffage (radiateur, ou électronique de chaudière), ventilation et enfin réseau ethernet (modem, routeur, switch, serveur). En fait, pour être certain de consommer la totalité de l’énergie produite, il faudrait alors sous-dimensionner l’installation, afin de s’assurer que toute l’énergie produite corresponde aux besoins minimum du logement.
Pas de solution tranchée donc, mais l’installation de quelques batteries est incontournable, si l’on souhaite bénéficier d’une réserve de courant en cas de coupure. Un peu comme un onduleur à l’échelle du logement, mais sans l’aspect correction du signal électrique. Pour la partie surplus de production, il serait juste que toute l’énergie injectée dans le réseau conduise à une rémunération, pas forcément à hauteur du prix d’achat d’énergie pilotée, ce qui ne semble pas toujours être le cas en cas d’installation de faible puissance (d’après les témoignages que j’ai pu lire ou entendre).
Je m’arrête ici pour cette première partie, qui pourra être développée par la suite, enrichie, prolongée, si le besoin ou l’envie se fait sentir.
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
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 !