Quelques astuces diverses, vingtième

Twitter Facebook Google Plus Linkedin email

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 :

Autre alternative, sur Ubuntu par exemple, sipcalc vous aidera :

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 😛

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é :

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) :

-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 :

On aura pris soin évidemment de configurer le ping dans le pool fpm embarqué :

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 :

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 :

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 :

La solution, dumper la collection « system.version » avec celle des utilisateurs parce que sinon il l’inclut pas de lui-même !!!

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 :

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 :

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 :

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 :

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) :

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 !

2
Poster un Commentaire

avatar
2 Fils de commentaires
0 Réponses de fil
1 Abonnés
 
Commentaire avec le plus de réactions
Le plus populaire des commentaires
2 Auteurs du commentaire
AlexDavid_5.1 Auteurs de commentaires récents
  S’abonner  
le plus récent le plus ancien
Notifier de
David_5.1
Invité
David_5.1

Pour dig, host et getent, il y a quand même une différence importante qui est que getent et host (je crois que ce n’était pas le cas dans des versions anciennes) utilisent la résolution DNS du système et donc ce qui est configuré dans /etc/nsswitch.conf et l’intégralité de /etc/resolv.conf là où dig et drill utilisent uniquement les lignes nameserver de /etc/resolv.confet pas par exemple les search, domain et options éventuels. Dit autrement avec nameserver 9.9.9.9 et search seboss666.info dans le /etc/resolv.conf, dig blog renverra que blog. n’a pas d’enregistrement A associé, là où getent blog comme ssh blog comprendront que… Lire la suite »

Alex
Invité
Alex

Bien sympa ce billet !