La première partie de cette article est accessible par ici.

Après avoir déployé Proxmox, nous allons poursuivre la mise en œuvre de notre infrastructure de Labs sur notre serveur dédié, en procédant aux étapes suivantes :

• Sécuriser l’OS
• Paramétrer les interfaces via la WebUI de Proxmox
• Installer la VM PFSense
• Utiliser l’iptables de l’hyperviseur pour router et sécuriser les flux

Basic hardening

Je vous conseille TRÈS VIVEMENT (non en fait c’est obligatoire) d’appliquer les bonnes pratiques élémentaires en matière de sécurisation listées dans ce très bon article rédigé par OVH et qui détaille tous les points ci-dessous.

Si vous voulez creuser un peu plus, regardez également du coté des outils d’audit du genre de Lynis (ex rkhunter), c’est simple à utiliser et ça vous donnera plein de piste sur des vulnérabilités potentielles : Doc d’installation officielle

Voilà, pour ma part, ce que j’ai mis en place :

Changement du mot de passe root

Si vous avez utilisé un mot de passe simple pour éviter les risques d’erreurs lors de la configuration (comme évoqué dans la part 1), on se connecte via SSH et on paramètre un VRAI password.

Mise à jour du système

Toujours une bonne habitude à prendre avant de commencer, même si à l’heure où j’écris ces lignes la version 5 de Proxmox est sortie depuis seulement quelques jours. Rien de compliqué, on est sur une Debian :

apt-get update; apt-get upgrade

Création d’utilisateur

La création d’un utilisateur « lambda », autre que root, est fortement recommandée. Par défaut l’authentification du portail de Proxmox se base sur PAM donc vous pourrez vous loguer avec, après l’avoir ajouté dans la WebUI.

Configuration du serveur SSH

Désactivez l’accès root et privilégiez le recours au user évoqué ci-dessus puis utilisez une élévation de privilège de type su ou sudo.

Installation de Fail2ban

Là aussi indispensable, il s’installe en une commande, il est déjà configuré avec un grand nombre de règles par défaut qui parsent vos différents log et bannissent toutes les @IP concernées. D’ailleurs, si vous n’êtes pas convaincu de son utilité, je vous mets un (petit) extrait de mon auth.log juste avant son installation :

Voilà, voilà … contrairement à notre ami de Nanjing qui a effectué 161 tentatives en 32h avec des logins plus ou moins improbables … nous on se marre moins tout de suite !!

Au passage, voilà un article sur la configuration de Fail2ban de l’hébergeur Digital Ocean (Ils en font d’ailleurs beaucoup d’intéressants je vous encourage à écumer leurs tutos)

Changement du port d’écoute du serveur SSH

Alors là attention, aucun doute sur la pertinence de la mesure, cela vous permettra d’éviter la grande majorité des tentatives d’accès non autorisées car la plupart des bots se contentent de scanner les ports par défauts des principaux services. Par contre si vous faites ça, vous allez devoir adapter le port SSH dans le script iptables que je vous fournis pas la suite et les tentatives d’intrusion sur le port 22 seront redirigés directement sur le PFSense, ce qui n’est pas forcément mieux. Bref à vous de voir, pour ma part je reste sur le port par défaut mais avec un Fail2ban bien configuré.

Configuration du réseau

Voici le plan réseau de l’infrastructure que nous allons mettre en place (cliquez pour agrandir) :

Le but est de rediriger la totalité du trafic entrant sur l’adresse IP public du serveur vers l’interface WAN du PFSense. Cela permet de gérer la sécurisation et le routage des flux simplement, directement depuis PFSense et surtout en évitant d’avoir à doubler chaque règles de filtrage sur l’iptables.

Paramétrage des interfaces virtuels

Cela peut se faire directement via la WebUI de Proxmox, Les réglages seront simplement automatiquement retranscrits dans le fichier « /etc/network/interfaces« .

• Se connecter à l’interface d’administration

Via un navigateur, on se rend en HTTPS sur l’IP public via le port 8006 (https://PUBLIC-IP:8006). Si vous souhaitez signer vos certificats pour éviter le genre de message que vous allez rencontrer, n’hésitez pas à lire ce superbe article de Zwindler

• Sélectionner votre node dans la colonne de gauche, puis naviguer dans System > Network

Vous devriez avoir deux interfaces, en01 et en02 (ou eth0 et eth1 chez Kimsufi), qui correspondent aux deux ports physiques de la carte réseau ainsi qu’une interface virtuel, vmbr0 bridgé sur eno1 qui est l’interface active.

On peut d’ailleurs voir à quoi cela correspond en affichant notre fichier de configuration :

cat /etc/network/interfaces

Qui devrait contenir ceci :

auto lo
iface lo inet loopback

iface eno1 inet manual
iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
 address xx.xx.xx.xx
 netmask 255.255.255.0
 gateway xx.xx.xx.xx
 bridge_ports eno1
 bridge_stp off
 bridge_fd 0

On voit que l’interface eno1 est configuré en « manual », sans adresse IP puisque elle est « portée » par vmbr0, et qu’eno2 n’est pas utilisée.

Création des bridges Linux

On reprend en configurant conformément au schéma ci-dessus :

• Cliquer sur « Create » et sélectionner « Linux Bridge« 

Le réseau « VmWanNET » (10.0.0.0/30) sera donc volontairement choisit pour limiter à deux le nombre d’adresses atribuables, celle-ci et le WAN du PFSense. Ici pas de bridge sur une interface réelle pour la vmbr1 puisque « WAN » n’existe pas au niveau de l’hyperviseur, mais cela facilitera la correspondance lors du paramétrage de PFSense.

• Cliquer (à nouveau) sur « Create » et sélectionner (encore) « Linux Bridge« 

Cette fois on configure l’interface vmbr2 qui fera parti du réseau « PrivNET » (192.168.9.0/24), et qui sera utilisée plus tard par l’interface « LAN » du PFSense  :

IP address : 192.168.9.1
Subnet mask : 255.255.255.0
Bridges Ports : LAN

Une fois terminé, cela donne :

• Rebooter l’hyperviseur

Il suffit de cliquer sur « Restart » en haut à droite. C’est impératif pour prendre en compte proprement les modifications, c’est pas moi qui le dis, c’est marqué au dessus de l’encadré affichant le log : « Pending changes (Please reboot to activate changes) » … allez promis c’est la seule fois où ce sera nécessaire.

Après le redémarrage, vous pouvez vérifier le contenu du fichier « interfaces » :

auto lo
 iface lo inet loopback

iface eno1 inet manual

iface eno2 inet manual

auto vmbr0
 iface vmbr0 inet static
 address xx.xx.xx.xx
 netmask 255.255.255.0
 gateway xx.xx.xx.xx
 bridge_ports eno1
 bridge_stp off
 bridge_fd 0

auto vmbr1
 iface vmbr1 inet static
 address 10.0.0.1
 netmask 255.255.255.252
 bridge_ports WAN
 bridge_stp off
 bridge_fd 0

auto vmbr2
 iface vmbr2 inet static
 address 192.168.9.1
 netmask 255.255.255.0
 bridge_ports LAN
 bridge_stp off
 bridge_fd 0

Je vous conseille de le conserver quelques part puisque en cas de réinstallation, un simple copier/coller suivi d’un reboot vous permettra de tout reconfigurer rapidement. Nous poursuivrons le paramétrage et la sécurisation par la suite.

Déploiement de PFSense

Création de la VM

• Télécharger l’ISO de PFSense

Rendez-vous sur le site officiel pour récupérer la dernière version stable de la Community Edition, de type « install« , au format ISO et pour archi AMD64 (64bits). On sélectionne ensuite le volume de stockage souhaité, ici « local« , puis on clique sur Content > Upload

Mais on peut également, surtout si votre débit d’upload est poussif, la télécharger directement depuis le serveur dans le répertoire des ISOs :

cd /var/lib/vz/template/iso
wget https://frafiles.pfsense.org/mirror/downloads/pfSense-CE-2.3.4-RELEASE-amd64.iso.gz
gunzip pfSense-CE-2.3.4-RELEASE-amd64.iso.gz

• Créer la VM pour PFSense

Voilà les paramètres que j’utilise, ceux qui n’y figure pas sont laissés par défaut :

OS
 - Linux/Other OS types : Other OS types

CD/DVD
Use CD/DVD disc image file (iso)
 - Storage : local
 - ISO image : pfSense-CE-2.3.4-RELEASE-amd64.iso

Hard Disk
 - Bus/Device : VirtIO / 0
 - Storage : local
 - Size : 8 GB
 - Format : QEMU (qcow2)

CPU
 - Sockets : 1
 - Cores : 2
 - Type : Défaut (kvm64)

Memory
 Mémoire fixe avec ballooning activé
 - Taille : 2048 MB

Network
 Bridged mode (Accès par pont)
 - Bridge : vmbr1
 - Model Intel E1000

/!\ Pour la carte réseau SURTOUT pas de VirtIO sans installer le driver requis /!\
Pour plus détails => https://forum.pfsense.org/index.php?topic=72907.0

• Créer la seconde interface réseau

Assurez-vous d’être dans la « Server View » dans le menu en haut à gauche, puis sélectionnez votre VM PFSense nouvellement crée. Enfin, cliquez sur Hardaware > Add > Network Device

La configuration est la même que pour la première mais pontée sur vmbr2.

Installation de l’OS

• Démarrer la VM via le bouton « Start »
• Ouvrir une console VNC avec le bouton « Console »

Laisser le boot se terminer, si ce n’est pas encore fait, jusqu’à voir s’afficher le premier écran de l’installeur :

Libre à vous de choisir les réglages qui vous conviennent, valider avec le dernier choix du menu.

• Choisir « Quick/easy Install »

• Valider à nouveau et l’installation se lance
• Sélectionner le choix par défaut « Standard Kernel« 
• Autoriser le reboot

Vérifiez le boot order de la VM pour bien démarrer sur le disque local, vous pouvez également éjecter l’ISO.

Configuration des interfaces

Une fois la VM redémarrée, vous arrivez sur le menu principal de la console de PFSense :

• Taper « 1 » (pas trop fort) pour assigner les interfaces, puis configurer comme suit :

 - Paramétrage des VLANs : No (n)
 - WAN interface name : em0
 - LAN interface name : em1
 - Optional 1 interface name : Aucun (appuyer sur entrée)
 - Valider (avec y) si :
 WAN -> em0
 LAN -> em1

• De retour dans menu général  taper « 2 » pour configurer les @IP des interfaces

Taper "1" pour le WAN (em0 - static)
 - DHCP : No (n)
 - @IP : 10.0.0.2
 - Masque : 30
 - Gateway : 10.0.0.1
 - DHCP6 : No (n)
 - WAN IPv6 address : Aucune (appuyer sur entrée)
 - HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 WAN address => 10.0.0.2/30

• A nouveau  « 2 » pour configurer les @IP des interfaces

Taper "2" pour le LAN (em1 - static)
 - @IP : 192.168.9.254
 - Masque : 24
 - Gateway : Aucune (appuyer sur entrée)
 - @IPv6 : Aucune (appuyer sur entrée)
 - DHCP server : No (n)
 - HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 LAN address => 192.168.9.254/24

• Rebooter la VM en tapant « 5 » puis « y »
• A l’issue, taper « 7 » pour tester le ping vers 10.0.0.1 (l’adresse de vmbr1) et ainsi vérifier la connectivité au sein du VmWanNET

Finalisation via la WebUI

• Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 …

… Quoi ? … Ça ne marche pas ? … Sûr ? … C’est con …

Bon pour ceux qui suivent encore, félicitations ! Pour les autres, l’interface LAN de PFSense n’est pour l’instant pas accessible depuis l’extérieur … et c’est tant mieux car le password et le login sont toujours ceux par défaut. La solution la plus simple est donc de créer une VM avec n’importe quel OS, du moment qu’il possède une interface graphique et un navigateur web (et que ce n’est pas un Windows). Une Ubuntu Desktop, à télécharger sur le site officiel, fera parfaitement l’affaire.

Je ne vais pas revenir sur la création de la VM, sachez juste que 5 Go de disque et 512 Mo de RAM suffisent. N’oubliez pas de bridger la carte réseau sur vmbr2 pour accéder au réseau LAN. Vous pouvez également, une fois la VM crée, modifier le paramètre Hardware > Display en « VMWare compatible » c’est qui vous permettra de disposer d’autres résolutions plus confortable que le minuscule 800×600.

Une fois l’OS installé, il faut tout de même paramétrer le réseau manuellement puisque nous n’avons pas (encore) de serveur DHCP fonctionnel :

- IP : 192.168.9.10 (Peu importe tant qu'on reste dans 192.168.9.0/24)
- Netmask : 255.255.255.0
- Gateway : 192.168.9.254
- DNS : 8.8.8.8.8

• Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 (non mais vraiment cette fois)

Username : admin
Password : pfsense

Suivez le (White) Wizard

Rapport à ma VM PFsense qui se nomme Olorin … pertinent pour un pare-feu …

« You Shall Not Pass ! » … ok si vous l’avez toujours pas j’abandonne.

• Choisir un hostname (non pas celui-là, c’est le mien) et le(s) serveur(s) DNS souhaité(s)
• Valider ou modifier le FQDN du serveur NTP

Pour la suite rien à modifier en principe puisque nous avons fait les réglages via la console précédemment.

• Vérifier la configuration de l’interface WAN

IP Address : 10.0.0.2
Subnet Mask : 30
Upstream Gateway : 10.0.0.1

• Vérifier la configuration de l’interface LAN

LAN IP Address : 192.168.9.254
Subnet Mask : 24

• Changer le mot de passe administrateur
• Recharger la configuration et l’accueil du dashboard s’affiche

Configuration du réseau (suite)

Routage et NAT

Particulièrement pour cette partie, je vous encourage à garder le plan réseau à portée de vue.

Pour l’instant, le WAN du PFSense communique bien avec le vmbr1 ,normal me direz vous, ils sont sur le même segment réseau et WAN est ponté sur vmbr1 dans Proxmox. Maintenant nous allons faire le nécessaire pour pouvoir sortir sur internet depuis la patte WAN du PFSense et donc également depuis le LAN par la suite.

• Pour cela, créer un petit script

vi /root/kvm-networking-up.sh

• Coller les lignes suivantes :

#!/bin/sh

## IP forwarding activation
echo 1 > /proc/sys/net/ipv4/ip_forward

# Point PFSense WAN as route to VMs
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1

# Point PFSense WAN as route to VPN
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Comme indiqué dans les commentaires :

• La première ligne active le routage
• La deuxième indique au serveur de sortir par vmbr1 puis de passer par le WAN du PFSense pour communiquer avec les VMs. Cela permet d’isoler vmbr2 du reste de « PrivNET », cette sécurité sera renforcée, lors de la configuration d’iptables par un blocage complet des flux sur vmbr2.
• Même chose pour la dernière mais pour communiquer avec le(s) client(s) du VPN que nous configurerons dans la suite de l’article.

Puis pour qu’il soit lancé automatiquement au boot, lors du démarrage de vmbr1 :

• Lui permettre de s’exécuter

chmod +x /root/kvm-networking-up.sh

• Paramétrer son appel dans le fichier « interfaces »

vi /etc/network/interfaces

Ajouter la ligne en gras à la fin du bloc de configuration du bridge vmbr1 :

[...]
auto vmbr1
 iface vmbr1 inet static
 address 10.0.0.1
[...]
 bridge_fd 0
 post-up /root/kvm-networking-up.sh

auto vmbr2
 iface vmbr2 inet static
[...]

Comme je vous ai promis qu’on ne rebooterait plus au début de cette article, on va simplement l’exécuter manuellement pour cette fois :

/root/kvm-networking-up.sh

• Relancer la console VNC du PFSense et taper « 7 » pour vérifier le ping vers l’internet (genre 8.8.8.8)

Sécurisation de l’hyperviseur via iptables

Voilà on a presque terminé mais pendant qu’on s’amusait, et malgré les mesures prises au début de ce tuto, une armée de bots (et pas que des chinois), des hordes de BlackHat ainsi que l’intégralité de la NSA, du GCHQ et de … l’ANSSI ? … se tirent la bourre pour essayer de pénétrer sur votre petit serveur sans défense.

Je n’aurais donc que trois choses à dire :

1. Si vous ne savez pas ce qu’est le GCHQ, il faut absolument lire ce magnifique article !
2. Si vous ne savez pas ce qu’est la NSA … là je ne peux plus rien pour vous
3. Nous n’allons pas mourir sans combattre et nous allons au moins … essayer de les ralentir !

Création des règles

Nous allons créer un script pour exécuter toutes les commandes iptables requises. Je vous encourage à ne pas automatiser son lancement au boot avant d’être totalement sûr que tout fonctionne bien.

Pour ceux qui ont pris iptables en deuxième langue au collège, je vous donne directement le contenu du script :

Pour les autres, je vous conseille de bien lire (et comprendre tant qu’à faire) ce qui suit jusqu’à la fin avant de vous lancer. J’ai commenté quasiment chaque ligne mon script le plus explicitement possible, donc je vais simplement vous expliquer le rôle de chacune des parties :

VARIABLES : On commence par la variabilisation des noms de bridges, des @IP et des réseaux. Cela vous permettra de l’adapter rapidement à votre configuration si elle diffère. Quoi qu’il en soit, il faut absolument définir la variable « PublicIP » avec celle de votre serveur.

CLEAN ALL & DROP IPV6 : Ensuite on supprime toutes les règles existantes.

DEFAULT POLICY : On positionne les polices par défaut à DROP : tout ce qui ne sera pas explicitement autorisé sera interdit (comme à l’armée … \o/ ça faisait longtemps).

CHAINS : On crée des chaines personnalisées pour éviter la répétition des options.

GLOBAL RULES : Elles permettent les communications from/to l’interface locale, préservent les connections déjà actives et autorisent la réponse au ping.

RULES FOR PrxPubVBR : On passe à la configuration des flux pour l’interface bridge vmbr0, c’est ici que tout se joue.

L’idée est simple, on ne va autoriser que les services du Proxmox auxquels on souhaite pouvoir accéder depuis internet via l’IP public (donc le moins possible). TOUS les autres flux seront redirigés sur l’interface WAN du PFSense ce qui nous permettra, comme expliqué au début, d’éviter une pénible gestion de deux firewall chainés. Une fois que le VPN sera configuré on pourra d’ailleurs désactiver l’accès externe à la WebUI. Pour le SSH on pourra garder un accès de secours en cas de problème avec le futur VPN.

RULES FOR PrxVmWanVBR : Pour vmbr1, c’est très simple, on autorise seulement les connexions, en provenace du LAN des VMs et du/des client(s) VPN,  à sshd et l’interface web de Proxmox.

RULES FOR PrxVmPrivVBR : Pour vmbr2, encore mieux, on laisse tout fermé !

De plus, comme paramétré précédemment, aucune route ne passe par ce bridge. C’est un moyen simple et assez efficace d’isoler au maximum cette interface du réseau auquel elle appartient. Le mieux aurait été d’utiliser une configuration similaire au mode « promiscuous » des Vswitchs d’ESX mais je n’ai pas trouvé d’équivalent pour KVM. Une autre solution utilisant la seconde interface physique du serveur est à l’étude par mon expert en sécurité et fera peut être l’objet d’un article spécifique ou d’une MAJ future. D’ailleurs j’en profite :

Merci Nico, Merci Zwindler !

La clusterisation de nos cerveaux (non ce n’est pas sale) m’a fait gagner beaucoup de temps

Et voilà ! (avec l’accent américain) Vous avez bien bossé et vous disposez d’une infra totalement fonctionnelle et relativement bien sécurisé, GG !

Il nous restera bien sûr à configurer les règles adéquates sur PFSense pour les services de vos futures VMs auxquels vous souhaiterez accéder depuis l’extérieur et configurer un serveur VPN afin d’y accéder directement au chaud depuis votre nouveau LAN.

Nous allons voir tout ça dans la 3e et dernière partie de cette article qui sera publié la semaine prochaine.

Cet article Déploiement de Proxmox VE 5 sur un serveur dédié – part 2 est apparu en premier sur Zwindler's Reflection.

La première partie de cet article est accessible par ici et la deuxième ici.

Nous avons donc à présent une belle infrastructure à disposition avec une VM PFSense en frontal et un niveau de sécurité relativement correct. Nous allons donc terminer par :

• La configuration d’un accès distant sécurisé grâce à OpenVPN
• L’adaptation des règles de filtrage pour que cela fonctionne

Mais avant cela, je vais juste faire un léger aparté pour vous montrer comment autoriser l’accès extérieur à un service d’une machine virtuelle.

Comme pour les parties précédentes, si des paramètres ne sont pas explicités, ils sont à laisser à leur valeur par défaut.

Publication de services sur l’internet du web

Imaginons que vous ayez quelques VMs qui vous fournissent des services de “Prod”, et que pour des raisons qui vous sont propres, vous souhaitiez pouvoir y accéder sans passer par votre futur VPN … “Comment faire ?” me demanderiez-vous. “Et bien, vous répondrais-je … C’est très simple mon cher ami, grâce à notre magnifique infrastructure, l’ajout d’UNE SEULE règle suffira !” (mouahaha)

Donc prenons le cas d’un serveur PLEX , au hasard, hébergé sur un NAS Synology virtualisé … son @IP est 192.168.9.10 et son port d’écoute est, par défaut, le TCP:32400.

• Se rendre dans le menu Firewall > NAT puis cliquer sur “ADD“

Interface : WAN
Protocol : TCP
Destination : Any
Destination Port Range (From) : Other – 32400
Redirect target IP : 192.168.9.10
Redirect target port : Other – 32400
Description : Choisir un nom pour la règle (ex: Synology – Plex)

• Valider avec “Save” puis “Apply Changes” pour recharger la configuration

Voilà, c’est tout !

Vous avez crée une règle de NAT qui renvoie toutes les requêtes arrivant sur le port TCP:32400 de votre interface WAN vers le port TCP:32400 de votre Plex ! Cerise sur le gâteau, vu que PFSense est bien conçu (et que vous n’avez pas modifié le paramètre “Filter rule association”) il vous a généré une règle de FW associée pour autoriser le flux de votre règle NAT.

Comme tous les services publiés sur votre IP public constituent des vecteurs potentiels d’attaque on va y allez “molo sur la mayo” (… vous connaissez cette expression ? Je crois que je viens de l’inventer … truc de fou … une fulgurance … Non sérieux quelqu’un connait ? … Euh oui pardon … ). Je disais donc que nous privilégierons évidemment un accès via le VPN que nous allons mettre en place …. genre maintenant, tout de suite.

Configuration d’accès distant sécurisé via OpenVPN

Je ne vais pas vous détailler l’action de chaque option, et je ne les connais pas toutes d’ailleurs, par contre si vous êtes intéressé, je vous encourage fortement à vous référer à ces sources :

• Documentation officielle d’OpenVPN
• Article “OpenVPN Remote Access Server” du Wiki de PFSense
• Un très bon tuto francophone qui détaille bien les options … lui

Création de l’autorité de certification

• Naviguer jusqu’à la liste des “CAs” via le menu System > Cert Manager :

Celle-ci est vide, nous allons donc créer une nouvelle entrée.

• Cliquer sur le bouton “ADD” en bas à droite, puis renseigner comme suit :

Descriptive name : Nom choisi pour la CA
Method : Create an internal Certificate Authority

Une fois la méthode sélectionnée, l’encadré inférieur va changé

Key length : 2048 (longueur de la clé de chiffrement)
Digest Algorithm : SHA256 (méthode de hachage)
Lifetime : 3650 (durée de validité en jours)
Country Code : FR (Code ISO du pays d’émission du CA)

Les autres champs sont libres et à titre indicatif, évitez toutefois les infos trop personnelles/confidentielles. Choisissez simplement un “Common Name” un peu explicite pour pouvoir l’identifier facilement.

• Cliquer sur “Save” et contempler le résultat :

Création du certificat serveur

• Cliquer à présent sur l’onglet rouge “Certificates” où un certificat utilisé par la WebUI existe déjà, puis cliquer sur le bouton “ADD” pour en créer un nouveau :

Method : Create an internal Certificate Authority

Et là grosse surprise ! … Une fois la méthode sélectionnée, l’encadré inférieur va changé

Descriptive name : Nom choisi pour la certificat serveur
Certificate authority:  Sélectionner la CA crée juste avant (la seule normalement)
Key length : 2048
Digest Algorithm : SHA256
Certificate Type : Server Certificat (Qui a dit pourquoi ? … Toi => [] … tu sors)
Lifetime : 3650 (10 ans ça devrait suffire)

Les champs suivants sont normalement pré-remplis donc conservez les même valeurs que précédemment sauf pour “Common Name” bien sûr (Pourquoi ? … t’étais pas sorti toi ??!)

• Valider avec le bouton “Save“

Création du certificat client

Alors là c’est tricky … attention … il va falloir relire le paragraphe précédent (oui y compris les vannes bidons) et refaire la même manip en changeant simplement :

Certificate Type : Client Certificat … \o/ 

Création du serveur VPN

• Se rendre dans le menu VPN > OpenVPN, puis cliquer sur “ADD“

General Information

Server Mode : Remote Access (SSL/TLS + User Auth)

Avec ce mode vous aurez besoin des certificats sur le client mais devrez également saisir le login/password du user crée ci-dessus à chaque connexion du tunnel VPN. C’est une sécurité supplémentaire que vous pouvez désactiver en choisissant “Remote Access (SSL/TLS)”

Local Port : 2294

Rien d’obligatoire ici mais pour les même raison expliquées dans la 2e partie de l’article ça limite drastiquement l’efficacité de nombreux bots qui utilisent les ports standards.

Cryptographic Settings

TLS Authentication :  Laisser coché

La TLS est une couche supplémentaire d’authentification/chiffrement qui permet d’ajouter une seconde ligne de défense à SLL et à priori l’impact n’est pas significatif au niveau des performances. Libre à vous de lire la doc et de l’enlever en toute connaissance de cause si vous le souhaitez.

Description : Choisir un nom pour le serveur OpenVPN
Certificate authority:  Sélectionner la CA créée juste avant (toujours la seule normalement)
Server Certificate : Choisir le certificat serveur créé précédemment

Tunnel Settings

IPv4 Tunnel Network : 10.2.2.0/24

Conformément à notre schéma réseau, visible dans la 2e partie de l’article. Là aussi, libre à vous de choisir votre segment réseau, du moment que vous adaptez la suite à votre plan d’adressage.

Redirect Gateway : Cocher la case

Ce paramètre permet de forcer le client à utiliser le VPN en tant que passerelle par défaut dès qu’il est activé. Ce qui peut faire office de proxy sécurisé pour l’ensemble de votre trafic quand vous vous connectez depuis un Wifi Public par exemple.

Concurrent connections : 3

Facultatif, permet de limiter le nombre de client connectés en même temps.

Inter-client communication : Cocher la case

Si vous souhaitez que vos client puissent communiquer entre eux.

Disable IPv6 : Cocher la case

Client Settings

Dynamic IP : Cocher la case

• Valider avec le bouton “Save“

Création de l'(unique) utilisateur

• Se rendre dans le menu System > User Manager, puis cliquer sur “ADD“

Disabled : A cocher pour empêcher le user d’avoir le droit de se loguer sur la WebUI

En effet, le but est d’avoir un utilisateur dédié sans accès à l’interface. Ensuite choisissez un login, un password, un nom long (facultatif), une date d’expiration (si vous cherchez des ennuis, vu que vous vous demanderez dans quelques mois pourquoi ça ne fonctionne plus). Une fois le user crée, nous allons lui attribuer le certificat client que nous avons généré précédemment :

• Cliquer sur le bouton “Edit user” (mais si, le petit crayon bleu à droite … l’autre droite)

• Dans le cadre  “User Certificates“, cliquer sur “Add“

Method : Choose an existing certificate

Existing Certificates : Sélectionner votre certificat client qui doit être le seul non encore utilisé

Il ne vous reste plus qu’à sauvegarder la modification. L’idée est de créer un couple user/certificat client par personne (logique) voir par machine cliente, ça permet notamment pouvoir les révoquer individuellement au besoin. Enfin si vous avez besoin de plusieurs utilisateurs, créez leur un groupe dédié pour les ranger (c’est plus propre, on est pas des sauvages).

Configuration du/des client(s)

Afin de pouvoir accéder à notre tunnel, il faut maintenant récupérer :

• La clé privé du certificat client crée précédemment
• La clé publique de ce même certificat
• Un modèle de configuration client d’OpenVPN et l’adapter

Je suis donc censé vous décliner la marche à suivre pour préparer des “kits” de configuration,  en fonction des options sélectionnées pour notre serveur, des spécificités de mise en forme de certificats pour les différents types de clients (Linux, MacOS, iOS, Android … voir Windows) et également pour chaque … ah ouai … mais non en fait.

Nous allons plutôt utiliser un des (nombreux) avantages de PFSense, à savoir son gestionnaire de paquets !

En effet, il existe plus d’une cinquantaine de packages (en release 2.3.4) qui permettent d’ajouter des fonctionnalités à notre Firewall. Pour ne rien gâcher, ils sont installables en un clic depuis l’interface Web et leurs paramètres sont sauvegardés automatique par le mécanisme de backup intégré de PFSense qui est un simple fichier XML.

Enfin, comble du bonheur, il en existe un qui fait exactement tout ce qui nous intéresse : openvpn-client-export !

• Se rendre dans le menu System > Package Manager, puis cliquer sur l’onglet “Available Packages“
• Taper “export” dans le champ de recherche, puis installer le paquet via le bouton “Install“

Vous pouvez aussi profiter d’une recherche manuelle pour parcourir les différents paquets disponibles.

Lien vers la documentation du package OpenVPN Client Export

• Naviguer vers le menu VPN > OpenVPN, puis cliquer sur le nouvel onglet “Client Export”

Remote Access Server : Sélectionner le serveur VPN souhaité (le seul à priori)
Host Name Resolution :  Other

Le choix par défaut “Interface IP Address” va renseigner l’@IP locale de votre interface WAN (10.0.0.2) dans le fichier de configuration du client et quand vous essaierez de vous y connecter depuis internet ça marchera beaucoup moins bien. Le mieux est de sélectionner “Other” et de saisir directement votre IP publique ou votre nom de domaine (en cas d’utilisation de DynHost par exemple).

Use Random Local Port : Cocher la case (obligatoire si vous prévoyez plusieurs client en simultanés)

Scroller à présent vers le bas jusqu’au cadre OpenVPN Clients :

Il ne reste plus qu’à télécharger les configs qui vous intéresse !

Pour les utilisateurs de MacOS, je vous conseille le client VPN Tunnelblick. Une fois installé, télécharger la “Standard Configuration” au format “Archive“. Dézipper l’archive, ajouter le suffixe “.tblk” pour transformer le dossier en configuration pour Tunnelblick et enfin l’ouvrir pour la charger automatiquement dans l’application.

Une fois la/les configuration(s) installé(s) sur votre/vos client(s), il ne reste plus qu’à paramétrer les règles PFSense requises.

Configuration des flux

Autoriser l’accès du client au serveur VPN depuis internet

• Naviguer vers le menu Firewall > Rules
• Sélectionner l’onglet WAN puis ajouter une nouvelle règle avec “ADD“

Action : Pass
Interface :  WAN
Protocol : UDP
Source : Any
Destination : WAN adress
Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner le nom qui s’affichera pour la règle (ex: OpenVPN nomad access)

Autoriser l’accès du client en provenance du tunnel VPN aux LAN & WAN

• Sélectionner l’onglet OpenVPN puis ajouter à nouveau une règle avec “ADD“

Action : Pass
Interface :  OpenVPN
Protocol : Any
Source : Network – 10.2.2.0/24
Destination : any

Ici on peut limiter l’accès des clients au seul LAN mais il faudra désactiver l’option “Redirect Gateway” du serveur et le VPN ne pourra plus être utilisé en tant que proxy Web.

Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner un nom pour la règle

• Valider les changements via le bouton “Apply Changes“

Vous n’avez plus qu’à démarrer votre client VPN, renseigner votre login/pass et c’est parti !

THE END !

Voilà n’hésitez pas à commenter, poser des questions, faire une donation via PayPal si vous vous voulez supporter le blog avec les quelques euros qui trainent sur votre compte et surtout abonnez-vous à NoLife … à non c’est pas ça je m’égare … allez see u guys.

Cet article Déploiement de Proxmox VE 5 sur un serveur dédié – part 3 est apparu en premier sur Zwindler's Reflection.

“J’ai un problèèèèèmeuh”

J’ai un problème (dramatique) sous Plex avec la séries The Powerpuff girls (Les Super Nanas). En réalité, j’en ai même deux…

1er problème : l’ordre des premiers épisodes ne colle pas

Lorsque je me suis mis à re-regarder les Powerpuff Girls, j’ai remarqué que le premier épisode n’avait aucun rapport avec le titre de l’épisode affiché dans Plex. Le premier épisode contient en fait “Insect Inside” et “Powerpuff Bluff”.

A l’épisode d’après, j’ai compris qu’il y avait un souci d’ordre : j’ai remarqué que l’épisode S01E01 “Monkey See, Doggie Do” et S01E02 “Mommy Fearest” sont en fait un seul et même épisode : le S01E02.

Le problème vient visiblement de ma série source, dont l’ordre ne correspond pas avec le référentiel de Plex. En réalité, je me suis rappelé que la source de Plex vient pour mes séries du site TheTVDB.com. Voilà ce qu’on voit quand on affiche la page des Powerpuff Girls :

Mais ça n’explique pas pourquoi ma série n’a pas le même ordre que TheTVDB

2ème problème : Un fichier, 2 épisodes

D’habitude, lorsque je veux des informations sur les épisodes d’une série, je vais sur Wikipedia. Ce n’est probablement pas la source d’information sur les série la plus pertinente, mais j’ai mes habitudes ;-).

Donc à partir de là, je suis encore plus perdu… Selon Wikipedia, l’épisode S01E01 contient bien 2 parties, “Monkey See, Doggie Do” et “Mommy Fearest”, et pas du tout “Insect Inside”. C’est à n’y rien comprendre !

1er contournement (pour le 2ème problème)

Ça ne règle pas le premier problème, mais dans Plex il est possible d’indiquer qu’un fichier contient 2 épisodes : renommer en maserie_s01e01-e02 (ou s01e01-s01e02, la syntaxe est floue et les retours sont parfois erratiques selon le forum de Plex).

Après rescan de la bibliothèque, les deux épisodes apparaissent bien dans Plex.

Cependant cette technique est tout sauf optimale ! Les deux épisodes sont bien visibles mais ne sont pas “liés”. Bien qu’il n’y ait qu’un seul fichier contenant 2 épisodes, Plex traite ce fichier comme 2 fichiers !

Quand vous aurez fini de voir le premier, Plex vous proposera de lancer le second (qu’il considèrera comme “Non vu”) et le relancera… Pas top.

“DVD order” versus “Aired date order”

En réalité ce problème est connu. Il apparait souvent dans des séries de type dessins animés (à quelques exception notables comme Firefly).

Un petit retour sur TVDB permet de se rendre compte qu’il existe parfois, pour une même série, des ordres et des découpages différents entre ce qui a été diffusé à la TV et le DVD de la série !

Ces deux ordres sont renseignés dans TVDB sous l’appellation “Aired Order” et “DVD Order”. Malheureusement, le plugin TVDB officiel de Plex ne semble pas prendre en compte le DVD Order et ceci explique les divergences qu’on retrouve dans notre bibliothèque.

Installation de l’agent

Comme le problème est connu depuis longtemps, un personne a modifié le plugin officiel de Plex pour TVDB et l’a adapté pour proposer à la main de modifier une séries pour qu’elle prenne en compte le “DVD order”.

Malheureusement, l’auteur du script ne semble plus le maintenir et ne fonctionne plus “out of the box”.

Récupérer la dernière version

La dernière version est cachée au milieu des commentaires. Vous pouvez la trouver ici :

• https://forums.plex.tv/discussion/comment/652345/#Comment_652345

Installer le module

Personnellement, je n’avais aucune idée de comment installer un module (Plex App) dans Plex. C’est quelque chose qu’on ne fait jamais car l’appli se suffit à elle même (je trouve), contrairement à Kodi qui lui met en avant un magasin d’extension par exemple.

Voici les sujets que j’ai consultés pour trouver la solution à ce problème

• https://forums.plex.tv/discussion/79243/how-to-manually-install-the-plex-app
• https://support.plex.tv/hc/en-us/articles/201106098-How-do-I-find-the-Plug-Ins-folder-

Et comme je suis sympa je vous donne les commandes que j’ai tappé sur la machine qui héberge mon serveur Plex

cd '/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-ins/'
sudo wget https://us.v-cdn.net/6025034/uploads/ipb/monthly_05_2014/DVD%20Order%20Agent.bundle.zip
sudo unzip DVD\ Order\ Agent.bundle.zip
sudo mv DVD\ Order\ Agent.bundle DVDorder.bundle
sudo chown -R plex:plex DVDorder.bundle/
/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-ins$ ll
    total 16
    drwxr-xr-x 4 plex plex 4096 juin 4 14:32 ./
    drwxr-xr-x 12 plex plex 4096 juin 4 14:34 ../
    drwxr-xr-x 3 plex plex 4096 déc. 16 2010 DVDorder.bundle/
    drwxr-xr-x 3 plex plex 4096 mai 7 17:51 Services.bundle/
sudo systemctl restart plexmediaserver.service

Une fois que c’est fait, il faut ensuite se connecter sur Plex depuis un navigateur avec le compte lié au serveur Plex, pour configurer (activer) le module.

Activer le DVD Order ?

A partir de là, j’étais assez content de moi et je me suis dis : “Chouette, ça va marcher maintenant.” Et ben non…

Voici ce que j’ai tenté :

• Sur la vignette des Powerpuff Girls, [petit crayon]

• Sur la ligne “Episode ordering”, passer à “DVD order”

Ça ne marche pas !

Même après modification, enregistrement, rescan de la librairie… rien n’y fait. L’ordre de mes épisodes n’a pas changé.

Du coup, je me suis dis que c’était peut être un conflit entre sources. Habituellement, lorsqu’un film ou une série est mal détectée par Plex (et que ce n’est pas de la faute d’un mauvais nommage du fichier), on peut forcer l’association pour imposer la bonne version.

Typiquement, j’ai eu l’exemple avec “Kung Fu Panda (2008)” qui était par erreur (j’ignore pourquoi) détecté comme le 3ème opus.

Pour en revenir à mon cas, j’ai donc tenté de forcer l’association en utilisant l’agent TheTVDBdvdorder.

Et c’est comme ça que j’ai trouvé mon erreur. L’agent ne trouve aucune information, et l’association automatique bascule donc sur l’Aired Order !

Le fix de la mort

A partir de cette erreur, j’ai rapidement pu trouver des gens qui ont débugué le plugin.

Il faut modifier le code source du fichier __init__.py pour décommenter deux vieilles URL qui ne répondent plus, et les remplacer par trois autres.

cd "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-ins/DVDorder.bundle/Contents/Code"

cp __init__.py __init__.py.ori
vi __init__.py

#TVDB_GUID_SEARCH = http://freebase.plexapp.com/tv/guid/
#TVDB_QUICK_SEARCH = http://freebase.plexapp.com/tv/names/
TVDB_GUID_SEARCH = http://meta.plex.tv/tv/guid/
TVDB_QUICK_SEARCH = http://meta.plex.tv/tv/names/
TVDB_TITLE_SEARCH = http://meta.plex.tv/tv/titles/

sudo systemctl restart plexmediaserver.service

Taaaadaaaa : Après redémarrage, les 2 problèmes ont été résolus d’un seul coup !!!

Bonus : On a perdu la musique de générique

Bon, bien sûr ça ne pouvait pas fonctionner à 100%…

Par défaut, Plex lance un extrait de la musique de générique d’une série quand on arrive sur la page de cette série. C’est vraiment très sympa (même si ça peut paraitre gadget dit comme ça).

Et oui… en ajoutant le TVDBdvdorder nous avons cassé un autre plugin et nous devons donc continuer notre petite séance de hacking !

Dans son post, jooniloh parle d’un plugin PlexThemeMusic.

Nevermind! Figured it out. Did not see the bit about editing PlexThemeMusic.bundle’s __init__.py earlier.
— jooniloh

Cependant ce plugin, comme le dit l’auteur, n’en est plus un. C’est maintenant une fonction intégrée qu’il faut donc aller chercher dans les ressources de Plex Media Server (ici 995fidead est ma version de plex, la dernière à l’heure où j’écris ces lignes) et non plus dans le dossier Plex Media Server/Plug-ins.

Vous pouvez retrouver ce dossier de la façon suivante :

locate PlexThemeMusic.bundle
/usr/lib/plexmediaserver/Resources/Plug-ins-995f1dead/PlexThemeMusic.bundle

On garde une copie du fichier source pour plus de sécurité

cd '/usr/lib/plexmediaserver/Resources/Plug-ins-995f1dead/PlexThemeMusic.bundle/Contents/Code'
sudo cp __init__.py __init__.py.ori

On créé un patch et on l’applique

sudo echo "41,42c41,42
<   def update(self, metadata, media, lang, force=False):
<     if force or THEME_URL % metadata.id not in metadata.themes: --- >   def update(self, metadata, media, lang):
>     if THEME_URL % metadata.id not in metadata.themes:" > __init__.py.patch

patch __init__.py __init__.py.patch
    patching file __init__.py

sudo systemctl restart plexmediaserver.service

Si vous voyez où je me suis trompé, je suis preneur !

Cet article Erreur dans l’ordre des épisodes dans Plex (Aired vs DVD order) est apparu en premier sur Zwindler's Reflection.

Qui a entendu du VMware Lookup Service ?

[Aparté]M4vr0x ayant pas mal monopolisé le temps de parole sur ProxMox VE, je retourne un peu sur VMware histoire de changer un peu, mais rassurez vous, d’autres articles sur le clustering vont suivre ;-).[/Aparté]

