CentOS on Zwindler's Reflection

k3os, le reboot de RancherOS à la sauce k3s

Tue, 08 Dec 2020 07:45:00 +0000

k3os, encore un produit Rancher ?

Oui, k3os. Je vais donc ENCORE parler d’un produit de Rancher aujourd’hui, et la raison principale est que cet article est plus ou moins la suite logique des deux précédents sur RancherOS et RKE

Dans Kubernetes avec RancherOS et RKE partie 1, je vous expliquais que j’avais ENCORE changé d’infra et que pour le fun, j’avais souhaité essayer d’installer RancherOS puis RKE, respectivement comme distrib pour mes nodes Kubernetes et comme méthode d’installation de Kubernetes lui même.

Bon, alors d’abord j’ai pas été super convaincu par RancherOS (pas seulement pour mon usage perso, mais aussi plus globalement) et en plus, j’ai découvert grâce aux commentaires que RancherOS était en fait abandonné.

Bummer…

k3s pour mon usecase c’est quand même mieux

Bon en vrai ce n’était pas bien grave, car le but était de tester ces produits dont j’entendais parler depuis un moment. Mais du coup, je n’ai toujours pas de Kubernetes viable pour mes geekeries…

Un des outils qui correspond le mieux à mon usecase, là encore chez Rancher, c’est k3s. Un Kubernetes minimaliste qui prend très peu de ressources et qui est simple à installer.

J’avais d’ailleurs fait quelques articles dessus, notamment pour parler d’un playbook Ansible qui permettait de déployer k3s sur des instances ARM dans le cloud de Scaleway (la bonne époque où ils en proposaient, en tout cas…).

Le code est toujours dispo et n’était pas spécifique à ARM ni à Scaleway, si ça vous intéresse.

Et k3os dans tout ça ?

La méthode d’installation de Kubernetes est donc choisie. Mais ça ne répond pas à la seconde question, à savoir, sur quelle distribution je l’installe.

Je peux l’installer sur n’importe quel OS Linux généraliste (Debian, Ubuntu, CentOS, … you name it), mais le but, c’est quand même d’installer un Kubernetes le plus léger possible (car je suis radin sur les serveurs que je loue et ils sont peu puissants).

Qu’à cela ne tienne, me dis-je ! Pourquoi ne pas retenter l’expérience CoreOS et RancherOS avec k3os ?

Et c’est vraiment une bonne question…

k3OS donc

k3OS is a Linux distribution designed to remove as much OS maintenance as possible in a Kubernetes cluster. It is specifically designed to only have what is needed to run k3s. Additionally the OS is designed to be managed by kubectl once a cluster is bootstrapped. Nodes only need to join a cluster and then all aspects of the OS can be managed from Kubernetes. Both k3OS and k3s upgrades are handled by the k3OS operator. github.com/rancher/k3os

k3os est donc une distribution optimisée par Rancher pour fonctionner avec k3s et consommer le moins de ressources possibles.

Les avantages mis en avant sont que dès que l’OS est installé, on a un Kubernetes fonctionnel puisque k3s est préinstallé et configuré à l’install de l’OS.

L’autre avantage mis en avant est que tout la gestion du cycle de vie de l’OS est piloté à l’aide d’un operateur dans Kubernetes (k3OS operator) qui va nous permettre de gérer l’OS depuis Kubernetes directement.

Mkay, pourquoi pas.

Et c’est reparti pour un tour

Même procédure que pour l’article sur RancherOS, les principes sont très similaires. On va télécharger une image iso, créer une VM et se connecter dessus en liveCD pour installer l’OS sur le disque.

La page des releases est ici : github.com/rancher/k3os/releases

cd /var/lib/vz/template/iso
wget https://github.com/rancher/k3os/releases/download/v0.11.1/k3os-amd64.iso

To copy k3OS to local disk, after logging in as rancher run sudo k3os install. Then remove the ISO from the virtual machine and reboot.

STOOOOOP

Exactement comme dans l’install de RancherOS, si vous partez bille en tête vous risquez de tomber sur un OS (ahah).

Dans l’article précédent, j’avais fait l’andouille et lancé la commande, pour me rendre compte qu’une fois installé, je n’avais ni réseau, ni clé SSH pour me connecter sur l’utilisateur rancher post install.

En vrai, tout doit se faire via cloud-config…

Bon, pour être honnête, cette fois-ci, ils ont quand même un peu plus prévu le coup. Si vous ne fournissez pas de cloud-config, cette fois-ci k3os vous propose de rentrer un mot de passe pour votre rancher.

Mais vous n’aurez pas plus de réseau si comme moi vous n’avez pas mis de DHCP sur votre LAN (cf aparté pour les bolosses qui n’ont pas de DHCP plus tard dans l’article).

cloud-config

Partons donc pour l’instant du principe que vous avez un DHCP et que vous aurez donc, une fois k3OS installé, accès réseau à votre machine.

Proxmox a la bonne idée de permettre la création de volume cloud-init directement depuis l’UI.

Cependant, j’ai bien l’impression que le format du cloud-init de Proxmox ne correspond pas au format attendu par k3OS…

OK, je suis pas fâché.

On va donc devoir le faire à la mimine et ça tombe bien, car on a ENCORE le souci du clavier Qwerty/Azerty… (cf Bonus Qwerty), ce qui est parfait pour copier à la main une clé SSH, c’est bien connu.

Vous l’aurez compris, on va s’en sortir une fois de plus avec un port série et la console de type xterm.js…

Grosso modo, mon cloud config s’est limité à ça.

cat > config.yml << EOF
k3os:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQAaaaaaaaaaaaaaaaaaaaaaaaaaaaOF0lZiHOjIZ/27aaHmNTq27Vws2dhzJ9 rancher
EOF

Tout ça pour ça me direz-vous ? Oui…

Mais bon, une fois qu’on a ça, on peut passer à l’install elle-même, qui est en fait un mini installeur qui vous pose quelques questions un peu triviales comme « rôle du node », « token », « chemin de la clé SSH ».

k3os-15121 [~]$ sudo k3os install
Running k3OS configuration
Choose operation
1. Install to disk
2. Configure server or agent
Select Number [1]:
Config system with cloud-init file? [y/N]: y
cloud-init file location (file path or http URL): config.yml
[...]

Ces valeurs peuvent d’ailleurs être ajoutées au cloud-config pour vous permettre d’automatiser la totalité de l’opération.

A l’issue de l’opération… magie ! vous aurez un Kubernetes tout neuf et tout léger :)

Aparté pour les bolosses qui n’ont pas de DHCP (aka. moi)

Ça aurait été plus simple de monter un petit serveur DHCP vite fait mais je suis têtu comme pas deux.

La blague avec k3OS est que, contrairement à RancherOS, il n’est tout simplement pas possible d’installer l’OS en lui spécifiant l’adresse réseau physique qu’il devra avoir post install.

En fait au début, j’avais copié ce que j’avais fait pour RancherOS. L’installeur de k3OS ne râle pas, mais il ignore simplement le code en trop.

Et vous ne pourrez plus vous connecter…

Mais comme je suis têtu (je me répète), j’ai cherché à tout prix la solution.

L’idée ici est de feinter l’installeur en ne lui donnant PAS de cloud config. On garde ainsi la possibilité de se loguer à l’utilisateur rancher avec un mot de passe (pas bien ça…).

Une fois k3OS installé, on se connecte une nouvelle fois en console (oui, on risque pas de le faire en SSH…) et on configure la carte réseau.

k3OS est un dérivé d’Alpine (pour les binaires userspace) avec le kernel d’Ubuntu 20.04 (oh…kay ?).

