Un petit retour sur l’article du failover mysql avec les clusters de red hat.

Lorsque l’on test son système de failover (machines virtuelles, ou …) sans matériel de fencing (switchs/routeurs/périph dédiés), les tests d’arrêts complets (coupure de courant barbare) échouent lamentablement, car pour switcher les services d’une machine à une autre, le daemon fenced envoie un signal de reboot au serveur ayant la main sur le service via le système de fencing, et si celui-ci ne répond pas, le service n’est pas redémarré (il considère qu’il a lui-même un problème), ne permettant pas de valider le test du « Si la machine crash, est-ce qu’une autre prendra le service ? ».

Il existe cependant des services permettant de faker ces systèmes lors d’utilisation de machines virtuelles, malheureusement pour moi, je n’utilise pas le système de machine virtuelle xen directement sur red hat6, ne me permettant de de jouir des agents fence RHEV-M et libvirt pour les machines virtuelles, et désactiver l’accès au groupe de fence empêche le rgmanager de se lancer (pose de lock sur dlm-control et dlm-rgmanager qui n’existe pas sans fence) donc passage obligé à la création d’un « fake fence ».

Pour simuler le système de fence de RHEV-M (un simple client http qui balance 3 requêtes pour vérifier si la machine existe et lance l’action de reboot), j’ai donc crée un serveur Web en python, qui renvoit des XMLs complétement faux, mais qui contiennent les infos que l’agent fence_rhevm cherche, lui permettant de valider le reboot et de débloquer le service!!!

Le codage est très simple (avec une belle XSS en prime ^^, mais comme l’agent fence_rhevm crée ses propres urls de requêtes … osef ;=)) :

Une fois lancé sur une machine, il ne reste plus qu’à fournir les infos dans le cluster.conf (à titre d’exemple) :

Si jamais le script est modifié par WP, il reste accessible ici : https://raw.github.com/cipher16/script/master/fence.py (à n’utiliser que pour des tests bien sûr )

Articles similaires :

• Controller sa carte wifi atheros sous ubuntu Lucid
• Les liens du week-end
• Centre Alsace : Le prix du gazole dépasse le prix essence
• Mise en place d’iSCSI pour le partage de données
• Envoyer des mails dans le passé

BackGround
Pour mon alternance on m’a chargé de switcher le système de HA tournant sur RH5.5 depuis 2 ans avec HeartBeat/DRBD sur le nouveau système (qui existe depuis pas mal de temps, en fait ) fournit par RedHat6 pour le clustering : le RGManager, avec ses dépendances (dispo sur toutes les bonnes distro du moment).

Le but de cette manoeuvre est de permettre au service Mysql de rester accessible pour les machines du réseau en cas de crash du serveur (logiciel ou matériel) en partageant une IP et les disques contenant les données (répliqué par DRBD) du serveur Mysql.

L’utilisation et la configuration du cluter fournit par RedHat est trivial (limite choquant pour un sysadmin habitué à un florilège de fichier de configuration dans lesquels taper, ici seul /etc/cluster/cluster.conf est à toucher, bien évidement les services subissant le failover sont à configurer )

Les machines
cluster1 (192.168.1.225) sera à la fois serveur et node
cluster2 (192.168.1.224) sera seulement node
192.168.1.31 sera l’ip partagé entre les deux machines pour la mise à disposition du service Mysql

Lucy et Ricci

(J’ai désactivé selinux (setenforce 0) et iptables (service iptbles stop) pour l’install)

Pour le serveur administrant les clusters, on installe lucy qui permet d’administrer la config des clusters, ainsi que leurs lancements/reboot, …

Pour les membres du clusters, installation de ricci du serveur mysql (puisque c’est lui qu’on veut partager) et leurs dépendances :

Il faut set le password de ricci, pour configurer les nodes

Une fois les nodes préparées et lucy installé et lancé, on peut se connecter via un browser à ipduserveurlucy:8084 et ajouter les nodes :

Puis commencer à configurer les services (c’est plutôt intuitif donc je zap cette partie) le résultat de la config XML est visible à la fin.

Compilation et installation de DRBD

Passage malheureusement obligatoire, car DRBD n’existe pas dans les dépôts RedHat, donc on install une machine virtuelle RH6 (ou bien directement sur la machine de prod si vous êtes un bourrin), avec les softs suivant :

