RHEL on Zwindler's Reflection

Oracle à la rescousse de Linux ? Quelle blague!

Tue, 11 Jul 2023 06:00:00 +0200

Petit billet d’humeur, ça faisait longtemps

Oracle vient à la rescousse de Linux ? Quelle blague…

En 2018, j’écrivais un article intitulé L’open source bashing a encore de beaux jours devant lui, prémisse d’un de mes tout premiers talks. A PSES ensuite, en 2019, je donnais une de mes toutes premières conférences en tant que speaker intitulée “Le logiciel libre a-t-il de beaux jours devant lui ?”.

Dans cet article et ce talk, j’avais parlé des “super-vilains” de l’histoire, les géants du monde propriétaires.

Ceux qui étaient passés de l’ignorance du logiciel libre, à la moquerie, puis au combat. Et finalement du rachat de RedHat par IBM.

First they ignore you,

Then they laugh at you,

Then they fight you,

Then they buy you

RedHat verrouille des sources RHEL derrière un paywall

Aujourd’hui, rien n’a changé.

Les super-vilains cyniques sont les mêmes, ils changent juste alternativement de rôles dans le triangle de karpman.

Note: Si vous avez loupé cette news qui a pas mal chahuté le petit monde de l’OSS et du logiciel libre, je vous ai fait une petite compilation de liens en fin d’article.

IBM/RedHat tue CentOS en 2020 (alors que normalement le support de la 8 courrait pendant encore plusieurs années), puis utilise en juin 2023 “une faille” (selon Jeff Geerling) de la GPL pour empêcher les clones de RHEL.

Et comme la saison du troll semble ainsi ouverte, aujourd’hui Oracle fait semblant d’aider l’open source (juste pour troller IBM), tout en ayant été de l’autre côté de la barrière tout aussi récemment.

Oracle.com - Keep Linux Open and Free—We Can’t Afford Not To

Et au milieu de tout ça, Microsoft Loves Linux, bien entendu 😏

Bref, l’histoire de l’informatique est un éternel recommencement.

Addendum : SUSE

SUSE vient (aujourd’hui !) de rajouter un pavé dans la marre en annonçant forker RHEL et investissant plus de 10 millions de dollars dessus.

*SUSE Preserves Choice in Enterprise Linux by Forking RHEL with a $10+ Million Investment

SUSE is committed to working with the open source community to develop a long-term, enduring compatible alternative for RHEL and CentOS users. SUSE plans to contribute this project to an open source foundation, which will provide ongoing free access to alternative source code.

Merci à ceux qui me l’ont forwardé :)

Sources

Pour comprendre rapidement (mais faut aimer les vidéos)

Vidéo Adrien LinuxTricks - Edito Red Hat : Debrief autour de la “fermeture des sources”

Les différents billets de blogs

Ma conférence à PSES 2019 / BDX I/O 2019 (sur mon peertube)

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

Déployer des VM VMware avec Ansible – part 2

Tue, 14 Nov 2017 12:45:27 +0000

Où est ce qu’on en était ?

La dernière fois qu’on a parlé de [machines virtuelles déployées à l’aide d’Ansible sur une infrastructure VMware][1], on avait un playbook fonctionnel, mais il me manquait encore un petit quelque chose.

En fait, à l’issue du déploiement de la VM, je n’avais pas encore trouvé la possibilité d’enchaîner sur l’exécution d’autres playbooks permettant de configurer la VM. L’objectif ultime étant de faire en une seule étape de :

déployer la VM (que j’appellerai « déploiement »)
et de la configurer, c’est à dire modifier les fichiers de configuration de la VM, installer les logiciels, etc… (que j’appellerai « configuration »).

Premier problème, connection:local

Pour rappel, le premier problème quand on veut déployer une VM qui n’existe pas encore… est justement le fait qu’elle n’existe pas encore !