Pour setter le réseau, vous pouvez donc faire :

sudo connmanctl services
*AR Wired ethernet_c6eb50d8c655_cable

Cette commande vous renvoie le nom de la carte réseau virtuelle. Vous pouvez maintenant regarder la configuration par défaut

sudo connmanctl services ethernet_c6eb50d8c655_cable
/net/connman/service/ethernet_c6eb50d8c655_cable
Type = ethernet
Security = [ ]
State = ready
Favorite = True
Immutable = False
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=eth0, Address=C6:EB:50:D8:C6:55, MTU=1500 ]
IPv4 = [ Method=auto, Address=169.254.126.16, Netmask=255.255.0.0 ]
IPv4.Configuration = [ Method=auto ]
IPv6 = [ ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ 8.8.8.8 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]

Grande classe. 8.8.8.8 en DNS… No comment.

Et setter votre carte réseau post installation avec cette dernière commande (à remplacer par vos valeurs à vous, hein) :

sudo connmanctl config ethernet_d2416991aa5b_cable --ipv4 manual 192.168.1.15 255.255.255.0 192.168.1.1 --nameservers 192.168.1.1

Conclusion

Bon je crois qu’il est temps d’arrêter de se faire du mal…

Oui clairement, je me suis mis dans un exemple un peu foireux. Tout le monde de normalement constitué dispose d’un DHCP de nos jours. Surtout que k3OS cible les usages de k3s, à savoir le edge et l’IoT.

Mais du coup, j’ai l’impression qu’on est vraiment dans le marché de niche de la niche : un OS optimisé pour l’IoT ou l’edge uniquement. Je ne suis clairement pas ciblé par k3OS.

Ça ne m’a pas vraiment donné envie de regarder plus en détails la partie k3OS operator, qui permet de gérer les mises à jours de l’OS depuis Kube.

La documentation sur le sujet est disponible ici et ça a l’air d’avoir beaucoup bougé entre la v0.9, la v0.10 et la v0.11, puisqu’il y a des exceptions dans tous les sens…

github.com/rancher/k3os#upgrade-and-maintenance

Bref… il est temps que je m’installe un bête OS généraliste…

Récupérer les informations sur la distribution avec les facts Ansible

Wed, 21 Nov 2018 12:45:40 +0000

Les facts d’Ansible

Si vous suivez le blog, vous savez que j’utilise énormément Ansible. J’ai même été faire un talk sur le sujet à BDX I/O 2018, à l’ENSEIRB.

Aujourd’hui, plutôt que de vous donner un playbook tout fait pour installer sans effort une des multiples applications dont j’ai automatisé le déploiement avec Ansible, je vous propose d’explorer une des features les plus importantes et utiles d’Ansible, les facts, par le biais d’un petit exemple.

C’est quoi les facts dans Ansible

Si vous avez déjà lancé un playbook, vous avez sûrement remarqué lors de son exécution, que la première tâche qui est réalisée n’est pas une tâche que vous avez demandée explicitement.

ansible-playbook -i inventory/prod/blop -u blop --private-key=blop.key configure-blop.yml
[...]]
TASK [Gathering Facts] *********************************************************
ok: [blop-vm1]

Cette tâche [Gathering Facts], qui ne fait à première vue rien, correspond en fait à la connexion à la ou les machines sur lesquelles seront exécutées les playbooks. Si la connexion échoue, le playbook échouera sur cette cible, et continuera éventuellement sur les autres (s’il en reste). Si l’hôte répond, alors Ansible en profite pour récupérer moult informations en rapport avec cette machines et les stockent dans une variable ansible_facts.

A quoi ça ressemble ?

Comme je ne disais, à première vue, cette commande de fait rien. Si on ne sait pas qu’elle stocke des informations dans une variables, on ne peut rien en faire.

Un bon moyen d’avoir un premier aperçu de ce qu’on peut en faire est de les afficher. On peut faire ça avec le module « setup », qui est en réalité le même module qui est appelé lors de l’étape [Gathering facts].

Le retour se fera au format JSON, ce qui est certes peu digeste, mais facilitera grandement les manipulations de type « filtre » (via le flag filter intégré ou via l’utilitaire jq par exemple).

ansible blop-vm1 i inventory/prod/blop -m setup
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"10.1.1.10"
],
"ansible_apparmor": {
"status": "enabled"
},
[...]

Je ne vous copie-colle pas tout, rien que pour cette machine, j’ai 719 lignes… La quantité d’informations disponible est impressionnante, et on peut même en venir à se demander à quoi ça va bien pouvoir nous servir.

Ok, on en fait quoi ?

Du coup je profite de cet article pour faire un tuto tout simple et qui peut être utile dans de nombreux cas, réaliser des opérations différentes en fonction de la distribution de la machine concernée.

L’information qui va nous intéresser ici concerne donc les remontées en tant que « nom » ou « version » d’une distribution. Je vais vous économiser la lecture de nos 700+ lignes, et vous indiquer que vous pouvez trouver ces informations en filtrant sur les mots clés « ansible_distribution… » et « ansible_os… »

Voilà ce qu’on pourrait obtenir sur une machine CentOS :

ansible blop-vm1 -m setup -a 'filter=ansible_distribution*'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
"ansible_distribution_release": "Core",
"ansible_distribution_version": "7.2.1511"
},
"changed": false
}
ansible blop-vm1 -m setup -a 'filter=ansible_os_family'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "RedHat"
},
"changed": false
}

Et sur une machine Ubuntu :

ansible blop-vm2 -m setup -a 'filter=ansible_distribution*'
ansible blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "Ubuntu",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "16",
"ansible_distribution_release": "xenial",
"ansible_distribution_version": "16.04"
},
"changed": false
}
ansible blop-vm2 -m setup -a 'filter=ansible_os*'
blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "Debian"
},
"changed": false
}

Utiliser les facts dans un playbook

Pour continuer dans l’exemple, on va faire une chose qu’il ne faut jamais faire : désactiver le firewall et SELinux.

Imaginons que vous souhaitiez quand même le faire. Si vous lancez ce playbook sur tout votre parc et qu’il n’est pas homogène, vous allez tomber sur des groupes de machines Ubuntu, CentOS 5, 6, 7…

Un moyen de gérer les cas particuliers pourrait être de les classer tous vos hosts dans des groupes, et de créer un playbook pour chaque OS/version, restreint à un groupe de machines uniquement.

---
- hosts: rhelcentos6only
tasks:
[…]

Ce n’est d’ailleurs pas une mauvaise idée, surtout pour gérer les distrib aussi différentes que RHEL et Ubuntu par exemple.

En revanche, dans le cas de RHEL, on a des différences qui apparaissent à partir de la RHEL 7, notamment la gestion du Firewall qui passe de IPtables à firewalld.

On va donc faire appel à la clause when: de ansible, qui conditionne l’exécution d’une tâche (ou d’un rôle ou d’un block) à une validation. Et ça donnerait quelque chose comme ça :

---
- hosts: rhelcentos6only
tasks:
- name: "shutdown and disable IPtables for RHEL <= 6"
service:
name=iptables
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version <= "6")
- name: "shutdown and disable firewalld for RHEL >= 7"
service:
name=firewalld
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version >= "7")
- name: "disable selinux"
selinux:
state=disabled

Dans cet exemple, lors de l’exécution du playbook, on aura donc, pour chaque VM CentOS ou RHEL, une tâche qui sera exécutée, et l’autre qui sera marquée « skipping » (en bleu clair) et le playbook marchera pour toutes les RHEL, quelque soit leur version.

Aller plus loin