Un matin d’astreinte comme les autres. On me réveille aux aurores car un serveur Business Object est encore dans les choux. Le serveur Windows qui l’héberge (je ne vous donnerai pas la version, vous allez vous moquer) est encore en carafe, encore pour une raison obscure (pas de pb de RAM, pas de charge CPU, pas de pic d’IO… normal ?).

C’est une vieille infra client, sur laquelle je n’ai plus trop mon mot à dire : elle n’est plus sous ma responsabilité directe, en dehors de l’astreinte. Mais j’ai quand même encore les accès en console VMware pour me connecter et regarder ce qui ne va pas.

Dans le doute, reboot. Si ça rate, reformate.
— Un des hymnes de l’IT au bureau. Roy et Moss approuveraient.

Depuis quelques temps, j’ai des soucis avec mon client lourd vSphere. La console ne s’affiche pas en entier, du coup je ne vois que le quart supérieur gauche de l’écran, ce qui est relativement handicapant.

De toute façon comme il est déprécié et censé disparaitre depuis des années (la 5.5 je crois ?), je n’ai pas pris la peine de chercher pourquoi et n’utilise plus que le client Web, malgré sa lenteur épique sur les plus vieilles versions.

Manque de chance, un message d’erreur m’attend au login !

Failed to connect to VMware Lookup Service. SSL certificate verification failed

L’erreur a le mérite d’être assez clair. Quelque part, il y a un service qui se charge de vérifier un certificat et ce certificat est mauvais ! Heureusement on trouve pas mal de ressources en anglais sur le sujet, notamment chez Yellow bricks (pour la 5.1, lui).

“Lorsque vous modifiez le nom d’hôte de vCenter Server Appliance, une erreur Lookup Service apparaît lorsque vous redémarrez le dispositif.”
— OK. Qui est le saucisson qui a modifié le hostname mais ne s’est pas logué après pour vérifier que ça fonctionnait ?

C’est donc tout simplement un certificat qui n’est plus valide car le nom d’hôte a changé.

On peut facilement corriger le problème en se connecter sur l’application d’administration de la VCSA. Vous l’avez utilisée lors de l’installation de l’appliance, via l’URL https://<@vcenter>:5480/.

Il faut se connecter avec le compte root de l’appliance, choisi au moment de l’installation.

Naviguez jusqu’à trouver l’onglet Admin. A partir de là, sur la 5.5, il y a un bouton radio qui permet de régénérer automatiquement les certificats si nécessaire. Passez le à “oui”. Idealement il faudra penser à l’enlever une fois le problème réglé, pour d’évidentes raisons de sécurité.

La documentation officielle indique que redémarrer les services ne suffisent pas. Il est donc réellement nécessaire de rebooter complètement l’appliance car la régénération des certificats se fait au reboot.

Ne cliquez pas sur “Reset”, ça efface tous le champs. J’en aurai une bonne à vous raconter à ce sujet d’ailleurs ;-).

Après le reboot, l’erreur sur le vsphere web client sur https://<@vcenter>:9443 devrait avoir disparue !

Unable to connect to server

Tout est bien qui fini bien ? Non ! Si vous essayez comme moi de retourner sur le serveur de configuration du vCenter (pour prendre des captures d’écran et faire un article de wiki ou de blog par exemple), vous ne pourrez plus vous connecter. Après le login vous aurez le message suivant qui apparaitra en rouge :

Unable to connect to server

En réalité, c’est simplement un problème de cache de votre navigateur web. Il faut vider votre cache navigateur et accepter le nouveau certificat qui vient d’être régénéré.

Source

• http://www.yellow-bricks.com/2012/12/19/failed-to-connect-to-vmware-lookup-service-ssl-certificate-verification-failed/
• http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.troubleshooting.doc%2FGUID-D9ACB836-2BB4-4DDC-9383-91EF6E546A30.html

Cet article vSphere Web Client : VMware Lookup Service SSL certificate verification Failed est apparu en premier sur Zwindler's Reflection.

Un sous titre qui ne casse pas des bricks

Mais si, tu vas voir, c’est drôle comme vanne, parce qu’en fait, tu vois dans Gluster ya des bricks, et… bon ok, j’arrête.

Comme vous le savez peut être si vous avez lu mon article sur ProxMox et GlusterFS, j’aime bien GlusterFS. C’est simple à installer, ça marche assez vite, c’est là depuis longtemps et plutôt stable. Mes perfs ne sont pas extraordinaires mais c’est lié à 100% à mon infrastructure qui ne respecte absolument pas les prérequis, à savoir : un stockage sur un réseau dédié et local, alors que moi je fais ça sur une ligne ADSL avec des disques grands public.

Bref, je synchronise des données sur les Internets et j’en suis très content. Mais ça c’était avant le drame.

Une promo chez Kimsufi

C’est les soldes; Kimsufi brade le serveur que j’utilise à 18€/mois au lieu de 24. Je leur aurais bien demandé de juste me faire une réduction et puis basta, mais je ne suis pas sûr que ça serait passé ;-).

J’ai donc résilié mon contrat pour « Executor » (le petit nom de mon KS-3) et migré mes machines vers mon nouveau serveur (appelé ici glusternode).

Et pour éviter de devoir resynchroniser un trop gros volume de données entre mes serveurs Gluster via ADSL, j’ai eu une de mes fameuses « idées de génie ». Supprimer tous les bricks sauf 1 sur mon volume Gluster, réduire la volumétrie réellement utile pour en avoir un minimum, puis resynchroniser le volume en ajoutant à nouveau une brick.

Pour ceux qui veulent savoir comment faire ça, vous pouvez suivre un tuto sur le site du support de rackspace.

Sauf que je n’ai pas supprimé les fichiers depuis mon client Gluster, mais directement depuis le filesystem /data/brick1/gv0…

Quel est le problème ?

Le problème, je l’ai vite vu. Après avoir libéré environ 60 Go d’espace, « du » me renvoie bien l’espace libéré…

root@glusternode:/data/brick1/gv0# du -shx *
30G dump
0 images
0 template

… mais pas « df » !

root@glusternode:/data/brick1/gv0# df .
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/mapper/pve-data_brick1 104806400 93579732 11226668 90% /data/brick1

Heureusement je ne suis pas le seul sysadmin « tête en l’air »… J’ai trouvé la solution sur la devlist GlusterFS.

Comment ça marche GlusterFS ?

Et c’est intéressant car ça m’a permis de descendre un peu sous le capot de GlusterFS. En réalité, lorsqu’on affiche le contenu du filesystem distribué, on ne voit pas tout !

Si on descend sur la brick elle même et qu’on regarde le contenu du filesystem en incluant les fichiers cachés, on peut découvrir un dossier « .glusterfs ». Et comme par magie :

root@glusternode:/data/brick1/gv0# du -shx .glusterfs/
90G .glusterfs/

Voilà mon espace disque perdu ! Une partie des fichiers sont visibles (30 Go) dans le dossier dump, à la racine de gv0, mais la totalité des fichiers sont aussi visibles dans le .glusterfs (30 Go + mes 60 Go perdus)… Comment est ce possible que j’ai 120 Go alors que le FS n’en fait que 100 ?

Et bien en fait, c’est parce que GlusterFS utilise un lien de type « hardlink ». Vous n’êtes peut être pas familier de la notion car elle n’est pas souvent utilisée mais c’est un système Unix qui permet, au sein d’un même filesystem, d’avoir un seul fichier référencé par 2 (ou plus) arborescences distinctes sans pour autant le stocker 2 fois.

Cette notion est à distinguer du lien symbolique (créé avec le « -s » de la commande « ln »), car si on supprime le fichier cible, le lien symbolique reste mais est brisé. Là, avec le « hardlink », tant qu’il reste un chemin vers le fichier, un « rm » ne fait que supprimer le pointeur en question. Seul le dernier « rm » vers le dernier pointeur supprime réellement les données.

On peut vérifier qu’il s’agit bien de ça avec les commandes suivantes :

Afficher le numéro d’inode de nos fichiers :

root@glusternode:/data/brick1/gv0/dump# ls -li
total 31411464
201326698 -rw-r--r-- 2 root root 1394 févr. 27 21:07 vzdump-qemu-100-2017_02_27-21_06_55.log
201326704 -rw-r--r-- 2 root root 2287 févr. 27 22:12 vzdump-qemu-100-2017_02_27-22_09_27.log
201326716 -rw-r--r-- 2 root root 3183 juil. 12 03:03 vzdump-qemu-100-2017_07_12-03_00_01.log

Ici dans la première colonne on obtient pour chaque fichier un « identifiant unique » au sein de notre filesystem. On peut donc vérifier que Gluster utilise des hardlinks en cherchant un même numéro d’inode pointant vers 2 chemins différents :

root@glusternode:/data/brick1/gv0# find . -links 2 -ls | grep 201326847
201326847 4 -rw-r--r-- 2 root root 3267 août 9 02:05 ./.glusterfs/24/80/2480dbf8-0f59-49aa-afca-9ad3595f11ca
201326847 4 -rw-r--r-- 2 root root 3267 août 9 02:05 ./dump/vzdump-qemu-121-2017_08_09-02_02_39.log

C’est deux chemins pointent vers un même inode et représentent ici un fichier (vzdump-qemu-121-2017_08_09-02_02_39.log) normalement présent sur le brick (c’est à dire un que je n’ai pas charcuté bêtement comme les autres).

Du coup le but du jeu dans mon cas est de retrouver les fichiers de données qui n’ont qui n’ont qu’une seule référence et non 2 (en mettant de côté les fichiers qui ont l’air importants genre « gv0.db » ou « health_check »).

J’ai fais un petit find dégueux qui fait ça pour nous, et j’ai rajouté un -exec file pour savoir si c’est bien un fichier de sauvegarde de proxmox (archive LZO dans mon cas).

find .glusterfs/ -mindepth 3 -size +1 -links 1 -type f -ls -exec file {} \;
201326708 1437628 -rw-r--r-- 1 root root 1472129448 juil. 29 02:12 .glusterfs/3f/1c/3f1cf4a6-8d36-4a08-b4c2-d82f88745b09
.glusterfs/3f/1c/3f1cf4a6-8d36-4a08-b4c2-d82f88745b09: lzop compressed data - version 1.030, LZO1X-1, os: Unix
201326736 10235876 -rw-r--r-- 1 root root 10481534660 juil. 19 05:00 .glusterfs/0f/e1/0fe1a6e3-61a4-4216-97c9-15b074d0a3a1
.glusterfs/0f/e1/0fe1a6e3-61a4-4216-97c9-15b074d0a3a1: lzop compressed data - version 1.030, LZO1X-1, os: Unix
[...]

A vous de jouer

Maintenant qu’on sait où sont nos données, à vous de choisir ce que vous voulez en faire. Dans mon cas, j’aurai pu me contenter de tout supprimer. Mais vous pouvez aussi tenter de les restauter si vous savez quel fichier correspond à quoi !

Dans mon cas encore, j’ai été capable de remettre finalement à disposition le fichier via une petite boucle :

root@glusternode:/data/brick1/gv0# for i in $(find .glusterfs/ -mindepth 3 -size +1 -links 1 -type f); do ln $i dump/vzdump-qemu-$(basename $i).vma.lzo; done
root@glusternode:/data/brick1/gv0# ll dump/
total 93441940
-rw-r--r-- 2 root root 10481534660 juil. 19 05:00 vzdump-qemu-0fe1a6e3-61a4-4216-97c9-15b074d0a3a1.vma.lzo
-rw-r--r-- 2 root root 1506948985 août 5 02:17 vzdump-qemu-149fd851-905e-4e60-bfb3-6f60d4142df2.vma.lzo
-rw-r--r-- 2 root root 1278854342 août 5 02:29 vzdump-qemu-2bdaa890-0753-42a7-948b-a9cd58c9f673.vma.lzo
-rw-r--r-- 2 root root 1472129448 juil. 29 02:12 vzdump-qemu-3f1cf4a6-8d36-4a08-b4c2-d82f88745b09.vma.lzo
-rw-r--r-- 2 root root 14089336831 juil. 29 03:33 vzdump-qemu-5c2a1f8e-3f86-4b2b-b924-b0ae6cb7739b.vma.lzo
-rw-r--r-- 2 root root 1474206817 août 2 02:08 vzdump-qemu-5e0467b5-8ac8-4774-8b24-2b37238cfd31.vma.lzo
[...]

On repasse sur le vrai point de montage pour voir si ça a bien marché :

cd /mnt/pve/GlusterBkp/dump
root@glusternode:/mnt/pve/GlusterBkp/dump# ll
total 93441733
-rw-r--r-- 2 root root 10481534660 juil. 19 05:00 vzdump-qemu-0fe1a6e3-61a4-4216-97c9-15b074d0a3a1.vma.lzo
-rw-r--r-- 2 root root 1506948985 août 5 02:17 vzdump-qemu-149fd851-905e-4e60-bfb3-6f60d4142df2.vma.lzo
-rw-r--r-- 2 root root 1278854342 août 5 02:29 vzdump-qemu-2bdaa890-0753-42a7-948b-a9cd58c9f673.vma.lzo
-rw-r--r-- 2 root root 1472129448 juil. 29 02:12 vzdump-qemu-3f1cf4a6-8d36-4a08-b4c2-d82f88745b09.vma.lzo
-rw-r--r-- 2 root root 14089336831 juil. 29 03:33 vzdump-qemu-5c2a1f8e-3f86-4b2b-b924-b0ae6cb7739b.vma.lzo
-rw-r--r-- 2 root root 1474206817 août 2 02:08 vzdump-qemu-5e0467b5-8ac8-4774-8b24-2b37238cfd31.vma.lzo
[...]