Si j’exécute un playbook deploy_vm.yml sur une VM « ma-vm » tel quel, je vais me prendre un message d’erreur (pour plus de détails, lire l’article précédent) car Ansible tente de se connecter à la machine pour récupérer des informations sur elle.

La méthode pour s’affranchir de ce genre de problèmes est de feinter Ansible en lui disant :

de ne pas récupérer les informations de la machine
d’exécuter le playbook sur une autre machine (le plus simple c’est localhost)

Pour le premier point, la solution est mettre en haut du playbook l’option gather_facts: false. Cela aura un impact mais on verra ça plus loin.

Pour le second point, il existe 2 solutions. La première, que je préconisais dans l’article précédent, consiste à utiliser en haut du playbook l’option connection: local. Cette option permet d’exécuter l’ensemble du playbook sur la machine locale et non pas la machine qu’on déploie.

En réalité, il est en fait plus simple d’utiliser l’option delegate_to, qui se limite à une seule tâche ou à un rôle, ce qui permet de déléguer la partie déploiement à localhost, puis tenter d’exécuter les autres playbooks sur la VM qu’on veut configurer.

Un problème de nom … pas si facile à résoudre

Vous avez vu le jeu de mot ? Ok, je sors…

Bien sûr, on va se heurter à plusieurs problèmes… Le premier est la résolution de nom. A moins d’avoir réalisé la mise à jour de votre DNS à l’avance (à la main du coup… c’est nul), dès que le déploiement sera terminé et qu’on passera à la partie configuration de la VM, Ansible essayera de contacter votre nouveau serveur.

Le plus propre serait d’ajouter à la partie « déploiement » une tâche permettant de mettre à jour le DNS. Dans mon environnement professionnel, le service DNS est géré par un serveur Windows Active Directory. La simple mise à jour du DNS depuis Linux est un vrai casse tête et le plus simple est d’intégrer la machine (qu’elle soit Windows ou Linux) dans le domaine Active Directory qui se charge alors de mettre à jour le DNS lui même.

C’est un gros sujet et je ferai un article à part dessus. Dans un premier temps on peut se contenter de juste mettre à jour le fichier /etc/hosts de la machine localhost.

- name: add to /etc/hosts file
lineinfile:
dest: /etc/hosts
line: '{{ custom_ip }} {{ inventory_hostname }} {{ inventory_hostname }}.zwindler.fr'
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Accès concurrents

Si vous vous y connaissez un peu en Ansible, vous remarquerez que je ne me suis pas contenté d’un simple lineinfile, mais que j’ai utilisé un with_items et un when.

En fait, on peut utiliser mon playbook pour déployer en parallèle un grand nombre de VMs en même temps. Le souci que j’ai rapidement eu a été un accès concurrent sur le fichier, et des noms de VMs ont alors manqué.

Il existe une fonction « serial » qui permet de désactiver la parallélisation des tâches, mais malheureusement, on ne peut l’appliquer qu’au playbook entier. Peut être qu’un jour la fonctionnalité sera ajoutée (la demande est référencée sur Github)

J’ai donc du passer par une boucle pour enregistrer tous les serveurs du play courant.

Clé SSH

OK, maintenant, on sait résoudre la (ou les) machine(s) qu’on vient d’ajouter. Cependant on est pas sorti de l’auberge !

En partant du principe que vous n’avez pas oublié de déposer la clé SSH du serveur localhost pour qu’Ansible puisse se connecter sur votre nouvelle machine, voilà ce qui va se passer :

TASK [gather facts] *************************************************************************************************************************************************************************
The authenticity of host 'zwindler01 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler02 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler03 (x.x.x.x)' can't be established.

Ansible bloque à la première connexion SSH vers votre VM nouvellement crée car il faut accepter l’empreinte de chaque VM manuellement au préalable. Même si on essaye de renseigner yes à toutes les questions, ce n’est clairement pas idéal et encore moins automatisé !

La solution temporaire, host_key_checking=False