Il existe une page spécifique sur la documentation d’Ansible pour parler des conditions dans les playbooks, accessible à l’adresse suivante : https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_conditionals.html

Vous pouvez aussi utiliser les facts dans les options des tasks, et dans les templates, en encadrant le nom de la variable souhaitée avec des « doubles curly braces » : {{ xxx }}

- command: "echo {{ ma_super_variable }}"

Sources

Installation xwiki 10.6.1 via un playbook Ansible

Wed, 05 Sep 2018 11:45:00 +0000

Ansible + XWiki

Je sais ce que vous vous dites :

Ça fait longtemps que zwindler n’a pas écrit un article sur Ansible ou XWiki !

Non ? Vous ne vous dites pas ça ? Bon tant pis c’est pas grave. Aujourd’hui, je rédige ENFIN l’article pour parler d’un playbook que j’ai déjà rédigé il y a presque un an déjà (et mis à jour et déployé de nombreuses fois). C’est dire si j’ai du retard dans les articles du blog…

Petit rappel des épisodes précédents

J’ai déjà rédigé de manière extensive sur XWiki qui est un belle solution open source de gestion de la connaissance. Parmi les articles les plus susceptibles d’intéresser, il y a déjà :

Il y en a plein d’autre (voir ici).

Et Ansible ?

Et bien oui. Je vous rabâche aussi les oreilles avec Ansible, l’Infrastructure as Code, et l’Idempotence. (Là encore, il y en a plein)

Alors pourquoi pas un playbook Ansible pour automatiser l’installation de XWiki, si vous n’avez pas de cluster Kubernetes sous la main et que vous êtes un Gaulois réfractaire à Docker ?

Ya quoi dans ton playbook ?

Trêve de suspense, les sources sont disponibles sur Github à cette adresse.

Ce playbook a été testé pour des RHEL/CentOS 7, en particulier de la version 7.2 jusqu’à 7.4. Une installation de RHEL/CentOS en mode minimale, même sans environnement graphique, devrait être suffisante. Je l’ai faite tourner en production sur des environnements Desktop dans des VMs, mais aussi en Minimal sur un container LXC dans Proxmox VE sans aucun souci.

L’installation n’utilise pas les serveurs web et de bases de données par « défaut » (MySQL), mais Tomcat 8 et PostgreSQL. Pour la version de Tomcat, c’est une version très particulière qu’il faut utiliser car des bugs ont étés introduits dans une version, puis RE-introduits quelques mois plus tard. Vous pouvez modifier la version par défaut qui est une variables de mon playbook (8.5.32) si elle ne vous convient pas. Les instructions d’installation se basent sur la documentation officielle.

- tomcat_version: 8.5.32

Vous pouvez également modifier la version de XWiki directement dans le playbook (c’est une variable là aussi) :

- xwiki_version: "10.6.1"

A noter, les vielles versions de XWiki n’étaient pas hébergées sur le même dépôt, qui a changé récemment, d’où les deux URLs dans le playbook.

Prérequis

On va utiliser git pour récupérer le playbook et ansible (version de l’OS, rien d’exotique).

yum install ansible git
git clone https://github.com/zwindler/ansible-deploy-xwiki-tomcat-postgresql
cd ansible-deploy-xwiki-tomcat-postgresql

Quand est ce qu’on installe XWiki ?

Maintenant !

Sur un poste qui dispose de git et Ansible :

ansible-playbook -l localhost ansible-deploy-xwiki-tomcat-postgresql.yml

Le playbook devrait vous prompter pour un mot de passe pour l’utilisateur de base de données PostgreSQL, n’hésitez pas à mettre quelque chose de complexe. Vous ne devriez pas en avoir besoin.

Si vous avez une erreur qui vous dit que localhost est ignoré, vous pouvez l’ajouter à votre fichier d’inventaire global : /etc/ansible/hosts

sudo vim /etc/ansible/hosts
[local]
localhost ansible_connection=local

Et Paf ! Vous avez un XWiki installé, disponible à l’adresse http://@IP:8080/. Il n’y a plus qu’à le configurer :)

Hack : diminuer la taille du VMDK d’une VM Linux LVM

Wed, 14 Mar 2018 12:45:43 +0000

Réduire un VMDK

Note : cet article n’est pas écrit par moi mais par mon ami et ancien collègue Steve aka ventreachoux85 (ahahah faut assumer maintenant Steve), que j’héberge avec grand plaisir sur le blog :-)

Note 2: Comme toute opération sur des disques, des partitions, des filesystems, elles sont à faire avec des backups préalables. Cette opération est dangereuse et est à vos risques et périls => vous voilà prévenus.

Sur un serveur Linux (CentOS 6.9 pour la petite histoire) hébergé sur un serveur VMware, je souhaite réduire la taille de mon disque virtuel de 75 Go car la volumétrie ne va pas bouger. S’il est simple d’agrandir un disque virtuel sous VMware, le réduire est une autre paire de manches !

Si la machine avait été un serveur Windows, voilà ce que j’aurai fais :

Réduction du volume depuis l’utilitaire de gestion de disques
Modification de l’extent description directement sur le fichier .vmdk depuis l’ESXi (en SSH)
Migration de la VM sur un autre datastore => elle aurait eu la taille voulue à l’issue de l’opération

Je ne détaille volontairement pas cette procédure car celle qui suit est similaire et nous allons prendre le temps de tout voir.

Et donc du coup, là c’était pas pour des windows, mais pour des machines sous Linux ! J’ai demandé son avis à zwindler, qui m’a demandé en échange de rédiger une petite procédure pour le blog ;-)

Réduction du FS

Voilà donc à quoi ressemble les disques de mon serveur avant l’opération :

Dans mon cas, je n’ai pas besoin de réduire les Filesystems, j’ai déjà beaucoup de PE de disponibles. S’il avait fallut le faire, on aurait été obligé de réduire les FS à froid (dans le cas ext*), voire même de passer par un liveCD si on avait du redimensionner « / » ou un autre FS vital pour l’OS.

Réduire un VMDK partitionné pour du LVM

Le problème avec la commande pvs est que la taille utilisée et la taille disponible est arrondie pour être au format « human readable » d’Unix. Idéalement, il nous faut une mesure exacte pour redimensionner au plus juste.

Une des manières simples de le faire est d’utiliser l’unité « secteur » de la commande pvs (512 octets). Il faut faire la différence entre le PSize et le PFree pour avoir la taille définitive du disque :

Après un rapide calcul, si je veux réduire le disque de tous les PE disponibles :

209453056 – 164757504 = 44695552

La nouvelle taille du PV sera de 44965552 secteurs

Note de zwindler : Personnellement j’aurai laissé quelques PE, par habitude (limitations de LVM1 pénibles quand il n’y a plus de PE) et parce que je suis un froussard, mais a priori « ça marche ».

On redimensionne le disque

A noter, malgré le fait qu’on ait spécifié qu’il ne devait pas rester de PE de libre, a priori il en reste quand même quelques uns. Je ne sais pas si c’est une sécurité du pvresize ou si c’est lié aux arrondis et à la taille d’un PE sur ce PV. C’était une erreur de calcul (cf voir les commentaires).

Pour vérifier que tout va bien, un petit pvscan/vgscan.

Réduire la partition

A partir de là, ça se corse. On a réduit sans trop de difficulté le PV qui héberge nos LV, mais il nous reste maintenant à réduire la partition qui héberge ce PV. Même si théoriquement on peut le faire à chaud, zwindler m’a conseillé de faire ça à froid.

Pour autant, si vous vous sentez l’âme d’un aventurier et/ou avec un OS récent et/ou que vous n’avez pas le choix, vous pouvez toujours aller lire ce post sur Ask Ubuntu.