Et les fichiers réapparaissent dans l’interface de ProxMox

Cet article Retrouver des fichiers supprimés sur une brick Gluster est apparu en premier sur Zwindler's Reflection.

Des hôtes qui n’existent plus sont toujours visible dans l’interface de Centreon

Je plante le décor : Vous avez une infrastructure supervisée avec Centreon. Cool :). Vous aviez des collecteurs distants (aka poller) et vous avez décidé de les supprimer finalement (je sais pas, imaginons que finalement le client décide d’annuler le projet par exemple, même si ça n’arrive jamais).

Et là, surprise. Vous n’aviez pas remarqué avant d’avoir définitivement supprimé la machine poller et toute sa configuration, mais les hôtes précédemment supervisés sont toujours visibles dans l’interface de Centreon, avec leur état en date de la dernière fois qu’un check a eu lieu, indéfiniment.

Pourtant, ils n’existent plus dans votre configuration !! Tout est désactivé (ou supprimé). Vous ne voyez pas ce que vous pouvez faire de plus !

Back in time

Il faut déjà se rappeler de comment marche Centreon, dans un premier temps.

Historiquement, Centreon se basait sur Nagios. Et Nagios est un programme des années 2000, monolithique, codé en C, et qui ne dispose pas, par conception, de stockage pour historiser les états des serveurs surveillés.

Ça peut paraitre fou aujourd’hui, mais Nagios n’a pas de base de données ! L’ensemble des états à un moment donné des serveurs était (est) stocké dans un fichier plat, tout le temps réécrit et que vous pouvez trouver dans un sous répertoire de nagios (var/status.log).

Cette méthode de fonctionnement « simple » (l’interface HTTP en CGI a juste à lire le fichier plat pour afficher les états des serveurs) est catastrophique pour les performances. J’ai vu des contextes où ce fichier était stocké en RAM via un ramdisk pour essayer de supporter un peu mieux la charge…

Conscients du manque qu’occasionne l’absence de base de données pour historiser l’état des serveurs au delà de leur état instantané, les gens de chez Nagios ont créé un connecteur externe (le « broker » ndo2db) qui permet de transmettre une copie des résultats à une base de données (MySQL le plus souvent mais je me demande si il n’y a pas aussi Oracle ?). Le modèle de la base NDO est accessible sur le site de Nagios.

Où je veux en venir avec tout ça ?

Ce broker externe a été un peu détourné de son but initial par plusieurs projets, dont Centreon, qui l’a utilisé en tant que source principale pour afficher les status des serveurs. Utiliser la base NDO comme source principale a un 2ème avantage : il est possible d’agréger plusieurs serveur Nagios dans une même base de données. On a donc la possibilité de gérer plusieurs serveur depuis une même interface => c’est le principe utilisé par les collecteurs de Centreon.

Le collecteur par défaut (Central) est composé du cœur de Centreon lui même gérant l’interface et la configuration de tous les pollers ainsi que de la base NDO et du connecteur NDO2DB. Les pollers eux ne sont que des moteurs Nagios, leur configuration « Nagios » est générée par le Central, et les données sont collectées via ndomod (le connecteur qui envoie les données sur le ndo2db).
[Avant de me prendre la remarque, ce que je dis ici n’est plus tout à fait vrai car Centreon et réécrit depuis longtemps tous ces composants, notamment centreon-broker pour ndo2db, centreon-engine pour le moteur Nagios. Mais le principe reste le même]

Comme la base contenant la configuration des pollers est distincte de la base NDO, il est « normal » que l’inactivation d’un poller n’ait pas d’impact sur le contenu de la base NDO. NDO ne stocke des données venant des serveurs Nagios, au fil de l’eau, et n’a aucune connaissance de la configuration dans Centreon…

La vraie méthode

Si vous n’avez pas encore tout pété comme je le décris dans le premier paragraphe, vous serez content d’apprendre qu’il existe une meilleure méthode. La « vraie » méthode (à moins qu’il y en ait encore une autre que je ne connais pas) est décrite dans ce post que j’ai retrouvé sur le forum Monitoring-fr.

David GUENAULT (un des piliers de Monitoring-fr et qui a contribué sur plusieurs projets) nous donne la solution :

bah en fait c’est tout simple
tu réaffecte tes hôtes sur le poller principal :

• configuration->hosts puis filtre sur le poller que tu veux enlever
• selection des hôtes
• dans la combo => massive change
• dans la combo monitored from => tu selectionne ton central et validation

tu supprimes ensuite le poller dans l’interface de centreon :

• tu supprime ta config ndo relative au poller que tu veux enlever : configuration -> centreon -> ndomod
• tu supprime le poller dans : configuration->centreon->pollers

tu pousses ta configuration : configuration -> nagios -> generate

Bon et si c’est trop tard ?

Mais si vous êtes sur cet article c’est peut être que c’est déjà trop tard et que vous n’avez plus moyen de réaliser la procédure ci-dessus ?

Et bien là, pas le choix. Il va falloir aller bidouiller la base de données NDO !

Le plus simple est de se connecter directement via le shell mysql depuis votre serveur Central. Dans la base de données NDO, on peut donc chercher les instances existantes :

select * from nagios_instances;
+-------------+---------------+----------------------+
| instance_id | instance_name | instance_description |
+-------------+---------------+----------------------+
|           1 | Central       |                      |
|           3 | Poller1       |                      |
|           4 | Poller2       |                      |
|           5 | Poller3       |                      |
+-------------+---------------+----------------------+

Dans mon cas, c’est Poller1 que j’ai supprimé. Pour essayer de ne pas trop faire n’importe quoi, je préfère toujours regarde un peu ce que je compte modifier avant de le faire

Je liste tous les objets de Nagios, puis je compare avec ceux de mon instance 3.

SELECT count(*) FROM nagios_objects;
+----------+
| count(*) |
+----------+
|    11820 |
+----------+
1 row in set (0.00 sec)

SELECT count(*) FROM nagios_objects where instance_id = 3;
+----------+
| count(*) |
+----------+
|      815 |
+----------+
1 row in set (0.00 sec)

Connaissant mon infra, cela parait cohérent. Le Poller1 est un petit poller peu chargé. Je peux donc utiliser ma baguette magique : on a de la chance, NDO prévoit un « flag » is_active qui permet d’activer ou non un objet. Et il se trouve que Centreon gère correctement ce flag. Pour cacher nos hôtes fantômes dans Centreon, il suffit juste de les désactiver avec la commande suivante :

UPDATE nagios_objects SET is_active=0 WHERE instance_id = 3;

Normalement c’est quasi-intantanné. Tous les hôtes précédemments liés au Poller1 doivent disparaitre de l’interface.

Et la même en un peu plus chirurgical :

select object_id,instance_id,name1,is_active from nagios_objects where name1 like "VIEUX_SERVEUR_OUBLIE_HS";
+-----------+-------------+-------------------------+-----------+
| object_id | instance_id | name1                   | is_active |
+-----------+-------------+-------------------------+-----------+
|      6462 |           4 | VIEUX_SERVEUR_OUBLIE_HS |         1 |
|      6472 |           4 | VIEUX_SERVEUR_OUBLIE_HS |         1 |
+-----------+-------------+-------------------------+-----------+

UPDATE nagios_objects SET is_active=0 where name1 like "VIEUX_SERVEUR_OUBLIE_HS";
Query OK, 2 rows affected (0.01 sec)
Rows matched: 2  Changed: 2  Warnings: 0

« J’aime beaucoup les zèbres, les rayures sont bien parallèles. »

J’ai eu le plaisir récemment de ré-écouter le sketch de Pierre Desproges : « Le maniaque ». Voilà la toute première phrase du sketch :

« Je ne suis pas à proprement parler ce qu’on appelle un maniaque. Simplement j’aime que tout brille et que tout soit bien rangé. »

Si vous non plus, vous ne pouvez pas vous résoudre à laisser trainer dans NDO des milliers d’objets, certes inactivés, mais toujours bien présents, cachés sous le tapis, la suite de cet article est pour vous (ou si vous êtes simplement curieux).

Pour descendre un peu plus dans les arcanes de NDO, je vous propose de regarder un peu ce qu’on peut trouver avec les requêtes suivantes :

select host_id,instance_id,display_name
from nagios_hosts
where instance_id != 1 limit 10;
+---------+-------------+--------------------+
| host_id | instance_id | display_name       |
+---------+-------------+--------------------+
|   32149 |           2 | AAAAAA-HHHHHH01    |
|   32157 |           2 | AAAAAA-DADADADAD02 |
|   32150 |           2 | AAAAAA-DAD02       |
|   32146 |           2 | AAAAAA-GGGG        |
|   32151 |           2 | AAAAAA-DDDDDA      |
|   32152 |           2 | AAAAAA-DDDDDB      |
|   32153 |           2 | AAAAAA-EEEE02      |
|   32154 |           2 | AAAAAA-FFFFFFF02   |
|   32155 |           2 | AAAAAA-FFFFFF02    |
|   32156 |           2 | AAAAAA-UUUUUUUUU01 |
+---------+-------------+--------------------+
10 rows in set (0.00 sec)

select object_id,instance_id,name1,name2,is_active from nagios_objects where instance_id != 1 limit 10;
+-----------+-------------+------------------+-------+-----------+
| object_id | instance_id | name1            | name2 | is_active |
+-----------+-------------+------------------+-------+-----------+
|      3307 |           0 | XXXXXXXXXX_ILO   | ping  |         0 |
|      5365 |           3 | check_icmp       | NULL  |         0 |
|      5366 |           3 | AAAAAA-CCC01     | NULL  |         0 |
|      5367 |           3 | 24x7             | NULL  |         0 |
|      5368 |           3 | AAAAAA-BBBBBA    | NULL  |         0 |
|      5369 |           3 | AAAAAA-BBBBBB    | NULL  |         0 |
|      5370 |           3 | AAAAAA-AAA       | NULL  |         0 |
|      5371 |           3 | AAAAAA-SAVE      | NULL  |         0 |
|      5372 |           3 | AAAAAA-SGBD01    | NULL  |         0 |
|      5373 |           3 | AAAAAA-VMOTION01 | NULL  |         0 |
+-----------+-------------+------------------+-------+-----------+
10 rows in set (0.01 sec)

select service_id,host_object_id,instance_id,display_name
from nagios_services
where instance_id != 1 limit 10;
+------------+----------------+-------------+------------------+
| service_id | host_object_id | instance_id | display_name     |
+------------+----------------+-------------+------------------+
|     213526 |           4686 |           2 | BasculeClusterHA |
|     213527 |           4686 |           2 | ping             |
|     213528 |           4687 |           2 | BasculeClusterHA |
|     213529 |           4687 |           2 | ping             |
|     213530 |           4688 |           2 | ping             |
|     213678 |           4669 |           2 | /appli           |
|     213531 |           4689 |           2 | ping             |
|     213532 |           4700 |           2 | ping             |
|     213533 |           4703 |           2 | ping             |
|     213534 |           4704 |           2 | ping             |
+------------+----------------+-------------+------------------+
10 rows in set (0.00 sec)

select nagios_hosts.display_name,nagios_services.display_name,nagios_services.instance_id
from nagios_hosts,nagios_objects,nagios_services
where nagios_hosts.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id in
(select host_object_id from nagios_hosts where instance_id = 3) limit 10;
+-----------------+-------------------------------+-------------+
| display_name    | display_name                  | instance_id |
+-----------------+-------------------------------+-------------+
| SRV             | BasculeClusterHA              |           3 |
| SRV             | check_http_aaaa               |           3 |
| SRV             | check_mountpoint_cifs_log     |           3 |
| SRV             | check_mountpoint_cifs_spl     |           3 |
| SRV             | ping_lan                      |           3 |
| SRV2            | BasculeClusterHA              |           3 |
| SRV2            | ping_lan                      |           3 |
| SRV3            | BasculeClusterHA              |           3 |
| SRV3            | ping_lan                      |           3 |
| ILO             | ping_lan                      |           3 |
+-----------------+-------------------------------+-------------+
10 rows in set (0.01 sec)

[Aparté]Je pense qu’il faut que je trouve un module WordPress pour pseudonymiser les données automatiquement, je me fatiguerais moins à changer le nom des serveurs…[/Aparté]

Comme vous pouvez le constater, il y en a partout : c’est terrible !

DELETE FROM nagios_hosts WHERE instance_id =3;
DELETE FROM nagios_services WHERE instance_id =3;
DELETE FROM nagios_hostgroups WHERE instance_id =3;
DELETE FROM nagios_servicegroups WHERE instance_id =3;
DELETE FROM nagios_objects WHERE instance_id =3;

Cet article Impossible de faire disparaitre les hôtes après suppression d’un poller Centreon est apparu en premier sur Zwindler's Reflection.

C’est la rentrée, vous reprendrez bien un petit article sur Proxmox !

Ou plutôt, c’est bientôt la rentrée et il est grand temps que je solde les articles qui trainent dans mes tiroirs car je moi pars bientôt en vacances.

« Et tout le monde s’en fout »

J’ai donc rédigé un tutoriel pas à pas pour vous montrer qu’on peut créer rapidement un petit cluster sous Proxmox avec deux petites machines chez un hébergeur pas cher type Kimsufi (j’avais justement deux machines car j’ai profité d’une promo chez eux), sans que les machines soient dans le même sous réseau IP.

Si vous ne connaissez pas Proxmox, je vous renvoie vers les articles que M4vr0x ou moi avons écris sur le sujet.

Pourquoi un tutoriel pour les clusters Proxmox ?

Vous allez me dire, pourquoi un énième article sur le sujet ? La documentation officielle, même si elle est en anglais, est assez claire et il existe plusieurs tutoriels en Français pour le faire.

Ah ah oui… mais la distinction c’est « faire un cluster de machines Proxmox, sans que les machines soient dans le même sous réseau IP » !

Et à moins que vous ayez une chance de ouf’, il est peu probable que vos deux Kimsufi le soient.

Petit rappel des prérequis pour faire un cluster Proxmox

• Deux serveurs physiques (au minimum)
• Port 22 accessible au moins dans un premier temps pour configurer le cluster
• Que la latence d’un serveur à l’autre soit inférieure à 2ms
• Que les deux serveurs soient capables de communiquer en multicast

Et là, c’est le drame !

Jusqu’à ce qu’on arrive à la dernière ligne, nous étions sereins.

Si jamais vous avez deux serveurs chez Kimsufi (ou autre) et que vous essayez de les faire communiquer en multicast, vous allez vite vous rendre compte que le multicast est bloqué !

Impossible donc de faire fonctionner correctement votre cluster Proxmox (basé sur corosync) sans cela. Vous pouvez mettre tous les autres tutos à la poubelle ;-).

Bidouille & compagnie, et les risques encourus

Si vous vous sentez la curiosité de monter quand même un cluster sur votre Kimsufi, on va contourner le problème en montant un VPN entre les deux machines. M4vr0x a déjà détaillé l’utilisation d’OpenVPN avec pfSense sur Proxmox, mais on n’était pas dans le même contexte.

On ne peut pas se baser là dessus dans le cas présent car Proxmox a la fâcheuse manie de réinitialiser toute la configuration lorsqu’on démarre le mode « cluster » .

ATTENTION !!!
Oui, ça veut bien dire que vous ne verrez plus ni vos VMs existantes, ni le stockage que vous avez précédemment configuré…
Les VMs continuent d’exister et sont accessibles tant que vous ne rebootez pas. Le stockage aussi. Ce n’est juste plus visible.

Vous l’avez deviné, c’est du vécu : j’ai flingué ma configuration existante lorsque j’ai initialisé le cluster.

Mise en réseau

Maintenant que vous savez ce que vous risquez, on va donc configurer tout ça à la main, directement en SSH sur les machines Proxmox :

Sur le serveur 1

La première chose à faire est simplement d’installer openvpn, ainsi qu’un utilitaire qui s’appelle easy-rsa qui va nous faciliter la tâche de configuration.

apt-get update
apt-get upgrade
apt-get install openvpn easy-rsa

Une fois que c’est fait, on copie les templates de config et les scripts de easy-rsa et on modifie les valeurs par défaut par nos propres valeurs.

cp -ai /usr/share/easy-rsa/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
vi vars
[...]
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Aquitaine"
export KEY_CITY="Bordeaux"
export KEY_ORG="mondomaine.tld"
export KEY_EMAIL="key@mondomaine.tld"
export KEY_OU="key"

Sourcez le fichier nouvellement rempli :

. ./vars

Nettoyez les clés provenant d’anciennes itérations de l’outil (pas nécessaire si c’est la première fois mais si vous n’en êtes pas au premier coup, ça peut éviter des erreurs bêtes) :

./clean-all

Et enfin, on génère l’ensemble des clés dont vous aurez besoin (les CA, les clés serveurs, les clés clientes et la diffie helmann) :

./build-ca
./build-key-server serveur1.mondomaine.tld
./build-key serveur2.mondomaine.tld
./build-dh

Normalement tout devrait se passer sans encombre et vous devriez avoir plusieurs certificats nouvellement créés. On va copier les certificats du serveur OpenVPN dans le dossier /etc/openvpn, puis envoyer les certificats du client par SCP :

cp keys/ca.* keys/serveur1.mondomaine.tld.* keys/dh2048.pem /etc/openvpn/

scp keys/ca.crt keys/serveur2.mondomaine.tld.crt keys/serveur2.mondomaine.tld.key serveur2.mondomaine.tld:/etc/openvpn/

Maintenant qu’on a tout, on peut créer le fichier de configuration. Ici rien de bien compliqué à comprendre :

• On créé un fichier server.conf qui va monter un VPN sur le port 1194 en UDP via un device de type TAP (j’y reviendrai) et on force le réseau en 10.9.0.0/24
• On donne le chemin vers tous les certificats qu’on vient de créer
• On ajoute un script « up » et un script « down », avec l’option script-security à « 2 » sinon ça ne fonctionnera pas

cat > /etc/openvpn/server.conf << EOF
    # [server.conf]
    port 1194
    proto udp
    #dev tun
    dev tap
    ca /etc/openvpn/ca.crt
    cert /etc/openvpn/serveur1.mondomaine.tld.crt
    key /etc/openvpn/serveur1.mondomaine.tld.key
    dh /etc/openvpn/dh2048.pem
    server 10.9.0.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    keepalive 10 120
    comp-lzo
    persist-key
    persist-tun
    status openvpn-status.log
    verb 3
    script-security 2
    up /etc/openvpn/add_multicast_route
    down /etc/openvpn/add_multicast_route
EOF

Bon et qu’est ce qu’il contient ce fameux script ? Et bien pour l’instant il se contente simplement d’ajouter et de supprimer une route sur les serveurs qui va router « à la main » tout le traffic multicast non par vers la gateway, mais vers le VPN ! Et c’est comme ça qu’on va contourner le blocage des flux multicast entre nos deux Kimsufi !

vi /etc/openvpn/add_multicast_route
    #!/bin/bash
    #
    # Add a route to force multicast through VPN

    [ "$script_type" ] || exit 0

    case "$script_type" in
      up)
            route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
            ;;
      down)
            route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
            ;;
    esac
chmod +x /etc/openvpn/add_multicast_route

On termine par démarrer (et activer au démarrage) le serveur OpenVPN :

systemctl enable openvpn
systemctl start openvpn

Dans ce cas là, comme on est pas en réel mode client serveur ou l’ensemble du traffic client est routé sur le serveur on a pas besoin de modifier le paramètre kernel « ip_forward » :

sysctl net.ipv4.ip_forward
   net.ipv4.ip_forward = 0

Aparté tun vs tap

Les plus aguerris d’entre vous auront remarqués que j’ai volontairement choisi de ne pas utiliser une interface virtuelle de type tun (par défaut dans OpenVPN) mais une interface de type tap.
Historiquement, ce type d’interface est connu pour ne pas fonctionner correctement en multicast, ce qui est ici notre but principal.

A priori c’est censé être résolu depuis longtemps, mais chez moi ça n’a pas marché alors que dès que j’ai switché sur tap ça a fonctionné directement. Je vous engage à regarder si ça vous intéresse. J’ai mis un lien vers une discussion à ce sujet sur le forum d’OpenVPN en fin d’article.

Sur le serveur 2

Maintenant que le serveur est configuré, au tour du client. Même topo, à ceci près qu’on ne va pas générer de certificats (c’est déjà fait).

apt-get update
apt-get upgrade
apt-get install openvpn

cat > /etc/openvpn/client.conf << EOF # [client.conf] client #dev tun dev tap proto udp remote @IP_publique_du_serveur1 1194 resolv-retry infinite nobind persist-key persist-tun mute-replay-warnings ca /etc/openvpn/ca.crt cert /etc/openvpn/serveur2.mondomaine.tld.crt key /etc/openvpn/serveur2.mondomaine.tld.key ns-cert-type server comp-lzo verb 3 script-security 2 up /etc/openvpn/add_multicast_route down /etc/openvpn/add_multicast_route EOF echo ' #!/bin/bash # # Add a route to force multicast through VPN [ "$script_type" ] || exit 0 case "$script_type" in up) route add -net 224.0.0.0 netmask 240.0.0.0 dev $1 ;; down) route del -net 224.0.0.0 netmask 240.0.0.0 dev $1 ;; esac' > /etc/openvpn/add_multicast_route
chmod +x /etc/openvpn/add_multicast_route

systemctl enable openvpn
systemctl start openvpn

Facile, hein ?

Sur tous les nœuds

Pour s’assurer que tout fonctionne comme ça devrait (ou pour déboguer), vous pouvez autoriser temporairement la réponse à l’ICMP sur multicast. Un simple ping permettra de s’assurer que les deux serveurs se voient bien :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

root@serveur1:/etc/pve# ping 224.0.0.1
PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 10.9.0.2: icmp_seq=1 ttl=64 time=1.07 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=2 ttl=64 time=0.672 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=3 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=3 ttl=64 time=0.619 ms (DUP!)

Les deux serveurs répondent aux pings depuis l’interface du VPN, on est bons ! Du coup vous pouvez re-désactiver la réponse aux broadcasts avec la commande suivante :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=1

Pour faciliter la résolution de noms dans le cluster, vous pouvez ajouter les IPs VPN des serveurs dans le fichier /etc/hosts.

vi /etc/hosts
[...]
10.9.0.1        serveur1-vpn
10.9.0.2        serveur2-vpn

Création du cluster

Sur le nœud 1

En théorie, si on lit la documentation il suffit simplement de faire « pvecm create mycluster » et le tour est joué.

STOOOOP !

Si vous le faite, ça ne fonctionnera pas. Pourtant tout est correct au niveau des prérequis : les nœuds fonctionnent bien et que le multicast est correctement routé via le VPN. Un coup d’œil au fichier de configuration de corosync nous en apprendra plus :

cat /etc/pve/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: serveur2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: serveur2
  }

  node {
    name: serveur1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: serveur1
  }

}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: mycluster
  config_version: 4
  ip_version: ipv4
  secauth: on
  version: 2
  interface {
    bindnetaddr: @IP_publique_du_serveur1
    ringnumber: 0
  }

}

En fait le problème ici, c’est que l’adresse bindée bindnetaddr: n’est pas bonne. Si vous n’avez pas lu mon gros « STOOOOP », il faut tout réinitialiser car il est assez compliqué de modifier un cluster existant sous Proxmox (a priori pas possible proprement mais je vous donnerai la tips dans un prochain article).

Voilà la bonne commande à taper :

pvecm create mycluster -bindnet0_addr 10.9.0.1 -ring0_addr serveur1-vpn
    Corosync Cluster Engine Authentication key generator.
    Gathering 1024 bits for key from /dev/urandom.
    Writing corosync key to /etc/corosync/authkey.

Sur le noeud 2

En théorie, là aussi c’est très facile. Il suffit de faire « pvecm add serveur2-vpn » pour que l’hôte serveur2.mondomaine.tld rejoigne le cluster créé sur le noeud serveur1.mondomaine.tld.

Voilà ce qui va se passer si vous le faites :

pvecm add serveur1-vpn
    The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
    ECDSA key fingerprint is SHA256:VOIH2X7kTzWLUEzRPCl4431hlYnc3HCsDmzXYEs3V+g.
    Are you sure you want to continue connecting (yes/no)? yes
    root@serveur1-vpn's password:
    copy corosync auth key
    stopping pve-cluster service
    backup old database
    Job for corosync.service failed because the control process exited with error code.
    See "systemctl status corosync.service" and "journalctl -xe" for details.
    waiting for quorum...

Même principe ici. Si l’adresse ring0_addr n’est pas spécifiée explicitement, corosync va tenter de s’abonner sur une IP multicast sur l’IP de l’interface Ethernet principale. Elle ne passera donc pas pas notre VPN et le cluster ne communiquera pas en multicast !

Vous pouvez en lire plus là dessus sur ce lien.

Sur le noeud serveur2, on ajoute donc l’adresse IP (et donc l’interface) que corosync devra emprunter pour communiquer avec serveur1-vpn (via le VPN donc).

pvecm add serveur1-vpn -ring0_addr 10.9.0.2
    The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
    ECDSA key fingerprint is SHA256:oKkuOYY1pbEa1RrM0y9fWVJfnQabhUvG7la+6fZUnQ4.
    Are you sure you want to continue connecting (yes/no)? yes
    root@serveur2-vpn's password:
    copy corosync auth key
    stopping pve-cluster service
    backup old database
    waiting for quorum...OK
    generating node certificates
    merge known_hosts file
    restart services
    successfully added node 'serveur2' to cluster.

A partir de là, tout devrait marcher. Vous devriez avoir sur la même interface vos deux serveurs, et avoir perdu toutes vos VMs si vous n’avez pas bien lu mon avertissement

A noter : chose qui n’était pas possible entre la version 3 et la version 4 (car les deux composants n’utilisaient pas le même logiciel pour le clustering), il est possible de faire un cluster ProxMox mixant version 4 et version 5 comme le montre cette capture d’écran :

Aller plus loin : les limites d’OpenVPN

On a maintenant un cluster de 2 machines Proxmox. Pour autant, ce n’est pas idéal et ça ne suffira pas pour passer en production, notamment en cas de coupure réseau entre les deux machines (split brain). On va vite vouloir en rajouter au moins une, sinon plus.

Cependant, on sera bloqués. Les limites de cette méthode est que la configuration d’OpenVPN est en mode client-serveur. Si vous avez plus de 2 machines, vous vous rendrez vite compte que vous pouvez communiquer entre les clients et le serveurs, mais pas entre clients.

Et en gros ça ne marche pas, le 3ème noeud ne rejoindra pas le cluster car il ne peut pas joindre l’ensemble des membres et il se mettra en defaut.

Pour bien faire en conservant ce mécanisme, il va falloir monter un service VPN externe aux serveurs Proxmox, qui seront tous clients de ce service, ou alors se créer un réseau de type full mesh, par exemple avec de l’IPSec si vous êtes un maitre en Réseau/Telco.

Autant dire qu’il vaut mieux passer par un hébergeur qui permet le multicast ou qui fourni un service VPN. Ca ira plus vite…

Sources et sujets connexes