Il existe un paramètre dans Ansible qui permet de passer outre la vérification de l’empreinte de la machine, soit en modifiant le fichier de configuration ansible.cfg, soit ajouter un flag à l’exécution de playbook, soit configurer une variable d’environnement.

ansible-playbook -l zwindler* -i hosts_deploy -e 'host_key_checking=False' deploy_vmware_guest.yml
#OU
export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -l zwindler* -i hosts_deploy deploy_vmware_guest.yml

Vous trouverez plus d’informations sur cette solution de contournement sur les sites suivants :

Cette solution de contournement est à proscrire en production, car elle va ignorer l’empreinte de TOUTES les machines et pour TOUS vos playbooks. Au delà du problème évident de sécurité que ça pose, si vous enlevez l’option à un moment donné, c’est retour à la case départ. Vous aurez de nouveau la question sur tous les serveurs dont vous n’avez pas explicitement accepté l’empreinte.

ssh-keyscan à la rescousse

On va donc ajouter la tâche suivante à notre playbook de déploiement :

- name: accept new ssh fingerprints
shell: ssh-keyscan {{ custom_ip }},{{inventory_hostname}} >> ~/.ssh/known_hosts
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Je sais… c’est terrible : la solution que j’ai à l’heure actuelle, bien que fonctionnelle, N’EST PAS IDEMPOTENTE… :-( mais elle fonctionne.

Et on fini par un petit setup pour récupérer les facts.

- name: gather facts
setup:

Et maintenant ?

Et bien ! Maintenant, ça marche ! Vous pouvez enchainer d’autres tâches (ou des rôles) en ne mettant plus delegate_to, et ces tâches de « configuration » seront bien lancées sur le serveur que vous venez de déployer, dans un seul et même playbook.

---
- hosts: all
gather_facts: false
vars_prompt:
- name: "vsphere_password"
prompt: "vSphere Password"
- name: "esxi_host"
promt: "ESXi host"
private: no
- name: "notes"
prompt: "VM notes"
private: no
default: "Deployed with ansible"
roles:
- deploy_vmware_guest
- other_role_for_configuration

Pari réussi !

Et le playbook, il est où ?

Une fois de plus, je suis sympa, je vous donne un exemple de code sur mon Github !

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 :)

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)

[Tutoriel] Installation d’Oracle VM for x86 – partie 2

Tue, 18 Oct 2016 12:00:57 +0000

Cet article fait suite à l’article Installation d’Oracle VM for x86 - partie 1 dans lequel j’ai introduis Oracle VM et installé la console de management Oracle VM Manager. Je vous conseille de commencer par là ;-).

Connexion du serveur Oracle VM avec la console OVMM

Maintenant que la console OVMM est opérationnelle et qu’on a pu s’y connecter, on remarque que les menus sont assez intuitifs bien qu’un peu austères !

Un onglet Health donne l’état général de la plateforme, puis les autres onglets permettent de configurer les différents aspects attendus d’une console d’administration de virtualisation x86.

La première étape pour nous est donc bien entendu d’ajouter dans OVMM le serveur Oracle VM préalablement installé, au même titre qu’on pourrait le faire avec un ESXi dans un vCenter.

Hormis les icônes pas forcément très parlantes, le menu de « découverte » de nouveaux serveurs est très simple. On a juste besoin de l’IP et du compte OVM Agent créé lors du déploiement de l’ISO d’installation.

En bas de l’écran, un bandeau vous donne l’état des dernières opérations déclenchées sur le cluster.

Un bref coup d’œil permet de voir que le serveur est bien ajouté. Des informations sur sa configuration s’affichent.

Créer un groupe de serveurs « server pool »

Vous aurez peut être remarqué que votre serveur de virtualisation a été ajouté dans le groupe de serveurs « Unassigned ». Intellectuellement ça me gène, et j’ai donc voulu créer un groupe de serveurs, pour « faire propre ».

Au delà de ça, c’est notamment via la création de ces groupes (clusters dans VMware) que l’on peut gérer la haute disponibilité et les clusters de machines. C’est donc plutôt important ;-).