Le plus safe est quand même d’arrêter la VM puis booter sur un liveCD avec GParted.

Clic droit sur la partition à modifier – désactiver (sinon impossible de la redimensionner)

Sélectionner la partition puis Redimensionner / Déplacer

Attention : lors du premier redimensionnement, GParted ne prend ne réduit pas au maximum la partition. Il reste 2 Go qui sont inutilisés.

On lance un nouveau redimensionnement pour récupérer la place disponible !!

Note de zwindler : moi j’aurai laissé comme ça ;-)

ATTENTION

On voit que /dev/sda2 fait 21.44 Go après le pvresize (cf. screenshot précédent). En essayant de réduire au maximum la place utilisée, on peut tout casser (expérience vécue !!!). Pour plus de sécurité, je conseille de resizer à l’entier supérieur (donc dans notre exemple 22 Gio soit 22528 Mio)

Redimensionner le VMDK

Maintenant que le disque est modifié au niveau de l’OS, il faut le redimensionner au niveau de VMware.

Et là, rebelote : c’est pas « simple » à faire. En effet, VMware ne supporte pas la réduction des VMDK (que ce soit à chaud ou à froid).

Note: You cannot shrink virtual disks using vmkfstools in ESXi as the hypervisor is not aware of the file system layout and cannot ensure a safe shrink operation.

Heureusement, des petits malins ont trouvés la technique depuis bien longtemps :

Se connecter en SSH sur l’ESX qui héberge la VM, se rendre dans le dossier de la VM et faire un vi sur le fichier NomVM.vmdk, qui est un fichier texte (configuration), contrairement au fichier NomVM-flat.vmdk qui contient les données réelles.
Modifier la valeur suivante :

# Extent description
RW 209715200 VMFS "testsba-flat.vmdk"

La nouvelle valeur du paramètre extent description sera « 22 GB = 22 x 1024 x 1024 x 1024 / 512 (octets/secteur) = 46137344 secteurs »

# Extent description
RW 46137344 VMFS "testsba-flat.vmdk"

Déplacer la VM vers un autre Datastore

A partir de là, vous vous dites : « cool ! j’ai récupéré l’espace disque ». Et vous êtes déçus car rien ne se passe.

En effet, ce paramètre n’est pris en compte que lors de la création du disque, lorsque le fichier contenant réellement les données (le fameux NomVM-flat.vmdk dont je vous ai parlé plus tôt) est créé. Vous pouvez mettre n’importe quoi, ça ne changera rien du tout.

Cependant, si vous avez la licence qui va bien sur votre cluster, vous pouvez feinter le cluster pour lui faire recréer un disque à chaud de la bonne taille avec un simple Storage vMotion.

Avant le Storage vMotion :

Après le Storage vMotion :

Pourquoi ça marche ?

Petit aparté de zwindler : Pour bien comprendre ce qu’il se passe, il faut comprendre comment marche un Storage vMotion. Au moment où vous demandez à VMware de déplacer un disque d’un datastore à l’autre, voici l’enchaînement des opérations :

Prise d’un snapshot du disque initial
Création d’un disque sur le datastore cible. Ce disque est identique au disque initial au moment du snapshot via la commande vmkfstools. Cette commande relis la valeur contenu dans extent description pour savoir quelle taille le fichier doit faire physiquement, ce qui nous permet de feinter VMware et d’avoir un disque à la bonne taille._
_
L’ensemble des IO depuis le snapshot sont écrites simultanément sur les deux datastores, ce qui permet d’avoir 2 copies identiques au moment de la fin de la copie du snapshot
Migration de la VM sur le nouveau disque
Suppression de l’ancien disque hébergé par l’ancien datastore

Note de zwindler : j’étais persuadé d’avoir fais un article là dessus (et en fait pas du tout) mais il est évidemment possible de faire la même chose à la main sans Storage vMotion, simplement avec vmkfstools à la main.

Boot de la machine

Pour finir, une fois la VM bootée, il reste encore une petite opération de maintenance à réaliser. Il y a une petite différence de nombre de secteurs suite au redimensionnement.

Il suffit de faire un pvresize avec le nombre de secteurs indiqué par la commande pvs précédente :

Tout est dorénavant OK :

Installer un cluster Kubernetes sur des VMs CentOS 7

Wed, 07 Jun 2017 12:00:53 +0000

Kubernetes, c’est quoi ça ?

Dans cet article, je vais vous guider pour installer pas à pas un cluster Kubernetes sur des serveurs CentOS/RHEL 7. Attention cet article est un gros morceau !

Pour ceux qui ne connaissent pas Kubernetes, il faut savoir que c’est un des leaders dans le domaine des orchestrateurs de containers Docker ou Rkt.

Un bel empilage de couches, pour au final exécuter des applications dans des containers LXC (ou Windows)

Pour ce qui est de la genèse de Kubernetes, c’est un outil dont le code provient de Borg d’un outil maison de chez Google. Au bout de 10 ans d’utilisation, quand les containers Linux ont commencés à percer, le code source a été légué en 2015 à la CNCF (Cloud Native Computing Foundation). L’outil est donc maintenant open source.

Sa couverture fonctionnelle est (pour l’instant) supérieure à celle de Docker Swarm, notamment grâce à :

une gestion de la multitenancy via les namespaces
une gestion des secrets (bien que limitée)
une gestion des replicas pour un même container, avec scale-up/down
une gestion native du loadbalancing
une gestion des rolling upgrades
…

Un article sympa d’Octo résume pas mal l’écosystème et la guerre qui fait rage dans ce domaine.

Prérequis

Avant de commencer le tutoriel, il faut déjà avoir une bonne connaissance de l’écosystème de la containerisation (sujet sur lequel j’ai écris quelques articles mais qui est bien plus vaste que ça!).
Il faut savoir que Kubernetes est aussi un outil assez complet mais complexe, avec ses propres concepts et sa terminologie associée. Je vous conseille d’abord de vous familiariser avec ces concepts sur un des tutos de Digital Ocean (ils sont souvent très biens fait).

Pour ceux qui sont extrêmement pressés, on peut dire brièvement que, dans la terminologie Kubernetes :

un Node est un serveur qui exécute les applications
le Kubelet est un service (au sens démon) présent sur tous les nodes qui leur permet de discuter et de recevoir les ordres
un Pod, généralement décrit comme « la plus petite unité de traitement de Kubernetes ». Il est composé d’un ou plusieurs containers et on le caractérise généralement comme « une application »
un Service représente un répartiteur de charge qui est conscient de la présence d’un ensemble de containers (backend) et qui permet de rediriger les flux entrants vers eux
un Deployment est un ensemble de sous éléments (comme les Pods et les Services, mais aussi d’autres que je ne présentent pas) qui permet de déployer une application avec toutes ses caractéristiques (volumes, secrets) et ses contraintes (nombres de réplicas)
toutes les interactions avec Kubernetes se font avec une seule commande : kubeadm

Source : kubernetes.io

Solutions de déploiement

D’abord, la première chose à dire est qu’il existe de nombreuses manières de déployer Kubernetes qui a donc créé un page dédiée à centraliser l’ensemble des solutions possibles. Et elle est longue !

Ceci n’est qu’une fraction des solutions actuellement proposées sur le site. Ça ne rentre pas sur mon écran 29 pouces…

Dans mon cas, je suis parti du plus simple pour moi, avec les ressources que j’ai à disposition, c’est à dire 2 machines virtuelles sous CentOS 7.3 :

controlplane01 : 192.168.100.100
worker01 : 192.168.100.101