• Un autre tuto qui ne me semble pas 100% exact, notamment la partie création et « join » du cluster
• Sending multicast over a openvpn tunnel
• La documentation officielle pour les clusters sur des sous réseaux distincts
• Un topic intéressant sur les limites d’OpenVPN et les réseaux full mesh

Cet article [Tutoriel] Faire un petit cluster Proxmox chez Kimsufi avec OpenVPN est apparu en premier sur Zwindler's Reflection.

Faire et défaire des clusters Proxmox VE, c’est toujours travailler

Si vous avez lu et appliqué à la lettre mon article précédent sur les clusters Proxmox VE quand on a pas de multicast (ou autre si vous n’êtes pas bridé sur le multicast), vous devriez être l’heureux propriétaire d’un cluster Proxmox VE fonctionnel.

Mille bravo !

Mais personne n’est parfait et n’est à l’abris d’une faute de frappe, d’un oubli ou d’une erreur, et je me suis retrouvé devant un cluster en vrac, complètement bloqué, avec une partie des nœuds fonctionnels et l’autre marqués « failed ».

OK… J’avoue. Je suis un bourrin quand je bidouille. Ça m’est arrivé… plusieurs fois…

Dans cet article, je vais donc vous donner la marche à suivre pour supprimer complètement toute trace des configurations du cluster et ainsi repartir à zéro pour recommencer (sans avoir à tout réinstaller car ça marche aussi mais bon…)

[Aparté]Une fois encore, si vous ne connaissez pas ProxMox VE je vous invite à consulter les articles que M4vr0x et moi avons écris à ce sujet, il commence à y en avoir pas mal[/Aparté]

Sous le capot

D’abord, je voudrais rapidement rappeler que Proxmox VE est un logiciel de virtualisation qui est majoritairement déployé via un ISO contenant une Debian modifiée. Le cœur du clustering dans ProxMox se base sur Corosync (depuis la version 4+), avec l’ajout d’un filesystem distribué maison pour ce qui est gestion de configuration cohérent sur tous les nœuds (pmxcfs).

On peut récupérer beaucoup d’informations sur le cluster simplement en allant consulter les fichiers de configuration présents dans les dossiers de corosync. C’est d’ailleurs comme ça que je m’en suis sorti quand j’avais tout cassé dans mon article précédent.

Sortir proprement un nœud

La documentation officielle donne la marche à suivre dans le cas où vous souhaitez juste sortir un nœud de votre cluster. Si ce n’est pas vraiment notre but ici, ça peut quand même vous servir et surtout, c’est une des étapes dont nous aurons besoin pour la suite.

Pour la suite de l’article, je vais appeler nœud srv1 le serveur que nous allons garder jusqu’à la fin, et srv2, srv3, etc… tous les autres serveurs du cluster.

Sur le nœud srv1

La première chose à faire est de réduire le nombre de nœuds expected par le cluster corosync. L’idée étant qu’à un moment donné, corosync s’attend à avoir au minimum X nœuds, X étant le nombre de serveurs du cluster. S’il en a moins, le cluster se bloque pour empêcher toute modification dans le cas où on serait en « mode dégradé ». On va donc réduire ce nombre de 1 pour que le cluster ne soit pas trop surpris par la suppression d’un nœud.

Dans mon exemple je n’ai que deux serveurs. Cependant, si on a plus de nœuds, il faudra reproduire la procédure jusqu’à ce qu’il ne reste plus qu’un nœud.

pvecm expected 1

pvecm delnode srv2
    Killing node 2

Sur le nœud à supprimer

A partir de maintenant, pour tout le reste du cluster, le nœud srv2 (ou tout autre à supprimer) n’en fait plus parti. Cependant, la procédure n’agit pas (ou pas entièrement) sur le nœud 2 en lui même : il reste quand même du ménage à faire. Et si on ne le fait pas, et qu’on essaye de le réintégrer dans le cluster, il y aura des restes et l’intégration risque d’échouer à nouveau.

A noter, à ma connaissance la coupure de ces services n’ont pas d’impact sur l’état de vos machines virtuelles actives. Cependant, par précaution, je vous conseille de ne pas me croire sur parole et de vous assurer que rien de critique ne tourne sur ce nœud avant retrait du cluster.

systemctl stop pvestatd.service
systemctl stop pvedaemon.service
systemctl stop pve-cluster.service
systemctl stop corosync

A noter que dans Proxmox VE, au delà du simple fichier texte présent sur le filesystem, la configuration est également stockée dans une base sqlite. Si on se contente de supprimer la configuration dans les fichiers, elle sera régénérée dès qu’on redémarrera les services. On va donc devoir la vider à la main :

sqlite3 /var/lib/pve-cluster/config.db
    SQLite version 3.8.7.1 2014-10-29 13:59:56
    Enter ".help" for usage hints.

sqlite> select * from tree where name = 'corosync.conf';
    2|0|3|0|1500655311|8|corosync.conf|logging {
    debug: off
    to_syslog: yes
    }
    nodelist {
        node {
            name: srv1
            nodeid: 1
            quorum_votes: 1
            ring0_addr: 10.9.0.1
        }
        node {
            name: srv2
            nodeid: 2
            quorum_votes: 1
            ring0_addr: 10.9.0.2
        }
    }
    quorum {
        provider: corosync_votequorum
    }
    totem {
        cluster_name: kimsufi
        config_version: 5
        ip_version: ipv4
        secauth: on
        version: 2
        interface {
            bindnetaddr: 10.9.0.2
            ringnumber: 0
        }
    }

sqlite> delete from tree where name = 'corosync.conf';
sqlite> select * from tree where name = 'corosync.conf';
sqlite> .quit

Maintenant qu’on a supprimé la configuration de corosync de la base sqlite, on peut supprimer la configuration définitivement (ou juste en faire un copie, si on est prudent) :

mv /var/lib/corosync/ /var/lib/corosync.$(date +%y%m%d%H%M)
mkdir /var/lib/corosync
mv /var/lib/pve-cluster/ /var/lib/pve-cluster.$(date +%y%m%d%H%M)
mv /etc/corosync /etc/corosync.$(date +%y%m%d%H%M)

Et enfin redémarrer les services :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service

On a donc un serveur qui a retrouvé son état initial (à savoir un serveur hors d’un cluster) sans avoir à le réinstaller complètement.

Pour la suite, je le rappelle : L’idée ici est donc d’appliquer cette procédure sur tous les nœuds sauf un (le dernier, srv1).

Détruire le cluster entier

Nous avons maintenant un cluster contenant une seule machine : srv1. Nous pouvons reproduire la même procédure que précédemment, à un détail près : pas besoin de réduire le nombre de votes expected, déjà descendu à 1.

Et on peut recommencer à jouer en redémarrer les services suivants sur srv1 :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service
systemctl start corosync

TADAM !!!! Vous pouvez re-tout casser

Source

• https://forum.proxmox.com/threads/removing-deleting-a-created-cluster.18887/

Cet article [Tutoriel] Démonter proprement un cluster Proxmox VE est apparu en premier sur Zwindler's Reflection.

Why would I deploy virtual machines with Ansible

[French readers]La version française de l’article est disponible à l’adresse suivante[/French readers]

Since a few month, I automate all that can be automated with Ansible (FR). Still, there was something that I still had to do manually and it bothered me (a lot).

Until then, I used Ansible both as a deployment tools (to install things on my machines) and also as a « Configuration Management » tool.

Let me explain :

• From a virtual machine template, I can deploy default configuration (depending of the machine role). I mean by configuration, the first sense of the term like configuration files, but also package installations.
• If I need to modify something on a subset of (or all!) my servers, I can push it on them with one command line.
• Should something/someone modify something on the server managed configuration, I can correct this with my Ansible magic wand by just playing all my playbooks on all the servers once in a while. All « non compliant » servers will be automatically corrected WITHOUT TOUCHING those that ARE compliant.

For the last part, it’s not really « magic ». Playbooks have to be written while keeping I mind that they must be « idempotent ». This is really important and that’s why I had to develop my own Ansible module for Centreon.

Still, I was frustrated because one last step was still missing: Provisionning VMs directly from Ansible!

What is the problem?

2 obstacles prevented me from doing it.

Gather facts

First, Ansible works with an inventory. If you try to tell Ansible that you want to create new machines and you add them to the inventory, the first thing Ansible will try to do is to connect to them… before they exists!

ansible-playbook -l 192.168.100.103 zwindler_deploy.yml

PLAY [xxxxxxaaaaaaaaaaa] ********************************************************************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************************************************************************
fatal: [192.168.100.103]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.100.103 port 22: No route to host\r\n", "unreachable": true}

PLAY RECAP **********************************************************************************************************************************************************************************
192.168.100.103 : ok=0 changed=0 unreachable=1 failed=0

We need to tell Ansible not to connect, at least at first.

You can do that by using the option gather_facts: false, which, you guessed, tells Ansible not to gather facts…

But that’s still not enough. If you try to run the playbook with just this option, Ansible will still try to connect to the yet to be created server, failing.

Most of the time, people use the delegate_to option, which tells Ansible to connect to another server for one specific task. I had used it previously to feed informations in Centreon with CLAPI.

Here, if you need to run several tasks and none of them have to be executed on the remote machine (that we are trying to deploy), you can just specify at the head of the playbook that all tasks are to be executed from the local machine, with connection: local :

  gather_facts: false
  connection: local

To sum this up, with these 2 options, you can tell Ansible not to « gather facts » as a preliminary step of every playbook, and to execute everything locally, thus avoiding the failing connection to the yet inexistant servers.

Problem solved.

vsphere_guest versus vmware_guest

My second issue was that 2 groups of modules were available in Ansible core, and one of them was abandonned. Of course, I was using the oldest abandonned one, because it’s the one that posts up in all the tutorials/examples I could find on Internet .

You can find it here vsphere_guest. It « works », and it has been integrated to the core way sooner (v 1.6) and needs the python dependancy pysphere (not maintained since 2013)!

There is no reason « not » to use vsphere_guest to provision your virtual machine. Latest version of this module works for vSphere v5 and should work for 6.X. A good example of what can be done with this module can be found on this nice blog-post from EverythingShouldBeVirtual.

Yet, you won’t be able to:

• Modify the virtual machine (like vCPU, …) if you generate it from a vm template
• Customize it on the OS level (change hostname, IP, …)

I massively use templates so this was clearly an issue. My typical usecase is this : I deploy a virtual machine from a given template (depending which type of service I want) and then finalize customisation through Ansible playbooks.

In this case, I would have to deploy my virtual machine, and still have to go into them to modify them (like hostname and IP) before playing my playbooks to customise them.

Hopefully, people at VMware didn’t stop at VIPerl and PowerCLI. It’s been a few years than there is a Python module, maintained by VMware, and regularly updated to take advantage of the new API functionnalities: pyvmomi.

From there, a new Ansible module, taking advantage of this python API, you have much more possibilities.

Let there be light

The list of Ansible modules taking advantage from pyvmomi is quite impressive. You can find them, they all start with vmware_ (you can find the list on the official Ansible documentation, VMware section).

Two of them particularly got my attention (but there are a lot more!):

• vmware_guest can help manage virtual machines
• vmware_vm_shell can execute commands directly inside the guest OS, provided it executes VMware Tools

Prerequisites

To execute this modules, you need:

• pyvmomi and its dependancies (python 2.6+ and sphinx)

pip install pyvmomi sphinx

• Ansible 2.2 minimum (but you’d better have 2.3 or even 2.4!)

On paper, the module « works » with Ansible 2.2, the actual version on stable depots. But most interesting functions appear in 2.3 so for now you have to compile sources!

The actual version on RHEL/CentOS 7 is 2.3.X. You don’t need to compile sources anymore, UNLESS you need the very latest additions which can be found in 2.4. I give you the necessary steps at the end of the article.

And now, the playbook !

The following playbook will:

• ask you for a priviledged account for vCenter
• deploy a virtual machine on the vCenter from a template

This deployment needs some variables that can be given directly from the Ansible host inventory like:

• virtual disk size
• vCPU number
• vRAM quantity
• target ESXi and target datasotre
• VM IP address and hostname

The virtual machine will be deployed as expected, except for hostname and IP. Those 2 parameters will be modified after first boot by VMware Tool.

cat zwindler_vmware_add_normal.yml
---
- hosts: all
  gather_facts: false
  connection: local

  vars_prompt:
    - name: "vsphere_password"
      prompt: "vSphere Password"
    - name: "notes"
      prompt: "VM notes"
      private: no
      default: "Deployed with ansible"

  tasks:
  # get date
  - set_fact: creationdate="{{lookup('pipe','date "+%Y/%m/%d %H:%M"')}}"

  # Create a VM from a template
  - name: create the VM
    vmware_guest:
      hostname: '{{ vsphere_host }}'
      username: '{{ vsphere_user }}'
      password: '{{ vsphere_password }}'
      validate_certs: no
      esxi_hostname: esxi_server
      datacenter: 'ZWINDLER'
      folder: A_DEPLOYER
      name: '{{ inventory_hostname }}'
      state: poweredon
      guest_id: rhel7_64Guest
      annotation: "{{ notes }} - {{ creationdate }}"
      disk:
      - size_gb: 150
        type: thin
        datastore: '{{ vsphere_datastore }}'
      networks:
      - name: server_network
        ip: '{{ custom_ip }}'
        netmask: 255.255.252.0
        gateway: 192.168.100.1
        dns_servers:
        - 192.168.100.10
        - 192.168.101.10
      hardware:
        memory_mb: 4096
        num_cpus: 2
      customization:
        dns_servers:
        - 192.168.100.10
        - 192.168.101.10
        domain : zwindler.fr
        hostname: '{{ inventory_hostname }}'
      template: tmpl-rhel-7-3-app
      wait_for_ip_address: yes

  - name: add to ansible hosts file
    lineinfile:
      dest: /etc/ansible/hosts
      insertafter: '^\[{{ ansible_host_group }}\]'
      line: '{{ item }}'
    with_items: '{{play_hosts}}'
    run_once: true

From there… well, you can do anything that pops in your mind!

Useful links

« pause » module might be useful in some cases when you really have to wait some time. I don’t use it and I wouldn’t even consider it for production.

• http://docs.ansible.com/ansible/pause_module.html

Also, I might write the same article with the Proxmox VE module. Stay tuned!

• http://docs.ansible.com/ansible/proxmox_kvm_module.html

New functionnalities

Until Ansible 2.3 2.4 becomes available in your OS repository, you might encounter this error if you use functions that aren’t included (yet) in your own version of Ansible (linked_clone or snapshot_src released in 2.4 for example) :

ansible-playbook zwindler_vmware_add_micro.yml
vSphere Password:
VM notes [Deployed with ansible]:

PLAY [ansible_node] **********************************************************

TASK [create the VM] ***********************************************************
fatal: [ansible_node]: FAILED! => {"changed": false, "failed": true, "msg": "unsupported parameter for module: linked_clone"}

PLAY RECAP *********************************************************************
ansible_node : ok=0 changed=0 unreachable=0 failed=1

Should you need a « yet to be released » functionnality, you can compile the latest version of Ansible from the sources (2.4 in my example here):

git clone https://github.com/ansible/ansible

cd ansible
make
make install

ansible --version
    ansible 2.4.0

Cet article Deploy VMware virtual machines with Ansible est apparu en premier sur Zwindler's Reflection.

ElasticStack

Il y a quelques temps, je me suis mis à tester ElasticStack et j’avais préparé des playbooks Ansible et un tutoriel pour vous en parler. m4vr0x (qui a déjà écrit quelques articles sur le blog) était super intéressé et je lui ai dit « t’inquiètes, j’écris un article bientôt sur le sujet ».

La bonne blague : c’était en juillet (ce qui n’est pas si loin quand je regarde mes plus vieux brouillons :-p ).

Présentation de la solution

Trêve de plaisanterie ! Plus connu sous son ancien acronyme (ELK), ElasticStack est une suite logicielle développée par elastic.co. Le cœur de l’application est basée sur les logiciels :

• Elasticsearch
• Logstash
• Kibana

Historiquement ces 3 produits étaient développés de manière indépendante (même si leur utilisation conjointe était conseillée). Courant 2016, elastic.co a décidé de refondre ces solutions et harmoniser les développements et les versions (tous les produits sont passés en version 5) pour proposer un ensemble complet cohérent.

Un bon article pour parler de ce renommage peut être consulté sur le site monitoring-fr.

La nouvelle architecture « classique » de la suite ElasticStack est la suivante :

Elasticsearch

Elasticsearch est un moteur de recherche et d’analyse RESTful distribué. C’est le cœur de la solution ElasticStack. Dans ce logiciel que sera stocké toutes les données qui seront collectés sur l’infrastructure. Les points forts de la solutions :

• la résilience et l’architecture hautement disponible
• la performance des requêtes grâce à l’indexation, particulièrement adapté à la recherche rapide de données de type métriques ou journaux

Paradoxalement, c’est la couche avec laquelle on interagit le moins au début, puisqu’on passe surtout du temps à configurer en amont la collecte des logs au niveau Beats et Logstash, puis en aval avec la visualisation dans Kibana.

Beats

La (relative) nouveauté. Introduit depuis le renommage et la version 5 de la suite logicielle, Beats regroupe un ensemble de modules logiciels de type « agents » à déposer sur les serveurs à surveiller.
Ce sont ces agents, adaptés pour chaque contexte, qui récoltent les données brutes et les transmettent à la brique suivante. Actuellement, il existe les agents suivants :

• Metricbeat
• Packetbeat
• Logbeat
• Winbeat

On peut directement collecter les données dans Elasticsearch, la couche Logstash étant optionnelle, mais on perd de nombreuses fonctionnalités et il est préférable de garder Logstash.

Logstash

Logstash est le module de collecte « historique ». C’est lui qui était chargé de récolter logs et métriques pour les transmettre à Elasticsearch.

Aujourd’hui, Logstash étant plus gourmand en ressources que les agents Beats, il peut être préférable de ne plus l’utiliser pour la collecte en elle même.

Cependant, à l’inverse, les agents Beats n’ont pas la capacité, contrairement à Logstash, de traiter les données récoltées. Il est donc intéressant de conserver Logstash en coupure entre les agents Beats et ElasticSearch pour réaliser des traitements sur les données collectées.

Un bon exemple est la collecte des logs. Par défaut, les données collectées par Filebeat contiennent les informations suivantes :

• un timestamp correspondant au moment de la collecte (attention, pas identique au moment où le log a été écrit!!!)
• le serveur source
• le fichier de log source
• la version de filebeat (super :/)
• la ligne complète collectée dans le log

Cependant, il est complexe d’exploiter les données ainsi collectées puisque les messages des logs contiennent souvent des informations multiples sur une même ligne. Par exemple dans /var/log/messages, on a les informations suivantes :

Date Heure Hostname Processus[PIDXXX]: le message

Avec Logstash, il est possible de « tronçonner » via une regexp cette ligne en plusieurs champs :

• Date et heure de l’événement journalisé (réelle cette fois, pas l’heure de collecte)
• Nom d’hôte
• Nom du processus concerné
• PID
• Le message réel

A partir de ces informations et associées aux informations récoltées par Beats, on peut donc gérer de manière beaucoup plus simple nos recherches et les consolider dans des graphiques avec Kibana.

Kibana

Kibana est une interface web qui permet d’explorer/de visualiser des informations provenant d’Elasticsearch et de les afficher sous formes de graphiques. On peut ensuite consolider les graphiques en tableaux de bords (dashboards).

Quelques exemples de dashboards qu’on peut créer :

Un gros point positif de la solution est la possibilité de filtrer en temps réel sur une sous catégorie des données, soit via une barre de recherche, soit en cliquant directement sur les graphiques, en mode « drill down« .

Par exemple, si je veux obtenir plus de détails sur les code retours 404, il me suffit de cliquer sur le code 404 dans le camembert, et Kibana filtrera les données de TOUS les graphiques du dashboard pour ne m’afficher que les données correspondantes :

Déploiement d’ElasticStack via Docker

Vous y avez cru ? Je ne vais pas vous donner les étapes pour installer ElasticStack via l’usage des containers Docker officiels.

Pourquoi ? Ce n’est pas parce que je n’utilise pas Docker. J’ai déjà massivement adopté cette techno. aussi bien dans le contexte pro que perso.
Mais tout simplement parce que c’est assez bien documenté sur le site et que c’est vraiment simple. Si l’article a vraiment beaucoup d’engouement et que c’est demandé gentiment, je ferai un effort .

Installation d’ElasticStack sur un serveur via Ansible

C’est un peu plus compliqué si vous ne voulez PAS déployer ElasticStack via Docker. La documentation indique d’autres méthodes, dont l’installation classique via des RPMs.

Au moment où j’avais écris les premières lignes du tutoriel, j’avais remarqué qu’il y avait aussi une méthode automatisée via Ansible et comme j’adore Ansible j’ai voulu l’utiliser.

Sauf qu’elle n’existait que pour Elasticsearch et en plus pour la version 2.3.X (version d’avant le grand renommage de 2016 dont je parle plus haut) !

Je me suis donc attelé à la tâche de développer mes propres playbooks pour automatiser tout ça. Et comme je suis sympa, je vous les met à disposition.

Installer la base, ELK

Le code suivant va vous permettre de déployer via Ansible les 3 logiciels ElasticSearch, Kibana et Logstash sur une seule et même machine. Mais comme les rôles ont été découpés en 3 playbooks, il est tout à fait envisageable d’installer ces rôles sur des machines différentes (ou juste une partie).

Les seuls prérequis sont d’avoir une machine CentOS 7 (ou RHEL ou équivalent) qui dispose d’Ansible et de git d’installé.

mkdir -p /etc/ansible/roles && cd /etc/ansible/roles
git clone https://github.com/zwindler/ansible-deploy-elasticsearch
git clone https://github.com/zwindler/ansible-deploy-kibana
git clone https://github.com/zwindler/ansible-deploy-logstash

A partir de là, vous n’avez plus qu’à créer un playbook qui va tirer parti de ces rôles :

cd /etc/ansible
cat deploy_kibana_elasticsearch_logstash.yml
---
- name: Install elastic stack
  hosts: localhost
  roles:
    - { role: ansible-deploy-kibana, tags: 'kibana' }
    - { role: ansible-deploy-elasticsearch, tags: 'elasticsearch' }
    - { role: ansible-deploy-logstash, tags: 'logstash' }

Et à lancer l’installation d’ELK sur l’hôte, affectueusement nommé « mon_serveur_elk » dans cet exemple, de la façon suivante :

ansible-playbook -l mon_serveur_elk deploy_kibana_elasticsearch_logstash.yml
ansible-playbook deploy_kibana_elasticsearch_logstash.yml

PLAY [Install elastic stack] ********************************************************************************************************************************

TASK [Gathering Facts] **************************************************************************************************************************************
ok: [mon_serveur_elk]

TASK [ansible-deploy-kibana : Add elasticsearch repository] ****************************************************************************************
changed: [mon_serveur_elk]
[...]
PLAY RECAP **************************************************************************************************************************************************
mon_serveur_elk               : ok=4   changed=21    unreachable=0    failed=0

A partir de là, on peut commencer à tester les composants uns par uns et vérifier que tout fonctionne.

Tester une config Logstash

On peut vérifier que Logstash fonctionne comme il le doit grâce à la fonction « config.test_and_exit ». Juste pour les besoins du test, je vais donc créer un fichier logstash qui va lire le dmesg présent sur la machine. Ça n’a pas forcément d’intérêt mais comme ça on verra s’il n’y a pas de lézards.

cd /etc/logstash/conf.d
cat > test.conf << EOF
input {
  file {
    path => "/var/log/dmesg"
    start_position => "beginning"
  }
}
output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
  }
}
EOF

/usr/share/logstash/bin/logstash -f test.conf --config.test_and_exit
    WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults
    Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console
    Configuration OK

On peut ignorer les warning ci dessus dans un premier temps. Tout fonctionne ! Si on le souhaite, on peut démarrer Logstash à la main et avec cette configuration avec la commande suivante :

/usr/share/logstash/bin/logstash -f test.conf --config.reload.automatic

Pour aller plus loin avec Logstash, je vous conseille de lire la documentation qui est assez progressive dans la difficulté. Les configurations de Logstash ne sont pas toujours évidentes et il peut y avoir pas mal de débuging les premières fois.

Requêter Elasticsearch

Il est tout à fait possible de requêter à la main ElasticSearch, directement via l’API. Un moyen simple de s’en convaincre est de réaliser un simple « curl » sur la base mais vous pouvez bien entendu faire beaucoup plus complexe avec des outils prévu pour explorer les APIs.

Par exemple, on peut afficher les informations de la base comme ceci :

curl -XGET 'localhost:9200/'
{
  "name" : "anXc9nn",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "5P9XdOMJRZOPIy38NegdnQ",
  "version" : {
    "number" : "5.5.0",
    "build_hash" : "260387d",
    "build_date" : "2017-06-30T23:16:05.735Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.0"
  },
  "tagline" : "You Know, for Search"
}

Autres commandes sympas, vous pouvez afficher l’état de santé de vos nœuds Elasticsearch. Ici je n’en ai qu’un et c’est donc considéré comme dangereux (car pas de redondance), d’où l’état « yellow » et pas « green » :

curl -XGET 'localhost:9200/_cat/health?v&pretty'
    epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
    1506795865 20:24:25  elasticsearch yellow          1         1    516 516    0    0      516             0                  -                 50.0%

curl -XGET 'localhost:9200/_cat/nodes?v&pretty'
    ip            heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
    x.x.x.x                 43          89   1    0.09    0.16     0.30 mdi       *      anXc9nn

Vous pouvez afficher la liste des fichiers correspondant à vos données avec cette commande :

curl 'localhost:9200/_cat/indices?v'
    health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
    yellow open filebeat-2017.06.19 w7tmj4L3ToqEdiHYmvHS8Q 5 1 981 0 270kb 270kb
    yellow open .kibana YFYjR5hFSGualaX-ahL_9g 1 1 2 0 23.5kb 23.5kb

Par défaut (et pour des questions de performance), on a pour habitude de segmenter les données dans Elasticsearch par jours. Au fil des jours de nouveaux fichiers seront créés et viendront remplir votre filesystem. Il ne faudra donc pas oublier de jeter un œil de temps et en temps et purger tout ça !

Et Kibana ?

Normalement, Kibana est accessible à l’adresse suivante :
http://[@ip_de_mon_serveur_elk]:5601/

Et maintenant, on collecte quoi ?

C’est bien gentil tout ça, mais pour l’instant on a rien du tout… Au delà de la simple connexion à Kibana, vous arriverez sur un écran de configuration qui cherchera, sans succès, des données dans elasticsearch.

Peine perdue, ces données n’existent pas encore puisqu’on ne collecte rien pour l’instant !

Vous trouverez probablement de nombreux tuto sur Internet expliquant comment collecter des données provenant de fichiers depuis Logstash. Cependant, comme je l’ai indiqué en début d’article, la méthode conseillée est maintenant d’utiliser plutôt les agents Beats, qui envoient les données à Logstash lorsqu’un traitement est nécessaire.

Et là encore, je vous ai préparé des playbooks tout fait pour installer et configurer à la fois les modules Beats sur les serveurs supervisés ET le logstash côté serveur ELK. Plus rien à faire donc, juste à attendre le 2ème article !

Haaan, quel suspense ! A la semaine prochaine

Ressources complémentaires

• Installer ELK sous Ubuntu 16.04 (Digital Ocean, encore eux)
• Sécurisation d’ElasticStack officielle avec les X-Pack : attention c’est payants !
• Comment sécuriser une plateforme Elasticsearch et Kibana (EN)