Ce qui permet, si tout c’est bien passer de chopper les RPMs dans le dossier (/root/rpmbuild/RPMS/x86_64/) :
drbd-utils-8.4.1-1.el6.x86_64.rpm
drbd-bash-completion-8.4.1-1.el6.x86_64.rpm
drbd-rgmanager-8.4.1-1.el6.x86_64.rpm
drbd-8.4.1-1.el6.x86_64.rpm
drbd-km-2.6.32_220.2.1.el6.x86_64-8.4.1-1.el6.x86_64.rpm

De les uploader et installer sur les nodes du cluster.

Configuration de DRBD

Création du fichier /etc/drbd.d/r0.res, avec l’utilisation du port de drbd par défaut (7789) et la création de la device /dev/drbd0 sur chacune des machines, avec la réplication du disque /dev/sdb1 (qui contiendra le /var/lib/mysql)

A exécuter sur les deux machines :

Passage en maitre sur l’une des deux machines pour créer le système de fichier

Qui devra retourner :

(Si il reste en Secondary/Secondary, y’a un soucis … :s).

Puis formatage de la partition (ça va tout supprimer … ), et copie du /var/lib/mysql courant sur la partition drbd

On peut maintenant supprimer le /var/lib/mysql sur LES DEUX MACHINES

Il faut maintenant configurer le failover du disque pour ensuite monter /dev/drbd0 dans /var/lib/mysql, fournir l’ip 192.168.1.31 puis démarrer le service mysql.

ATTENTION A NE PAS DEMARRER LES SERVICES AVANT LA SYNCHRO COMPLETE DES DISQUES

Une fois les disques synchro, redémarrer les services drbd, pour qu’il soit tout deux en secondary, et laisser le rgmanager s’occuper de faire switcher le master

Configuration du cluster

La configuration au format XML (la capture d’écran est beaucoup trop grande pour la version http) :

Une fois la conf mise en place (si c’est en autostart, ça devrait partir tout seul), sinon :

Les astuces du LoupZeur
Pour ne pas subir d’interblocage du rgmanager avec fence (blocage complet du service, rgmanager renvoit dans les logs un joli « Waiting for CMAN to start »), je vous conseille vivement de rajouter le clean_start=1 pour le fence_daemon.

Dans l’interface Web : Preferences -> Enable « Expert » mode puis HomeBase -> « ClusterName » -> Configure -> Fence Daemon -> Clean Start

En cas d’interblocage : 2 solutions

et si ça marche pas
modification de /etc/sysconfig/cman et mettre FENCE_JOIN à NO avec un beau

et rgmanager devrait se relancer.

bon HAing

Articles similaires :

• Fake fencing sur Red Hat6
• Changement d’adresse
• Se monter un environnement de developpement LAMP rapidement
• Tentative de Hack … quand les kikoolols attaquent!!!
• Sécurité : Installation de l’IDS Prelude sur debian

Vous êtes seul responsable de vos actes sur internet, et veillez à toujours avoir les autorisations nécessaire pour pénétrer un réseau (autorisation écrite).

J’ai eu récemment à auditer les réseaux wifi d’une entreprise suite à des problèmes wifi inconnus (oui ça met en confiance ^^) … Certes, les articles de cracking wpa sont légions sur internet, mais mon approche étant un peu différente de la normal (une commande de kikoolol s’est cachée dans cet article ), j’ai pensé utile de relater mon expérience ici.

Côté soft, j’ai utilisé la suite aircrack-ng, et pyrit/cowpatty.

On démarre une interfaces virtuelle en monitor (pour les cartes atheros)  :

airmon-ng start wlan0

Puis on commence par récupérer des handshakes WPA, on peut le faire de manière naturelle, en attendant une nouvelle handshake :

airodump --channel 1,2,3 --w audit-entx mon0

L’entreprise ayant 5 réseaux wifi sur différent canaux, l’option –channel suivie de chiffres séparés par des , permet d’enregistrer dans des fichiers préfixés « audit-entx », les handshakes nécessaires au cracking des passes.

Si besoin est, on peut demander des déconnexions des clients, pour récupérer plus rapidement les handshakes :

aireplay-ng -e "essid d'un reseau" -0 5 mon0

A partir de là s’arrête l’attaque online … ça n’aura duré d’une dizaine de minutes pour récupérer une dizaine de handshakes par réseaux wifi … un seul par réseaux aurait suffit, mais on ne sait jamais …