Pour autant, les solutions avec Vagrant ou sur des clouds publics sont aussi des solutions valables pour commencer si vous maitrisez ces outils. Je vous laisserai regarder la documentation associée si ça vous intéresse.

A noter, en fonction de la solutions choisie, il existe aussi des considérations réseaux à avoir, et elles sont documentées ici.

Le plus simple : Minikube

Je ne vais pas m’attarder sur cette méthode mais celle qui me semble vraiment la plus simple si vous voulez commencer rapidement à jouer avec Kubernetes est d’utiliser minikube. Elle utilise de la virtualisation pour déployer l’environnement Kubernetes de manière automatisée sur votre poste et ça fonctionne très bien.

minikube start
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...

La solution de l’article : Utiliser Kubeadm

On ne va pas se le cacher, installer Kubernetes à la main est complexe. Tellement complexe qu’il existe de nombreuses méthodes clé en main pour automatiser le processus.

La solution que je vous présente ici est un script qui package l’installation des différents composants de Kubernetes. Ces composants sont en fait containerisés pour faciliter leur déploiement.

La documentation officielle de cette méthode est disponible à l’adresse suivante.

Configuration des dépôts

Sur les deux nœuds

A noter : Dans le cas où vous ne disposeriez pas d’un serveur DNS en propre, le plus simple est de configurer sur vos deux machines leurs noms complets dans le fichier « hosts ». Cela vous évitera des bugs et effets de bords.

echo "192.168.100.100 controlplane01.example.org
192.168.100.101 worker01.example.org" >> /etc/hosts

Configurer les repositories officiels :

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
#yum install -y yum-utils
#yum-config-manager \
# --add-repo \
# https://download.docker.com/linux/centos/docker-ce.repo

J’ai volontairement commenté l’ajout du dépôt de Docker car à date, la dernière version de Kubernetes n’a pas encore complètement validé les dernières versions de Docker (celles depuis le grand renommage, qui sont sur le modèle YY.MM comme la 17.03). C’est pourquoi j’utilise dans ce tutoriel la version packagée par mon OS, la 1.12.6.

SELinux

A l’heure actuelle, SELinux est mal supporté par kubelet, le client de Kubernetes présent sur chaque machine. Il est donc malheureusement nécessaire de désactiver cette sécurité pour pouvoir utiliser Kubernetes, pour l’instant.

Disabling SELinux by running setenforce 0 is required in order to allow containers to access the host filesystem, which is required by pod networks for example. You have to do this until SELinux support is improved in the kubelet.

Il se peut aussi que le firewall pose des problèmes s’il est activé et mal configuré

firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly

Dans le cadre d’un PoC, on pourra éventuellement se permettre de désactiver le firewall et SELinux si on estime que l’environnement est suffisamment sécurisé. C’est bien entendu hors de question pour tout autre environnement non éphémère !

setenforce 0
vi /etc/selinux/config
[...]
SELINUX=disabled
systemctl disable firewalld
systemctl stop firewalld

Installation des packages

Comme dit plus haut, j’installe la version Docker de l’OS et non la dernière version. Dans les versions suivantes, Kubernetes aura probablement rattrapé ce retard (si ce n’est pas déjà le cas). On termine par démarrer Docker puis le démon kubelet.

yum install -y docker kubelet kubeadm kubectl kubernetes-cni
#yum install -y docker-ce kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker && systemctl start docker
systemctl enable kubelet && systemctl start kubelet

Initialisation du cluster

Sur le controlplane

Maintenant que les prérequis sont installés, on peut démarrer Kubernetes. L’ensemble des commandes de Kubernetes utilise le binaire kubeadm et la première à utiliser est kubeadm init.

Attention cependant, la commande kubeadm init peut nécessiter des arguments complémentaires en fonction du fournisseur de réseau qui sera choisi.

kubeadm init
#ou
kubeadm init --pod-network-cidr 10.244.0.0/16 #Si on utilise flannel
#ou
kubeadm init --pod-network-cidr=192.168.0.0/16 #Si on utilise Calico

Si vous avez un proxy chez vous, n’hésitez pas d’exporter la variable http_proxy et à configurer docker pour l’utiliser (voir ce thread sur stackoverflow).

export http_proxy=http://@IP_proxy.zwindler.fr:8080/
export no_proxy=localhost,127.0.0.0,[@IP_control_plane]
mkdir /etc/systemd/system/docker.service.d
cat > /etc/systemd/system/docker.service.d/http-proxy.conf << EOF
[Service]
Environment="HTTP_PROXY=http://@IP_proxy.zwindler.fr:8080/"
EOF
systemctl daemon-reload
systemctl restart docker

On termine l’initialisation côté serveur controlplane avec les commandes suivantes (indiquées dans le retour donné par le kubeadm init) :

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

A noter, en toute fin de retour, kubeadm nous donne la ligne de commande nécessaire pour ajouter des nœuds supplémentaires au cluster via un token. Copiez et conservez cette partie pour plus tard. NE PAS LE FAIRE MAINTENANT !

#You can now join any number of machines by running the following on each node
#as root:
# kubeadm join --token <token> <ip_controlplane>:6443

A partir de là, le cluster va s’initialiser et déployer tous les containers nécessaires. Cela peut prendre un certain temps et certains containers peuvent passer par un état Fail, mais au final tout doit être dans l’état « Running », à l’exception des kube-dns*.

kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-controlplane01.example.org 1/1 Running 0 13m
kube-system kube-apiserver-controlplane01.example.org 1/1 Running 0 12m
kube-system kube-controller-manager-controlplane01.example.org 1/1 Running 0 13m
kube-system kube-dns-3913472980-gnt72 0/3 Pending 0 13m
kube-system kube-proxy-4m1nd 1/1 Running 0 13m
kube-system kube-scheduler-controlplane01.example.org 1/1 Running 0 13m

Vérifiez la présence du controlplane avec la commande :

kubectl get nodes
NAME STATUS AGE VERSION
controlplane01.example.org NotReady 12m v1.6.2

A noter : Le Nœud restera à NotReady tant que les containers « kube-dns- » ne seront pas démarrés. Or, les « kube-dns- » ne démarreront pas tant que la configuration des « Network Pods » n’est pas faite (on va voir ça plus loin), ce qui est donc normal pour l’instant.

« waiting for the control plane to become ready » qui ne rend jamais la main

En cas de blocage sur l’étape « [apiclient] Created API client, waiting for the control plane to become ready« , vérifier les logs dans /var/log/messages.

Apr 26 16:27:58 controlplane01 kubelet: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
Apr 26 16:27:58 controlplane01 systemd: kubelet.service: main process exited, code=exited, status=1/FAILURE
Apr 26 16:27:58 controlplane01 systemd: Unit kubelet.service entered failed state.
Apr 26 16:27:58 controlplane01 systemd: kubelet.service failed.

Ceci est du à un bug de kubeadm sur CentOS.

Il n’y a pas vraiment de solution à partir de là. On ne peut pas utiliser « kubeadm reset » pour désinstaller proprement car cela supprime le fichier 10-kubeadm.conf, celui qui doit être corrigé/modifié.
La seule possibilité d’est d’interrompre le processus « kubeadm init », de modifier le 10-kubeadm.conf puis de recommencer.

[CTRL-C]
sed -i 's#Environment="KUBELET_KUBECONFIG_ARGS=-.*#Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --cgroup-driver=systemd"#g' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl daemon-reload
systemctl restart kubelet
#Puis relancer
kubeadm init #--pod-network-cidr 10.244.0.0/16
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.2
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.03.1-ce. Max validated version: 1.12
[preflight] Some fatal errors occurred:
/etc/kubernetes/manifests is not empty
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
kubeadm init --skip-preflight-checks
#Là, ça devrait fonctionner