Cet article ElasticStack : Kibana, Elasticsearch, Logstash & Beats est apparu en premier sur Zwindler's Reflection.

Comment collecter ? Les agents Beats à la rescousse

Dans l’article précédent, je vous ai donné la marche à suivre pour déployer ELK très simplement sur un même serveur. Je vous avais aussi expliqué la nouvelle architecture d’ElasticStack et notamment l’ajout des agents Beats, moins gourmands et plus spécialisés que Logstash.

Dans cet article je vais donc continuer où nous nous étions arrêté et faire un focus sur les agents Beats pour les intégrer à notre plateforme ELK existante.

Qui sont-ils ? Quels sont leurs réseaux ?

Et oui parce qu’il y en a plusieurs. Si vous avez lu précédent, vous savez qu’il existe pour la collecte de données, en plus de Logstash, des modules plus légers dont la fonction n’est que de récupérer les informations sur les noeuds que vous voulez surveiller (et rien de plus).

On a donc :

• Filebeat, pour les fichiers de logs (texte)
• Metricbeat, qui collecte tout un tas de métriques, notamment système, mais aussi provenant de Docker
• Packetbeat, qui remonte des informations réseaux. Attention je parle d’informations très poussées sur les échanges réseaux, à la transaction près ! On peut faire de superbes graphiques et des analyses très poussées de flux réseaux intermachines… mais au prix d’un développement des dashboard assez complexe !
• Winlogbeat, la même chose que Filebeat, mais sous Windows
• Heartbeat, pour l’uptime (à quoi ça sert un module rien que pour ça et qui plus est pour l’afficher dans ELK… mystère?)

Vous trouverez plus d’informations sur le site officiel.

Collecte de données dans des fichiers plats avec Filebeat

Pour faire un exemple simple, on va commencer par utiliser Filebeat, le module dédié à la collecte de logs (documentation).

Filebeat (et les autres modules Beats) utilise des fichiers YAML pour savoir quoi faire. Là encore, je vous met à disposition mon playbook Ansible permettant d’installer simplement.

[A NOTER] Toute la configuration qui va suivre va être générée par le playbook ansible. Vous n’avez « rien » à faire mais je vous explique quand même ce que je fais histoire que vous puissiez reproduire vous même dans d’autre contexte. Le fameux poisson à pêcher proverbial, en somme.

mkdir -p /etc/ansible/roles && cd /etc/ansible/roles
git clone https://github.com/zwindler/ansible-deploy-filebeat-nginx

cd /etc/ansible
cat deploy_filebeat_for_nginx.yml
---
- name: Install filebeat for nginx
  hosts: @ip_ou_hostname_du_serveur_nginx
  vars:
    - elk_server: @ip_de_votre_serveur_elk
  roles:
    - { role: ansible-deploy-filebeat-nginx }

ansible-playbook deploy_filebeat_for_nginx.yml

Le principe du playbook est de :

• déployer sur un serveur avec nginx un collecteur filebeat
• qui va remonter les informations au logstash qu’on a installé sur notre serveur ELK
• qui sera lui même configuré pour traiter les données nginx
• et les réinjecter dans elasticsearch

Tout ça en un ligne de commande. Elle est pas belle la vie ?

Logstash en coupure…

Mais pourquoi s’embêter et passer par Logstash quand Filebeat envoie les logs et pas directement alimenter Elastisearch (sur la même machine) ?
C’est effectivement possible mais je préfère ne pas le faire pour plusieurs raisons.

D’abord, l’empreinte mémoire est bien moins importante. Là où Logstash consomme par défaut entre 512 et 1024 Mo, Filebeat ne consomme que quelques dizaines de Mo, 100 grand maximum. Un réel gain sur une infrastructure, quelle soit petite ou grande (chez moi, chaque Go compte !).

Ensuite, pour des raisons de sécurité, je n’ai autorisé que les connexions provenant de localhost sur Elasticsearch. Ainsi, seul Logstash (situé sur la même machine pourra y accéder), ce qui simplifie les autorisations au niveau du firewall et les flux de connexion. Les mauvaises langues diront « oui mais là tout le monde se connecte à Logstash, qui est sur la même machine, c’est pareil ».

Certes. Mais rien ne vous oblige à tout héberger sur la même machine et vous pouvez sécuriser vous même un peu mieux la plateforme. Toujours est-il que seul mon unique logstash peut alimenter la base et c’est quand même mieux, conceptuellement parlant.

Et enfin, Logstash dispose de plusieurs fonctionnalités pour trier et traiter les logs AVANT de les envoyer dans Elasticsearch, option que vous n’aurez pas si vous envoyez directement vos logs (ou toute autre information) directement depuis Beat vers Elasticsearch.

Configuration de Filebeat

Côté Beats, le template de configuration au format YAML est assez simple :
Ici, on donne 2 fichiers à manger, qu’on type tous les deux comme des « log » (purement informatif), puis un hôte et un port pour le Logstash de destination.

cat /etc/filebeat/filebeat.yml
filebeat.prospectors:
- type: log
  paths:
    -  /var/log/nginx/access.log
  document_type: nginx-access

- type: log
  paths:
   -  /var/log/nginx/error.log
  document_type: nginx-error

output.logstash:
  hosts: mon_serveur_elk:5044

Configuration côté nginx

Je ne vais pas insister longuement là dessus, mais j’utilise une modification de l’output du logs pour disposer d’une information supplémentaire pas indiquée par défaut : l’hôte dont provient la requête.

En effet lorsque vous avez un serveur nginx, il ne vous indique pas dans le log l’URL exacte d’où vient la requête. Si comme moi, vous avez plusieurs « Virtual Hosts », pointant vers plusieurs serveurs, c’est très pratique pour débuguer en cas de mauvaises redirections.

Rien ne vous oblige à utiliser « mon » log_format, mais il faudra bien entendu modifier ce qui va suivre dans ce cas là…

cat /etc/nginx/conf.d/default_main_log_format.conf
#add host in default logging format
log_format main '$remote_addr - $remote_user [$time_local] "$host" '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';
#                   '$request_time';
access_log /var/log/nginx/access.log  main;

Configuration de logstash

Nécessairement, puisque je passe par Logstash, je suis obligé de configurer Logstash (logique). C’est un mal pour un bien puisque ça me permet de traiter les lignes des fichiers de logs avant qu’ils soient intégrés dans Elasticsearch, comme je l’ai déjà dit.

Du coup le fichier de configuration côté Logstash est forcément plus complexe.

input {
    beats {
        port => "5044"
    }
}

filter {
#/var/log/nginx/access.log
  if [type] == "nginx-access" {
    grok {
      match => {
        "message" => '%{IPORHOST:remote_ip} - %{DATA:user_name} \[%{HTTPDATE:time}\] "%{DATA:target_host}" "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}" %{NUMBER:response} %{NUMBER:bytes} "%{DATA:referrer}" "%{DATA:agent}"'
      }
    }

    date {
      match => [ "time", "dd/MMM/YYYY:HH:mm:ss Z" ]
      locale => en
    }

    geoip {
      source => "remote_ip"
      target => "geoip"
    }

    useragent {
      source => "agent"
      target => "user_agent"
    }
  }

#/var/log/nginx/error.log
  if [type] == "nginx-error" {
    grok {
      match => {
        "message" => '(?<time>%{YEAR}[./]%{MONTHNUM}[./]%{MONTHDAY} %{TIME}) \[%{LOGLEVEL:severity}\] %{POSINT:pid}.%{NUMBER}: %{DATA:errormessage}, client: %{IP:remote_ip}, server: %{IPORHOST:server}, request: "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}", host: "%{DATA:target_host}"'
      }
    }

    geoip {
      source => "remote_ip"
      target => "geoip"
    }
  }

}

output {
    elasticsearch {
        hosts => [ "mon_serveur_elk:9200" ]
        index => "logstash-%{+YYYY.MM.dd}"
    }
}

Là on comprend qu’on va un peu plus en baver. Mais je vais y aller par étapes.

Le plus facile

On va commencer par le plus facile : les balises input et output. En théorie, elles sont même auto-siffisantes. Si on ne met que ça, Logstash fera simplement office de passe plat.

input {
    beats {
        port => "5044"
    }
}

[...]

output {
    elasticsearch {
        hosts => [ "mon_serveur_elk:9200" ]
        index => "logstash-%{+YYYY.MM.dd}"
    }
}

Pour faire clair, ici, on indique à Logstash de se mettre en écoute sur le 5044 pour des contenus provenant de beats, puis d’envoyer le résultat au serveur ELK dans l’index Logstash daté du jour. Trivial.

filter

Et là on arrive dans le vif du sujet. Si j’ouvre un log /var/log/nginx/access, voici ce que je pourrais y trouver :

1.1.1.1 - - [02/Oct/2017:03:44:27 +0200] "blog.zwindler.fr" "GET /2015/02/11/irl-redhat-virtualise-et-haute-dispo-rhcs-vmdk-partage-vs-vsphere-replication/ HTTP/1.1" 200 18219 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"

Mon but ici, clairement, c’est de trouver comment débiter mon log en morceaux.

Petite note moins anglophiles d’entre vous, log en anglais, ça veut dire journal mais aussi rondin (de bois). D’où le petit jeu de mot/analogie avec Logstash (un abris bois) où l’on stocke les rondins après les avoir tronçonnés. Ça explique aussi l’ancien logo :

access.log

Si vous avez bien suivi plus haut, nous avons récolté et différencié 2 logs via l’attribut « document_type » : access.log et error.log. Je ne vais en décrire qu’un car le principe est similaire.

filter {
#/var/log/nginx/access.log
  if [type] == "nginx-access" {
    grok {
      match => {
        "message" => '%{IPORHOST:remote_ip} - %{DATA:user_name} \[%{HTTPDATE:time}\] "%{DATA:target_host}" "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}" %{NUMBER:response} %{NUMBER:bytes} "%{DATA:referrer}" "%{DATA:agent}"'
      }
    }
[...]

Ici, une fois ma balise ouverte, je commence par ajouter une clause « if » qui va me permet de filtrer le log en fonction du document_type du log dont il s’agit.

Ensuite, je lui indique que je souhaite utiliser « grok », un module pour parser mes données brutes. Grok utilise ensuite la fonction match sur l’attribut « message » (ma ligne de log, rappelez vous) sur lequel je vais appliquer une sorte d’expression régulière qui va devoir matcher votre ligne de log à tous les coups !

Et quand on a dit ça, on a tout dit. Préparez vous à des tonnes de fun !

Alors bien entendu, si vous êtes chanceux, vous trouverez toujours une bonne âme qui partagera avec l’Internet le bon pattern qui correspond au bon output de votre log pour votre application. Mais sachez que des fois, il n’y a d’autres choix que de tester à la main… et c’est long !

La méthode bourrin pour vérifier que votre pattern est la suivante :

• modifier la configuration dans logstash
• redémarrer logstash
• attendre un peu pour que des logs soient générés et vérifier dans kibana que ça fonctionne correctement

grokparsefailure ==> dommage vous pouvez recommencer

Heureusement au fil de mes recherches, je suis tombé sur un outil qui vous aide à tester sans devoir dérouler ce fastidieux processus… Vous pouvez simuler sur cette page web vos pattern grok sur des bouts de logs.

Ça change la vie !

Le mot de la fin

Voilà, vous avez maintenant des logs qui remontent dans nginx et qui contiennent pléthore d’informations sur les requêtes entrantes et les utilisateurs. De quoi s’amuser pendant des heures pour créer des graphiques puis des dashboard.

Je ferai rapidement un prochain article sur la partie utilisation de Kibana car pour l’instant vous ne pouvez pas faire grand chose avec ça ;-).

J’ai également développé d’autres playbook pour déployer les autres modules Beats, je ferai également un article là dessus.

En attendant : have fun !

Pour aller plus loin

• https://www.digitalocean.com/community/tutorials/how-to-use-kibana-dashboards-and-visualizations
• https://github.com/elastic/examples/tree/master/ElasticStack_NGINX
• https://logz.io/blog/nginx-access-log-monitoring-dashboard/

Cet article ElasticStack : Collecter et exploiter des métriques provenant de nginx est apparu en premier sur Zwindler's Reflection.

Collecter, c’est bien ; visualiser, c’est mieux

Cet article fait partie d’une suite d’articles sur ElasticStack, un produit elastic.co, composé des produits ElasticSearch, Logstash, Kibana et depuis plus récemment des agents Beats.

Pour ceux qui auraient raté les articles précédents, j’explique plus en détail de quoi il s’agit dans 2 articles. Et bon DevOps que je suis, tout est bien entendu entièrement automatisé par des playbooks Ansible (et oui, vous n’avez rien à faire) :

• ElasticStack : Déployer Kibana, Elasticsearch, Logstash & Beats avec Ansible
• ElasticStack : Collecter et exploiter des métriques provenant de nginx

On en est où ?

Dans les deux articles précédents nous avons donc travaillé en amont d’ElasticSearch. Les données des serveurs ont été collectées, centralisées, traitées puis intégrées dans ElasticSearch. On sait faire des requêtes simples dessus via des curl.

C’est bien beau tout ça, mais on en fait quoi maintenant ? Et bien maintenant on va aller en aval et travailler avec Kibana !

Premiers pas avec Kibana

Normalement si tout s’est bien passé, on peut maintenant se connecter à Kibana, et Kibana peut communiquer avec ElasticSearch.

L’URL par défaut est http://MON_SERVEUR_ELK:5601

S’il y a un souci de connexion entre les deux logiciels qu’on vient de citer, vous aurez rapidement un message d’erreur plutôt explicite qui vous indiquera que ElasticSearch n’est pas joignable. Parfois c’est temporaire, par exemple lorsque vous démarrez ElasticSearch il arrive qu’il mette du temps à récupérer les index mais ça sera indiqué dans le message d’erreur.

Création des Index Patterns

La première page sur laquelle vous devriez tomber est une page de Management pour la création des Index Pattern. Il s’agit ni plus ni moins d’indiquer à Kibana quels sont les données (index) dans ElasticSearch nous intéressent (on peut en avoir plusieurs) et ensuite de lister les différentes colonnes pour chaque information contenue dans l’index en question.

Attention il s’agit là d’une notion importante : Plus les données présentes dans un même index seront différentes (différentes sources, différents champs), plus le nombre de champs dans votre « index pattern » sera important (logique).

Ça compliquera d’autant plus la création de nouveau graphique et l’exploitation de l’outil en général. Si vous voulez ajouter un nouveau graphique, il faudra filtrer potentiellement beaucoup de données pour n’extraire que celle qui vous intéresse et EN PLUS, de nombreux champs ne vous serviront à rien du tout et compliqueront la conception des visualisation.

Dans la mesure du possible, on s’astreindra donc à séparer en amont (lors de la configuration Logstash ou Beats) les données trop différentes dans des index distincts.

Si vous avez suivi les 2 premiers tutos, ça devrait fonctionner tout seul puisque les playbooks utilisent l’index par défaut, logstash-*. Sélectionnez @timestamp comme Time Filter puis cliquez simplement sur Create.

Discover

L’interface d’ELK est relativement simple une fois qu’on sait à quoi sert chaque menu. Maintenant que les index sont configurés, la conception des graphiques peut commencer, dans l’onglet Discover.

Cette vue est la plus importante pour la conception des graphiques puisque c’est là que vous pourrez explorer puis filtrer vos données, pour en tirer des indicateurs pertinents à surveiller.

Cette vue se découpe en plusieurs parties que je vais décrire ici :

• En jaune, l’index courant et l’ensemble des champs qu’il possède. Dans mon cas, j’en ai pratiquement 200 sur cet index, d’où la nécessité de ne pas trop en rajouter !
• En vert, un rapide graphique permettant de visualiser le nombre d’occurrences correspondant aux filtres et à la plage horaire sélectionnée. Très pratique pour avoir une idée du volume de données récoltées avec le filtre en cours.
• En bleu, un extract des données en elles même. On peut ainsi analyser ce qui tombe dans notre filtre, et ainsi concevoir les graphiques en fonction.
• En violet, la plage horaire sélectionnée (ici 7 jours en relatif, on peut aussi définir un intervalle fixe avec des dates/heures).
• En rouge, la grande force de l’outil => vous pouvez écrire à la main des requêtes pour filtrer en live vos données.
• En orange, les filtres en cours d’utilisation. Ici, j’ai cliqué sur la remote IP 80.74.x.x ce qui a eu pour effet d’immédiatement filtrer et restreindre à cette seule IP.

La barre de recherche s’utilise de la façon suivante : on entre les infos qu’on souhaite voir (ou ne pas voir avec « -« ) et hop, ça filtre !

Une fois qu’on est content de son filtre, on peut le sauvegarder grâce au menu Save en haut à droite. Il suffit de lui donner un nom explicite, puis de confirmer en cliquant sur le bouton Save Bleu.

Visualize

Le but du jeu avant de passer à cet étape est donc de créer un ensemble de requêtes plus ou moins complexes permettant de récupérer les données qui nous sont pertinentes.

L’onglet Visualize sert donc à créer des graphiques à partir de ses sources de données pertinentes (aka filtrées). Dans mon cas, je vais donc directement m’appuyer sur la recherche que je viens de sauvegarder pour ne récuperer que les données dont le type est égale à « nginx_access ».

A partir de là, le 2ème gros travail commencer. Ce n’est pas si simple de trouver les champs pertinents pour visualiser nos données de manières efficaces.

Comme j’ai un peu bossé pour vous dans l’article précédent, j’ai déjà ajouté dans la configuration logstash un champ qui n’est pas présent par défaut : à savoir geoip.ip.

Avec ce champ, je vais pouvoir me baser sur l’adresse IP pour déterminer plusieurs informations pour chacune des requêtes arrivant sur mon frontal nginx.

Je tire donc partie de ce champ pour réaliser un comptage de toutes les adresses IP distinctes pour l’axe des ordonnées.

Pour l’axe des abscisse, dans la majorité des cas, on se contentera du temps via le timestamp.

Cliquez sur le petit logo « Play » en haut pour visualiser le résultat :

Même principe que dans « Discover », on sauvegarde la visualisation en cliquant sur le menu Save en haut à droite, puis en validant avec le bouton Save bleu.

D’autre exemples de visualisations

En sélectionnant un graphique de type « Pie Chart », avec comme Aggregation « Count » et en séparant les tranches via le terme response.keyword, on peut faire un camembert des codes retours HTML.

En utilisant le module geoip, dont j’ai parlé plus haut, on peut créer une carte des visiteurs d’un site web :

Vous n’êtes donc maintenant (presque) limités que par votre imagination. Je dis « presque » parce qu’il n’est, à ma connaissance, pas facile voire impossible de réaliser des opérations mathématiques sur un graphique donné.

Un exemple : si je souhaite afficher la RAM consommée par un container Docker en Mo et non pas en octets (ce qui est illisible), a priori je ne peux pas le faire (à moins d’utiliser une obscure fonction permettant de dupliquer un index en lui appliquant une formule mathématique, bref, c’est compliqué).

Pour remédier à ça, elastic.co a sorti un outil appelé Timelion, intégré dans Kibana, mais ce n’est pas le sujet d’aujourd’hui ;-).

Dashboard

Le plus simple maintenant ! On peut créer des Dashboard dans l’onglet Dashboard, simplement en sélectionnant les graphiques précédemment créés puis en les réagençant avec des drags and drops. E-Z !

Voilà quelques uns des dashboards que j’ai créés pour les besoins de cet article pour vous donner une idée, mais on peut bien entendu faire bien plus complexe !

Have fun !

Cet article ElasticStack : Visualisez vos données dans Kibana est apparu en premier sur Zwindler's Reflection.

Pourquoi déployer XWiki sur Kubernetes ?

Vous le savez surement maintenant vu le nombre d’article que j’ai écrit sur le sujet, j’aime bien XWiki. C’est un super projet mené par des gens passionnés, réactifs et surtout, c’est cet outil qui a permis à mon entreprise d’adopter ENFIN le wiki comme outil de documentation, que ce soit pour documenter les procédures, mais aussi documenter entièrement les concepts de l’outil que nous développons.

D’un outil quasi-confidentiel utilisés par quelques admins peu motivés (sous Mediawiki), nous sommes donc progressivement passés à un outil utilisé par toutes les équipes, du dev. au support en passant par les ergo. et les CPs, utilisés par plusieurs entités internes et même accepté comme document contractuel par nos prestataires. J’ai d’ailleurs documenté la migration sur cet article.

Mais j’aime aussi XWiki car c’est selon moi l’exemple parfait d’une appli 2 ou 3 tiers relativement simple pour explorer l’écosystème Docker (construction des images, les problématiques réseau et stockage, …). Je joue régulièrement avec ma propre image sur le Dockerhub pour explorer un peu plus cet écosystème riche (c’est rien de le dire).

Quelle meilleure application donc pour réellement tester mon tout nouveau cluster Kubernetes (je ne compte pas nginx ou helloworld) ?

Kubernetes ?

Pour ceux qui ont besoin d’un rappel sur Kubernetes ou des premiers concepts et/ou comment l’installer, je vous invite à lire/relire mon article précédent sur le sujet.

A noter également (j’ai pas mal communiqué là-dessus sur les réseaux sociaux), la Linux Foundation, qui gère également la Cloud Native Computing Foundation (et qui elle-même gère Kubernetes), a mis à disposition gratuitement un cour en ligne de type MOOC sur edX. Vous pouvez même vous « certifier » à la fin si vous réussissez le QCM, moyennant 100$.

A l’issue de ces lectures, vous devriez donc avoir :

• la connaissance des différents concepts de Kubernetes
• un cluster Kubernetes opérationnel (une ou plusieurs machines, ou simplement un minikube en local)

Ce sont les prérequis pour la suite de cet article, même si je vais essayer de détailler tout ce qui va suivre.

Plan de bataille

Je ne vais pas vous le cacher, si on veut tout faire soit même, ce n’est pas « trivial ». Mais en décomposant toutes les étapes, vous allez voir que c’est logique.

Pour faire tourner mon image Docker zwindler/xwiki-tomcat8, j’ai besoin, sur mon cluster Kubernetes, des choses suivantes :

• un Deployment qui exécute la partie PostgreSQL. Ce Deployment contiendra :
  • un ReplicaSet avec une seule instance car on ne souhaite avoir qu’un seul Pod avec l’image postgresql officielle
  • Un Service de type ClusterIP pour lui permettre de communiquer avec le XWiki mais pas avec le monde extérieur
  • Un PersistantVolumeClaim et son PersistentVolume associé pour stocker les données de la base
  • Des Secrets pour permet de configurer les mots de passes de postgres et de l’utilisateur XWiki
• un Deployment qui exécute la partie XWiki. Ce Deployment contiendra :
  • un ReplicaSet avec une seule instance car on ne fait tourner qu’un seul Pod avec l’image zwindler/xwiki-tomcat8, car on n’utilise qu’un tomcat à la fois pour exécuter XWiki
  • Un Service de type NodePort (ou mieux si vous avez des LoadBalancers ou des Ingress à dispo.) qui permettra d’exposer le port interne au cluster Kubernetes vers le monde extérieur
  • Un PersistantVolumeClaim avec le PersistentVolume pour stocker les pièces jointes car mon image Docker utilise l’option filesystem_store pour éviter de surcharger la base pour les PJ
  • et aussi le Secret défini précédemment pour accéder à la BDD.

OK.

Voir ça posé dans une liste comme ça, ça peut faire peur.

Alors vous allez me dire : « c’est plus facile de lancer ton DockerCompose » (car j’ai montré qu’avec DockerCompose on peut démarrer une instance XWiki en 2 ou 3 lignes de commandes). Mais au final, tout ce que j’ai écris ici peut être concaténé dans un seul et même fichier YAML et le résultat est aussi simple dans l’absolu.

Créer les Secrets

Clairement, c’est un des gros points forts par rapport à la solution plus simple avec juste Docker / DockerCompose : la gestion des Secrets (et des configurations, dans une moindre mesure).

Ici, plutôt que d’avoir un mot de passe en clair dans mon fichier compose, le mot de passe est renseigné à part, soit via un fichier, soit via l’API. Et ces mots de passes ne pourront plus être consultés via la CLI, mais pourront être utilisés.

Pour créer un secret dans Kubernetes en CLI, il existe plusieurs méthodes. Soit on utilise la CLI directement depuis le prompt ou depuis un fichier plat (qui va se charger d’encoder le secret en base64 et de générer le YAML pour nous), soit on décide de créer le YAML nous-même. Je vous met les deux méthodes :

echo -n "xwikidb" > ./POSTGRES_USER.txt
echo -n "xwikipwd" > ./POSTGRES_PASSWORD.txt
kubectl create secret generic postgresql-xwiki-user-password --from-file=POSTGRES_USER.txt --from-file=POSTGRES_PASSWORD.txt
	secret "postgresql-xwiki-user-password" created

#ou
cat > postgresql_xwiki_user_password.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
  name: postgresql-xwiki-user-password
type: Opaque
data:
  username: $(cat POSTGRES_USER.txt| base64 -w 0)
  password: $(cat POSTGRES_PASSWORD.txt| base64 -w 0)
EOF

Au final, pour un déploiement unitaire pour vous même, ça ne change pas grand-chose bien sûr. Vous avez renseigné en clair le mot de passe (ou en base64 mais c’est pareil) à un moment donné.

Cependant, dans le cadre d’un gros projet avec des développeurs qui poussent du code régulièrement d’un côté et des admins qui gèrent de l’autre les utilisateurs et les mots de passes, on peut permettre aux développeurs consommer les mots de passe sans jamais avoir à les connaitre (et laisser trainer sur Gitlab, ou pire, Github !).

kubectl describe secret postgresql-xwiki-user-password
	Name:           postgresql-xwiki-user-password
	Namespace:      default
	Labels:         <none>
	Annotations:
	Type:           Opaque

	Data
	====
	password:       8 bytes
	username:       7 bytes

Créer les Persistent Volumes

Dans mon infrastructure, j’ai déjà un cluster GlusterFS. GlusterFS étant un SDS, il est particulièrement indiqué comme stockage persistant dans le cadre d’un cluster Kubernetes (comme Ceph, Cinder, S3 ou autre). Ces types de méthodes de stockage peuvent facilement se piloter par API et sont hautement disponibles.

Création de l’endpoint GlusterFS

cat > gluster-endpoints.yaml <<EOF
apiVersion: v1
kind: Endpoints
metadata:
  name: gluster-cluster
subsets:
- addresses:
  - ip: 10.0.0.1
  ports:
  - port: 1
    protocol: TCP
- addresses:
  - ip: 10.0.0.2
  ports:
  - port: 1
protocol: TCP
EOF

kubectl apply -f gluster-endpoints.yaml
   endpoints "gluster-cluster" created

kubectl get endpoints gluster-cluster
	NAME		ENDPOINTS		AGE
	gluster-cluster 10.0.0.1:1,10.0.0.2:1	39s


cat > gluster-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: gluster-cluster
spec:
  ports:
- port: 1
EOF

kubectl apply -f gluster-service.yaml
	service "gluster-cluster" created

kubectl get service gluster-cluster
	NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
	gluster-cluster   10.96.114.181   <none>        1/TCP     1m

La partie GlusterFS a été configurée côté Kubernetes. On peut maintenant s’atteler à la création des PV et PVC associés. D’abord la base de données :

cat > gluster-pv-xwiki-pg.yaml << EOF

apiVersion: v1
kind: PersistentVolume
metadata:
  name: gluster-pv-xwiki-pg
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteMany
  glusterfs:
    endpoints: gluster-cluster
    path: /xwiki-pg-storage
    readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF

