Archives mensuelles : septembre 2018

Top commandes linux #9 : git, mdk3, wifi over loading, hypertext, rpm

Comment ça va la team des xavki ? petit à petit l’oiseau fait son nid et vous êtes de plus en plus nombreux à vous abonner… MERCI !!! si ce n’est pas déjà fait vous pouvez le faire dans la colonne de droite je ne pollue personne avec des ventes de ebook gratuits lol et autres méthodes marketing.

Avant de commencer, l’article du blog qui a le mieux marché la semaine dernière est :

 

# git

comparer les deux derniers commits avec un diff

git diff $(git log --pretty=format:%h -2 --reverse | tr "\n" " ")

moins bien que :

git diff HEAD^ HEAD

# sed & HTML

Convertir une url en lien cliquable html (balise <a>)

cat url.txt | sed "s/\([a-zA-Z]*\:\/\/[^ ]*\)\(.*\)/\<a href=\"\">\<\/a\>/"

avec url.txt contenant des liens format : http://monlien.fr

# PS & sort

Lister le top 10 des processus en cours

ps -auxf | sort -nr -k 4 | head -10

# RedHat

Lister les 10 derniers paquets installés avec RPM

rpm -qa --last | head

Article de la semaine :

Vidéo de la semaine : brouiller un wifi avec mdk3 (démo)

https://www.youtube.com/watch?v=FF_tVKPOelY

[Ansible] : le samedi c’est debug de mon erreur avec include_tasks

Pour une fois je publie un article le samedi. Ne vous inquiétez pas, pas de spam. D’ailleurs si ce n’est déjà fait vous pouvez vous inscrire pour recevoir les articles du blog et ne pas manquer les prochains.

J’aimerai revenir sur ma mésaventure ansible de la semaine.

En fait, je suis toujours en train de monter en compétences sur ansible. Hier je testé un rôle tout simple de ntp (dont la source est le très bon geerlingguy).

Donc j’importe mon rôle :

ansible-galaxy install -p roles geerlingguy.ntp

Et là paff ça marche pas.

The error appears to have been in '/home/oki/autoform_ansible/roles/geerlingguy.ntp/tasks/main.yml': line 16, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

Pourtant l’auteur de la source est ultra fiable et les dernières mises à jour datent de 22 jours. Là j’ai un gros doute.

Donc mon premier réflexe (le mauvais), je recherche sur internet à partir du message d’erreur. Je vois donc que l’on parle de la version 2.4 et je ne suis qu’en 2.3. Bon ben je décide de monter de version.

Me voici en 2.4 et là je tombe sur une autre erreur : mauvaise reconnaissance de l’inventory.

 [WARNING]: * Failed to parse /home/oki/autoform_ansible/hosts with constructed plugin:
Unable to parse /home/oki/autoform_ansible/hosts: Syntax Error while loading YAML.

Pas de bol. Donc je recherche et là je tombe sur quelqu’un qui explique qu’un patch est passé pour régler le pb en 2.4.1. Ce que je fais je monte de version.

Ah au fait pour monter de version facilement :

sudo pip install ansible==2.4.1

et la bingo tout marche comme il faut.

Mais le  bon réflexe c’est déjà de voir la doc ansible de include_tasks. J’aurais vu que cette fonctionnalité est incrémentée à partir de la 2.4. Bon pour l’autre problème c’est autre chose.

[Docker][Ansible] : comment se créer un mini datacenter de test sans VM ? (parc de conteneurs)

Datacenter, le terme est bien prétencieux car il ne s’agit ni de machines physiques, ni de vm mais de simples conteneurs docker. L’idée est très simple et je sais que certains d’entre vous ont besoin de ce genre de script : comment créer facilement, à la volée, une série de conteneurs identiques pour reproduire des actions à la manière d’un centre serveur (orchestration, scheduler…).

Attention, ce qui est fait dans ce script et l’image utilisée (que j’ai adapté pour l’occasion) ne prennent pas en compte la sécurité nécessaire pour faire de la production. L’idée est de créer ce mini pool de conteneurs et de le supprimer une fois les manipulations réalisées. En moins de 5 minutes vous avez autant de machine que vous voulez sous la main et dans le même réseau.

Le besoin ? faire des tests sur un parc de « machines »

Pourquoi moins sécurisé que d’autres ? Par exemple, je permets de faire du ssh sur le user root depuis l’extérieur du conteneur. Je mets en place un mot de passe unique pour root et le user. Tout cela pour faire comme si il s’agissait d’une vm ou une machine physique donc de ne plus passer par un « docker exec » pour accéder à root.

Pourquoi faire ? des tests. Dans mon cas, je vais m’en servir pour me faire la main sur Ansible et runner des playbooks sur tout le parc ou sur une partie.