Taint node

Par défaut, Kubernetes n’utilise pas le controlplane pour faire tourner des pods. Si vous voulez changer ce comportement, on peut le faire avec la commande suivante :

kubectl taint nodes --all node-role.kubernetes.io/controlplane-

Configuration des Network Pods

La première chose à configurer sur le cluster est le « Network Pod ». On a le choix entre un certain nombre de modules, dont la liste est disponible sur cette documentation.

Flannel

La configuration la plus couramment utilisée semble être flannel (de CoreOS), donc le fichier de configuration yaml est disponible sur Github

Sur le controlplane

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
serviceaccount "flannel" created
configmap "kube-flannel-cfg" created
daemonset "kube-flannel-ds" created

Calico

On peut aussi essayer Calico. Personnellement j’ai eu des disfonctionnement avec la version Flannel et donc j’utilise Calico.

Sur le controlplane

kubectl apply -f http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
clusterrolebinding "calico-cni-plugin" created
clusterrole "calico-cni-plugin" created
serviceaccount "calico-cni-plugin" created
clusterrolebinding "calico-policy-controller" created
clusterrole "calico-policy-controller" created
serviceaccount "calico-policy-controller" created

Les pods pour le réseaux se créent. Vérifiez que tout a bien fonctionné avant d’ajouter des nœuds dans le cluster :

kubectl get pods --all-namespaces

Ajout de nœuds supplémentaires

A partir de cette étape, le cluster Kubernetes fonctionne réellement, tous les composants sont opérationnels, à ceci près que c’est un cluster avec seulement une machine. On peut donc maintenant intégrer les machines supplémentaires.

Récupérez la commande avec le token que vous avez conservé précédemment (lors du kubeadm init) et exécutez la sur le nœud « worker ».

Sur le worker

kubeadm join --token <token> 192.168.100.100:6443

Si on obtient l’erreur suivante, il faut ajouter 2 lignes dans le fichier « sysctl.conf » et appliquer la modification.

[preflight] Some fatal errors occurred:
/proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
echo "net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p

Sur le controlplane

Vérifier la présence du controlplane et de son worker avec la commande kubectl :

kubectl get nodes
NAME STATUS AGE VERSION
worker01.example.org NotReady 1m v1.6.2
controlplane01.example.org Ready 33m v1.6.2

Déployer la console web

Bravo, votre cluster Kubernetes fonctionne !

Un bon moyen de débuter est d’installer la WebUI de Kubernetes. Comme tout le reste sur Kubernetes, elle se déploie simplement avec un fichier YAML. La documentation officielle est disponible à cette adresse.

# Add kubernetes-dashboard repository
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
# Deploy a Helm Release named "kubernetes-dashboard" using the kubernetes-dashboard chart
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard

La console est déployée. Elle est accessible de 2 manières.

kubectl proxy

Cette sous commande kubectl permet de faire un tunnel entre le poste depuis lequel la commande est lancée et le serveur exécutant les pods. Cette commande est pratique pour tester les connexions à des pods sans avoir à travailler sur le serveur (depuis son poste par exemple).

Le Dashboard deviendra accessible via l’URL :

http://localhost:8001/ui

Cependant, dans ce cas là, l’interface ne sera disponible que depuis votre poste, ce qui peut ne pas vous convenir.

Via le serveur controlplane

On peut également accéder à la console directement depuis l’URL /ui, qui pointe sur le serveur « controlplane » (controlplane01 dans notre cas).

https://@ip_controlplane]/ui

La console demandera un login/mdp que l’on peut retrouver avec kubectl

kubectl config view

Le mot de la fin

Ça y est, vous savez tout.

Vous êtes maintenant en mesure de déployer vos premières applications avec Kubernetes, et vous amuser à Scale-up & scale-down, faire des rolling upgrades, tester la haute disponibilité et la répartition de charge !

Have fun :)

Hacker un calendrier javascript (datepicker) avec un scraper python

Tue, 09 May 2017 12:00:26 +0000

Mais quel rapport entre un datepicker javascript et un scraper python ?

Si vous ne savez ni ce qu’est un datepicker en Javascript ou un scraper python, je vous ai probablement déjà perdu. Pourtant, dans cet article ultra fun (ok, je suis bizarre), je vous montrerai comme j’ai automatisé via un scraper développé en python la recherche de dates libres dans un calendrier Javascript sur une page web :

en scriptant la génération de cette page via une ligne de commande
en simulant un clic pour passer au mois suivant
et enfin en récupérant les bonnes valeurs (pour me les envoyer par email par exemple)

Commençons donc par un peu de storytelling

Depuis quelques mois, je vais régulièrement sur un site web un peu artisanal sur lequel je fais des réservations. Pour se faire, ce site web propose une page web simple dans lequel a été intégré un composant calendrier :

Rien de particulièrement extraordinaire jusque là.

Mais (car bien sûr il y a un mais), ce site à l’inconvénient d’être victime de son succès. Pour vous donner une idée, c’est le genre de site web qui tombe 30 secondes après l’ouverture des réservations à 19h00. Et que dès que l’administrateur système le relance entre 20 et 50 minutes plus tard, les réservations sont complètes en quelques minutes.

Méthode 1 : F5

La première méthode, probablement plébiscité par la plupart des utilisateurs, est à base de refresh frénétique du site web, jusqu’à ce qu’il devienne inopérant… Une fois que le site est down, on peut continuer à appuyer sur F5 en espérant être le premier quand il reviendra.

Le souci de cette méthode, c’est que je manque cruellement de patience et que je lâche l’affaire assez vite. Et donc tous les mois, les plus hargneux (ou les plus chanceux) me passent toujours devant car j’ai loupé le moment où le site redevient accessible.

Méthode 2 : cURL

En bon administrateur système que je suis, je ne pouvais pas me résoudre à en rester là. Mon problème principal étant d’être prévenu lorsque le site devenait à nouveau opérationnel, j’ai sorti ma boîte à outils habituelle : cURL !

cURL (abréviation de client URL request library), est un outil à tout faire quand on veut jouer avec des URL sur un serveur Linux. C’est simple et efficace.

Dans le cas où le site est tombé suite à la connexion massive des internautes avides de réservations, j’ai donc créé un petit script basé sur ce oneliner

curl http://@IP_ou_FQDN/le_chemin_de_la_page/ -I 2>/dev/null | head -n 1
HTTP/1.1 200 OK

Dès que le code retour passe de 503 à 200, c’est que le site web est de nouveau accessible et je peux me remettre à faire F5 en espérant que les réservations ouvrent.

Méthode 2bis : aller plus loin avec cURL

Bon… La méthode précédente fonctionne… mais ce n’est pas encore ça !

Typiquement, il arrive que l’ouverture des dates soit reportée au lendemain, quand le site est vraiment trop longtemps dans les choux. Du coup le site répond (et mon test me revoie que le site est opérationnel), mais les dates ne sont pas disponibles pour autant…

Un rapide coup d’œil aux sources me donne l’info que je cherche. Il n’y a plus qu’à automatiser ça.

Mais évidemment ça n’est pas si simple…

Firefox interprète le Javascript, mais pas cURL, qui ne sait pas interpréter le Javascript (cf ce post de Stack Overflow). Le retour de ma commande contient donc le code source HTML avec le Javascript brut, mais pas les données que je recherche…

Méthode 3 : Un scraper ?

Je dois écrire un scraper qui va aller simuler l’action de l’humain qui va ouvrir la page dans un navigateur. Le post de Stack Overflow cite PhantomJS qui est probablement une bonne solution.

