Carnet 6 – Confinement

Après maintenant plus d’un mois de confinement seul dans mon appartement, je prends un peu de temps pour écrire quelques lignes, sans objectif, ni fil directeur, si ce n’est quelques réflexions techniques des dernières semaines. Pas de grands changements pour moi en cette période, j’ai la chance de pouvoir faire du télétravail et d’être sur une mission qui le permet. Les interlocuteurs principaux de notre équipe résidant au Canada, nous sommes habitués à échanger en mode asynchrone pour que les informations circulent malgré le peu d’heures de travail en simultanée.

Pas de grands changements non plus du côté infrastructure de mon réseau, ou de mes services auto-hébergés. Avec les années, l’ensemble à gagner en cohérence et en stabilité, ce qui m’a permis de gagner en tranquillité d’esprit. J’ai plusieurs idées qui flottent dans mon esprit pour la prochaine itération, sans avoir vraiment pris forme pour l’instant :

  • L’amélioration de la segmentation réseau de mon LAN, en fait partie, pour séparer les différents contextes et appareils.
  • L’assemblage d’une machine serveur très basse consommation en remplacement du PI remplissant actuellement ce rôle, ou remplacer le stockage sur carte SD par un montage propre avec disque SDD.
  • La mise à jour du serveur hébergeant Unicoda est également à prévoir.

En parallèle, mon intérêt se porte doucement vers la domotique et l’électronique, en particulier, du côté capteurs autonomes à base de carte ESP8266 ou ESP32. Je commence donc les expérimentations avec panneau solaire, batterie et carte de gestion d’alimentation.

Autre sujet que j’évoquerai peut-être plus en détails dans avenir plus au moins lointain, la gestion de mes connaissances. Outre ce site, j’avais commencé, il y a plusieurs mois, à remplir une sorte de wiki et j’ai découvert récemment le principe du « Zettelkasten », où chaque idée fait l’objet d’une note, d’une entrée dans le Zettelkasten. J’en suis au stade d’expérimentation. En outre, la gestion des connaissances me renvoie en partie à la gestion de mes documents numériques, pour lesquels il manque encore une hiérarchie, une organisation, pour tout ce qui n’est pas photo, vidéo ou son. Système de gestion qui devrait permettre d’empêcher l’accumulation de documents d’intérêt temporaire, ou en tout cas, faciliter l’archivage et prévenir le tri de contenu périodique, tout en garantissant la synchronisation avec le NAS comme point d’autorité.

Quelques bugs persistants dans le fonctionnement du son sur mon système Arch Linux, et un bip dérangeant dans les consoles Webstorm sur chaque exécution de commande, laissent poindre qu’il est peut-être temps de réinstaller le système pour repartir sur des bases saines et profiter des connaissances acquises après des années d’utilisation. Et soyons fous, de scripter entièrement le processus de réinstallation et de réinitialisation des données du système, comme c’est déjà le cas pour mes services auto-hébergés.

Bref, comme souvent, beaucoup d’idées se bousculent dans ma tête, chacune à un stade de maturation différent. Le temps n’étant pas extensible, l’une ou l’autre aura la priorité selon l’envie et l’intérêt de la mise en œuvre. Je remarque néanmoins que, souvent, commencer à poser les bases de l’idée, définir quelques étapes, quelques objectifs, aident à entreprendre la réalisation et à repousser la distraction facile de média comme la télévision (autre sujet intéressant qu’il me plairait d’aborder un jour plus longuement).

Pour finir et clore cet énoncé un peu décousu, j’ajouterai que j’utilise désormais un clavier QWERTY au travail au quotidien, et que j’apprécie beaucoup l’agence des touches pour tout ce qui touche à la programmation : crochets et accolades en particulier. C’est évidemment bien moins pratique pour rédiger du français avec toutes les lettres accentuées.

Enfin, en cette période d’incertitudes tant sanitaires qu’économiques, chers lecteurs, portez-vous bien et prenez soin de vos proches. À la prochaine, et bon vent !

GCP Private Kubernetes cluster for Helm installation of Elasticsearch

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 »

Petite réflexion autour de l’auto-production d’électricité

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.

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