Connexion
Quelques astuces diverses, vingtième
Quoi, ce blog est encore en vie ? Oui, c’est une première je pense aussi longtemps sans billet. Le problème, c’est la motivation et la satisfaction de ce que je peux écrire, pour que ça parvienne jusqu’au partage. Malgré tout, et histoire d’enlever quelques toiles d’araignées, on va repartir sur ces bonnes vieilles astuces !
ipcalc pour IPv6 ?
Historiquement, sur Manjaro j’utilise le paquet ipcalc tout court pour valider/vérifier des subnet réseaux. Mais il est limité à IPv4, et si on veut IPv6, AUR vient à notre rescousse en nous mettant à disposition le fork maintenu par RedhHat :
$ ipcalc 2001:41d0:304:200::9bb4/64 Full Address: 2001:41d0:0304:0200:0000:0000:0000:9bb4 Address: 2001:41d0:304:200::9bb4 Full Network: 2001:41d0:0304:0200:0000:0000:0000:0000/64 Network: 2001:41d0:304:200::/64 Netmask: ffff:ffff:ffff:ffff:: = 64 Address space: Global Unicast HostMin: 2001:41d0:304:200:: HostMax: 2001:41d0:304:200:ffff:ffff:ffff:ffff Hosts/Net: 2^(64) = 18446744073709551616
Autre alternative, sur Ubuntu par exemple, sipcalc vous aidera :
$ sipcalc 2001:41d0:304:200::9bb4/64 -[ipv6 : 2001:41d0:304:200::9bb4/64] - 0 [IPV6 INFO] Expanded Address - 2001:41d0:0304:0200:0000:0000:0000:9bb4 Compressed address - 2001:41d0:304:200::9bb4 Subnet prefix (masked) - 2001:41d0:304:200:0:0:0:0/64 Address ID (masked) - 0:0:0:0:0:0:0:9bb4/64 Prefix address - ffff:ffff:ffff:ffff:0:0:0:0 Prefix length - 64 Address type - Aggregatable Global Unicast Addresses Network range - 2001:41d0:0304:0200:0000:0000:0000:0000 - 2001:41d0:0304:0200:ffff:ffff:ffff:ffff
Des sons de vague dans le terminal ?
Non pas que les baignades me manquent, mais tout de même, sans être accro à la mer, un son de vague, c’est toujours apaisant (limite je m’endors avec). Alors jouer un son de vagues via le terminal, ça coûte moins cher en ressources qu’une vidéo YouTube 
play -n synth brownnoise synth pinknoise mix synth 0 0 0 15 40 80 trapezium amod 0.2 20
Il faut le mentionner, play est une commande qu’on retrouve dans le paquet « sox », disponible dans toutes les bonnes crèmeries/distributions.
OpenSSH et format de clé privée « legacy »
Ah oui tiens, une belle surprise qui m’est arrivée au taf. Mise en place d’un Rundeck qui, pour le SSH a décidé d’utiliser une bibliothèque Java de mes deux plutôt que le SSH natif de l’hôte (du container en l’occurrence, mais on s’en fout). Souci, quand on génère la clé SSH sur un système récent, voilà le résultat de l’entête de la clé :
$ ssh-keygen -t rsa -b 2048 -f private.key $cat private.key -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEb (...)
Et l’implémentation en Java ne supporte que l’ancien format « RSA ». L’astuce, c’est de changer le format de la clé en modifiant la passphrase, et donc le format au passage (ouais c’est pas trivial comme méthode) :
$ ssh-keygen -p -N "" -m pem -f /path/to/key
-N vide si pas de passphrase, sinon mettez la votre ou une autre si vous souhaitez la changer par la même occasion.
Liveness Probe sur container php-fpm dans Kubernetes ?
Eh oui, il arrive dans certains contextes qu’on sépare l’exécution de php-fpm du serveur web (quand c’est Nginx par exemple le serveur web, et non on met pas tout dans le même container, bandes de gros dégueulasses). Pour vérifier son état de santé, on peut lancer la commande suivante en guise de Liveness Probe :
readinessProbe:
exec:
command:
- sh
- "-c"
- "SCRIPT_FILENAME=/ping /usr/bin/cgi-fcgi -bind -connect localhost:9000"
On aura pris soin évidemment de configurer le ping dans le pool fpm embarqué :
pm.status_path=/status ping.path=/ping ping.response=pong
Obtenir l’uptime d’un container ?
Comme le brouillon a trainé pendant un temps beaucoup trop long et que j’ai pas pris suffisamment de notes, je n’ai plus de contexte particulier (j’aime bien avoir le contexte, pourtant). Enfin bref, j’ai eu à un moment donné besoin d’avoir l’uptime d’un container, vu par l’hôte, sans accès au runtime. Ben si on cherche bien, on peut récupérer l’uptime du processus démarré par le container via des options de ps :
$ ps -eo pid,comm,lstart
PID COMMAND STARTED
1 init Sat Jul 31 11:15:54 2021
2 init Sat Jul 31 11:15:54 2021
3 bash Sat Jul 31 11:15:54 2021
4 terminator Sat Jul 31 11:15:54 2021
32 dbus-launch Sat Jul 31 11:15:54 2021
33 dbus-daemon Sat Jul 31 11:15:54 2021
35 at-spi-bus-laun Sat Jul 31 11:15:54 2021
Faire le total des pages des supports PDF en ligne de commande
Pendant ma préparation à la certification Google Cloud Professional Architect (que j’ai eu, champagne ! Bon c’était en Décembre dernier déjà, mais c’est pas grave), j’ai accumulé les supports PDF des formations préparatoires à la certification. C’était assez touffu — 65h de formations prévues, ateliers compris–, et en discutant d’un éventuel partage des documents, j’ai voulu savoir à quel point c’était dense. Avec tous les PDFs dans le même dossier, et grâce à qpdf, voilà à quoi on peut s’attendre :
$ find . -name "*.pdf" -exec qpdf --show-npages {} \; | awk '{s+=$1} END {print s}'
1032
Oui, c’est dense, très dense. Et le pire, c’est que ça couvre pas toutes les questions posées à l’examen, il faut quand même un cerveau !
MongoDB est un con
J’avoue, j’étais un peu énervé. Déjà que je suis pas spécialement fan (parce que je pratique pas assez, certainement), mais là, quand même… Sur mysql/mariadb, dans un dump vous avez à disposition moultes métadonnées très pratiques pour savoir si ça peut bien ou mal se passer à l’importation, Dedans, la version du serveur et de l’outil de dump utilisé.
Apparemment ce n’est pas le cas avec mongoDB, en voulant transférer les utilisateurs, voilà ce que j’ai eu comme erreur pendant la restauration :
#commande du duump $mongodump --db admin --collection system.users #commande de restauration $ mongorestore -d admin admin 2021-01-20T10:47:23.897+0100 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2021-01-20T10:47:23.897+0100 building a list of collections to restore from admin dir 2021-01-20T10:47:23.897+0100 assuming users in the dump directory are from <= 2.4 (auth version 1) 2021-01-20T10:47:23.898+0100 Failed: the users and roles collections in the dump have an incompatible auth version with target server: cannot restore users of auth version 1 to a server of auth version 5
La solution, dumper la collection « system.version » avec celle des utilisateurs parce que sinon il l’inclut pas de lui-même !!!
$ mongodump --db admin --collection system.users --collection system.version
Vérifier les services en erreurs
Après l’incendie d’OVH et surtout le redémarrage du serveur, je me suis retrouvée face à une VM redémarrée mais plusieurs services en échec à cause de la lenteur (systemd arrête généralement ses actions au bout d’1m30s). Pour afficher la liste des services HS, c’est simple :
[root@vox ~ ]# systemctl list-units --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● b3.service loaded failed failed LSB: Starts b3 Server Daemon ● certbot.service loaded failed failed Certbot ● systemd-modules-load.service loaded failed failed Load Kernel Modules ● webmin.service loaded failed failed LSB: Start or stop the Webmin server
Et hop, on est bon pour des start manuels (et découvrir quelques services zombie du passé qui n’ont rien plus à faire là aussi, mais ça, c’est une autre histoire :D).
Pas de dig ? Les alternatives !
Eh oui, dig ne fait pas partie des commandes de bases dans toutes les distributions, il fait souvent partie d’un paquet « dns-utils » (ou dnsutils, ou dns-tools, aucune distrib n’utilise le même nom !!), et pour des raisons fréquentes d’optimisation, c’est encore moins souvent ajouté dans des images docker. Il est donc possible de reposer sur certaines alternatives.
La commande host est embarquée dans bind9-host, qui peut être souvent installée en dépendance d’un autre package. Idem pour getent, beaucoup plus facile à trouver, puisqu’il est fourni par libc-bin, du assez bas niveau cette fois :
$ getent hosts blog.seboss666.info 91.121.61.180 blog.seboss666.info $ host blog.seboss666.info blog.seboss666.info has address 91.121.61.180
Après on en convient, pour du débug de résolution DNS plus avancée, dig reste une très bonne trousse à outils
Ansible : environnement conditionné !
Que j’en ai chié pour ça. Je devais travailler dans un environnement particulièrement contraint où les machines n’ont pas de réseau public, pas d’accès au réseau extérieur, et même pour joindre nos propres outils, un proxy spécifique dans le réseau privé a été mis en place. Et je travaille sur deux datacenters différents, l’un en France, l’autre en Belgique, donc avec des proxy différents.
Je peux passer les proxys en variables d’environnement, mais il faut pouvoir identifier si l’on se trouve en France ou en Belgique. Par chance les domaines des machines permettent facilement d’identifier leur localisation, et c’est là-dessus que je joue avec Ansible, et des groupes de variables :
vars:
proxy_fr_env:
http_proxy: "http://proxy_fr.domain.tld:3128"
https_proxy: "http://proxy_fr.domain.tld:3128"
proxy_be_env:
http_proxy: "http://proxy_be.domain.tld:3128"
https_proxy: "http://proxy_be.domain.tld:3128"
tasks:
- name: force chef-client configuration
shell: "chef-client -c {{ chef_path }}/client.rb -o lin-chef-client"
environment:
"{{ proxy_be_env if 'belgium' in inventory_hostname else proxy_fr_env }}"
Ici, je met l’environnement au niveau des tâches qui en ont besoin, mais si vous pensez que c’est plus simple de foutre l’environnement au niveau global, ça fonctionne aussi
Ubuntu et WSL : mais c’est quoi ce masque ?
Je vais pas revenir sur mon setup WSL, vous le connaissez (sinon c’est à relire par ici). Un truc qui m’a fait chier pendant un bon moment sans que je me penche sur le problème avant trop longtemps, c’est le masque par défaut, umask de son petit nom. En effet, sur une installation fraiche d’Ubuntu WSL, si on vérifie c’est moche :
$ umask -S u=rwx,g=rwx,o=rwx
Ce qui veut dire que tous les fichiers et dossiers seront avec des permissions pas du tout adaptées au schéma habituel des distributions dans le reste du monde (des vraies installations de Linux, en gros), c’est à dire que c’est open bar pour tous les utilisateurs de l’installation (666 pour les fichiers, 777 pour les dossiers). Tout ça parce que sous Ubuntu, le masque par défaut est géré par un plugin pam_umask, mais pam n’est pas exploité par défaut dans ce cadre précis de WSL. Du coup, faut aller soi-même ajouter le correctif dans /etc/profile.d/umask.sh (à créer évidemment) :
umask 022
Et on peut lancer la commande à chaud si on en a besoin tout de suite sans relancer tout le bousin. On peut aussi adapter le masque si on veut du fichier privé par défaut (le masque sera alors 077).
Bon, est-ce que ça va permettre de décoincer un peu les sorties sur le blog ? l’avenir nous le dira. J’ai les mains actuellement dans les migrations, VPS tout d’abord, big serveur ensuite, et surtout l’ansiblisation de toute ça, sachant qu’il va y avoir Debian 11 bientôt dans l’affaire, sait-on jamais, y’aurait peut-être quelque chose à en dire !