PhantomJS is a headless WebKit scriptable with a JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.

Cependant je ne connais pas bien JS (ça fait longtemps on va dire) et je préfère capitaliser sur Python. J’ai donc cherché un module Python pour régler mon problème, et j’en ai trouvé 2 : un module python selenium et un plus simple appelé dryscrape.

J’ai installé dryscrape sur un de mes serveurs (un CentOS 7 minimal, sans environnement graphique). La documentation de dryscrape est disponible ici et ici (stable, documentation plus fournie).

yum install -y qt5-qtwebkit-devel gcc-c++
sed -i 's/PATH=$PATH:$HOME\/bin/PATH=$PATH:$HOME\/bin:\/usr\/lib64\/qt5\/bin/' .bash_profile
source .bash_profile
pip install dryscrape

Et j’ai tout de suite voulu tester un bout de code sans trop chercher à comprendre.

cat << EOF > test.py
import dryscrape
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

… je me suis donc pris un bon gros Traceback :

Traceback (most recent call last):
File "test.py", line 3, in <module>;
session = dryscrape.Session()
[...]raise NoX11Error("Could not connect to X server. "
webkit_server.NoX11Error: Could not connect to X server. Try calling dryscrape.start_xvfb() before creating a session.

Ahhhhh oui… ça !

xvfb_ (necessary only if no other X server is available)

En fait il suffit d’ajouter un test pour exécuter dans xvfb si nécessaire.

Un premier exemple

Le bout de code suivant ne fait que récupérer le code source de la page et l’afficher à l’écran.

cat << EOF > simple_scraper.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

Mais la grosse différence avec le cURL précédent, c’est que dans le cas présent, ici le Javascript est interprété. Cette fois ci dans le code source retourné, je retrouve bien mon calendrier

A partir de là, il ne me reste donc en théorie qu’à terminer d’écrire un petit bout de script pour extraire les informations qui m’intéressent et à me notifier quand des places sont libres ! On progresse !

Méthode 3 : Scraper comme jamais

Ce montage pourri d’un clip de Maître Gimms avec des logos dans la main vous est offert par Zwindler

Mais je n’étais pas encore satisfait. Mon but est d’être prévenu lorsque des places sont disponibles. Or, les places s’ouvrent le 1er du mois, pour le mois suivant. En revanche, le composant Javascript datepicker a la mauvaise idée de donner les disponibilités pour le mois en cours. Mon script simple_scraper.py ne récupère donc pas les bonnes dates…

Pour contourner le problème, il faut aller encore un peu plus loin dans l’automatisation des actions. Il faut simuler le clic de l’utilisateur sur la flèche vers la droite, qui passe au mois suivant.

C’est possible avec dryscrape, qui propose notamment une fonction pour sélectionner des nodes XPATH et interagir avec. Pour ceux qui ne connaissent pas XPATH, vous pouvez aller sur la doc de dryscrape qui donne quelques exemples, et aussi sur le tutoriel de la W3School.

Comme j’ai examiné le code HTML retourné par le datepicker, je sais quoi chercher :

Pour changer de mois en cours, dans un premier temps j’ai essayé d’utiliser le label « » » mais le module dryscrape ne supporte pas les caractères non ASCII ! Une solution qui fonctionne est de cliquer sur le lien qui contient javascript:void(0) contenu dans le div de classe datepick-next :

cat << EOF > datepick_scraper.py
#!/usr/bin/python
# -*- coding: iso-8859-15 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
datepicknext = session.at_xpath('//*[@class="datepick-next"]/a')
datepicknext.click()
response = session.body()
print response
EOF

Après vérification, cette version du script renvoie bien le tableau avec les date de Juin (quand on est en Mai) !

Le mot de la fin

A partir du moment où vous en êtes là, il n’y a plus vraiment de limites à ce que vous êtes capable de faire. Dans mon exemple, j’aurai pu aller encore plus loin, extraire les dates disponibles, et même pourquoi pas aller jusqu’à remplir automatiquement le formulaire pour réserver automatiquement une date prédéfinie (voire même toutes les dates disponibles).

Ce n’est pas mon but : je vais me contenter de m’envoyer un email dès qu’une date se libère. Mais c’est possible !

Si vous voulez explorer les possibilité de dryscrape, la documentation officielle donne quelques exemples, et notamment celui de l’envoi d’un email depuis Gmail, entièrement automatisé comme si c’était un humain (!)

De quoi donner des idées, pour scraper comme jamais !

Comprendre et configurer SELinux sur RHEL

Wed, 26 Oct 2016 12:00:13 +0000

Présentation

Security-Enhanced Linux, abrégé SELinux, est un Linux security module (LSM), qui permet de définir une politique de contrôle d’accès obligatoire aux éléments d’un système issu de Linux.

Wikipedia

Des fois, pas la peine de chercher plus loin : les définitions sont techniques sur Wikipedia sont souvent très bonnes et concises.

Concrètement, SELinux permet de n’autoriser des processus ou des groupes de processus à ne réaliser que des opérations (écrire dans tel FS, ouvrir un port, etc) qui sont légitimes par rapport à leur utilisation. L’avantage : en cas de vulnérabilité sur tel ou tel processus, l’attaquant sera limité aux fonctionnalités normalement utilisées par le processus en question, lui compliquant la tâche.

Par défaut, SELinux est activé sur tous les serveurs RHEL mais il est souvent désactivé pour pallier certains effets de bords difficilement décelables (charge CPU très importante, plantages de certaines fonctions d’un logiciels).

Je me souviens avoir lu un jour un fervent défenseur de ce mécanisme de sécurité le qualifier de logiciel le plus incompris de Linux et je suis assez en phase avec cette analyse, tant il est courant de voir comme premier élément d’une procédure d’installation « Désactivez SELinux », même de la part de grandes multinationales comme IBM…

Pour autant, comme toute mesure de sécurité, il n’est évidement pas conseillé de le désactiver, même si cela demande effectivement un peu plus de travail ;-). Et comme tout système, il n’est évidemment pas infaillible non plus donc n’allez pas nécessairement vous croire sortir couvert (plusieurs failles ont été remontées).

Commandes de gestion de SELinux

Afficher l’état actuel

getenforce
Disabled

SELinux est complètement désactivé

getenforce
Permissive

SELinux n’empêche pas les processus de réaliser des actions non préalablement autorisées mais logue tous les accès non autorisés dans /var/log/messages. Pour autant, certains effets de bords (comme des surcharges CPU) peuvent quand même apparaitre…

getenforce
Enforcing

SELinux est activé. Toutes les actions non préalablement autorisées sont bloquées par sécurité et logué dans /var/log/audit/audit.log et /var/log/messages.

Ajout d’autorisations SELinux

Par défaut lorsque SELinux est réglé sur Permissive ou Enforcing, chaque action non autorisée génère une remontée dans /var/log/messages.

Exemple de message dans messages :

Oct 16 03:43:38 tstbench01 setroubleshoot: SELinux is preventing /usr/bin/bash from getattr access on the file /usr/bin/sudo. For complete SELinux messages. run sealert -l 9a71f3f1-e624-470a-99ae-af04934769e3
Oct 16 03:43:38 tstbench01 python: SELinux is preventing /usr/bin/bash from getattr access on the file /usr/bin/sudo.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that bash should be allowed getattr access on the sudo file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sh /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

SELinux a beaucoup évolué et est maintenant relativement simple a administrer. L’ensemble des erreurs provoquées par les modes Enforcing et Permissive sont logués dans /var/log/messages et indiquent la marche à suivre pour corriger le problème.