kubectl create -f gluster-pv-xwiki-pg.yaml
persistentvolume "gluster-pv-xwiki-pg" created

cat > gluster-pvc-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-pvc-xwiki-pg
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
EOF

kubectl create -f gluster-pvc-xwiki-pg.yaml
	persistentvolumeclaim "gluster-pvc-xwiki-pg" created

Et maintenant l’application XWiki

cat > gluster-pv-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: gluster-pv-xwiki-app
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteMany
  glusterfs:
    endpoints: gluster-cluster
    path: /xwiki-app-storage
    readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF

kubectl create -f gluster-pv-xwiki-app.yaml
 persistentvolume "gluster-pv-xwiki-app" created

cat > gluster-pvc-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-pvc-xwiki-app
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
storage: 5Gi
EOF

kubectl create -f gluster-pvc-xwiki-app.yaml
	persistentvolumeclaim "gluster-pvc-xwiki-app" created

Dans le cadre d’un test, vous pouvez vous contenter de faire simplement appel à un partage NFS ou même à du stockage local (si vous n’avez qu’un worker) mais sachez que vous n’aurez pas le même niveau de résilience ni les même facilités d’administration.

Si vous voulez un exemple de PersistentVolume utilisant NFS, je vous conseille cet article qui traite d’un sujet peu plus complexe mais qui donne les étapes de base pour mettre en place le PV et PVC : Créer un cluster PostgreSQL avec un seul et même Deployment en utilisant les StatefulSets.

Créer le Deployment postgreSQL

Voilà, on a tous les prérequis ! Il ne reste plus qu’à créer dans un premier temps notre base de données, puis notre XWiki. Comme indiqué au début, le Deployment contiendra tous les éléments qu’on a créé plus tôt, dont les Secrets et le Persistent Volume. Il manquera aussi un Service, que nous verrons plus tard.

cat > xwiki-pg.yaml << EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: xwiki-pg
  labels:
    app: xwiki-pg
    application: xwiki
spec:
  replicas: 1
  selector:
    matchLabels:
      app: xwiki-pg
      application: xwiki
  template:
    metadata:
      labels:
        app: xwiki-pg
        application: xwiki
      name: xwiki-pg
    spec:
      containers:
      - image: postgres:9.6
        name: xwiki-pg
        env:
        - name: POSTGRES_DB
          value: xwiki
        - name: PGDATA
          value: /var/lib/postgresql/data/pgdata
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgresql-xwiki-user-password
              key: username
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgresql-xwiki-user-password
              key: password
        ports:
            - containerPort: 5432
              name: xwiki-pg
        volumeMounts:
            - name: xwiki-pg-storage
              mountPath: /var/lib/postgresql/data/pgdata
      volumes:
          - name: xwiki-pg-storage
            persistentVolumeClaim:
              claimName: gluster-pvc-xwiki-pg
EOF

kubectl create -f xwiki-pg.yaml

Normalement, un Pod devrait se créer et monter le disque Gluster, puis s’initialiser avec les variables d’environnement qu’on lui a donné.

A partir de là, on ne peut cependant pas accéder à la base de données car on a pas encore créé le Service associé au Deployment. Par défaut, on ne donne pas de type, c’est donc un ClusterIP. Pour « savoir » vers quoi le Service doit rediriger, on a ajouté un Selector, qui pointe sur le tag « app » avec la valeur « xwiki-pg » définie plus haut.

cat > xwiki-pg-svc.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: xwiki-pg-svc
  labels:
    app: xwiki-pg
spec:
  ports:
  - port: 5432
    protocol: TCP
  selector:
    app: xwiki-pg
EOF

kubectl create -f xwiki-pg-svc.yaml
	service "xwiki-pg-svc" created

Créer le Deployment XWiki

Youhou ! Plus qu’un ! Ici pas de grosses différences, le principe est le même. On doit créer un Deployment puis un Service.

cat xwiki-tomcat.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: xwiki-app
  labels:
    app: xwiki-app
    application: xwiki
spec:
  replicas: 1
  selector:
    matchLabels:
      app: xwiki-app
      application: xwiki
  template:
    metadata:
      labels:
        app: xwiki-app
        application: xwiki
      name: xwiki-app
    spec:
      containers:
      - image: zwindler/xwiki-tomcat8
        name: xwiki-app
        env:
        - name: POSTGRES_INSTANCE
          value: xwiki-pg
        - name: POSTGRES_DB
          value: xwiki
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgresql-xwiki-user-password
              key: username
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgresql-xwiki-user-password
              key: password
        ports:
          - containerPort: 8080
            name: tomcat-port
        volumeMounts:
            - name: xwiki-app-storage
              mountPath: /usr/local/tomcat/work/xwiki
      volumes:
          - name: xwiki-app-storage
            persistentVolumeClaim:
              claimName: gluster-pvc-xwiki-app

kubectl apply -f xwiki-tomcat.yaml
	deployment "xwiki-app" created

cat xwiki-tomcat-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: xwiki-app-svc
  labels:
    apps: xwiki-app
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: tomcat-port
    protocol: TCP
  selector:
    app: xwiki-app


kubectl apply -f xwiki-tomcat-svc.yaml
service "xwiki-app-svc" created

Est-ce que ça marche ?

kubectl get svc
NAME              CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
gluster-cluster   10.96.114.181    <none>        1/TCP            4h
kubernetes        10.96.0.1        <none>        443/TCP          10d
xwiki-app-svc     10.103.218.140   <nodes>       8080:31484/TCP   4m
xwiki-pg-svc      10.108.219.88    <none>        5432/TCP         16m

Tout d’un coup

Chose promise chose due ! Je vous ai dit en début d’article que vous pouviez tout déployer en quelques lignes de commandes. Dans l’absolu, vous pourriez tout déployer via un seul fichier. Je préfère découpler la partie stockage (qui va dépendre du stockage que vous allez utiliser) et la partie secret du reste pour les raisons que j’ai énoncé plus haut. Voilà ce que ça donne :

On récupère les sources sur github

git clone https://github.com/zwindler/docker-xwiki

A adapter en fonction de votre contexte, à minima les adresses IP si vous avez du gluster, et carrément à réécrire si vous utilisez autre chose (NFS ou CEPH par exemple) :

kubectl apply -f docker-xwiki/kubernetes/gluster-endpoints-service.yaml
endpoints "gluster-cluster" created
service "gluster-cluster" created

On injecte ensuite les secrets. A vous de les changer comme on a vu plus haut.

kubectl apply -f docker-xwiki/kubernetes/postgresql_xwiki_user_password.yaml
secret "postgresql-xwiki-user-password" created

Et on fini par… tout le reste ! Là normalement il n’y a rien à changer à part éventuellement des ports, les seules « variables » dans ce déploiement étant le stockage et les mots de passes (qu’on vient de gérer).

kubectl apply -f docker-xwiki/kubernetes/xwiki-tomcat-pg-allinone.yaml
persistentvolume "gluster-pv-xwiki-pg" created
persistentvolume "gluster-pv-xwiki-app" created
deployment "xwiki-pg" created
persistentvolumeclaim "gluster-pvc-xwiki-pg" created
service "xwiki-pg-svc" created
deployment "xwiki-app" created
persistentvolumeclaim "gluster-pvc-xwiki-app" created
service "xwiki-app-svc" created

Le mot de la fin

Voilà, avec ce tutoriel vous avez maintenant une vue détaillée, étape par étape, de ce qu’il faut mettre en place pour gérer « proprement » le déploiement d’une application java + postgreSQL via Kubernetes.

Clairement, c’est bien plus complexe qu’un simple Docker compose comme j’ai pu le présenté dans l’article sur ce sujet. Pour autant, il faut comparer ce qui est comparable, les deux installations n’ont rien à voir !

D’un côté, vous avez une application déployée sur un nœud docker simple (éventuellement avec Swarm maintenant que les deux sont compatibles).

De l’autre, vous avez une application qui est déployée sur un cluster de machines :
– Si l’une tombe en panne, la haute disponibilité est gérée : pas seulement sur le runtime, mais aussi sur le stockage !
– Vous pouvez segmenter votre cluster en namespaces, et donner des droits à certains namespace à certains utilisateurs avec un gestion fine des autorisations (RBAC)
– Vous disposez d’un dashboard et d’une API pour automatiser tous les déploiements (via Jenkins par exemple). Si vous voulez faire une mise à jour ou besoin de modifier un paramètre, c’est une simple commande ou un fichier de conf à appliquer à nouveau.
– Vous avez la possibilité de faire du scaling up/down, voire de l’autoscaling.
– …

La liste est longue ! En bref, vous passez d’une bidouille à la production.

Sources additionnelles

• https://docs.openshift.org/latest/install_config/storage_examples/gluster_example.html
• https://coderjourney.com/using-kubernetes-persistent-volumes/
• https://www.xenonstack.com/blog/how-to-deploy-postgresql-on-kubernetes

Cet article [Tutoriel] XWiki, ma premier appli Stateful sur Kubernetes est apparu en premier sur Zwindler's Reflection.

Forfait jour Syntec, explication et jurisprudences

Petit aparté : j’ouvre une nouvelle catégorie sur le blog : le Droit. Si vous suivez un peu mon blog, vous avez peut-être déjà lu quelques articles sur le droit, en particulier celui du travail.

POINT IMPORTANT : Cet article ne s’applique qu’à la convention collective Syntec. Les autres conventions ayant mis en place des forfaits jours reposent sur d’autres règles qui n’ont strictement rien à voir.

J’ai rencontré, par le biais de mes connaissances, le cas du « forfait jour » à plusieurs reprises dans le cadre d’entreprises en convention collective Syntec. Le cadre autonome au forfait jour semble être la solution à tous les problèmes des entreprises. Pas d’heures supplémentaires à payer, le cadre s’organise comme il l’entend, etc.

Mais de quoi s’agit-il réellement ?

Personnellement, j’ai trouvé cette notion de cadre autonome très floue et j’ai voulu en savoir plus, notamment ce que cela implique et dans quel cas ces contrats sont valides ou invalides selon la Syntec et les jurisprudences en cours.

Définition Syntec

Ce n’est pas simple de s’y retrouver pour les néophytes tant la convention collective Syntec est décousue. Il y a tous les articles d’un côté, puis les annexes… Un vrai bazar !

La Syntec, très couramment appliquée dans les sociétés du numérique, propose 3 types de contrats de travail (voir l’annexe 7), appelées modalités :

• La modalité standard (1), qui est en fait une application classique des 35 heures.
• La modalité dite de « réalisation de missions » (2), qui est assez souvent appliquée pour les ingénieurs en SSII/ESN car plus souple que les 35 heures. Il s’agit d’une adaptation des 35 heures dans lesquelles un contingent d’heures supplémentaires non rémunérées est inclus, à hauteur de 10% par semaine, contre une revalorisation des minima de 15% supérieure ET un salaire mensuel au moins égal au PMSS.
• La modalité dite de « réalisation de missions avec autonomie complète » (3), qui est le vrai forfait en jour pour les cadres dirigeants.

A noter : la modalité 2 est parfois confondue par les salariés avec le « forfait jour » car elle fait mention d’un « nombre de jours maximum travaillés dans l’année ». Pour autant, il s’agit bien d’un forfait en heures et donc potentiellement générateur d’heures supplémentaires. Certaines entreprises que j’ai pu rencontrer laissent planer le flou…

« En bonne intelligence »

Vous trouverez également une notice assez bien faite sur les 2 types de forfaits qui existent (heures et jours) sur le site de travail-emploi.gouv.fr (et plus digeste que Legifrance !).

Conditions pour bénéficier de la modalité 3

OK, nous connaissons maintenant les 3 types de contrats existants. Maintenant, ça se complique.

Il pourrait être tentant au premier abord de mettre tous les cadres au forfait jours sans se poser de questions. En 2015, le Monde indiquait que près de 1,5 millions de cadres étaient concernés !

La Syntec a cependant instauré un certain nombre de conditions et d’obligations pour l’employeur, en plus de ce que dit le code du Travail.

Ce qu’en dit le code du travail

Pour les cadres mentionnés à l’article L. 3121-38, la convention ou l’accord collectif de travail qui prévoit la conclusion de conventions de forfait en jours fixe le nombre de jours travaillés. Ce nombre ne peut dépasser le plafond de deux cent dix-huit jours.

Cette convention ou cet accord prévoit :

• Les catégories de cadres intéressés au regard de leur autonomie dans l’organisation de leur emploi du temps ;
• Les modalités de décompte des journées et des demi-journées travaillées et de prise des journées ou demi-journées de repos ;
• Les conditions de contrôle de son application ;
• Des modalités de suivi de l’organisation du travail des salariés concernés, de l’amplitude de leurs journées d’activité et de la charge de travail qui en résulte.

Vous pouvez retrouver le texte complet sur Legifrance.

Les forfaits en jours sont donc limités au maximum à 217 jours par an (+1 avec le jour de solidarité donc 218). Ils peuvent néanmoins être diminués par accord ou convention collective.

Ce qu’en dit la Syntec

Au-delà du seul code du travail, la Syntec est venu ajouter des conditions supplémentaires pour restreindre l’usage de la modalité 3 :

Pour pouvoir relever de ces modalités, les collaborateurs concernés doivent obligatoirement disposer de la plus large autonomie d’initiative […]
Ils doivent donc

• disposer d’une grande latitude dans leur organisation du travail et la gestion de leur temps
• et doivent également bénéficier
  • de la position 3 de la convention collective (en général les positions 3.2 et 3.3 et dans certains cas 3.1)
  • ou avoir une rémunération annuelle supérieure à 2 fois le plafond annuel de la sécurité sociale
  • ou être mandataire social

En plus des 3 règles énoncées ci dessus en terme de rémunération, les minima sont également majorés à 120 % pour les cadres en modalité 3.

En clair, quelles sont les conditions ?

Il y a donc plusieurs façons de vérifier si un salarié est éligible ou non au forfait jour dans un entreprise Syntec.

Classification

D’abord, le plus rapide à vérifier : la classification. La Syntec est claire sur les règles d’éligibilité, il faut être cadre 3.1 au minimum (ou bénéficier d’une rémunération égale à 2 fois le PMSS mais on en parlera plus tard). Force est de constater aujourd’hui que dans mon entourage, un certain nombre d’entreprises utilisent le forfait jour en dehors de cette disposition Syntec.

Point important à prendre en compte quand on parle de la classification : elle obéit à des critères objectifs de diplômes, d’âge, d’expérience et de responsabilité. N’est pas cadre 3.1 qui veut ! Tout est décrit dans l’annexe 2 de la Syntec, qui détaille également les appointements minimaux.

Des salariés au forfait jour en ont fait l’expérience aux prud’hommes. En modalité 3 Syntec, ces salariés demandaient un rappel de salaire équivalent à celui d’un cadre 3.X alors que leurs contrats stipulaient qu’ils appartenaient aux positions 2.X.

Contrairement à cette lecture, les magistrats ont estimés qu’il n’y avait pas lieu de rattraper les salaires de ces employés car ils ne répondaient pas aux critères permettant d’accéder à la position 3.1. Ils n’étaient donc pas éligibles au forfait jours (et donc au rappel de salaire consécutif), qui a été annulé.

« qu’en statuant ainsi, alors qu’elle avait constaté que le salarié qui avait moins de six ans de pratique en qualité de cadre, ne pouvait être classé à la position 3.1, ce dont il se déduisait qu’il n’était pas susceptible de relever du régime du forfait jours qui lui avait été appliqué, la cour d’appel, qui n’a pas tiré les conséquences légales de ses constatations, a violé les textes susvisés. » (Cass. Soc.3 novembre 2011, n°10-14638 et 10-14637).

« La cour d’appel, qui a constaté que le salarié ne rapportait pas la preuve de ce qu’il occupait réellement des fonctions correspondant à la position 3.1, a exactement décidé que le bénéfice d’une rémunération supérieure au double du plafond annuel de la sécurité sociale ou le classement à la position 3 de la classification des cadres constituent des critères possibles permettant de ranger un cadre parmi ceux définis à l’article 4 de l’accord du 22 juin 1999 en vue de lui appliquer un régime forfaitaire de durée du travail mais ne sauraient être interprétés comme une obligation d’assurer une telle rémunération ou une telle classification à un cadre n’entrant pas dans le champ d’application de cet article. »
Cass. Soc.3 novembre 2011, n°10-20191

Rémunération

Maintenant qu’on a bien en tête mes problématiques de classification, on peut s’intéresser aux minima. Depuis cet été, les minima (qui n’avaient pas été réévalués depuis 2014) ont été augmentés :

Pour information, le PMSS 2017 se situe à 3269 €. Multiplié par 2 et ramené à l’année cela correspond à une rémunération de 78456 € bruts annuels. Cette somme très importante n’a aucun rapport avec les salaires d’ingénieurs sortis d’école qui bénéficient pourtant parfois de forfaits en jours via la Syntec…

Pour autant, une fois encore, la jurisprudence tend plutôt à annuler le forfait jours plutôt qu’accorder des rappels de salaires…

S’affranchir du PMSS

Certains employeurs proposent, par le biais d’un accord collectif d’entreprise signé par les syndicats, de modifier ces deux conditions d’entrée en modalité 3.

Je suis sceptique face à ce genre d’accords : jusqu’aux très récentes ordonnances dites Travail/Macron de cette année, il ne me semble pas qu’il était possible de déroger aux minima imposés par un accord de branche avec un accord d’entreprise. A vérifier, c’est peut être une erreur d’interprétation de ma part…

Article L2253-3 sur Légifrance

« En matière de salaires minima, […] un accord d’entreprise ou d’établissement ne peut comporter des clauses dérogeant à celles des conventions de branche […] »

Quoiqu’il en soit, ce point de doute sera bientôt de l’histoire ancienne puisque les ordonnances ont chamboulé tout ça :

Conformément au IV de l’article 16 de l’ordonnance n° 2017-1385 du 22 septembre 2017, pour l’application du présent article, les clauses des accords de branche, quelle que soit leur date de conclusion, cessent de produire leurs effets vis-à-vis des accords d’entreprise à compter du 1er janvier 2018.

Autonomie

Le dernier critère, pas seulement applicable à la Syntec, mais aussi dans le code du travail, est l’autonomie.

On l’a vu au début de l’article, ce point est capital et les deux textes insistent lourdement là dessus.

1) Les cadres qui disposent d’une autonomie dans l’organisation de leur emploi du temps et dont la nature des fonctions ne les conduit pas à suivre l’horaire collectif applicable au sein de l’atelier, du service ou de l’équipe auquel ils sont intégrés ;

2) Les salariés dont la durée du temps de travail ne peut être prédéterminée et qui disposent d’une réelle autonomie dans l’organisation de leur emploi du temps pour l’exercice des responsabilités qui leur sont confiées.

Article L3121-43 du Code du travail

Cependant c’est aussi le plus subjectif ou soumis à interprétation, car il n’existe pas de définition légale de ce qu’est l’autonomie. Deux questions me viennent à l’esprit :

• Est ce qu’un ingénieur, piloté par un chef de projet, mais qui a toute latitude pour exécuter les tâches qu’on lui donne et dans l’ordre qu’il le souhaite, est considéré autonome ?
• Est ce qu’un salarié dont les congés sont déterminés ou annulés par son supérieur peut être au forfait jour ?

Quelques avis sur la question, notamment sur l’organisation des jours de travail et de repos :

La prise des jours RTT est généralement définie par l’accord d’entreprise. Il définit aussi la période de référence qui est souvent l’année civile. Généralement ces jours de RTT sont acquis par avance (anticipation) mais leur prise reste soumise à l’accord préalable du chef d’entreprise, comme pour les congés payés.

CGT UGICT

[…] la cour d’appel avait constaté que l’emploi du temps du salarié était déterminé par la direction et le supérieur hiérarchique de l’intéressé, lesquels définissaient le planning de ses interventions auprès des clients, et que le salarié ne disposait pas du libre choix de ses repos hebdomadaires, ce dont il se déduisait que, ne bénéficiant d’aucune liberté dans l’organisation de son travail, le salarié n’était pas susceptible de relever du régime de forfait en jours

Cour de cassation, civile, Chambre sociale, 31 octobre 2007, 06-43.876

Modalités supplémentaires

A noter, il existe également plusieurs obligations faites à l’employeur :

• Le passage au forfait jour doit faire l’objet d’un avenant au contrat du cadre, qui par définition peut le refuser
• Le cadre doit bénéficier de plusieurs entretiens annuels, notamment pour valider que sa charge de travail n’est pas importante, que les repos quotidiens et le repos hebdomadaires sont bien respectés, etc. La fréquence de ces entretiens est bi-annuelle depuis 2014

Conséquences d’une hypothétique annulation du forfait en jours

Je l’ai déjà dit, on voit bien avec les arrêts des cours tendent plutôt à annuler les forfaits jours plutôt qu’accorder des rappels de salaires.

Pour autant, cela peut quand même avoir des conséquences pour l’employeur. En effet, une fois son forfait annulé, le salarié repasse dans les 35 heures (modalité 1 ou 2 selon ce qui se fait dans l’entreprise). Il peut donc demander un rappel de toutes les heures supplémentaires qu’il a effectué dans une limite de 3 ans.

On pourrait penser qu’elles ne peuvent pas être réclamées. Le cadre, précédemment réputé au forfait jour, ne peut pas justifier des heures supplémentaires qu’il aurait pu réalisé, puisqu’il n’est pas soumis au contrôle horaire.

Cependant, il s’avère que la jurisprudence ne demande pas aux salariés de fournir une preuve complexe. Par exemple, dans le cas d’une veilleuse de nuit qui réclamait des heures supplémentaires non payées suite à un licenciement, un simple décompte des heures supplémentaires réalisées noté sur un papier a été considéré comme suffisant !

En cas de litige relatif à l’existence ou au nombre d’heures de travail accomplies, il appartient au salarié d’étayer sa demande par la production de tous éléments suffisamment précis pour permettre à l’employeur de répondre en apportant, le cas échéant, la preuve contraire.

Dès lors doit être cassé l’arrêt qui pour rejeter une demande en paiement d’heures complémentaires retient que le salarié ne produit pas d’éléments de nature à étayer sa demande lorsqu’il verse aux débats un décompte établi au crayon, calculé mois par mois, sans autre explication ni indication complémentaire, alors que ce document permettait à l’employeur d’y répondre.

Charge à l’employeur d’apporter la preuve que l’employé n’a pas réalisé les heures supplémentaires qu’il prétend avoir faites. Et sans contrôle horaire, ça me parait compliqué à prouver.

Sources :

• La convention collective Syntec
• Conventions de forfait en jour sur Legifrance

Bonus : un peu d’histoire

En 2011, c’est la panique !

L’examen de la validité du forfait jour dans le cadre de la convention collective métallurgie donne lieu à une jurisprudence qui est venu gripper les autres conventions collectives proposant cette disposition :

[…] toute convention de forfait en jours doit être prévue par un accord collectif dont les stipulations assurent la garantie du respect des durées maximales de travail ainsi que des repos, journaliers et hebdomadaires ;

Si Métallurgie n’est elle pas épinglée car ayant mis en place des dispositifs jugés suffisants, de nombreuses conventions ne sont elles pas conformes et ne garantissent pas ce respect.

C’est notamment le cas de la Syntec : comme toutes les conventions collectives qui ne prévoyaient pas de suivi des employés pour garantir que la charge de travail n’est pas trop importante, tous les contrats au forfait jours risquaient de se voir annulés :

« […] ni les dispositions [de la Syntec] ni les stipulations [des accords d’entreprise], ne sont de nature à garantir que l’amplitude et la charge de travail restent raisonnables et assurent une bonne répartition, dans le temps, du travail de l’intéressé, et, donc, à assurer la protection de la sécurité et de la santé du salarié, ce dont elle aurait dû déduire que la convention de forfait en jours était nulle »
Cour de cassation, civile, Chambre sociale, 24 avril 2013, 11-28.398

En catastrophe, le 1er avril 2014, un accord a été conclu pour ajouter des mesures manquantes et ainsi garantir la viabilité du dispositif de forfait en jours dans la Syntec.

Cet article Convention Syntec : le cadre autonome au forfait jour est apparu en premier sur Zwindler's Reflection.

Customiser un ISO d’ESXi, mais pourquoi faire ???

Vous avez été plusieurs à réagir suite à mon post sur LinkedIn, du coup j’ai décidé de faire un petit article rapide pour en parler. Brièvement, j’avais posté une photo de deux Dell Optiplex sur lesquels j’avais installé ESXi.

Tout ça dans le but d’organiser une petite formation VMware improvisée pour des collègues, et sans investir quoique ce soit bien sûr ! Mon idée était de leur faire installer un hyperviseur from scratch, de créer un cluster avec un vCenter et de tester les fonctionnalités de base de la suite VMware.

Le point important à savoir lorsqu’on installe des serveurs ESXi est qu’il s’agit d’un Linux minimaliste, avec seulement une liste très restreinte de pilotes autorisés par VMware. Ce « problème » que tous les DIYer ont rencontrés existe depuis longtemps. Comme je l’explique dans le post LinkedIn, les bidouilleurs trouvent des moyens de contournement depuis au moins ESX 3/ESXi 4. Personnellement, je bidouille depuis 2010, moment où je me suis monté ma première Whitebox ;-).

Le Matoss

En informatique, à défaut de moyens, il faut avoir des idées !

Voilà comment j’ai introduis mon post sur LinkedIn et il représente assez bien ce qu’on va faire ici. A défaut de pouvoir acquérir ou même louer deux serveurs pour les quelques jours de formation, je me suis rabattu sur des desktops qui trainaient au stock.

Les modèles concernés sont :

• Un Optiplex 390 avec un core i5 2400, 16 Go de RAM (barettes piquées sur d’autres PCs)
• Un Optiplex 3020 avec un core i3 4150 avec 8 Go de RAM (barettes piquées elles aussi)

Dans mon tiroir, j’avais aussi en réserve une carte PCI Express Intel, juste au cas où (une carte perso, je vous expliquerai pourquoi après).

L’installation échoue !

Au cas où vous ne sauriez pas où le trouver, l’ISO de l’hyperviseur de VMware peut se télécharger gratuitement sur le site MyVMware. Il suffit de créer un compte sur le site puis télécharger la version souhaitée de l’hyperviseur (la dernière par exemple, « VMware vSphere Hypervisor (ESXi) 6.5 u1 » au moment de la rédaction de l’article). Il est même possible d’obtenir une licence gratuite, qui sera limitée et n’offrira pas le droit à du support, mais tout de même !

Si vous utilisez un PC et pas un serveur pour installer l’ISO que vous aurez téléchargé, il y a de très fortes chances pour que l’installation échoue au tout début du processus d’installation. En effet, l’installeur vérifie la présence d’une carte réseau compatible avant de démarrer complètement.

En cas d’échec de l’installation de l’ISO d’ESXi, on peut commencer par changer d’ISO. Les constructeurs de serveurs (Dell, HPe, whatever) mettent souvent à disposition sur leur site une image customisée par leurs soins.

Par exemple dans le cas de Dell, il est disponible à l’adresse suivante.

A la recherche de la carte perdue

Aujourd’hui, la plupart des PCs de bureau disposent d’une carte réseau on-board Realtek, souvent un modèle de type realtek 8168 (parfois du Intel et plus rarement du Killer Networks). Ce pilote n’est pas inclus dans l’ISO ESXi, ni d’ailleurs dans l’ISO customisé par Dell.

YES ! Il va falloir mettre les mains dans le cambouis !