Ce groupe peut se créer via l’icône située juste à droite de celle sur laquelle nous avons cliqué pour « découvrir » le serveur Oracle VM.

Cependant, lorsque j’ai tenté de créer mon groupe de serveurs, j’ai reçu l’erreur suivante :

OVMAPI_4010E Attempt to send command: create_server_pool to server: lab01 failed.
OVMAPI_4004E Sync command failed on server: x.x.x.32.
Command: create_server_pool, Server error: org.apache.xmlrpc.XmlRpcException: <type 'exceptions.Exception'>:
Invalid hostname resolution: lab01 -> 127.0.0.1 [Wed Jul 20 16:30:40 CEST 2016]

Lors de l’installation automatique de l’ISO Oracle VM, le hostname lab01 a été ajouté par défaut dans le fichier /etc/hosts. Or, ceci pose problème.

Connectez vous en SSH sur le serveur et retirez le hostname (ici lab01) du fichier /etc/hosts :

vi /etc/hosts
127.0.0.1 lab01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Création de pools de stockage

La seconde opération consiste à ajouter du stockage au cluster.

Avec Oracle VM, on peut utiliser du stockage local via des disques inutilisés. La procédure est détaillée à l’adresse suivante.

On peut également découvrir des cibles iSCSI ou éventuellement utiliser l’espace disponible sur le filesystem local. Pour ce dernier choix, l’espace ne sera cependant bien entendu uniquement visible depuis le serveur local uniquement.

Pour l’exemple, j’ai créé un disque de test de 200 Go sur un NAS Windows.

La procédure est la suivante. On commence par ouvrir l’onglet « Storage ». Dans SAN Servers, il n’y a encore aucun serveur déclaré. Au même titre que pour le serveur de virtualisation, il y a un bouton « Discover SAN Server ».

On peut déclarer un ou plusieurs hôtes, avec ou non de l’authentification. J’ai rarement vu des contextes où l’authentification CHAP (côté client ou serveur) était activée, mais je trouve ça bien en production. Pour autant, dans le cas du PoC je n’en ai pas mis.

Editer les access groups

Et enfin, on ajoute les serveurs qui peuvent avoir accès aux périphériques de stockage. Ici lab01.

Cliquer sur Finish pour valider.

Dans mon cas, juste avec la configuration de cet article, je suis tombé sur l’erreur suivante. A l’écran d’avant j’avais loupé la modification des access groups et en particulier l’onglet storage initiators. Si vous avez une erreur, c’est surement le même problème.

Le stockage nouvellement intégré apparait maintenant avec les volumes disponibles

Créer des repositories pour stocker des images

Une fois les périphériques de stockage déclarés auprès de vos serveurs de virtualisation, on peut maintenant créer des pools appelés repositories.

L’ensemble des opérations qui suivent sont a effectuer dans l’onglet Repositories. Ces pools logiques de stockage vous permettent de stocker vos fichiers ISO, mais aussi vos templates et vos disques durs virtuels pour vos machines virtuelles. Sur VMware on parlerait de Datastores.

Avec le disque local

Comme indiqué précédemment, ce type de stockage aura l’inconvénient de n’être accessible que d’une seule machine. Cependant c’est le plus simple à utiliser.

Cliquer sur le logo « + » pour créer un nouveau repository.

On doit d’abord renseigner quelques informations descriptives et d’appartenance.

Enfin, on sélectionne le disque (Physical Disk) sur lequel placer le repository.

La dernière étape consiste à ajouter les serveurs qui verront ce stockage. Dans ce cas précis, seul lab01 pourra le voir.

Après validation, le nouveau repository apparait dans la liste des repositories.

Avec le disque SAN

Le principe est le même pour les disques SAN, à ceci près que celui ci pourra bien être partagé entre plusieurs serveurs d’un même cluster (pour peu que les serveurs concernés aient bien été autorisés à voir ce stockage lors de l’étape précédente).

Gestion du réseau