L’intérêt comme je l’ai déjà dit :

  • pouvoir casser et repartir avec des machines vierges en 2 minutes
  • pouvoir en lancer une bonne dizaine (voir plusieurs) sur mon pc
  • avoir un réseau facilement opérationnel
  • switcher d’OS ou d’image à volonté
  • cela reste léger car il n’y a pas de noyau embarqué

Dans le détail du conteneur

De base, j’utilise une image que j’ai créé et mis à disposition sur mon compte dockerhub (priximmo/debian-sshd). Il s’agit d’une image debian officielle à laquelle j’ai ajouté un openssh-server et dont j’ai permis la connexion en ssh sur le user root. C’est ce point qui aura été le plus difficile car je ne voyais pas pourquoi je ne pouvais pas passer root sur les conteneurs docker. Il suffit d’ouvrir /etc/ssh/sshd_config et de passer la clause PermitRootLogin à « yes ».

Le mot de passe root est aussi configuré mais je vous invite à le modifier à l’aide d’une commande docker (en lançant chgpasswd). Mais comme le but est de ne pas garder les conteneurs en fonction hors des phases de test c’est moins grave.

Le script ? c’est du shell et il est dispo sur le github

Quatre options :

  • –proxy : utilisation perso mais à vous de l’adapter vous pouvez avec prévoir d’ajouter votre proxy dans http-proxy.conf
  • –create : par défaut il créé 2 conteneurs mais vous pouvez en mettre autant que vous souhaitez
  • — drop : pour nettoyer les conteneurs créés
  • –infos : donne les ips,users des conteneurs

Dans le create, vous pouvez voir que l’on créé un user du même nom que votre utilisateur courant et on pousse votre clé publique dans le conteneur. On installe aussi python-minimal et sudo, nécessaires pour faire du ansible dans mon cas. Et à la fin de la création j’utilise docker inspect pour récupérer les ip des conteneurs pour donner un petit récapitulatif.

#!/bin/bash

###############################################################
#  TITRE: parc de conteneurs
#
#  AUTEUR:   Xavier
#  VERSION: 1.1
#  CREATION:  17/09/2018
#  MODIFIE: 
#
#  DESCRIPTION: 
#   mot de passe obtenu par :
#          perl -e 'print crypt("password", "salt"),"\n"'
###############################################################

USERNAME=$(id -nu)

if [ "$1" == "--proxy" ];then
	
	if [ -f /etc/systemd/system/docker.service.d/http-proxy.conf ];then
		sudo rm -f /etc/systemd/system/docker.service.d/http-proxy.conf
		sudo service docker restart
	fi 

fi