Cela dit, comparé à une attaque wep (en ne passant pas par l’envoi de deauth), une attaque sur un réseau WPA reste très « furtive », puisqu’aucun paquets n’est forgés, les IDS déployés sur le wlan ne découvre rien concernant l’attaque.

Pour la suite, il y a plusieurs possibilités :

Utiliser l’outil airolib (prend une bonne demi journée), qui génére une matrice de mot de passe associé à l’essid du réseau, pour ce faire, il faut un dictionnaire de mot de passe (cherchez password list sur google ou utilisez celui de backtrack 4 ) et la liste des essid sur lesquels il faut lancer l’attaque.

L’entreprise étant la seule dans les environs à utiliser du TKIP/PSK, les commandes suivante créées un fichier nommé essid avec la liste des essid répondant à mes critères, importe dans la base de données sqlite « audit-entx » les essid et la liste de mot de passe (~2 millions de mot de passes entre 8 et 32 caractères).

iwlist ath0 scan|egrep -B 10 "TKIP|PSK"|grep ESSID|awk -F\" '{print $2}' > essid
airolib-ng audit-entx --import essid essid
airolib-ng audit-entx --import passwd malistedepasse

Il faudra ensuite générer les hash associant le mot de passe et l’essid, soit pour mon cas environ 8 millions de combinaisons différentes :

airolib-ng audit-entx --batch

Cette opération peut prendre beaucoup de temps (une demi journée dans mon cas … en tournant à 300PMK/s).

et on lance le crack avec (nécessite la compilation de aircrack avec sqlite)

aircrack-ng -r audit-entx monfichier.cap

Utiliser l’outil pyrit (qui prend environ 10 minutes avec une bonne carte graphique pour moi une GTX 260 et un phantom X4 en SSE2).

Pour installer pyrit et cpyrit_cuda, suivre la manip ici, installer CUDA et le CUDAToolkit (sinon il va manquer des libs lors de la compilation du soft).

Une fois installé, on ajoute les essid et la liste de pass, et on commence le batch :

pyrit -e "monessid" create_essid
pyrit -i passwd.lst import_passwords
pyrit batch

En 5 bonnes minutes, mes 5 réseaux était « batchés » :

Plus qu’à passer au cracking :

pyrit -r monfichier.cap attack_db

Manque de pot, l’outil me renvoi une erreur d’argument de la fonction unpack … a part en mettant les doigts dans la bête, je ne pouvais rien faire. Il faut donc ensuite passer par cowpatty pour terminer le crack :

pyrit -e "monessid" -o hash export_cow
cowpatty -d hash -r monfichier.cap -s "monessid"

Et en 5 secondes on a le mot de passe (si il a le malheur d’être dans la liste de mot de passe).

Donc voilà, pour ma première expérience de cracking en WPA avec pyrit … et la première fois que j’ai pu entendre les ventilo (package Zotac) de ma GTX260 faire du gros boucan (SC2 et HON ne pompent pas assez de ressources pour passer les 75°C requit pour le lancement des ventilo xD).

Articles similaires :

• Cracking de pass via GPU (Cuda) avec Durandal (MD5, SHA, …)
• Téléchargement Direct et Linux (Tucan)
• BT3 dans les bacs … les hackeurs vont se régaler

Le but de cette technique était de recycler quelques PC sur mon réseau et gagner en puissance de calcul avec de vieux AMD 3000+ avec 1Go de ram.

Kerrighed est un cluster de type « Grappe de serveur » qui permet un truc assez sympa, il suffit que l’ensemble des machines du réseau utilisent le kernel modifié (un 2.6.20 obligatoire …) pour que l’ensemble de ces machines puissent être emulées comme une seul machine SMP partageant donc le CPU et la RAM des machines, assez sympa pour des logiciels qui bouffent de la ram et du cpu (genre firefox ?? xD).

Le gros intéret de ce type de réseaux face à des solutions comme les systèmes MPI est qu’il n’y a pas besoin d’avoir des logiciels spécifique qui utilisent l’interface en question, ici la plupart des softs qui peuvent tourner sur du kernel SMP (qui devient assez commun sur les dernières machine multi-core pour partager les calculs entre les cores d’une même machine) peuvent être susceptible d’utiliser le CPU/RAM des autres ordi.