La première chose à faire est donc de trouver le modèle exact de carte réseau que vous avez sur votre PC. Le plus simple est en fait de se connecter en shell sur le PC juste après que l’installeur est planté (Et oui, c’est possible !).

Avec votre clavier, faites [Alt] + [F1]. A partir de là vous pouvez directement vous loguer (root + mot de passe vide), puis exécuter la commande suivante :

lspci -v | grep "Class 0200" -B 1
0000:02:00.0 Ethernet controller Network controller: Realtek Realtek 8168 Gigabit Ethernet
    Class 0200: 10ec:8168

Petite blague, le clavier est en US donc pour ceux qui n’ont pas pris qwerty en seconde langue (ahah…), il y a une petite astuce pour modifier le layout du clavier (trouvée grâce au post suivant de akhpark).

localcli system settings keyboard layout set -l French

Si vous galérez à faire le tiret pour le ‘-l’, vous pouvez aussi utiliser la 2ème astuce que nous donne akhpark, à savoir la possibilité de faire des caractères spéciaux via leur code ASCII en maintenant la touche [ALT] enfoncée tout en tapant rapidement le code ASCII ([ALT]+45 pour le ‘-‘).

Maintenant on peut customiser

OK, maintenant on connait le pilote réseau qui nous manque. En espérant que ce soit le seul composant qui nous pose problème (il peut aussi y avoir le contrôleur disque…), on va donc customiser notre ISO d’ESXi.

Heureusement pour nous, depuis la version 5.X, il existe des outils pour automatiser cette modification. Le site v-front.de héberge un script Powershell qui permet de customiser nos ISO en ligne de commande. Et c’est tant mieux parce qu’avant, c’était beaucoup plus pénible ! Il fallait aller modifier des fichiers texte à la main et copier des binaires dans les bons dossiers !

ESXi customizer PS supporte les ISO d’ESXi de la version 5.0 jusqu’à la version 6.5, en se basant directement sur les ISOs disponibles sur les sites de VMware.

Les prérequis sont :

• Powershell 2+ (par défaut sur tous les Windows >= 7)
• VMware PowerCLI 5.1+ (disponible sur MyVMware)

Téléchargez la dernière version du script qui est compatible avec la version ESXi 6.5, puis récupérez le(s) pilote(s) dont vous avez besoin. Pour vous faciliter la vie, le site v-front.de met aussi à disposition les pilotes (.VIB) les plus utilisés, compilés par la communauté, dont le Realtek 8168 :-).

Ouvrez un terminal Powershell en mode administrateur et lancez la commande suivante :

.\ESXi-Customizer-PS-v2.5.1.ps1 -v65 -vft -load sata-xahci,net55-r8168

Vous devriez maintenant avoir un ISO ESXi modifier qui intègre en plus les pilotes pour la carte Realtek 8168 (et consorts) ainsi qu’un pilote SATA AHCI (souvent nécessaire aussi) !!

Bonus : If all else fails

Dans le cas où rien ne marche, que vous n’y arrivez pas… une solution de contournement peut être tout simplement d’acheter du matériel compatible. Certes ce n’est pas idéal mais il est possible d’acheter une carte Intel gigabit toute simple et compatible avec l’ESXi (6.5u1 support le chipset 82574L par exemple) pour une trentaine d’euros.

La liste des chipsets compatible est disponible sur les sites d’Intel et de VMware.

C’est la solution que j’ai choisi moi pour ma Whitebox à l’époque d’ESXi 4.0. Les matériels compatibles ou quasi compatibles étaient à l’époque référencés sur des sites comme vm-help. Les utilisateurs qui réussissaient à faire marcher ESXi sur leurs matériels décrivaient les opérations nécessaires pour y arriver : c’était vraiment de la grosse bidouille ;-).

Sources

• Une procédure similaire pour la v6 (en anglais) sur le site de VDICloud.nl
• Une procédure similaire pour la v5.5 (en anglais) sur le site de vladan
• La documentation de esxi-customizer-ps
• Configurer le proxy pour un script Powershell (si vous aussi vous avez la maladie chronique du proxy capricieux)
• La documentation officielle pour vSphere ESXi Image Builder de VMware. Cet outil permet de customiser soit même une image ESXi. Cette procédure est beaucoup plus complexe que le script Powershell, bien sûr !

Cet article Lab : installer ESXi 6.5 sur un Dell Optiplex est apparu en premier sur Zwindler's Reflection.

Les services clients et moi, toute une histoire (pas que Sosh)

Ça me passera un jour (quand je serai vieux et sage), mais pour l’instant, je ne lâche rien lorsque le service payé n’est pas rendu. J’insiste (poliment), j’appelle, je tchate, j’interpelle sur les réseaux sociaux et surtout, je garde les logs.

La dernière fois que j’avais perdu du temps avec ça, c’était lorsque j’avais résilié ma V5 et que Free avait continuer à me prélever pendant quelques semaines. Enfin, pas si perdu que ça puisque j’avais fini par avoir gain de cause

« Et vous, quand est ce que vous pashé cez Sosh »

Au détour d’une promotion sur les forfaits mobiles, ma femme a décidé de passer chez Sosh.

Elle se déplace beaucoup et utilise parfois son téléphone personnel pour recevoir des appels professionnels, envoie beaucoup de SMS et s’appuie pas mal sur la data.

Sosh s’appuyant sur sa maison mère Orange, connu pour son réseau historique de qualité couvrant pratiquement toute la France, c’était un choix qui paraissait judicieux.

« Mais ça, c’était avant le drame ! »

Je ne relate ici qu’un cas isolé et beaucoup de gens pourront probablement témoigner du contraire, mais la qualité du réseau tant louée ne s’est pas vraiment faite sentir.

Alors qu’elle n’avait jamais eu de problèmes auparavant, elle s’est mise à ne plus recevoir certains SMS (plusieurs amis m’ont remontés le même problème chez Sosh), à perdre fréquemment le réseau téléphonie (et louper des appels pro) et à avoir une couverture data assez moyenne (particulièrement en région parisienne !!!).

Au bout de 4 appels avec le support, une réinitialisation de ligne sans nous prévenir que cela induirai une coupure de réseau pendant 6h (en déplacement pro, of course), une nouvelle SIM … pas d’amélioration.

Bref, on était pas contents.

Obtenir du support

Sosh étant un opérateur « low cost », il faut s’attendre à un service client « low cost ».

Ce n’est pas le pire auquel j’aie eu affaire, rien de choquant. Sur le site de Sosh, on essaye clairement de vous aiguiller sur le forum de la communauté plutôt que vers le vrai service client. Mais si vous insistez un peu vous finirez par trouver la page pour tchater avec le service client. Un exemple en image :

Dans votre espace client, cliquez sur Aide et contact, puis dans la barre de recherche, tapez une question bidon pour un sujet qui ne peut pas être traité facilement par le forum ou une FAQ

Dans cet exemple, le RIO ne fonctionne pas dans le cadre d’une résiliation de la ligne fixe (oh le gros spoil !). En descendant presque tout en bas de l’écran, vous devriez avoir ceci. Bravo vous allez pouvoir chatter avec un être humain !!!

J’ai une offre à vous faire !

Un beau matin, une conseillère Sosh est venu nous faire une offre alléchante : Si nous souscrivions à une offre Sosh + Livebox, elle nous prolongeait la réduction de -15€/mois pendant 2 ans.

Comme nous étions déjà très très contents de la partie mobile, on s’est dit que c’était une super idée et on a accepté (lol). A notre décharge, on avait senti le coup venir et nous avions une liste de prérequis obligatoires.

A toutes les objections pour ne pas migrer sur cette offre, la conseillère s’est trompée (ou nous a trompé) sur presque toutes. Je dis « presque » car nous n’avons pas attendu le fibrage de l’immeuble, mais comme tout le reste était faux…

• Q1 : Est ce qu’on va avoir une coupure de service lors de la bascule du fixe
  R : Non, avec la portabilité c’est maintenant transparent vous n’aurez aucune coupure
  En réalité : Coupure de 5 jours sans Internet ni TV lors de la portabilité
• Q2 : Est ce qu’on aura bien du VDSL
  R : Oui, vous aurez du « débit boosté VDSL »
  En réalité : Jamais de VDSL par défaut, il faut faire la démarche auprès du service client (malheur !). La migration prend 10 jours à compter de la date de la demande (et coupure de TV pendant 2 jours) !
• Q3 : Est ce que la Livebox v3 à toujours un moins bon débit que notre Freebox
  R : Non il n’y aura aucune différence
  En réalité : Débit VDSL nettement inférieur à celui fourni par Free, notamment en upload, exactement comme je l’avais relaté dans cet article en 2015 (et pour un autohébergeur, l’upload est capital)
• 4 : Est ce qu’il sera possible de ne résilier que le mobile et si oui, est ce qu’on gardera la réduction de -15€/mois pendant 2 ans
  R : Tout à fait, c’est parfaitement possible et vous garderez votre réduction
  En réalité : Non, il n’est pas simple de passer d’une offre mobile + fixe à une offre fixe seul ET vous perdrez les promotion en cours.
  
• Q5 : L’immeuble va être fibré, est ce que les frais de raccordement seront pris en compte comme dans le cas d’une nouvelle souscription
  R : Les frais seront offerts
  

Les promesses n’engagent que ceux qui les écoutent

Il n’y avait pas de raisons que ça se passe bien

En fait Sosh ne propose que du mobile. L’offre Sosh + Livebox leur impose de sous-traiter la partie fixe à Orange.

On se retrouve avec un micmac à moitié côté Sosh, à moitié côté Orange, que ce soit pour la livraison, pour le service client ou pour tout le reste !

Et quand nous avons résilié l’offre mobile, nous nous sommes retrouvé ni vraiment chez Sosh, ni vraiment chez Orange :

• Côté Sosh – pour eux nous avions résilié la ligne fixe (alors que c’est faux, ma livebox fonctionne toujours depuis 1 mois) : impossible d’obtenir un RIO pour passer facilement chez un autre opérateur Internet fixe.
• Côté Orange – nous n’avions ni compte ni numéro pour obtenir de l’aide.

Des dialogues sur-réalistes

Mais le mieux dans tout ça, c’est quand même cette relation client qui serait à mourir de rire si ça n’en était pas « à pleurer ».

Vous n’êtes pas obligés de me croire, mais les dialogues que je vais vous mettre ici sont véridiques. Je n’ai rien déformé et il s’agit même de copié collé des logs dans le cas du tchat Sosh.

A propos des SMS qui n’arrivent pas :

Sosh : Dites nous combien de SMS vous n’avez pas reçus ?

Moi : Comment voulez vous que je le sache, je ne les ai pas reçus !

Sosh : Dites nous au moins l’heure et la date ou l’expéditeur !

Moi : …???

Le technicien qui se souvient qu’on peut paramétrer le centre de réception de SMS et qui finira par nous traiter de menteurs (WTF!) :

[Il nous fait lire l’écran des paramètres à haute voix, mais tout est déjà paramétré correctement]

Sosh : Tous les paramètres sont bons, je suis ravi d’avoir pu vous aider !

Moi : Mais… attendez, je n’ai rien modifié tout était déjà bon !

Sosh : Je sais très bien ce que j’ai dis, vous avez modifié un écran

Moi : Je vous assure que non et je n’aime pas votre ton

Sosh : Ne soyez pas de mauvaise foi !

A propos de la carte SIM qu’ils proposent de changer :

Sosh : Nous allons vous envoyer une nouvelle carte SIM et j’ai le plaisir de vous informer que nous vous la fournissons gratuitement !

A propos du VDSL à activer :

Sosh : Désolé monsieur, le 02XXXXXXXX n’est pas éligible au VDSL

Moi : Pardon ? Moi c’est un 05XXXXXXXX

Sosh : Ah non je me suis trompé de numéro. Pour pouvoir donner suite à votre demande, il faut que je vous passe un expert. Mais retentez plutôt lundi à 8h, parce que là vous n’aurez plus personne !

Moi : Je ne comprend pas, vous n’êtes pas censés fermer à 20h ? Il est 19h15…

Sosh : Ah oui, mais là, à cette heure ci, vous n’aurez personne d’ici à l’heure de fermeture !

A propos de la « ligne fixe après avoir résilié l’offre mobile » :

Sosh : Votre ligne fixe a été déjà résiliée , et le numéro de la ligne fixe est actif chez un autre opérateur

Moi : Quoi ? Non c’est une erreur je n’ai résilié que la partie mobile

Sosh : Je sais ce que j’ai dis. Vous n’êtes plus chez Sosh pour la ligne fixe, cette ligne est résiliée !

2 fois de suite, quand le téléopérateur n’est pas en mesure de répondre, il botte en touche :

Sosh : Je retransfère la demande auprès du service expert, mais il faut attendre une réponse par mail. Délai de traitement entre 48h et 5 jours

Moi : Pardon ? C’est la 2ème fois que vous me faites le coup. Je n’ai jamais eu de réponse par mail la dernière fois et c’est pour ça que je reviens vers vous aujourd’hui. Je veux une réponse cette fois.

Sosh : Non, il faut attendre. Dans 5 jours vous pourrez nous recontacter.

Inutile de vous dire que j’attends toujours le retour des experts

Alors ? Et vous, quand est ce que vous passez chez Sosh ?
Parce que moi, ils sont rayés à vie aux côtés de Numéricable

Cet article Retour d’expérience avec le service client Sosh est apparu en premier sur Zwindler's Reflection.

GhettoVCB, depuis VMware Infrastructure 3, toujours compatible !

En 2010, un de mes tout premiers articles sur ce blog parlait d’un script s’appelant GhettoVCB. Il permettait de réaliser des sauvegardes à chaud sur des ESXi, SANS vCenter. Et c’est là toute la nuance, car si toutes les solutions de sauvegardes d’entreprises savent aujourd’hui sauvegarder des machines virtuelles VMware, elles se basent toutes sur un API (historiquement VCB pour VMware Consolidated Backup).

Or, l’usage l’API de sauvegarde (VCB, puis VADP et maintenant VMware vSphere Storage APIs – Data Protection) est conditionnée à la présence d’une licence ! Impossible d’utiliser ces outils avec un ESXi « gratuit » (free).

What licensing is required to use VMware vSphere Storage APIs – Data Protection?
Data Protection APIs are included with all licensed vSphere editions.

Ce script (mis en ligne depuis 2008 !) se base directement sur les binaires présents sur l’OS, sans passer par l’API VCB. Il fait donc pratiquement la même chose, mais gratuitement. Inutile de vous dire que ce script est très populaire parmi les bidouilleurs au budget limités et souhaitant quand même faire des sauvegardes.

Je vous met aussi le lien vers le post historique.

Installation

Historiquement, en guise « d’installation », il fallait simplement copier le script dans le répertoire de son choix. Aujourd’hui, c’est un peu plus « propre » puisque l’auteur a mis à disposition un VIB qui permet d’installer sur l’ESXi via un package. Les sources ont été hébergées sur Github.

Télécharger le fichier depuis le Github, puis le copier en SSH/SCP/SFTP dans /tmp. Se connecter en SSH et installer la VIB :

esxcli software vib install -v /tmp/vghetto-ghettoVCB.vib -f

Pas besoin de rebooter avec cette VIB (simple copie du script). E-Z.

Mise en place de la sauvegarde

La documentation n’a pas été reportée sur le Github malheureusement, mais elle est toujours disponible sur le site historique de la communauté VMware.

Dans l’exemple suivant, on va, configurer le datastore VMFS_BCK comme destination de notre sauvegarde, sélectionner les VMs qu’on souhaite sauvegarder, et planifier (enfin… crontab quoi) nos sauvegardes. Youhou !

Sauf erreur de ma part, la documentation n’indique pas les chemins des fichiers scripts et de configuration. Avant c’était plus simple, vous téléchargiez tout et vous le mettiez dans le dossier que vous vouliez. Maintenant, la VIB dépose le fichier de configuration principal, un template de sauvegarde et un autre de restauration dans /etc/ghettovcb/. Les scripts sont quant à eux installés dans /opt/ghettovcb/bin/.

Se connecter en SSH sur le serveur VMware concerné. Voici un exemple de configuration de sauvegarde :

cd /etc/ghettovcb/
vi ghettoVCB.conf
  VM_BACKUP_VOLUME=/vmfs/volumes/VMFS_BCK/backup
  DISK_BACKUP_FORMAT=thin
  VM_BACKUP_ROTATION_COUNT=3
  POWER_VM_DOWN_BEFORE_BACKUP=0
  ENABLE_HARD_POWER_OFF=0
  ITER_TO_WAIT_SHUTDOWN=3
  POWER_DOWN_TIMEOUT=5
  ENABLE_COMPRESSION=0
  VM_SNAPSHOT_MEMORY=0
  VM_SNAPSHOT_QUIESCE=0
  ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
  SNAPSHOT_TIMEOUT=15
  EMAIL_ALERT=0
  EMAIL_LOG=0
  EMAIL_SERVER=[@IP]
  EMAIL_SERVER_PORT=25
  EMAIL_DELAY_INTERVAL=1
  EMAIL_TO=ghettovcb@zwindler.fr
  EMAIL_ERRORS_TO=
  EMAIL_FROM=alert_ghettoVCB@zwindler.fr
  WORKDIR_DEBUG=0
  VM_SHUTDOWN_ORDER=
  VM_STARTUP_ORDER=

Ce fichier va nous permettre de configurer toutes les valeurs « par défaut » lors de nos sauvegardes.

Pour éviter tout souci, vérifiez qu’il y a bien de l’espace disponible sur le datastore choisi et que le chemin existe ;-).

ls /vmfs/volumes/VMFS_BCK/backup

Chacune des valeurs contenues dans la configuration peuvent être surchargées par le fichier de sauvegarde que nous allons créer. Dans cet exemple je ne modifie rien mais là c’est à vous de voir ! Ici, j’ajoute simplement la VM à une liste des machines virtuelles à sauvegarder :

vi /etc/ghettovcb/vm_backup_list
  ma_vm_a_sauvegarder

On commence par lancer le script à la main pour voir en live si ça fonctionne :

/opt/ghettovcb/bin/ghettoVCB.sh -f /etc/ghettovcb/vm_backup_list -g /etc/ghettovcb/ghettoVCB.conf

Une fois que le script rend la main, vérifier dans le dossier de destination que la sauvegarde s’est bien réalisée. Il devrait contenir un dossier daté du jour et tous les fichiers de la VM.

cd /vmfs/volumes/VMFS_BCK/backup

Pour faire simple, vous pouvez commencer par une sauvegarde toutes les semaines (dimanche minuit) :

crontab -e
	#Sauvegarde hebdo des VMs critiques
	00 0 * * 0 /opt/ghettovcb/bin/ghettoVCB.sh -f /etc/ghettovcb/vm_backup_list -g /etc/ghettovcb/ghettoVCB.conf

Restauration

Nous allons jouer ici le scénario d’une restauration (ma_vm_a_restaurer) située sur le datastore /vmfs/volumes/VMFS. Il faut donc :

• Mettre de côté la machine HS
• Trouver la sauvegarde que l’on souhaite restaurer
• La restaurer à l’emplacement initial de la VM

Retirer la VM à restaurer de l’inventaire et garder une copie au cas où

vmware-cmd -s unregister ma_vm_a_restaurer
mv /vmfs/volumes/VMFS/ma_vm_a_restaurer /vmfs/volumes/VMFS/ma_vm_a_restaurer.ko

Retrouver la sauvegarde qu’on souhaite restaurer

cd /vmfs/volumes/VMFS_BCK/backup/ma_vm_a_restaurer
ls -l
	drwxr-xr-x 1 root root 840 Sep  3 14:12 ma_vm_a_restaurer-2032-09-03_00-00-00

Réaliser la restauration en elle même

Ici, on fait une copie du template de restauration et on y modifie les variables comme le chemin souhaité et le datastore cible. On termine l’opération en exécutant le script ghettoVCB-restore.sh

cd /etc/ghettovcb/
cp ghettoVCB-restore_vm_restore_configuration_template ghettoVCB-restore_ma_vm_a_sauvegarder
vi ghettoVCB-restore_ma_vm_a_restaurer
  /vmfs/volumes/VMFS_BCK/backup/ma_vm_a_restaurer/ma_vm_a_restaurer-2032-09-03_00-00-00;/vmfs/volumes/VMFS;3
/opt/ghettovcb/bin/ghettoVCB-restore.sh -c /etc/ghettovcb/ghettoVCB-restore_ma_vm_a_restaurer

Finaliser la restauration

Une fois la recopie de la sauvegarde terminée, la VM devrait réapparaitre (automatiquement) dans l’inventaire de votre serveur VMware (le script effectue le register_vm).

Démarrer la VM. Si tout a fonctionné, la VM devrait rester bloquée et c’est « normal ».

VMware va détecter qu’il y a eu une opération et vous posera la question pour savoir si c’est une copie ou déplacement. Même si dans la majorité des cas ça ne devrait pas avoir d’impact, il est préférable de répondre « I moved it »/ »Je l’ai déplacé ».

Dans le cas contraire, VMware modifiera une partie de la VM, notamment son adresse MAC, ce qui n’est pas forcément souhaitable dans le cadre d’une restauration. « I moved it » permet de garder la VM telle quelle.

Enjoy !

Cet article Sauvegardez vos ESXi 6.5 sans licence avec GhettoVCB est apparu en premier sur Zwindler's Reflection.

Terraform ?

Si vous avec passé un peu de temps sur Twitter, LinkedIn ou dans n’importe quel conf un peu orientée DevOps, vous ne pouvez pas avoir loupé Terraform.

Terraform est un outil d’Infrastructure as Code développé par Hashicorp. Que le nom de cette entreprise vous dise quelque chose ou pas, vous avez très probablement entendu parlé de Vagrant (eh oui c’est eux) et de Consul (peut être même de Packer, Vault ou Nomad). Bref, l’entreprise propose un certain nombre d’outils pour faciliter l’exploitation et l’automatisation de ressources, particulièrement dans le cloud.

Ok, mais Terraform c’est quoi ?

Des fois le plus simple est de laisser les développeurs en parler d’eux même

What is Terraform?
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Il y a deux phrases, et les deux sont importantes. En Français :
– Terraform est un outil pour construire, changer, versionner l’infrastructure de manière sécurisée et efficace (efficiente?).
– Terraform peut gérer des fournisseurs de services (comprenez cloud plublic) mais aussi des solutions maison sur site (comprenez cloud privé).

Pourquoi c’est important ?

Comme je le disais un peu plus haut, même s’ils disent le contraire, Terraform est quand même (historiquement) plutôt à destination des cloud providers.

C’est là où Terraform a apporté la plus-value qui a fait sa renommée. Il permet une gestion plus agnostique des ressources et permet de passer facilement d’un cloud à l’autre.

Et mon cluster VMware/Openstack on-premise alors ?

Heureusement, l’outil s’enrichit de jour en jour et on dispose aujourd’hui de beaucoup de providers au delà des AWS, Azure et GCP et s’ouvre à d’autres usages comme MySQL, Kubernetes, Grafana, … La liste complète est disponible sur le site de Hashicorp.

Le tutoriel « officiel » est disponible à l’adresse suivante, mais on reste un peu sur sa faim. Et surtout on ne voit pas comment faire du on-premise (ou que vous êtes allergiques à AWS).

Quelques concepts

Je ne peux pas faire un article sans vous donner un minimum de concepts pour appréhender Terraform. La première chose à savoir est que Terraform utilise un langage de configuration appelé HCL qui lui est propre HashiCorp Configuration Language. C’est avec ce langage de configuration qu’on va décrire l’infrastructure à construire et l’état dans lequel on souhaite avoir cette infrastructure. Moi qui suis habitué au YAML, dommage…

On va donc devoir décrire un provider, qui sera notre point d’entrée pour créer/interagir avec l’infrastructure (un login/mdp pour AWS, un serveur vCenter et les logins/mdp privilégiés, etc). Il est très probable qu’on ait plusieurs providers.

Ensuite on pourra commencer à décrire nos ressources (tout objet nécessaire pour notre application, que ce soit une VM, un container, un réseau virtuel, une URL dans un loadbalancer, etc).

Assez de théorie, la pratique !

Pour voir autre chose et mettre un peu plus les mains dans le cambouis, je vous propose donc un petit exemple avec un cluster VMware que vous auriez sous la main.

La première chose à faire est sans surprise de récupérer terraform => https://www.terraform.io/downloads.html

Installer et configurer Terraform

Si vous travaillez sur un Linux, un petit curl et on en parle plus.

curl https://releases.hashicorp.com/terraform/0.10.6/terraform_0.10.6_linux_amd64.zip -o terraform_0.10.6_linux_amd64.zip
unzip terraform_0.10.6_linux_amd64.zip
mv terraform /usr/local/bin

Sous Windows, le plus simple est de télécharger le binaire, de le déposer dans un dossier de votre disque et d’alimenter le PATH (modifier les variables d’environement du systèmes)

On peut maintenant tester que la commande répond correctement :

Mon premier script Terraform

Dans cet exemple, je me base sur le provider vSphere, dont vous retrouvez la documentation ici. Ce simple script va se connecter à mon vcenter, créer un répertoire test à la racine du cluster, puis créer une VM dans ce répertoire.

cat example_vsphere.tf

# Configure the VMware vSphere Provider
  provider "vsphere" {
  user = "root"
  password = "xxxx"
  vsphere_server = "vcenter.zwindler.fr"
  # if you have a self-signed cert
  allow_unverified_ssl = true
}

# Create a folder
resource "vsphere_folder" "test" {
  path = "test"
  datacenter = "VMware zwindler"
}

# Create a virtual machine within the folder
  resource "vsphere_virtual_machine" "test" {
  name = "terraform-test"
  datacenter = "VMware zwindler"
  cluster = "Cluster_VMware"
  folder = "${vsphere_folder.test.path}"
  vcpu = 2
  memory = 4096
  network_interface {
    label = "Virtual Network"
    ipv4_address = "192.168.1.100"
    ipv4_prefix_length = "24"
    ipv4_gateway = "192.168.1.1"
  }
  disk {
    template = "tmpl-rhel-7-3"
    datastore = "VMFS01"
  }
}

On récapitule. Le premier objet de base dans terraform est le « provider », qui nous permet de prendre le contrôle du cluster. Les deux autres objets sont les « ressources » qu’on souhaite créer/modifier.

It’s alive!

La première commande à lancer est terraform init, dans le dossier qui contient notre fichier de définition de l’infrastructure. Cela permet d’initialiser le contexte recherché ainsi que des variables. terraform plan permet ensuite de faire un essai à blanc des modifications pour s’assurer que tout fonctionnera bien comme attendu (dry run).

terraform init
terraform plan

Et pour finir, on exécute notre plan avec terraform apply (création du dossier et génération de la machine virtuelle) :

terraform apply

A l’issue de ces commandes, une VM devrait être créée dans votre cluster comme spécifiée. Vous remarquerez également la présence dans le même dossier que votre fichier example_vsphere.tf un fichier terraform.state. Ce fichier terraform.tfstate (qui enregistre l’état dans lequel est l’infrastructure) est important et doit être disponible pour tous les postes/utilisateurs qui utilisent terraform pour cette infrastructure (sinon ça ne marche pas).

Hashicorp conseille d’utiliser un moyen de rendre ce fichier disponible à distance, par exemple avec un serveur Consul (de Hashicorp, bien sûr). On peut utiliser etcd ou artifactory ou même un simple partage mais il y aura des risques d’accès concurrents (il n’y aura pas de locking au niveau Terraform).