if [ "$1" == "--create" ];then
	
	nbserv=$2
	[ "$nbserv" == "" ] && nbserv=2
	
	# rapatriement de l'image si elle n'exsiste pas
	echo "Installation de l'image "
	docker pull priximmo/stretch-systemd-ssh:v3.1

	# création des conteneurs
	echo "Création : ${nbserv} conteneurs..."

	# détermination de l'id mini
  id_first=$(docker ps -a --format "{{ .Names }}" |grep "oki-vmparc" | sed s/".*-vmparc"//g  | sort -nr | head -1)
	id_min=$(($id_first+1))

	#détermination de l'id max
	id_max=$(($nbserv + $id_min - 1))

	for i in $( seq $id_min $id_max );do
		echo ""
		echo "=> conteneur ${USERNAME}-vmparc${i}"
    docker run -tid -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name ${USERNAME}-vmparc${i} priximmo/stretch-systemd-ssh:v3.1
		echo "    => création de l'utilisateur ${USERNAME}"
		docker exec -ti ${USERNAME}-vmparc${i} /bin/bash -c "useradd -m -p sa3tHJ3/KuYvI ${USERNAME}"
		echo "Installation de votre clé publique ${HOME}/.ssh/id_rsa.pub"
		docker exec -ti ${USERNAME}-vmparc${i} /bin/bash -c "mkdir  ${HOME}/.ssh && chmod 700 ${HOME}/.ssh && chown ${USERNAME}:${USERNAME} $HOME/.ssh"
		docker cp ${HOME}/.ssh/id_rsa.pub ${USERNAME}-vmparc${i}:${HOME}/.ssh/authorized_keys
		docker exec -ti ${USERNAME}-vmparc${i} /bin/bash -c "chmod 600 ${HOME}/.ssh/authorized_keys && chown ${USERNAME}:${USERNAME} ${HOME}/.ssh/authorized_keys"
		docker exec -ti ${USERNAME}-vmparc${i} /bin/bash -c "echo '${USERNAME}   ALL=(ALL) NOPASSWD: ALL'>>/etc/sudoers"
		docker exec -ti ${USERNAME}-vmparc${i} /bin/bash -c "service ssh start"
	done
	echo ""
	echo "Liste des ip  attribuées :"
	for i in $( seq $id_min $id_max );do

	infos_conteneur=$(docker inspect -f '   => {{.Name}} - {{.NetworkSettings.IPAddress }}' ${USERNAME}-vmparc${i})
	echo "${infos_conteneur} - Utilisteur : ${USERNAME} / mdp:password"
	
	done

fi

if [ "$1" == "--drop" ];then

	for i in $(docker ps -a --format "{{ .Names }}" |grep "${USERNAME}-vmparc" );do
		echo "     --Arrêt de ${i}..."
		docker stop $i
		echo "     --Suppression de ${i}..."
		docker rm $i
		done

fi

if [ "$1" == "--infos" ]; then

	for i in $(docker ps -a --format "{{ .Names }}" |grep "vmparc" );do
		infos_conteneur=$(docker inspect -f '   => {{.Name}} - {{.NetworkSettings.IPAddress }}' ${i})
		echo "${infos_conteneur} - Utilisteur : ${USERNAME} / mdp:password"
	done

fi

if [ "$1" == "--start" ];then
	
	sudo /etc/init.d/docker start

	
        for i in $(docker ps -a --format "{{ .Names }}" |grep "vmparc" );do
                echo "     --Démarrage de ${i}..."
                docker start $i
                #echo "     --Démarrage de sshd sur ${i}"
                #docker exec -ti ${i} /bin/bash -c "sudo service ssh start"
        done
echo ""
echo "#### Récap des infos ####"
echo ""


	for i in $(docker ps -a --format "{{ .Names }}" |grep "${USERNAME}-vmparc" );do
                infos_conteneur=$(docker inspect -f '   => {{.Name}} - {{.NetworkSettings.IPAddress }}' ${i})
                echo "${infos_conteneur} - Utilisteur : ${USERNAME} / mdp:password"
        done


fi

[Mysql] :Comment diagnostiquer et optimiser votre base et moteur ? avec mysqltuner

Mysql est une base que l’on trouve souvent derrière de nombreux outils web (par exemple wordpress…). Elle s’est généralisée avec la montée en puissance de WAMP ou LAMP. Mais souvent les moteurs et les bases installés sont installés avec des valeurs par défaut sans optimisation. C’est pourquoi, de temps en temps, il est nécessaire de faire des optimisations (défragmentation de base…).

Dans ce genre de travail d’optimisation de bases, on cherche des outils qui permettront de faire une partie du travail à notre place. Et c’est là que vous trouverez votre bonheur avec le binaire intitulé mysqltuner.

Il est facile à installer et comme vous le verez ci-dessous son rapport est plutôt bien fichu. tout cela en perl donc on aime bien.

Pour l’installer rien de plus simple :

sudo apt-get install mysqltuner

Et après on le lance simplement :

└─ $ ▶ mysqltuner

 >>  MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: ------
Please enter your MySQL administrative password: 
[OK] Currently running supported MySQL version 5.5.60-0+deb8u1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM 
[--] Data in MyISAM tables: 714M (Tables: 400)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 496K (Tables: 4)
[--] Data in InnoDB tables: 55M (Tables: 14)
[!!] Total fragmented tables: 28

-------- Security Recommendations  -------------------------------------------
[!!] User 'rundeck@%' has no password set.

-------- Performance Metrics -------------------------------------------------
[--] Up for: 18d 0h 10m 24s (136M q [87.417 qps], 261K conn, TX: 113B, RX: 23B)
[--] Reads / Writes: 80% / 20%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (15% of installed RAM)
[OK] Slow queries: 0% (81/136M)
[OK] Highest usage of available connections: 19% (29/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/266.3M
[OK] Key buffer hit rate: 99.5% (362M cached / 1M reads)
[OK] Query cache efficiency: 94.4% (123M cached / 131M selects)
[!!] Query cache prunes per day: 258354
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 508K sorts)
[!!] Temporary tables created on disk: 35% (1M on disk / 3M total)
[OK] Thread cache hit rate: 99% (1K created / 261K connections)
[!!] Table cache hit rate: 0% (400 open / 393K opened)
[OK] Open file limit used: 73% (756/1K)
[OK] Table locks acquired immediately: 99% (9M immediate / 9M locks)
[OK] InnoDB buffer pool / data size: 128.0M/55.5M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Variables to adjust:
    query_cache_size (> 16M)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    table_open_cache (> 400)

Vous avez donc une liste de recommandations qui vous permettront d’atteindre votre but pour optimiser votre moteur et votre base :

  • faire un OPTIMIZE TABLE
  • activé le slow query
  • ajuster des variables de configuration  : tmp_table_size…
  • réduire les volume de « SELECT DISTINCT » en utilisant la clause « LIMIT »

Les choses sont donc relativement bien formulées. Je pense que nous aurons l’occasion de revenir en détail sur certaines de ces actions et de leurs effets.

De votre côté utilisez vous ce genre d’outils ?