Alors bon … d’un côté ça parait super intéressant de pouvoir ajouter la puissance de nos anciens PC, d’un autre ont se dit … c’est naze, faut installer le kernel à la main sur chacune de ces machines, de quoi repousser n’importe qu’elle geek en puissance devant le travail à fournir …

C’est là qu’intervient un truc super sympa que l’iut de stras utilisait pour faire booter les terminaux X (et que d’autre utilisent surement). Utiliser une machine comme serveur dhcp,nfs,tftpd-hpa pour faire booter d’autres machines sur un réseau (en clair, on installe le système sur une machine, et toute les autres boot dessus, permettant même de d’utiliser des machines sans disque dur, comme ça on peut ce faire une machine qui prend tt les dd et les partager sur le réseau et pouvoir rajouter une nouvelle machine en la connectant simplement au réseau et en la bootant dessus).

Pour ça, j’ai suivi un superbe tuto (en anglais, et pas trop vieux en plus) que je vais traduire et commenter avec mes superbes retour d’expériences ^^.

L’architecture :

J’ai ma machine HOST (serveur nfs,dhcp,tftpd, …) sur laquelle je fait toute mes manipulations, avec deux interfaces, la première connectée au net (histoire de pouvoir mettre à jour la machine), et la seconde connectée à mon réseau de cluster, qui a besoin d’un réseau à part, puisque j’utilise un serveur DHCP dédié à l’adressage de ces machines.

Donc voilà, pour les IPs : 192.168.0.1 est mon serveur principal, 192.168.0.10 et 192.168.0.11 sont mes deux nodes qui vont booter sur le réseaux.

L’ensemble des manipulations à suivre ce faisant depuis 192.168.0.1 (nommé HOST).

La première commande :

qui permettra d’installer l’ensemble des softs nécessaire à notre cluster.

Puis on modifie le fichier /etc/default/dhcp3-server et on spécifie l’interface sur laquelle est connecté notre cluster (eth0 étant ma connexion au net) :

Puis le fichier /etc/dhcp3/dhcpd.conf

On permet le lancement en daemon de tftp au démarrage de la machine en modifiant /etc/default/tftp-hpa

On copie notre loader pxe

On créer notre dossier de conf :

Et on edit notre fichier de boot réseau dans /var/lib/tftpboot/pxelinux.cfg/default :

Maintenant que notre boot est prêt, il faut créer le système sur lequel les autres machines vont booter :

On prépare l’import en éditant le fichier /etc/exports :

Puis un coup de

Qui peut prendre un bon bout de temps (z’avez le temps de faire un warsong voir même une instance de 30 minutes sur WoW ^^) … puis on fait un coup de

Pour changer les fichiers de config de notre « nouvelle machine » :

Puis modification du /etc/fstab

On passe par /etc/network/interfaces pour configurer notre réseau … pour moi :

Une fois que la plupart des configs sont faites, on peut passer par la compilation du kernel kerrighed.

Dans le menu ‘super ecran bleu’ :
Allez dans « Device Drivers » puis « Network device support » et choisir sa carte réseau (sinon vous n’arriverez pas à monter le root une fois le kernel booté).
Revenir au premier menu et choisir « File systems » puis « Network File Systems » et permettre le nfsV3.
On quitte et on sauvegarde la configuration (en cliquant sur « exit »).

On reprend nos commandes (on peut faire un match sur HoN là, y’en a pour une heure) :

On continue la configuration de notre systèmes en modifiant le fichier /etc/kerrighed_nodes

et on termine ici en modifiant /etc/default/kerrighed

on quitte notre chroot par un superbe :

On copie notre « booter » dans le boot et on redémarre tout nos soft :

A partir de maintenant, toute machine bootant en réseau sera capable d’utiliser le kernel compilé. (assez sympa en cyber café, ou … ).

Par contre une fois lancer, il ne faut pas oublier d’autoriser la migration des processus en se connectant sur l’une des nodes :

Et voilà … les geeks en puissance vont pouvoir faire revivre leurs premières machines ^^ (et les terminer dignement xD)

Articles similaires :

• Mysql failover sur Red Hat 6 avec DRBD et RGManager
• Annuaire LDAP et authentification UNiX/Linux
• Connecter un réseau de machines virtuelles sur un réseau local
• Primary Domain Controller sous Linux …
• Wifi ou 3G tethering sur cyanogenmod via Bluetooth ou USB