With remote state, Terraform stores the state in a remote store. Terraform supports storing state in Terraform Enterprise, Consul, S3, and more.
Remote state is a feature of backends. Configuring and using backends is easy and you can get started with remote state quickly. If you want to migrate back to using local state, backends make that easy as well.

Si vous voulez en savoir plus, allez lire cette page.

Conclusion

J’ai essayé de faire bref pour vous donner un aperçu très rapide de ce qu’est Terraform et de ce qu’on peut faire avec mais il reste forcément encore beaucoup de choses à dire. Déjà, j’ai résumé à l’extrême la partie théorie et n’ai pratiquement expliqué aucun concept. Ensuite, je n’ai pas beaucoup exploré les limites de Terraform, notamment dans l’utilisation à plusieurs et les manques par rapport à d’autres outils.

Pour ma part j’ai trouvé l’outil intéressant mais je ne peux pas m’empêcher de faire le parallèle avec Ansible, que je maitrise beaucoup mieux.

Que peut faire Terraform que ne peux pas faire Ansible ? Peut être une meilleure gestion de fournisseurs de services autres que AWS Azure et GCP (Dyn, Datadog ou Mailgun).

A l’inverse, Ansible permet de faire beaucoup plus de choses que Terraform, car c’est un outil bien plus fourni (à date) et surtout plus généraliste, qui sert à la fois à déployer ET à configurer.

Pour autant, je ne m’interdis pas de l’utiliser dans un prochain contexte professionnel qui devrait justement me demander plus d’interaction avec les clouds public.

Have fun !

[Bonus]Life in graphic, it’s fantastic

Une fonctionnalité sympathique de Terraform est la possibilité offerte de générer un « graphe » de vos ressources et de leurs dépendances les unes aux autres. Certes, dans des cas concrets et complexes c’est peut être un peu gadget, mais l’idée est bonne.

En réalité, c’est même pour cette raison que je me suis intéressé à Terraform. A la base, on m’a demandé de trouver un outil permettant de visualiser une infrastructure complexe. Or celle ci étant changeante car en pleine conception, je n’avais pas envie de repasser 50 fois sur un diagramme de type Visio. J’ai donc cherché une solution pour le faire de manière automatique.

Voilà le genre de résultats que vous pouvez attendre de Terraform :

Pour se faire, installez simplement la bibliothèque graphviz et utilisez la commande terraform graph.

yum install graphviz
terraform graph | dot -Tpng > terraform-graph.png

A noter : je n’ai pas trouvé la solution satisfaisante et c’est pour ça que j’ai commencé à développer ma propre bibliothèque Python pour grapher des infrastructures. Quand ça ressemblera à quelque chose je ferai un article dessus (#Teasing).

Cet article Premiers pas avec Terraform est apparu en premier sur Zwindler's Reflection.

Behold!

J’en ai déjà parlé sur le blog, j’ai entamé une phase de dés-auto-hébergement. Oui je sais, c’est triste.

Au delà des problématiques de disponibilités des services plus réduite en auto-hébergement (sauf à réaliser des efforts conséquents) par rapport à des services en ligne, héberger son serveur, ce n’est pas toujours très écolo et ça peut couter plus cher.

Louer une machine physique et y installer un hyperviseur chez Kimsufi (ou OneProvider ou autre) permet de faire des économies pour une qualité de service supérieure (cf les articles de M4vr0x). Alors ce n’est certainement pas aussi fun que de concevoir et monter son propre meuble « rack » et y visser une carte mère dedans mais c’est probablement aussi plus rationnel.

N’ayant plus que le « serveur NAS » dans mon Red Helmer maison, j’ai donc décidé d’aller au bout de la démarche et d’abandonner mon Xubuntu customisé pour acquérir un QNAP TS431 P2.

Synology ou QNAP, un choix de société ? Vous avez 4 heures !

Je vais esquiver (ou au moins tenter d’esquiver) un flame war Synology versus QNAP et simplement lister mes besoins. Je veux remplacer un NAS existant à base d’OS Linux disposant des caractéristiques et fonctionnalités suivantes :

• Matériel :
  • Intel Pentium (dual core 3GHz)
  • 8 Go de RAM
  • ~6 To via 3x 3To de HDD Western Digital Red en grappe RAID 5 via mdadm

  . Le but est de réutiliser ces disques.

  • 4 baies 3,5″ minimum (cf ligne précédente)
• Performances :
  • Je souhaite disposer d’un NAS capable a minima de saturer le port gigabit Ethernet (>100 Mo/seconde en lecture ou écriture séquentielle) sans perte de performance sur les autres services
• Fonctionnalités :
  • Partages NFS, CIFS, iSCSI
    • Serveur SFTP, Plex et Deluge centralisant les téléchargement démarrés depuis tous les PC du foyer
  • Accès SSH en admin (pour hébergement de petits services complémentaires comme des scripts de supervision, mise à jour de DynHost OVH, …)
• Prix :
  • Le moins cher possible une fois que les critères de performances et fonctionnalités sont respectés

Si on met de côté le serveur Deluge qui est un besoin un peu exotique, les fonctionnalités nécessaires sont relativement basiques. Ce n’est donc pas réellement un critère de choix.

Shortlister du matériel

Je me suis néanmoins limité à Synology et QNAP (les deux leaders) pour m’assurer un meilleur support et une meilleure assurance d’avoir de nouvelles fonctionnalités dans les années à venir car leurs OS sont régulièrement mis à jour.

J’ai donc épluché les références sur le site des deux marques (Synology et QNAP) et voilà les modèles qui ont retenus mon attention :

• QNAP TS431P2 (Home – Middle range)
• QNAP TS451* (Home – High end)
• Synology DiskStation DS418j (Home – Middle range)
• Synology DiskStation DS418 (Home – Middle range)

Clairement, le TS451 (et ses déclinaisons) est overkill. Outre la sortie HDMI dont je n’ai que faire (le NAS est dans le dressing, loiiiin de la TV), le TS451 dispose d’un Celeron, capable sur le papier de faire tourner des VMs. L’argument est intéressant mais je ne pense pas en avoir l’utilité à la maison, toutes mes VMs ayant été transportées sur les serveurs chez Kimsufi.

La vraie « battle » s’est donc faite entre le TS431P2 et les deux Synology DS418 et sa version « j ».

Comparer des oranges et des bananes

Voici un petit tableau comparatif des trois NAS :

La RAM

Il y a clairement 2 philosophies. Synology se vante d’avoir doublé la capacité de la RAM de ces modèles de 2018 (2G/1G) par rapport à ceux de 2016 (1G/512M). En même temps on partait de tellement loin ! Chez QNAP, si les modèles d’entrée de gamme sont aussi en 1Go, on hésite pas à proposer des modèles avec 2, 4, voire 8 Go, et à indiquer que tous les modèles sont upgradables. Dans l’optique d’héberger de futurs services supplémentaires à la maison, c’est rassurant, mon TS431P2 ne manquera pas de RAM.

Performance brute

A première vue, les 3 NAS disposent de processeurs ARM récents et se valent.

Pourquoi je parle de CPU ? Au delà de la vitesse des disques qui est indépendante du NAS choisi, et de la vitesse des ports Gigabit (bridée… à 1 Gbit ! surprise !), c’est le CPU le facteur limitant sur la plupart des NAS sur le marché.

Or dans le cas présent, les 3 saturent les ports Ethernet en lecture ou écriture séquentielles (le DS418j n’a qu’un port Ethernet, d’où les débits 2x inférieurs).

C’était une vraie inquiétude pour moi car les premiers Synology que j’avais pu manipuler il y a quelques années étaient plombés par des ARM sous dimensionnés induisant des plateaux à 40-50 Mo/s et bloquant toutes les autres opérations (CPU à 100%). C’était la raison pour laquelle j’ai monté plusieurs « NAS maisons » depuis 2011, avec des performances bien plus importantes à tarif égal.

Comparer les ARM entre eux

A ma connaissance, il n’existe pas de base de données en ligne de benchmark sur les différents CPU ARM (comme on peut trouver pour Intel et AMD par exemple), donc pas de possibilité de comparer comme cela.

Cependant, en fouillant un peu plus, j’ai pu me rendre compte que l’Alpine AL-314 semble surclasser très (très) largement les deux autres. En épluchant la fiche technique du TS431X2 (un NAS QNAP entrée de gamme pour PME avec un port… 10GbE fibre !) qui a le même processeur, on découvre des performances maximales théoriques de 1014 Mo/s en lecture et 580 Mo/s en écriture ! On sature même le 10GbE en lecture…

Cet avantage se confirme sur les transferts chiffrés. Le DS418 ne sature plus qu’un seul port Ethernet et le DS418j tombe même bien en dessous des 100Mo/s en écriture.

Parallèlement, le TS431P2 garde un débit assez proche de la saturation de ses deux ports Ethernet. Autant dire qu’avec ce processeur, le NAS s’ennuie quand on transfère à 100 Mo/s (ce que j’ai pu vérifier IRL).

Il n’y a donc aucune contrindication à héberger des services supplémentaires et les gros transferts n’ont aucun impact sur les performances globales du NAS (si ce n’est congestionner le réseau).

Killer features (containers et snapshots)

Déjà, côté matoss, le QNAP est donc devant.

Côté fonctionnalités, si DSM (OS des Synology) possède beaucoup plus de paquets/applications que QTS (OS des QNAP), les DS418(j) ne sont pas compatibles avec l’application Docker alors que le TS431P2 (et tous les autres QNAP) propose une application officielle pour gérer les containers LXC ET Docker.

Dans l’optique de remonter mon serveur Deluge sur le NAS (et d’autres services par la suite), c’est donc un autre point positif pour QNAP.

Deux derniers point mis en avant par QNAP, la possibilité de gérer sur tous les modèles de la gamme des snapshots de tous les volumes avec la dernière version (QTS 4.3.4), ce qui n’est pas possible sur les DS418(j), ainsi qu’une application pour gérer des devices de type IoT.

User friendly versus bidouilleur

Clairement, le positionnement de Synology est de proposer des boitiers suffisants pour la plupart des utilisateur, un peu moins customisables et performants mais aussi un peu plus simple d’utilisation. C’est pour ça que, pour tout autre personne que moi (ou un geek sysadmin), je conseille les Synology.

J’insiste : les différences sont vraiment infimes car QNAP est aussi très user friendly. L’interface est très fluide et très intuitive, mais on a clairement plus la main (pas encore autant que je voudrais :-p) et un néophyte serait probablement plus à l’aise sur un Synology.

Mais le fait que le CPU soit bien plus costaud côté sur les QNAP et qu’on ait la possibilité d’augmenter la RAM sont clairement des points qui plaisent aux bidouilleurs dont je fais partie.

L’ajout de fonctionnalités comme Docker/LXC, les snapshots ou le support de l’IoT sur toute la gamme aussi.

Sans trop d’hésitation, j’ai donc choisi le TS431P2. En profitant d’une promo j’ai réussi à avoir le modèle 1 Go avec une barette de RAM 8 Go pour pratiquement le même prix que sans. Je ferai peut être un petit article sur la partie upgrade de la RAM

Sources

• Liste des NAS 4 Baies Synology
• Performance des NAS 4 Baies Synology
• Liste des NAS 4 Baies QNAP
• Performance des NAS 4 Baies QNAP
• Plugins Nagios et compatibles pour superviser un QNAP

Cet article Stockage pour un admin geek : QNAP TS431P2 ou Synology DS418(j) ? est apparu en premier sur Zwindler's Reflection.

Hack-It-N, une conf sécu organisée (entre autre) par Tehtris et l’ENSEIRB-MATMECA

Comme l’an dernier, je suis allé faire un tour à l’édition 2018 du Hack-It-N. Cette conférence cybersécurité est organisée par la société Tehtris et l’école d’ingénieur ENSEIRB MATMECA.

Je vous met le pitch :

Les thématiques de cyberdéfense et de cyberattaque seront au coeur des préoccupations, pour coller à la réalité technique et à l’actualité des menaces : hacking, cyber-espionnage, cyber-surveillance, etc. Venez découvrir les enjeux actuels de la cybersécurité, ainsi que les techniques offensives et défensives du moment !

Et pour une fois, j’ai enfin pris le temps de faire un petit récapitulatif des présentations qui y ont eu lieux !

Discours d’ouverture Toufik ahmed et Laurent Oudot

Pour ceux qui ne connaissent pas l’ENSEIRB-MATMECA, cette école nationale supérieur, intégrée à Bordeaux INP, forme des ingénieurs dans plusieurs filières comme l’informatique, l’électronique, les systèmes embarqués et la modéliation mathématique et mécanique. Coïncidence (ou pas), il se trouve que je suis diplômé de l’ENSEIRB.

Toufik Ahmed, directeur de l’option RSR (cybeR-sécurité, Systèmes & Réseaux) de la filière informatique, co-organise Hack-It-N avec la société Tehtris, représentée par Laurent Oudot (co-CEO & CTO).

Cette deuxième édition a été l’occasion de créer une identité visuelle à la conférence, notamment avec un nouveau logo que Laurent Oudot a décrypté pour nous.

Cette introduction a également été l’occasion de citer les partenaires de l’événement dont la région Nouvelle Aquitaine, l’ANSSI, eShard, aDvens, Exaprobe et Digital Security.

Table ronde/forum

Comme l’an dernier, Hack-It-N a organisé une table ronde, animée par Nicolas CESAR, journaliste à Sud Ouest Eco. Autour de la table, des experts de tous bords :

• Guy Flament (Référent Nouvelle Aquitaine ANSSI)
• Hervé Le GUYADER (Délégué stratégie et partenariats internationaux de l’ENS Cognitique)
• Frédéric GOUTH (Consultant Cybersécurité, Nystek // spécialiste des problématiques RGPD et aspects techniques de cybersécurité)
• Christophe MAILLET (CEO ADACIS, spécialiste des Infrastructures Sensibles)

Cette table ronde a été l’occasion de soulever de nombreux sujets, que je vais tenter de résumer au mieux.

Évolution des attaques

Oui, les attaques viennent aussi d’états souverains, et depuis longtemps. Mais il est difficile de dire qui exactement (exemple de Stuxnet => USA ou Israel ?). La souveraineté est menacée : l’OTAN a classé en juillet 2016 le cyberespace comme 4ème domaine de conflit.

Elles viennent aussi de criminels voire de concurrents, car l’intelligence économique et espionnage industriel sont souvent sous-estimés.

Les cyberattaques reposant sur l’exploitation de failles humaines risquent de devenir de plus en plus difficiles à détecter avec la combinaison de moyens techniques (big data, profilage, machine learning) et l’ajout de recherches dans les sciences cognitives. On parle dans plusieurs universités américaines de « computer as persuasive technology« .

• Pour lutter contre cela, la coopération entre les écoles est capitale pour former des experts pluridisciplinaires.

Coût des attaques

Le coût réel des attaques en France est quasiment impossible à chiffrer :

• D’un part, le coût d’une attaque implique les coûts directs (remise en état) mais surtout indirects (perte de CA et perte d’image).
• D’autre part, les société Françaises préfèrent encore garder le secret, même par rapport à des entités comme l’ANSSI.

Pour ce dernier point, les experts autour de la tables s’entendaient quand même à dire qu’il y avait du mieux. Les entreprises communiquent un peu plus qu’avant mais aussi parce qu’elles sont pour certaines obligées de le faire. Les législations à venir vont dans ce sens et cela devrait progressivement s’améliorer.

• Ce point est capital car la prise de conscience des risques cyber se fait par les pairs. Plusieurs exemples ont cités (Fox-it, Saint Gobain), ont permis à certains participants de la conférence de justifier des arbitrages devant des directions.

Prise en compte des risques

Il y a encore de gros déficits de formation/prise de conscience des risques numériques, aussi bien dans le public que dans les entreprises.

• L’apprentissage de ses risques devrait se faire (selon les participants de la table ronde) beaucoup plus tôt, dès le collège. RGPD va permettre une prise de conscience aux gens : leur données leurs appartiennent !
• Côté entreprise, au delà des bonnes pratiques, c’est surtout la méthode de l’amélioration continue qu’il faut prôner (les guides de l’ANSSI et i901 ne font pas tout).

Confiance dans les acteurs de la filière

Quel confiance je peux avoir dans mon prestataire qui va mettre les mains dans mon SI et l’auditer ?

Cette question qui a été posée a fait écho à mon expérience personnelle car ce n’est pas la première fois que j’entends cet argument. Notamment dans la bouche de direction d’entreprise pour justifier l’absence d’audits de sécurité. Il y a un vrai problème de confiance.

Pour les OIV (Organisme d’Importance Vitale), il existe une qualification par l’ANSSI des prestataires mais elles n’est pas du tout pertinente pour les autres entreprises.

• Une partie de la solution est en train d’être mise en place sur le portail cybermalveillance.gouv.fr (en cours de construction, s’adressera surtout aux TPE).

Dissection d’attaques contemporaines

Présenté Fabien Debuire (Exaprobe), cette présentation a cité 2 exemples pour décrire l’évolution des attaques récentes.

On remarque qu’on bascule de plus en plus dans un aspect commercial de l’attaque : des hackers livrent des outils clés en main (exploit ou malware tout faits pour réaliser des attaques).

Même si Wannacry était une attaque ratée (très mal codée), elle était basée sur une faille mise en ligne par les Shadow Brokers quelques jours plus tôt et découverte bien avant. Elle a aussi l’avantage d’avoir demandé une rançon via des cryptomonnaie dont on peut suivre les paiements, ce qui est utile pour faire des statistiques sur les payeurs.

Je n’avais pas bien en tête ce qu’était CERBER en revanche, et j’ai trouvé le principe génial. Des affiliés sont mis en relation avec des utilisateurs lambda via une offre de service avec une interface web. On créé un profil sur un réseau et on se met d’accord avec des attaquants sur un pourcentage pour l’affilié et l’utilisateur.

Buzzword => « Hacking as a Service »

Autre point intéressant, comme toute offre de service en ligne, l’outil a ajouté des fonctionnalité au fil du temps comme l’ajout de statistiques ou un monitoring des systèmes pour détecter les honeypots, etc.

La deuxième partie de la présentation a été axée sur « Comment s’en protéger ? ». Sans trop de surprise, les préconisations ont été de mieux former les utilisateurs aux risques numériques, respecter les bonnes pratiques de bases et utiliser des outils poussés du marché.

Ce dernier point à permis de mettre en lumière quelques problématiques face à l’utilisation des outils de sécurités qui pour des raisons purement commerciales implémentent des protocoles propriétaire en dehors des normes, empêchant de disposer d’outils de sécurité qui communiquent entre eux.

Ne négligez pas la sécurité des applications mobiles

Cette présentation a été faite par Tiana Razafindralambo, expert chez eShard  (société spécialisée dans la Sécurité des systèmes embarqué, Mobile et IoT).

Toute la présentation a tourné autour de la sécurité dans une application mobile Android APK, et les différents vecteurs d’attaques utilisables. Pour rappel les APK sont simplement des archives (similaires aux JAR/WAR), contenant les ressources (images, données sensibles) et le binaire (qu’on peut décompiler éventuellement).

Par defaut, dans Android-Studio, l’outil de dev d’app android le plus utilise défaut, il existe un outil intégré d’obfuscation et d’optimisation de code (ProGuard) permettant de ralentir un minimum le reverse engineering.

Pour « pirater » ces applications, il existe 2 vecteurs d’attaques principaux. Les attaques locales (dans le cas ou l’attaquant a le téléphone en main et qu’il est capable d’exécuter son attaque directement sur le téléphone) et à distance (via NFC, wifi, 3g/4g, voire même au travers d’attaques de type canaux-caches exploitant les fuites de signaux électro-magnetiques, ou acoustiques).

Pour comprendre pourquoi l’obfuscation de code n’est pas si inutile que ça, un exemple sur la protection des communications HTTPS a été donnée.

Cependant, dans le cas de l’attaque locale, il est souvent très simple de réaliser des analyses statiques (nombre de caractères dans les mots, patterns dans les fichiers) et de l’instrumentation de code pour comprendre puis compromettre une application. Par exemple, on peut usurper assez facilement les certificats mis en place, même lorsqu’ils utilisent du certificate pinning.

Tiana a cité deux cas d’analyses de surface d’applications bancaires, une étude polonaise et sa propre étude, qui fait relativement froid dans le dos :

• Pologne : Pas de certificate pinning, obfuscation trop simple
• France : beaucoup de proguard (obfuscation simple), certificate pinning trop facilement retrouvable, clavier virtuel réimplémenté (WTF) par les appli bancaires, opérations faciles à récupérer, …
  

Il nous a ainsi prouvé qu’avec différentes techniques on peut retrouver où se situe dans le code le clavier virtuel, le certificate pinning, etc. On peut retrouver des patterns et trouver des appli bancaires qui partent du même code légèrement modifié, ce qui facilitera l’exploitation d’une même faille par exemple.

Conseils :

• Utiliser les options offerts par Android, les outils de protection prévus pour
  
  • Safetynet
  • Verify apps API
  • reCaptcha (anti rejeu)
  • Android Keystore (matériel plus logiciel)
  • Protection de la configuration réseau (Android 7+)
• ne pas réimplémenter sa propre sécurité !

Pause de midi => concours de lockpicking

Je ne vais pas vous embêter avec ce qu’on a mangé mais j’ai trouvé original qu’un tournoi de lockpicking soit organisé pendant les pauses. Le crochetage de serrures est souvent vu comme une compétence complémentaire aux hackers, notamment ceux qui font du social engineering.

Ransomware et déplacement latéraux

Là où les présentations du matin étaient surtout dédiées aux attaquants, la présentation d’André Lenoir de Tehtris était un peu plus orientée « défense ».

André est parti du constat que de nos jours, même les ransomware tentent à minima de passer inaperçus pour au moins passer les gateway email et les antivirus. La furtivité augmente sur toutes les menaces.

Il a rappelé les règles de bases pour organiser correctement sa défense et limiter les dégâts en cas d’attaque

• Utiliser le whitelisting d’applications
• Séparer les rôles des utilisateurs
• Réalisation des mises à jour
• Mise en place de policies (GPO sous Windows)
  
• Restrictions de l’accès aux partages aux seuls utilisateurs autorisés
• Avoir des sauvegardes non accessibles sur le réseau
• Avoir un antivirus à jour avec un bon sandboxing

Bloquer la propagation des ransomwares

Si ces protections ne sont pas suffisantes pour arrêter l’ensemble des attaques, elles permettent d’en limiter la portée. Idem pour les systèmes d’antivirus, qui restent un must have même s’ils ne pourront rien contre un 0 day.

Si on reste dans l’exemple des ransomwares, parmi les protections moins courantes, on a cité l’utilisation d’Honeyfiles déposés sur les postes utilisateurs et les partages réseaux. A la moindre modification, cela peut être le signe d’une attaque et les processus incriminés peuvent être coupés.

On peut également ajouter des seuils de détection d’activité anormale, par exemple sur le CPU ou sur le disque de la machine. Cependant cette méthode est complexe à calibrer et peut nécessite un mode apprentissage avec un humain ou éventuellement via du Machine Learning.

Enfin, André a présenté des travaux intéressants sur la détection des opération de chiffrement via l’entropie des fichiers. Seulement cette technique n’est pas utilisable en l’état car les fichiers compressés ont des entropies très importantes, parfois difficiles à distinguer des fichiers chiffrés (trop de faux positifs selon les algorithmes, forte dégradation des performances de la machine).

Déplacement latéraux

Pour éviter que les infections se propage, on peut limiter les flux d’administration entre les machines des administrateurs et les machines des utilisateurs (ou les serveurs) en ajoutant des gateway centralisant tous les accès et interdisant tout accès distant en dehors de la gateway. Ainsi même si les credentials des administrateurs sont volés, un malware ne pourra pas se propager de machine en machine car seuls les flux de la gateway seront autorisés.

On peut également mettre en place des métriques pour détecter les connexions massives, et si cela arrive isoler le endpoint et bloquer l’utilisateur compromis.

Outils DevOps : de la confiance aveugle des débuts à l’utilisation prudente avec l’âge

Cette présentation présentée par Charles Prost (Scality) a parlé rapidement de 3 sujets que vous avez sûrement vous aussi rencontré en entreprise et les impacts qu’ils peuvent avoir sur la sécurité de vos applications : Offline mode / Ansible / Vagrant&Packer.

Pour la partie « Offline mode », c’est à dire builder une application sans avoir accès à Internet, clairement c’est du vécu ! Entre les dépendances Perl quand on a pas accès à CPAN et les applications front en JS qui tirent 1000 dépendances et 700 Go de données

Il faut donc éduquer les développeurs à figer leurs versions via des dépôts offline pour éviter :

• de télécharger tout l’Internet à chaque build (donc toutes les 10 minutes en DevOps) et d’attiser la colère de l’admin réseau
• que le build plante s’il n’y a pas Internet
• qu’une dépendance disparaisse ou introduise une régression 10 minutes après

Pour la partie Ansible j’ai eu plus de mal à faire le parallèle avec mon expérience car ce qu’il a mis en avant, c’est que les développeurs téléchargent parfois des rôles sans s’inquiéter de ce qu’il y a dedans (et exécutent potentiellement des scripts avec sudo sans les lire). Sincèrement je n’ai jamais travaillé de cette manière et nous avons toujours plutôt réécrit nos propres rôles (parfois en s’inspirant d’existants).

Idem pour Vagrant et Packer dont les images les plus utilisées réalisent des opérations potentiellement dangereuses et dont tout le monde se fiche éperdument et Atlas cloud qui propose d’ajouter un checksum pour certifier une images mais n’en propose pas dans les images les plus usitées.

La sécurité du code est elle une illusion ou une réalité en 2018

Cette dernière présentation était présentée par Stéphane JOURDOIS (Directeur technique) et Jean Philippe GAULIER (Directeur de l’innovation), tous deux chez Digital Security. Elle a été particulièrement ludique, avec des passages en musique (tous les deux sont joueurs) et un humour très caustique (qui m’a fait beaucoup rire) sur les nombreuses failles lorsqu’on déploie du code.

L’idée de la présentation était de prendre les 7 couches qui permettent l’exécution d’une application et de voir que la sécurité était à prendre en compte à tous les niveaux, ce qui est rarement fait par le développeur lambda (avec une faille/CVE pour chaque) :

• CPU
• OS
• Langage
• Bibliothèque
• Framework
• Application
• IPC

Au delà de l’aspect évident de la chose, le message que les deux intervenants ont essayé de faire passer c’est qu’il ne sert à rien d’essayer de trouver un expert capable d’appréhender les problématiques de toutes les couches. Il faut se concentrer sur la création d’équipes pluridisciplinaires.

Un avis qui ne peut que faire sourire quand on voit que pour certains recruteurs, DevOps veut dire « un développeur qui sait aussi gérer les FS full et qui nous permet d’économiser le salaire d’un sysadmin ».

Mining Ethereum the ugly way

Présentée par Florian Gaultier, cette présentation décalée a été l’occasion de parler du principe des Blockchains et en particulier d’Ethereum par rapport à Bitcoin (proof of stake vs proof of work).

Après avoir rapidement brossé le principe de distributed ledger, proof of work et proof of stake, Florian a expliqué le principe des smart contracts (ajout d’un langage Turing complet dans les blocks) et nous a montré quelques exécutions possibles avec Ethereum Virtual Machine et le principe de GAS (du GAS pour chaque instruction, plus le code et complexe, plus il coute à exécuter).

Malheureusement je n’ai pas pu la voir en entier mais je récupèrerai les slides pour mettre à jour l’article. C’était très fun !

Cet article Récap’ du Hack-It-N 2018 est apparu en premier sur Zwindler's Reflection.