Vous l’aurez deviné, pour la gestion du réseau, tout se passe dans l’onglet « Network » de la console OVMM.

Petite subtilité, par défaut, le réseau de management ne peut pas être utilisé par les VMs. Vous ne pourrez donc pas affecter de réseaux virtuels aux machines virtuelles en l’état actuel des choses.

Dans mon cas (PoC), je ne souhaite pas créer un nouveau réseau pour me simplifier la vie, et j’ai donc ajouté « Virtual Machine » au réseau de management créé par défaut lors de l’installation du serveur OracleVM.

Dans un contexte de production, on préfèrera en ajouter un nouveau et lui affecter des interfaces réseaux et des VLANs (comme on le ferait sur VMware ou RHEV).

Créer une nouvelle VM

Maintenant que les aspects stockage et réseau ont été réglés, on peut enfin créer une machine virtuelle. La documentation officielle donne quelques informations utiles sur le sujet.

Le début de la création de machine virtuelle est similaire à n’importe quel outil de virtualisation.

HVM, HVM + PV, PVM

Cependant, par rapport aux autres hyperviseurs (full virtualisation vs paravirtualisation, différences que j’aborde dans cet article), Xen et donc OracleVM apporte une subtilité dans la méthode de virtualiser : la paravirtualisation (PVM). On a le choix entre HVM, HVM + PV et PVM.

En réalité il s’agit de :

Xen HVM: Hardware virtualization, or fully virtualized
Xen HVM, PV Drivers: Identical to Xen HVM, but with additional paravirtualized drivers for improved performance
Xen PVM: Paravirtualized

En théorie, vous aurez donc de meilleures performances lorsque vous disposerez d’un OS capable d’être paravirtualisé (mode Xen PVM) que lorsque vous aurez une HVM.

Ça c’est la théorie. En fait en pratique, certains OS, même Linux, seront plus performants en HVM + PV selon Oracle. Pour plus d’informations, voir la page de documentation officielle qui traite du sujet

La liste des OS supporté pour chaque mode est disponible dans les release notes.

Créer des interfaces virtuelles

La seconde étape du wizard permet de configurer les interfaces virtuelles et les réseaux qui y sont associés.

Ajouter des disques virtuels

L’étape d’après permet de configurer les différents périphériques qui sont associés à la VM. Dans le cas du disque dur virtuel, il faut le créer ou en réutiliser un existant.

Lorsqu’on clique sur le « + », on peut créer un nouveau disque virtuel qui sera stocké sur le repository choisi.

Enfin, on peut affecter ou non les différents périphériques éligibles à la séquence de boot et les ordonner.

Une fois la VM créée, on peut la démarrer et ouvrir sa console.

Boot

Dans l’état actuel des choses, la VM démarre mais n’a aucun disque bootable (CD ou HDD). En effet, il faut monter un ISO sur la VM, mais pour ça on doit l’uploader dans un premier temps sur un des repositories précédemment créés.

A priori, dans le menu d’import du repository, on ne peut uploader que des ISO depuis un partage web HTTP. Une solution alternative probable est que l’on peut simplement aller déposer le fichier en SSH mais je trouve que clairement il manque une fonctionnalité à la console d’upload en directe depuis un navigateur !

Une fois qu’on dispose d’un ISO pour booter notre VM, on peut éditer la machine virtuelle et y ajouter l’ISO.

On redémarre la machine virtuelle qui boote sur l’ISO comme souhaité.

Sources

[Tutoriel] Installation d’Oracle VM for x86 – partie 1

Tue, 11 Oct 2016 12:00:23 +0000

Présentation d’Oracle VM

Dans le cadre d’un très sérieux Dossier de Choix de Solution d’Infrastructure, j’ai été amené à étudier la plateforme de virtualisation proposée par Oracle : Oracle VM.

