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 »

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

[Routeur] Firmware alternatif: passage à FreshTomato

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:

  • Remise à zéro de la configuration du système du routeur.
  • Installation de l’image initiale du firmware.
  • Installation de l’image AIO (All In One) du firmware.
  • Suppression du contenu de la NVRAM.
  • Redémarrage

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 :

  • Initial image : admin/password
  • AIO image : admin/admin

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 !

YtAutoDark – Publication sur le Chrome Web Store

En ce début d’année, j’ai pris un peu de temps pour effectuer quelques modifications cosmétiques sur l’extension YtAutodark publiée en octobre sur Firefox et que j’avais présenté dans l’article [Extension Firefox] yt-auto-dark. Ajout d’une icône relativement simple, gestion des langues dans un dossier dédié et modification d’autres propriétés du manifest de l’extension pour pouvoir la publier également dans le Chrome Web Store.

L’extension est donc dès à présent disponible pour Chrome sous le nom Thème Sombre Automatique pour Youtube™.

[ArchLinux] Choix de la sortie son par défaut

Après avoir effectué une mise à jour et redémarré mon système il y a de cela un mois environ, j’ai constaté que je n’avais plus aucun son en sortie de mes haut-parleurs. Après bien des recherches, j’ai remarqué que le son sur la sortie HDMI semblait fonctionner.

En cherchant les sorties disponibles sur ma machine, je découvre donc que la sortie 0 utilisée jusqu’à présent, du moins dans mes souvenirs, est désormais la sortie HDMI. J’indique donc au système d’utiliser la sortie 1 :

pactl set-default-sink 1

Retour du son dans mes haut-parleurs et vérification de la sortie utilisée.

# pactl list sinks short
0 alsa_output.pci-0000_01_00.1.hdmi-stereo-extra2 module-alsa-card.c s16le 2ch 44100Hz SUSPENDED
1 alsa_output.pci-0000_00_1b.0.analog-stereo module-alsa-card.c s16le 2ch 48000Hz RUNNING

En outre, lorsqu’il s’agit de débuger un problème de son, je commence généralement par faire un tour du côté de alsamixer et pavucontrol.

Toutefois, il s’avère que si cette opération suffit pour la session courante, la configuration ne persiste pas au redémarrage du système. Pour configurer la carte par défaut, je commence donc par lister une nouvelle fois les sorties disponibles.

# pacmd list-sinks | grep -e 'name:' -e 'index:'
  index: 0 name: <alsa_output.pci-0000_01_00.1.hdmi-stereo-extra2>
* index: 1 name: <alsa_output.pci-0000_00_1b.0.analog-stereo>

Ensuite, j’édite le fichier /etc/pulse/default.pa pour y ajouter la ligne suivante :

set-default-sink alsa_output.pci-0000_00_1b.0.analog-stereo

Après un redémarrage du système, le son sort à nouveau de mes hauts-parleurs.