
Quelques astuces diverses, deuxième

J’ai bien aimé faire le premier billet, alors je vous ai encore noté plusieurs astuces qui sont beaucoup trop courtes et où le contexte de découverte ne serait pas nécessairement intéressant pour en faire des billets à part entière. Et en écrivant ce qui est le deuxième épisode d’une nouvelle série, je pourrais presque en faire une catégorie tiens (Séries ?).
Liste d’arguments trop longue
Vous n’avez jamais eu ce message d’erreur ? Alors regardez cet exemple :
1 2 3 4 5 6 |
$ mv -v documents.old/* documents/ -bash: /bin/mv: Liste d'arguments trop longue $ ls -l |wc -l 58741 |
Mais c’est pas une raison pour les faire un par un, ça prendrait trop de temps. Passons plutot par find :
1 |
$ find documents.old/ -type f -exec mv {} documents/ \; |
Dans l’absolu, ça sera toujours super long, donc vous pouvez faire autre chose en attendant.
Filtrer la sortie d’un tail -f
Vous détestez les logs verbeux autant que moi (coucou Java) ? Si vous cherchez un message en particulier lors du démarrage d’une application, vous pouvez faire un grep sur la sortie d’un tail -f plutot que de rester hypnotisé devant un écran dégueulant des milliers de lignes de logs. Sisi, c’est faisable :
1 |
tail -f catalina.out |grep "Server startup" |
Pour l’anecdote, si vous faites un grep sur vim (quoi, ça peut arriver à tout le monde ?), vous pouvez tout de même quitter vim de manière habituelle même si vous ne voyez rien.
Vérifier tous les certificats de vos sites
Si vous cumulez les certificats provenant de différents fournisseurs, il peut être intéressant, si vous les rangez au bon endroit (typiquement, avec la configuration des virtualhosts), d’en vérifier les informations pour ne pas se faire surprendre par un certificat expiré.
1 |
mysite=""; num=0; for cert in $(find . -type f -name "*.crt"); do echo -ne "[${num}] Certificate file: ${cert}\n-------------------\n"; openssl x509 -noout -subject -in ${cert} | sed -n '/^subject/s/^.*CN=//p' | cut -d\/ -f1; openssl x509 -noout -dates -in ${cert}; echo -ne "\n"; num=$((${num}+1)); done | egrep -B2 -A3 "${mysite}$" |
Peut éventuellement servir dans un rapport mensuel envoyé par mail sur l’état d’une machine.
Purger le cache ARP
Très rare, mais il peut arriver, dans certains réseaux un peu conséquents et posant quelques problèmes de stabilité (un routeur en fin de vie qui fait un peu de la merde par exemple), qu’il faille vider le cache ARP pour retrouver une connexion stable. Ça peut se faire avec une seule boucle :
1 |
for i in $(arp -a | awk '{print $2}' | sed "s/(//g;s/)//g"); do arp -d $i; done |
Répertoire partagé VirtualBox
Dire que je me suis cassé les dents pendant des mois à faire du sudo cp <fichier> /media/sf_VM/ pour transférer des fichiers entre machine virtuelle et hôte Windows. En fait, il suffit simplement de s’ajouter au bon groupe :
1 |
sudo usermod -a -G vboxsf seboss666 |
Et de déconnecter/reconnecter la session (ou comme moi, mode bourrin redémarre). Et hop, on peut directement copier/déplacer des fichier dedans.
Purger uniquement certains éléments de la file de mail en attente
Quand vous avez soit subi une attaque sur un site, soit un test mal branlé d’envoi de mail de la part d’un développeur (les deux étant du vécu), il se peut qu’il faille faire le ménage sans perdre de message légitime. Exit dont l’arme atomique postsuper -d ALL, il faut un peu plus de travail, exemple sur une installation qui repose sur Postfix :
1 |
mailq |tail -n +2 |awk 'BEGIN {RS=""} /email.com/ {print $1}' |tr -d '*!' |postsuper -d - |
Et hop, tous les mails en @email.com à la baille. Les autres peuvent repartir une fois les vannes rouvertes et/ou votre serveur déblacklisté.
Ne pas vérifier la signature SSH d’un serveur
Cas que j’ai régulièrement quand j’essaie de me servir d’Ansible au boulot, pour une raison que j’ignore et sans que les serveurs soient compromis, il me redemande systématiquement de valider la signature de certains serveurs. Pour contourner ça, j’ai placé ces deux petites lignes à la fin de mon fichier ~/.ssh/config :
1 2 |
Host * StrictHostKeyChecking no |
Et voilà, avec un peu plus de 150 hôtes sur lequel pousser la mise à jour d’un script (avec un nombre en constante augmentation), plus de problème à devoir rester devant pour taper « yes » à tout bout de champ. A utiliser avec précaution toutefois, parce que si jamais vous l’utilisez sur un réseau non maitrisé, c’est la porte ouverte au Man-in-the-middle.
Faire le ménage dans le fichier hosts d’Ansible
Pour reparler d’Ansible, je l’utilise entre autres pour déployer/mettre à jour un script maison sur un gros groupe de machines. Pour mettre à jour le fichiers hosts afin de purger les machines qui ont disparues, et en m’assurant qu’elles sont effectivement à la retraite, je me base sur le fichier .retry qu’il crée pour indiquer les machines sur lesquelles il n’est pas arrivé au bout du playbook. Et c’est sed qui vient à la rescousse :
1 |
s.verdet@SebLBNvm:~/ansible/$ for i in $(cat playbook.retry); do sed -i "/$i/d" ./hosts; done |
Si vous n’êtes pas à l’aise, je vous conseille de faire une sauvegarde du fichier hosts auparavant.
Comme d’habitude, tout ce que je présente n’est pas forcément le plus optimisé qui soit, si vous avez des remarques à faire, des suggestions, commentaires toussa, vous commencez connaitre la musique non ? 🙂
Sinon, pour ssh, avec un
yes yes | commande
, c’est pas possible ?C’est amusant, en ce moment, je vois pas mal de gens contourner le problème d’un trop grand nombres d’arguments avec des ruses de sioux… mais pourquoi ne pas utiliser xargs ?
la page wiki : https://en.wikipedia.org/wiki/Xargs
Ca règle le problème quand il y a trop d’argument. ça traite les arguments par paquet et ça les envoie à la commande. un autre lien sympa :
https://www.cyberciti.biz/faq/linux-unix-bsd-xargs-construct-argument-lists-utility/