Exemple de résolution pour des plugins Nagios exécutés via NRPE

Le check check_cpu_stats ne fonctionne pas correctement à cause de SELinux et provoque de fausse alertes sur l’utilisation du CPU. On peut créer un fichier de définitions et le réutiliser pour d’autres serveurs.

grep check_cpu_stats /var/log/audit/audit.log | audit2allow -M nrpe
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i nrpe.pp

La commande audit2allow parse le log audit.log puis consolide les autorisations à ajouter dans un fichier de définitions. On peut directement corriger le problème simplement en exécutant la commande suivante :

semodule -i nrpe.pp

Si on souhaite savoir quelles autorisations ont été ajoutés, il est possible de consulter les règles en ouvrant le fichier nrpe.te et éventuellement y réaliser des modifications si nécessaire.

cat nrpe.te
module nrpe 1.0;
require {
type nrpe_t;
type tmp_t;
type var_lib_t;
class dir { write remove_name add_name };
class file { execute read create getattr execute_no_trans write ioctl unlink open };
}
#============= nrpe_t ==============
allow nrpe_t tmp_t:dir { write remove_name add_name };
allow nrpe_t tmp_t:file { write create unlink open };
allow nrpe_t var_lib_t:file { ioctl execute read open getattr execute_no_trans };

Ici, on voit que le plugin souhaite effectuer des opérations sur /var/lib et /tmp.

Ce fichier « .te » modifié ne peut pas être directement appliqué sur le serveur. Il devra être compilé avant de pouvoir être appliqué sur les serveurs.

checkmodule -M -m -o nrpe.mod nrpe.te
semodule_package -o nrpe.pp -m nrpe.mod
semodule -i nrpe.pp

Une fois compilé et installé sur le serveur, le fichier « .pp » se retrouve dans un dossier spécifique de SELinux.

updatedb
locate nrpe
/etc/selinux/targeted/modules/active/modules/nrpe.pp

On peut ensuite propager ce fichier de définition de sécurité sur tous les serveurs concernés.

Modification manuelle de la politique de sécurité

ATTENTION : la commande setenforce ne survie pas au reboot.

Passer de Enforcing à Permissive (pas possible de passer directement à Disabled).

setenforce 0
getenforce
Permissive

Passer à Enforcing.

setenforce 1
getenforce
Enforcing

Pour faire des modifications permanentes, il est nécessaire de modifier le fichier /etc/selinux/config. La valeur a modifier est SELINUX= avec comme choix enforcing, permissive ou disabled.

vi /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinu security policy is enforced.
# permissive - SELinu prints warnings instead of enforcing.
# disabled - No SELinu policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of three two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

ATTENTION : une erreur dans ce fichier (même une simple faute de frappe) aura pour effet de bloquer la machine au boot. Il faudra passer en mode maintenance ou rescue pour éditer et corriger le fichier. Prudence donc !

RAPPEL : Comme tout mécanisme de sécurité, il est évidemment fortement déconseillé de désactiver SELinux de façon permanente !

Désactivation automatisée

Pour ceux qui utilisent Ansible, sachez qu’il existe également un module officiel permettant de activer/désactiver SELinux.

cat no_selinux.yml
---
# Playbook pour couper SE Linux
- name: "No SE Linux"
hosts: all
remote_user: root
tasks:
- selinux: state=disabled

Sources

Un article détaillant de manière plus complète SELinux est disponible sur les HowTos de CentOS.

Et aussi :

SELinux expliqué aux administrateurs frileux
Le guide de déploiement de CentOS (lien mort, pas dispo sur Internet Archive)
Les limites de la sécurité apportée par SELinux (lien mort, j’utilise Internet Archive)

Bug : unable to execute QEMU command ‘cont’ sous KVM et RHEL/CentOS

Sat, 10 Oct 2015 10:30:00 +0000

Cet article est encore un vieil article que je n’ai jamais pris le temps de sortir. Voilà maintenant c’est fait ;-)

Bug unable to execute QEMU command ‘cont’

Aussi rare que cela soit, après ma migration de KVM sur Ubuntu a KVM sur CentOS, je suis tombé sur un bug du Kernel Linux qui affectait directement ma capacité à faire fonctionner des machines virtuelles sous Windows 7 ou Windows 2008 ! Mais toutes les autres fonctionnaient normalement.

Symptôme

Lorsqu’on démarre la VM ou qu’elle démarre seule au boot, elle se met en pause. Si on essaye de la sortir du mode pause on reçoit l’erreur suivante.

Error unpausing domain: internal error unable to execute QEMU command ‘cont’: Resetting the Virtual Machine is required<

L’erreur en elle même n’est pas très explicite. Dans le log de la machine virtuelle en question, on a un message plus long mais guère plus évocateur :

/var/log/libvirt/qemu/[maVM]
kvm: unhandled exit 80000021
kvm_run returned -22
If you’re running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

Bien évidemment, toutes les autres VMs sous Linux fonctionnent parfaitement donc on ne peut pas accuser Qemu de ne pas fonctionner correctement.

Solution

En théorie, j’ai lu à plusieurs endroits que le bug était censé être corrigés sur des patchs des kernels de CentOS 5 ou 6 (toujours présent en 2.6.32-431.3.1.el6.x86_64 par exemple) et même pour Ubuntu.
Dans la pratique, même en mettant l’OS CentOS à jour, impossible de faire fonctionner cette VM.
La seule vrai solution que j’avais trouvé à l’époque était de forcer le passage à un kernel plus récent, à savoir au moins 3.+.

Pour ceux qui se sentiraient un peu perdu, le plus simple est de changer de version de CentOS ou d’Ubuntu. Sur les dernière version le bug n’est plus présent.

Cependant, si vous avez un système en place et qu’une migration n’est pas à l’ordre du jour, voici la marche à suivre pour installer un kernel plus récent. Voici la procédure que j’ai utilisée pour installer un 3.13 sur lequel la VM fonctionne à nouveau (3.11 fonctionne aussi, je ne sais pas avant).

yum install gcc ncurses ncurses-devel
yum update
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.13.1.tar.gz
tar xzf linux-3.13.1.tar.gz -C /usr/src/
cd /usr/src/linux-3.13.1/
make menuconfig
make
make modules_install install

N’oubliez pas de vérifier que votre kernel est bien choisi en premier dans le boot loader, ce qui n’est souvent pas le cas par défaut (modifier la valeur default dans le grub.conf pour correspondre à la bonne entrée) sinon le problème ne sera pas résolu au reboot.

vi /etc/grub.conf
default=X
[...]
root (hd0,0)
kernel /vmlinuz-3.13.1 ro root=/dev/mapper/vg_root-lv_root rd_LVM_LV=vg_root/lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_MD_UUID=8f43b4fe:e72ed9aa:2da568b5:5f43b223 SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rd_LVM_LV=vg_endeavour/lv_swap rd_NO_DM rhgb quiet
initrd /initramfs-3.13.1.img

Et vous pouvez vérifier que vous êtes sur le bon kernel avec un uname.

reboot
uname -r

Erreur/bug Error starting virt-manager

En bonus track, je voudrais aussi ajouter un petit bug de plus pour la route, sur l’utilisation de l’interface graphique virt-manager cette fois ci.

Pour une raison obscure, lorsque je voulais lancer ma GUI virt-manager, il m’est arrivé une ou deux fois de suivre la procédure décrite sur le blog de nutanix lorsque je recevais l’erreur suivante :

Error starting virt-manager

dbus-uuidgen --get
cat /var/lib/dbus/machine-id
dbus-uuidgen > /var/lib/dbus/machine-id