Dans la lignée d’Oracle Unbreakable Linux qui est une copie de RHEL modifiée (les sources étant disponibles sur Internet car open source), Oracle tente depuis plusieurs années de pénétrer le marché de la virtualisation de serveur, sans jamais vraiment parvenir à percer. La faute à une concurrence trop forte de VMware et Hyper-V, trop loin en tête en adoption dans les entreprises et un retard fonctionnel conséquent, surtout dans les suites logicielles périphériques (internes ou tierces) de SDS, SDN, sauvegarde, VDI, cloud, etc etc.

Pourtant sur le papier, Oracle VM a de bons arguments pour séduire les administrateurs : un noyau robuste (RHEL + Xen), sans coût de licence et avec un coût de support (souscription comme chez Redhat) en 24×7 à 500$ / serveur / an en prix public, très en deçà de la concurrence moyenne !

Cerise sur le gâteau, contrairement à l’ensemble des autres solutions de virtualisation x86, Oracle permet de ne licencier que les vCPU réellement affectées aux VMs Oracle VM sur lesquelles sont installés des produits Oracle. Et c’est probablement là que le bat blesse. Dans bon nombre d’entreprises, Oracle est devenu synonyme d’audit et de changement de règles de licencing au petit bonheur la chance…

Ce sont quand même de sérieux atouts et je ne voyais pas passer outre un PoC pour me faire une idée du produit.

Info : Pour plus de lisibilité j’ai scindé l’article en 2 parties. Celle ci concerne les prérequis pour l’ensemble des composants et l’installation de la console (non trivial) et la seconde se concentrera sur la configuration de notre premier serveur (réseau, stockage, vms).

Prérequis

Oracle VM (virtualisation)

Pour la partie virtualisation, Oracle VM se base sur RHEL et Xen. Et ces deux composants sont peu gourmands et assez flexibles en terme de compatibilité matérielle. Vous n’aurez aucun mal à trouver un vieux serveur pour faire un PoC comme je l’ai fais.

On trouve assez facilement sur le site d’Oracle les valeurs minimum pour Oracle VM 3.4. A noter quand même que les liens qui remontent dans Google pointent parfois sur des versions antérieures. Attention donc.

Items	Minimum Value
Memory	1.0 GB
Processor Type	64 bit i686 P4
Processor Speed	1.3 GHz x 2
Available Hard Disk Space	6 GB

Oracle VM Manager

Pour ce qui est de la console de management Oracle VM Manager, les prérequis sont par contre plus élevés, mais c’est malheureusement une habitude avec les consoles d’administration de plateforme de virtualisation (les premiers vCenter / appliances Linux plantaient dès qu’on passait sous les 8 Go de RAM).

Items	Minimum Value
Memory	8.0 GB
Processor Type	64 bit
Processor Speed	1.83 GHz x 2
Swap Space	2.1 GB
Hard Disk Space	5.5 GB in /u01 3 GB in /tmp 400 MB in /var 300 MB in /usr

Vous trouverez la liste des OS compatible sur le site d’Oracle au même endroit que l’ISO pour Oracle VM Manager :

Oracle Linux 5 Update 5 64-bit
Oracle Linux 6 64-bit
Oracle Linux 7 64-bit
Red Hat Enterprise Linux 5 Update 5 64-bit
Red Hat Enterprise Linux 6 64-bit
Red Hat Enterprise Linux 7 64-bit

A noter, sans surprise, il peut s’agir soit d’une machine virtuelle soit d’un serveur physique.

Installation

Configuration d’Oracle VM Manager

Dans mon cas, j’ai installé OVMM sur un RHEL 7.

Il est nécessaire d’avoir (au moins localement) une résolution du nom de la machine qui héberge l’oracle VM Manager. Idéalement, il est préférable d’avoir une résolution de nom par DNS donc, mais à minima, vous devez avoir une entrée similaire au retour de la commande hostname dans votre fichier /etc/hosts :

# hostname
ovmm01.example.org
# vi /etc/hosts
[…]
192.168.100.10 ovmm01.example.org ovmm01

La documentation d’Oracle vous indique que selon votre contexte, vous pouvez soit désactiver complètement votre firewall soit ajouter les règles correspondantes. L’exemple donné dans la documentation (iptables) ne fonctionne pas avec firewalld installé par défaut sur RHEL 7. Voici les bonnes commandes :

firewall-cmd --get-active-zones
public
interfaces: eno16780032
firewall-cmd --permanent --zone=public --add-port=7002/tcpfirewall-cmd --permanent --zone=public --add-port=10000/tcp
firewall-cmd --permanent --zone=public --add-port=123/udp
firewall-cmd --reload
firewall-cmd --zone=public --list-ports
123/udp 10000/tcp 7002/tcp

Ou si vous n’avez peur de rien (et que c’est un serveur de test)

systemctl stop firewalld
systemctl disabled firewalld

Pour une bonne introduction avec les commandes firewalld je vous conseille le post suivant

Prérequis complémentaires

Monter le fichier ISO sur le serveur sur lequel sera installé Oracle VM Manager. Oracle a mis au point un script qui permet de paramétrer les prérequis (utilisateur oracle, limites, /u01, …).

mount /dev/cdrom /mnt
cd /mnt
./createOracle.sh
Missing required package, Oracle VM Manager requires 'iptables-services' to be installed, you can use 'yum install iptables-services' to install it.

La encore, petit oubli d’Oracle ! Le script createOracle.sh utilise iptables et pas firewalld. Il ne fonctionne donc pas sur RHEL7 alors que cet OS est censé être supporté ! On ne peut pas utiliser ce script, il faut faire les modifications à la main (heureusement simples) !

mkdir /u01
chmod 755 /u01
groupadd dba
groupadd -g 54321 oinstall
useradd -u 54321 -g dba -G oinstall -d /home/oracle oracle
/bin/chown oracle:dba /home/oracle
vi /etc/security/limits.conf
oracle hard nofile 8192
oracle soft nofile 8192
oracle soft nproc 4096
oracle hard nproc 4096
oracle soft core unlimited
oracle hard core unlimited

Une fois les modifications réalisées, on peut lancer l’installeur à proprement parler.

Installation du VM Manager

Lancer l’installeur présent sur l’ISO.

[root@ovmm01 mnt]# ./runInstaller.sh
Oracle VM Manager Release 3.4.1 Installer
Oracle VM Manager Installer log file:
/var/log/ovmm/ovm-manager-3-install-2016-07-20-150727.log
Please select an installation type:
1: Install
2: Upgrade
3: Uninstall
4: Help
Select Number (1-4): 1
Verifying installation prerequisites ...
Conflicts when MySQL install. Oracle VM Manager requires 'mariadb-libs' to be uninstalled, you can use 'yum remove mariadb-libs' to uninstall it.
Configuration verification failed ...

Dans mon cas la première installation n’a pas fonctionné. Pour une raison que j’ignore, mon installation contenait déjà mariadb-libs dans une version entrant en conflit avec le MySQL embarqué par OVMM. Etrangement ils préfèrent qu’on utilise MySQL plutôt que MariaDB ;-). Je l’ai donc désinstallée comme demandé, mais attention aux dépendances qui sont désinstallées dans la foulée !

yum remove mariadb-libs

Et on recommence…

Verifying installation prerequisites ...
Starting production with local database installation ...
One password is used for all users created and used during the installation.
Enter a password for all logins used during the installation:
Invalid password.
Passwords need to be between 8 and 16 characters in length.
Passwords must contain at least 1 lower case and 1 upper case letter.
Passwords must contain at least 1 numeric value.

Tu pouvais pas me le dire avant ? ;-)

Enter a password for all logins used during the installation:
Enter a password for all logins used during the installation (confirm):
********
Please enter your fully qualified domain name, e.g. ovs123.us.oracle.com, (or IP address) of your management server for SSL certification generation, more than one IP address are detected: 192.168.20.94 192.168.122.1 [ovmm01.example.org]: ovmm01.example.org
Verifying configuration ...
Start installing Oracle VM Manager:
1: Continue
2: Abort
Select Number (1-2): 1
Step 1 of 7 : Database Software ...
Installing Database Software...
[...]
Oracle VM Manager UI:
https://ovmm01.example.org:7002/ovm/console

Vous pouvez maintenant vous connecter à l’URL donnée en fin d’installation.

Sources

[En bref] Modifier des interfaces réseaux en ligne de commande avec nmcli sous RHEL 7

Sat, 16 Apr 2016 10:00:03 +0000

Les changements de RHEL 7 avec NetworkManager (et nmcli)

Le moins qu’on puisse dire de RedHat c’est qu’ils ont quand même changé pas mal de choses avec la version 7 !

Entre XFS en FS par défaut (juste après avoir introduit ext4), la gestion du firewall avec firewalld, l’abandon de SysV pour systemd, les améliorations de SELinux, … Il y a de quoi s’y perdre ! Alors, quand j’ai monté ma première VM et que j’ai galéré à changer le hostname et le FQDN proprement, je me suis dis « trop c’est trop! » ;-).

Voici un petit récap’ de quelques commandes pour vous permettre de gagner du temps plutôt que passer par l’interface NetworkManager, pas toujours extraordinaire… (surtout nmcli, la version CLI de l’utilitaire de NetworkManager et dont les commandlets ont été enrichis depuis la RHEL 6!)

Via hostnamectl

Afficher le hostname du serveur dans ces différentes formes : static (nom court), pretty (avec des caractères spéciaux) et « transcient » (???)

hostnamectl status

Commande pour effectuer des modifications sur le hostname (avec les options --pretty, --static, --transient)

hostnamectl set-hostname monhostname

Via nmcli

Comme je le disais en introduction, nmcli est l’utilitaire en ligne de commandes qui permet de modifier les paramètres réseau sur les serveurs qui utilisent Network Manager.

Pour expliquer un peu pourquoi des fois en arguments je met con ou connection, c’est parce que toutes les commandes peuvent être abréviées autant que vous le souhaitez tant que la sous-commande appelée n’est pas ambiguë. Du coup, pour s’économiser 5 caractères parce qu’on est particulièrement fainéant, on peut mettre « g » au lieu de « global« . Mais rien ne vous y oblige.

Afficher le hostname

# nmcli g hostname
server.example.org

Modifier le FQDN (change le hostname et ajoute domain dans /etc/resolv.conf)

# nmcli g hostname desktop.example.org

Afficher le status des cartes réseau

# nmcli dev status

On dispose de deux types d’objets : les périphériques (sous-commande device) et les connexions (sous-commande connection) qui leur sont associées. Elles peuvent ne pas avoir le même nom mais et ne représentent pas tout à fait la même chose. C’est pourquoi il y a bien deux commandes distinctes :

# nmcli con show net-eth0
# nmcli dev show eth0

Désactiver la connexion automatique pour une connexion donnée

# nmcli con mod net-eth0 connection.autoconnect no

Pour modifier des paramètres de connexion

# nmcli con mod net-eth0 ipv4.addresses 192.168.2.10/24
# nmcli con mod net-eth0 ipv4.gateway 192.168.2.1
# nmcli con mod net-eth0 ipv4.method manual

Pour activer une connexion

# nmcli con up net-eth0

Procédure pour ajouter un serveur DNS avec persistance au reboot (mais nécessite une déconnexion/reconnexion de l’interface via GUI ou systemctl restart network ou ifdown+ifup)

# nmcli con mod net-eth0 +ipv4.dns 8.8.8.8
# nmcli con up net-eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)

Le fichier resolv.conf a été mis à jour

# more /etc/resolv.conf
# Generated by NetworkManager
nameserver 8.8.8.8

Note :

On ajout un serveur DNS avec +ipv4.dns, et on le retire avec -ipv4.dns

Source

J’ai gagné beaucoup de temps grâce à certdepot.net qui donne la plupart des commandes expliquées ici