Redhat on Zwindler's Reflection

S'authentifier sur Proxmox VE avec Keycloak

Wed, 11 May 2022 12:30:00 +0000

Résumé des épisodes précédents

Cet article est la suite d’un article que j’avais sorti en aout dernier (time flies…) sur l’installation de Keycloak (sans utiliser l’image Docker).

J’avais bien entendu une idée derrière la tête (on installe pas un Keycloak pour le plaisir ?). cette idée était de tirer parti de l’authentification OIDC qui venait d’être ajoutée à Proxmox VE 7.

Je pars donc du principe que vous avez un serveur Keycloak fonctionnel et on va s’en servir pour ajouter l’authentification OIDC à notre cluster PVE.

Getting Started

Dans l’article précédent, je vous avais laissé au moment où on se connectait à l’UI de Keycloak, et qu’on arrivait sur le “Getting Started”. Si vous voulez plus de détails sur cette étape, je vous conseille de lire l’article de documentation associé sur le site officiel.

Nous, on va commencer direct par la création d’un “Realm”.

Dans un contexte multi client ou multi entreprise, les Realms vous permettraient d’avoir un Realm par client par exemple, chacun avec son propre système d’authentification (LDAP, AD, …).

Ici, on ne va pas d’embêter, je fais un realm pour mon Proxmox et il servira juste pour ça.

Créer un Realm

C’est peut-être un manque d’habitude, mais j’ai pas trouvé la navigation entre “Realm” hyper intuitive, au début. En fait, par défaut vous êtes sur un realm “master” (visible tout en haut à gauche de l’écran, sous le logo Keycloak).

En cliquant sur la flèche qui va vers le bas, à droite de “Master”, on ouvre un menu déroulant, qui dévoile option “Add realm”.

On lui donne un petit nom et c’est bon.

Créer un client

Dans la terminologie Keycloak (OIDC en général), un client, ça va en fait être notre application qui va déléguer l’authentification à Keycloak.

Dans le realm Proxmox, on va donc créer un client pour ProxmoxVE.

On lui donne un petit nom, mais surtout l’URL de connexion qui va avec (on prend le premier serveur du cluster, car chaque serveur à sa propre URL de connexion à l’UI, mais on va gérer ça plus tard).

Vous devriez ensuite être redirigé vers les paramètres (plus complets) du client. De mémoire, il n’y a rien à changer, les paramètres par défaut sont bons, sauf si vous avez plusieurs URIs de connection.

C’est mon cas, j’ai plusieurs serveurs proxmox VE en cluster, mais je n’ai pas de loadbalancer qui me redirige sur les backends :8006 sur même URL en frontal.

Je dois donc renseigner dans la case “Valid Redirect URIs” autant d’URI que j’ai de serveurs PVE.

Créer un utilisateur dans Keycloak

Avant d’aller configurer Proxmox VE, on va vouloir ajouter des utilisateurs dans Keycloak.

Idéalement, vous avez déjà une base de comptes interne (LDAP, AD, etc) ou externe (Google Gmail, Azure AD, que sais-je encore). C’est cet “Identity Provider” que vous allez devoir connecter à votre Keycloak. Cependant, ça sort du scope de cet article.

Pour info, j’ai réussi en très peu de temps, et en suivant cet article How to setup Sign in with Google using Keycloak (lien mort, j’ai utilisé Internet Archive), à connecter mon compte gmail perso à Keycloak et je peux l’utiliser pour me logger dans ma console Proxmox.

Pour rester simple, on va seulement créer un login dans Keycloak, car l’outil offre une base de comptes interne qui suffiront pour cet article.

Dans le menu de gauche, sur le realm Proxmox qu’on vient de créer, allez dans “Manage / Users”, puis cliquez sur “Add User”.

On va vous demander des informations :

Une fois validé, affectez-lui un mot de passe.

Normalement, une fois que c’est fait, on en a fini avec Keycloak.

Configurer Proxmox VE

On peut donc aller configurer Proxmox VE. L’opération est relativement simple. Une fois loggé dans l’interface de management, on peut trouver le menu “Authentification” (dans le scope Datacenter).

On crée un provider de type OIDC :

Note: l’URL que vous devrez mettre dans issuer URL est de la forme https://mykeycloak.myexample.org/auth/realms/myrealm

Une fois que c’est fait, vous pouvez vous délogger. Dans le menu des “Realm” (les Realm au sens “Proxmox VE”, cette fois-ci) doit apparaitre maintenant “keycloak”.

Une fois que vous le sélectionnez, ça doit donner ça :

Si vous cliquez sur Login, vous serez redirigé sur une mire de login de Keycloak qui devrait ressembler à ça :

(Ou ça, si vous avez suivi le tuto pour gmail)

Enjoy !!

Bonus : debug OIDC

En partant du principe que votre Keycloak est accessible à l’URL mykeycloak.myexample.org et que vous avez créé le realm myrealm, dans lequel existe un user proxmox avec pour mot de passe KEYCLOAKPASSWORD :

curl https://mykeycloak.myexample.org/auth/realms/myrealm/protocol/openid-connect/token --user proxmox:cacf30e8-d71d-4cba-8dd6-cd1bf3661053 -H 'content-type: application/x-www-form-urlencoded' -d 'username=proxmox&password=KEYCLOAKPASSWORD&grant_type=password'

La requête doit renvoyer un access token en JSON

{"access_token":"eyJaaaaaaaaaaaaaaa90A","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJaaaaaaaaaaaaaaa_Ks","token_type":"Bearer","not-before-policy":0,"session_state":"f68a1fcc-7741-4ba7-bea6-51756e81f6e1","scope":"profile email"}

Installer Keycloak 15 sur Ubuntu 20.04 (sans Docker)

Mon, 30 Aug 2021 06:30:00 +0000

Keycloak sur Ubuntu, pour faire de l’OIDC comme un chef

J’en ai parlé un peu lors de l’article sur les soucis que j’ai rencontré lors de mon passage de Proxmox VE 6 à 7 : une des features (surprise en plus) de cette release a été le support d’OpenID Connect pour l’authentification dans Proxmox VE.

Ça fait très longtemps que j’ai envie d’ajouter une authentification externe de type SSO à mon cluster Proxmox VE perso, mais je n’ai pas eu le courage (l’envie) d’installer un LDAP et encore moins un Active Directory (heureusement cette période de ma vie est loin derrière).

Or, je sais que dans les produits permettant de faire de l’OpenID Connect (et du SAML), il y a Keycloak, le IAM récupéré par Redhat et qui cartonne pas mal depuis quelques années maintenant.

Add authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It’s all available out of the box.

You’ll even get advanced features such as User Federation, Identity Brokering and Social Login.

Et il se trouve aussi que j’ai pour plan d’installer, dans les jours / semaines / mois qui viennent un keycloak au boulot pour d’autres besoins qui n’ont rien à voir. Vous me voyez donc venir, j’ai pris les devant et j’ai installé keycloak sur mon infra perso ;-)

Note : dans cet article, on ne va parler que de l’installation de Keycloak. S’il n’y a que ça qui vous intéresse, ne vous inquiétez pas, la partie Proxmox sera traitée dans un autre article.

Pourquoi pas un container Docker ?

La plupart des gens installent keycloak de la façon qui est maintenant mise en avant par beaucoup d’éditeurs quand leur soft est un peu pénible à installer : un container Docker.

Effectivement ça simplifie grandement l’installation, surtout comparé à la doc d’install sans docker qui est pas terrible terrible…

For more details go to about and documentation, and don’t forget to try Keycloak. It’s easy by design!

easy by design ??? p%$$£ç*µ !!!

Alors qu’avec Docker, l’image est prête à l’emploi et « juste marche » (pour peu qu’on sache à peu près faire de l’OIDC ce qui n’était pas mon cas mais ça c’est une prochaine histoire ;-p).

docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:15.0.2

Et donc du coup, nous on va l’installer à la mano

Eux disent que c’est une installation « baremetal ». Enfin, ça, c’est leur terminologie à eux. Moi je vais l’installer dans un container LXC, mais ça aurait très bien pu être installé sur une « vraie » VM Linux, un serveur physique ou un raspberry Pi (des gens l’ont porté sur ARM avec succès).

Keycloak est relativement peu gourmand (surtout pour une application Java !!) et tourne sans broncher dans mon container LXC avec 512 Mo de RAM. Je suis certain que j’aurais pu mettre moins en tweakant la JVM.

L’installation « baremetal » donc se base sur un serveur Wildfly à faire tourner sur un OpenJDK > 8. Une fois mon container LXC (ou ma VM) installée en Ubuntu 20.04, j’ai donc installé le dernier JRE disponible (16)

apt update
apt dist-upgrade
apt install openjdk-16-jre
java -version
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 16.0.1+9-Ubuntu-120.04, mixed mode, sharing)

Dans les autres prérequis que je m’impose moi-même, c’est la création d’un utilisateur Linux non privilégié (ne pas lancer un soft en tant que root sauf si c’est vraiment nécessaire !)

groupadd keycloak
useradd -r -g keycloak -d /usr/lib/keycloak -s /sbin/nologin keycloak

Récupérer la dernière version

Redhat package son soft dans un tar.gz disponible sur github dans la section releases de dépôt principal de keycloak. Vous trouverez aussi des raccourcis sur cette page. Dans mon cas, je n’ai pas essayé encore la version Quarkus (en preview) mais bien la bonne vieille version Wildfly.

cd /usr/lib
wget https://github.com/keycloak/keycloak/releases/download/15.0.1/keycloak-15.0.1.tar.gz
tar xzf keycloak-15.0.1.tar.gz
ln -s keycloak-15.0.1 keycloak
rm keycloak-15.0.1.tar.gz
chown -R keycloak: /usr/lib/keycloak-15.0.1
chmod o+x /usr/lib/keycloak/

Configuration

A partir de là, on a quasiment tout pour démarrer le serveur Keycloak. En vrai, on pourrait déjà lancer le script standalone.sh et ça démarrerait.

Mais ça ne marcherait pas très très bien, car on a pas mal de configuration à faire. Ce genre de procédure cracra m’a rappelé la bonne époque de configuration des produits Redhat et IBM (maintenant la même maison, comme par hasard) qui fleure bon la prise de tête et les erreurs humaines…

La première chose à faire est de créer quelques dossiers et de copier des fichiers :

mkdir /etc/keycloak
mkdir -p /var/run/keycloak
chown keycloak: /var/run/keycloak
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/launch.sh /usr/lib/keycloak/bin/
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/wildfly.conf /etc/keycloak/keycloak.conf
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/keycloak.service

La « blague » c’est que les PATH sont rentrés en durs dans la plupart de ces fichiers et pointent vers « /opt/wildfly » ce qui a peut-être beaucoup de sens pour les gens de chez Redhat mais pas dans mon setup (j’installe keycloak, pas un serveur wildfly, dans /usr/lib, pas dans /opt…).

Comme je suis feignant et que je crains les fautes de frappes difficiles à voir à l’œil nu, j’édite les fichiers incriminés avec des sed. Mais libre à vous de préférer les éditer à la main avec vi (d’ailleurs, ça vaut le coup de vérifier que le fichier est pas en vrac).

sed -i 's!wildfly!keycloak!g' /etc/systemd/system/keycloak.service
sed -i 's!/opt/keycloak!/usr/lib/keycloak!' /etc/systemd/system/keycloak.service
sed -i 's!/opt/wildfly!/usr/lib/keycloak!' /usr/lib/keycloak/bin/launch.sh
#lire la suite avant de lancer la suivante
sed -i 's!\$3$!\$3 -Dkeycloak.frontendUrl=https://keycloak.example.org/auth!' /usr/lib/keycloak/bin/launch.sh

Petite subtilité pour la dernière commande sed, j’ai mis keycloak derrière un reverse proxy pour faire plus joli et ajouter une couche TLS gérée par moi (et pas par wildfly) et arrêter de faire du PLAIN sur un soft d’IAM (facepalm).

(lien mort, je ne suis plus sur Twitter)

Sauf que la totalité liens sur les pages d’admin de keycloak pointaient en HTTP plain qui échouaient donc.

La solution dans ce genre de cas est décrite ici et en gros le plus simple c’est de coller l’URL de votre frontend / reverse proxy dans les paramètres de lancement. Pourquoi faire simple quand on peut faire compliqué ?

Démarrer le service

A partir de là, on a quasiment un keycloak vraiment fonctionnel. Vous pouvez lancer la console :

systemctl enable keycloak.service
systemctl start keycloak.service

La console est accessible sur votre LAN via l’IP de la VM sur le port 8080

Reste la dernière petite subtilité : il n’y a aucun compte pour s’y connecter :trollface:.

On retourne dans notre shell et on lance le script suivant, qui va injecter un bout de XML dans notre conf (qu’est ce que c’est crade… heureusement que le soft est bien au-delà de l’install…)

/usr/lib/keycloak/bin/add-user-keycloak.sh -r master -u youruser
Press ctrl-d (Unix) or ctrl-z (Windows) to exit
Password:
Added 'youruser' to '/usr/lib/keycloak/standalone/configuration/keycloak-add-user.json', restart server to load user

Ah, et bien sûr, comme c’est de la configuration XML en dur, il faut redémarrer wildfly ;-)

systemctl restart keycloak.service

Et maintenant, à partir de là, vous pouvez commencer le “Getting Started”.

Erreur multipath « Path not correctly configured for failover »

Wed, 24 May 2017 14:15:45 +0000

Path not correctly configured for failover

Il y a quelque temps, nous avons du décommissionner une vieille baie HP EVA (qui nous coutait plus cher en maintenance que d’acquérir une baie neuve) et migrer les LUNs vers une baie EMC VNX, elle encore sous maintenance. Cependant, lorsque la migration a été faite, le consultant qui s’est chargé de reconfigurer multipath pour migrer d’une baie à l’autre l’a un peu fait « rapidement ».

Quelques mois plus tard, lors d’une maintenance classique sur une des baies EMC, de grosses anomalies ont été détectés. Lors de la coupure d’un contrôleur pour mise à jour, certains serveurs hébergeant une partie de nos progiciels, encore sous Redhat 4, se bloquaient au niveau I/O au lieu de basculer sur les chemins encore disponibles. L’occasion rêvée pour refaire un peu de multipath !

Dans cet article, je vais donc passer en revue quelques unes des erreurs que j’ai pu rencontrer, et comment les corriger.

Liloo Dallas Multipath ?

D’abord un bref rappel.

Pour ceux qui ne connaissent pas multipath, il s’agit d’un module de Linux qui permet de gérer les chemins multiples vers une même disque. On l’utilise sur des réseaux de stockage d’entreprises qui disposent de plusieurs niveaux de tolérance aux pannes.

Chacun des chemins SAN menant à un même disque (LUN A sur le schéma ci dessus) sont indexés côté OS par leur propre special device du type /dev/sd[n] (4 chemins : sde, sdf, sdg et sdh dans l’exemple).

On ne peut pas directement les utiliser puisqu’on utiliserait dans ce cas là qu’un seul des chemins disponibles. Et écrire en direct sur 2 chemins menant vers un même disque en même temps serait catastrophique.

Heureusement, Multipath détecte de lui même (via l’UUID du disque) que les chemins sont en fait un même périphérique et créé pour nous un fichier spécial /dev/dm-[n] qui permet de pointer vers le disque via l’ensemble de ses chemins.

Vérifier le plus évident

Initialement, l’anomalie n’était pas visible car les vérifications de l’état de multipath n’avaient été faites qu’avec le niveau de détail standard : les chemins sont bien déclarés, visibles et fonctionnels… RAS de ce côté.

# multipath -l
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active]
\_ 1:0:5:3 sdh 8:112 [active]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active]
\_ 1:0:4:3 sdg 8:96 [active]
[…]

De même les modules multipath étaient bien chargés dans le kernel :

# lsmod |grep dm
dm_mirror 32585 0
dm_round_robin 5185 1
dm_emc 7745 1
dm_multipath 22865 3 dm_round_robin,dm_emc
dm_mod 76585 7 dm_mirror,dm_multipath

Cependant, le démon multipathd qui permet de gérer les bascules de chemins est lui hors service…

# service multipathd status
multipathd est arrêté

ATTENTION : Le démarrage du démon multipath peut éventuellement provoquer une coupure des chemins, ce qui va planter le serveur et les traitements en cours. Il faut donc bien prendre garde que le serveur ne soit pas utilisé lors de son activation.

chkconfig multipathd on
chkconfig --add multipathd

Doublons dans les user-friendly device names

Une fois les problèmes basiques réglés, nous avons remarqué que le consultant en question ne s’était pas trop embêté avec les user-friendly names. Voici ce que la commande suivante renvoyait :

# multipath -v2
remove: mpath9 (dup of mpath2)
mpath9: map in use
remove: mpath23 (dup of mpath2)
mpath23: map in use

Bien que non bloquant, ceci est clairement peu élégant ;-).

Comme je l’explique plus haut, multipath agrège les /dev/sd[n] en un seul et unique /dev/dm-[n]. Cependant, il est déconseillé d’utiliser directement le fichier /dev/dm-[n]. En effet, tout comme les /dev/sd[n] (que ce soit dans le cadre de multipath ou pas d’ailleurs), les fichiers /dev/dm-[n] sont susceptibles de changer au cours de la vie du serveur ! De quoi avoir une mauvaise surprise après maintenance…

Pour résoudre ce problème, plusieurs solutions sont conseillées. Soit on utilise le WWID du disque qui est garanti unique, soit on utilise le device mapper qui transpose ce dm-[n] un user-friendly name du type /dev/mpath[n].

Dans le cas présent, au gré de la migration, les WWID avaient générés plusieurs mpath pour un même disque et il n’y avait plus de cohérence !

Pour régler le problème, le plus simple est de couper toutes les applications, puis d’effacer la configuration (pas les données, hein, juste les chemins et la table de correspondance) pour repartir de zéro. On récupère les WWID de chaque disques, puis on supprime tous les chemins courants avec les commandes suivantes :

multipath -ll #affiche les chemins et leurs informations
multipath -F #flush de tous les chemins enregistrés

Une fois les chemins supprimés, il faut modifier le fichier de configuration /etc/multipath.conf pour y ajouter en fin de fichier la déclaration des WWID à associer à des friendly_names fixés manuellement :

[...]
multipaths {
multipath {
wwid "360060160da302f009cd38abe2f5ee111"
alias mpath0
}
multipath {
wwid "36006016067302f00e458ad06345ee111"
alias mpath2
}
}

En enfin, on peut les réenregistrer à l’aide de la commande :

multipath -v2

Mode ALUA 4/PNR 1 pour les LUNs

Pour autant, la vraie cause de l’anomalie n’a pu être détectée que lorsque le mode de détails supérieur a été utilisé pour afficher les chemins (option -ll). Plusieurs messages d’erreurs relativement explicites se sont affichés, et notamment :

la mention Path not correctly configured for failover
les chemins en « [active][faulty] »

multipath -ll
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active][faulty]
\_ 1:0:5:3 sdh 8:112 [active][faulty]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active][faulty]
\_ 1:0:4:3 sdg 8:96 [active][faulty]

Après consultation de ressources en lignes et du « [Host Connectivity Guide for Linux][3] », il apparait que le mode « ALUA 4 actif actif» n’est pas supporté sur les serveurs Redhat Entreprise Linux 4. Il faut utiliser le mode « PNR 1 actif passif» qui lui est bien certifié.

Dans notre cas, c’est pourtant bien ce mode « ALUA 4 » qui avait été déclaré côté baie EMC pour les chemins vers l’hôte. A l’inverse, la configuration qui avait été appliquée côté serveur était bien en mode « PNR 1 ». Il y avait donc une incohérence de ce côté-là.

Changer le mode des LUNs sur une baie VNX

La modification du type de Failover pour un LUN donné peut se faire depuis la console Unisphere mais ce n’est pas évident à trouver !

Une fois connecté, il faut choisir une des baies, ouvrir le menu « Hosts » puis « Host List ». Sélectionner le serveur concerné dans la liste, puis ouvrir l’onglet « Initiators » en bas de page.

Sélectionner un port, puis cliquer sur « Edit », et reconfigurer les 4 chemins.

Valider, et recommencer l’opération autant de fois que nécessaire.

Le mot de la fin

Dans notre cas, beaucoup d’erreurs avaient été faites lors de la configuration des LUNs, de la baie de disques et de multipath. Ça donne donc un bon tour d’horizon des premières choses à vérifier si jamais votre multipath sous Linux fonctionne mal.

Lorsque vous avez comme nous des baies EMC, j’aimerais insister sur le fait que le Host Connectivity Guide for Linux (lien mort, j’utilise Internet Archive) est vraiment un document très important, qui vous aidera à correctement tout configurer. N’hésitez pas à le lire en détail !

Problème de pointeur souris sur la console dans OracleVM 3.4

Thu, 09 Feb 2017 13:00:44 +0000

OracleVM, quelques faiblesses sur la console, comme les autres…

Dans la série des articles sur OracleVM avant que je n’en reparle plus (le PoC est ~~terminé~~ enterré chez nous), voici un petit retour sur un des problèmes que j’ai pu rencontrer.

Comme beaucoup de technologies de visualisation d’écrans consoles pas totalement maîtrisées (ça vaut pour les vieux ILO en Java ou autres : que de bons souvenirs), le pointeur de la souris fait littéralement n’importe quoi. Généralement c’est décalé mais pas de manière linéaire sur tout l’écran pour bien qu’on se marre.

Crédits : GameDev.net

Le problème vient du client web VNC proposé par Oracle VM Manager et est un problème archi-connu mais pour autant pas totalement résolu.

Accéder directement au flux VNC

Comme je l’explique juste avant, il arrive couramment que les technologies de virtualisations intégrées vers l’écran (virtuel) de la machine virtuelle soient mal calibrées. Mais c’est encore plus courant lorsque ce déport d’écran est réalisé avec un connexion VNC elle même affichée dans une console HTTP.

Un moyen de contourner le problème de ce type de clients VNC web (et ça vaut pour d’autres outils qui utilisent les mêmes techniques) est de simplement se « brancher » sur le flux VNC sans passer par la console web. A priori sur les versions précédentes de OVMM, il était possible de se brancher directement sur le flux VNC, tout simplement parce que le serveur VNC était en écoute sur l’interface LAN.

Au delà du fait que ce soit du bidouillage, cette technique n’est aujourd’hui plus permise depuis OVMM 3 et il faut donc … bidouiller encore plus ! Voici ce que propose le support d’Oracle :

You can redirect the remote port to local using the ssh(1) command. For example, the VM guest vnc port is 5900 on Oracle VM Server and listening on localhost:

# xm list -l 2|grep 59
(location 127.0.0.1:5900)

Then you can run this to redirect the port to your desktop:

$ ssh -L 12345:localhost:5900 root@OVS

The « 5900 » port will be redirected to « 12345 » of your local desktop, so that you can run the following command to connect the guest console:

$ vncviewer localhost:12345

En gros, ce qu’il faut en comprendre, c’est que le serveur VNC n’est maintenant plus disponible depuis autre part que localhost et qu’on peut contourner la limitation en faisant un tunnel SSH. Rien de bien sorcier, mais est ce qu’il n’y a pas un peu plus simple ?

La vraie solution

En fait si.

Au début, je n’ai même pas cherché à appliquer cette solution car elle ne s’applique normalement que pour les machines virtuelles Windows.

Si vous avez un problème du type de celui que je décris sur une VM Windows, on vous conseille chez Oracle d’ajouter un paramètre à la machine virtuelle qui permet de mieux suivre les mouvements de la souris.

Add below your config to force the device model to use absolute (tablet) coordinates:

usbdevice=’tablet’

Mais sur le papier, la solution est bien indiquée « For Windows virtual machines (guests) ». Mon problème moi, c’était sur les machines virtuelles CentOS, indiquées comme pas impactées par ce genre de problèmes.

Bon j’ai bien compris ou tu veux en venir. Comment on modifie ce paramètre ?

En fait, c’est TRES mal indiqué dans la documentation. Il s’agit de la configuration de la machine virtuelle, VM éteinte, mais où faire la modification ? Ahah ! Mystère !

La documentation fait elle état d’un fichier de configuration de la machine virtuelle mais je n’ai pas su trouver ce fichier. Cependant, et ce n’était pas dit dans la documentation on peut modifier ce paramètre directement depuis la GUI de Oracle VM Manager !

Dans les paramètres de la machine virtuelle, dans l’onglet Configuration, on trouve le paramètre Mouse Device Type. Sur les machines Windows, comme le problème est connu, il me semble d’ailleurs que le paramètre est passé à « tablet » par défaut.

Une fois validé, on peut vérifier que cette configuration a effectivement été modifiée en affichant ce fameux VM Config File que je ne sais pas où trouver :

A partir de là, la souris ne devrait plus vous faire de blagues. Même si avec Oracle VM, on ne sait jamais trop ;-) #Troll

Source

Humeur : Licence libre, auteurs du web et copyright

Fri, 09 Sep 2016 12:30:36 +0000

Mais ce n’est pas un post technique, ça !?!

Lorsque j’ai commencé ce blog il y a quelques années, j’avais dis que je n’écrirais pas de « billets d’humeur » et me concentrerais sur les sujets techniques peu traités par les autres blogueurs IT Francophone.

Je me garderais de donner mon opinion pour ne pas déclencher de flame wars.

Mais hier soir je suis tombé sur ce tweet du très bon Léo Grasset qui anime (entre autre) la chaine Youtube Dirty Biology :

Le tweet pointe sur un article de blog S.I.Lex de Calimaq et qui relate l’histoire d’une BD sous licence Creative Commons. Je ne défendrai pas l’article en lui même, l’auteur s’en charge.

De quoi s’agit-il ?

D’un comic sur le net, Pepper & Carrot, disponible gratuitement via une licence libre.

Tous les épisodes de Pepper & Carrot sont publiés en libre accès sur Internet via le site de David Revoy et ils ont été placés depuis l’origine sous la licence Creative Commons BY (Paternité). Celle-ci est très ouverte, puisqu’elle autorise toutes les formes de réutilisation (y compris à caractère commercial) à condition de citer le nom de l’auteur.

–Calimaq

Là où d’autres auteurs du web sont furieux, c’est surtout parce que Glénat profite de cette licence très ouverte pour faire un tirage de ces planches et sur lequel l’auteur ne reçoit pas un centime (normal, les sources sont libres de droits).

[Edit]Manque de clarté : il s’agit des auteurs « autres » qui ont réagit en commentaire de l’article de Calimaq, donc Béhé, BouletCorp, … Ce n’est ni Calimaq, ni David Revoy, l’auteur de Pepper & Carrot pourtant le seul concerné[/Edit]

Et pour faire genre ils sont sympas chez Glénat et se faire de la bonne publicité, ils donnent symboliquement à chaque publication nouvelle et selon leur bon vouloir (mécénat).

Mais pas seulement. Je ne peux m’empêcher de réagir quand je vois les réactions (presque violentes) de plusieurs auteurs qui ont commentés pas seulement l’article en lui même mais aussi la démarche « libriste » de son auteur David Revoy, que moi je trouve admirable.

Et là c’est le drame

Franchement en lisant le tweet de DBY, je n’ai même pas compris le problème au début. L’article est plutôt flatteur face à l’initiative (peut être un peu trop?) et je n’arrivais pas à comprendre pourquoi Léo GRASSET avait mis le #entubage. En réalité, je n’arrivais pas à imaginer qu’on puisse voir cette initiative d’un mauvais œil !

Et puis j’ai lu les commentaires.

Un petit « best of »

Je ne remets aucunement en cause les motivations de l’auteur [ahaha, mon œil, attendez la suite] (c’est un combat qui s’apparente au mieux à une révolte contre l’économie du livre tel qu’il est, ou à une résistance au marché, au pire à un sacrifice à la passion ou une servitude volontaire)

- Béhé

[à propos du droit d’auteur]Le recul il est là : la concurrence est telle que les auteurs réussissent à foutre en l’air le seul outil qui leur permettait de faire respecter quelques droits.

- Béhé

D’un côté, on a un auteur qui a créé un univers et qui bosse comme un fou pour pas grand chose, malgré son succès

- Audrey A.

Un investissement sans limites de cet auteur passionné doublé d’un combat quasi politique pro « Open Source » (alors que sous couvert de modernité, on est juste revenu sur la place du marché en plein moyen âge quand les saltimbanques essayaient de vivre des pièces jetées par les passants).

- Audrey A.

Pour ma part il me fait penser à un trader qui liquiderait son portefeuille d’actions la veille d’un crash boursier : à titre individuel il tire son épingle du jeu et on pourrait l’en féliciter mais si on adopte un point de vue plus large on réalise qu’il contribue à accélérer un processus qui laisse tous les autres sur le carreau.

- Emlyn

Je résume & simplifie : l’auteur est donc un militant de l’open source qui se fait entuber par une maison d’édition qui fait de l’argent sur son dos. Ce monsieur contribue à renvoyer au moyen âge les artistes qui finiront à la rue dans les années qui viennent.

Je ne citerai même pas le condescendant BouletCorp (gratuitement en plus) qui a carrément écrit un e-mail à David Revoy pour lui expliquer à quel point il est sot (mais met quand même une copie du mail publiquement dans les commentaires histoire d’enfoncer un peu le clou).

Et l’article de Calimaq dans l’histoire ?

Tous les auteurs sont d’accord sur un point : Calimaq (l’auteur de l’article sur S.I.Lex) n’a rien compris !

Je suis un peu consternée par cet article qui témoigne quand même d’une méconnaissance de l’économie du livre assez monumentale

Je rétorquerais donc à nos amis auteurs que si (moi) je n’ai assurément pas la connaissance qu’ils ont de l’économie du livre, je suis pour ma part consterné par leur méconnaissance du monde libre. ;-)

Je pense qu’ils n’ont pas compris la démarche « libre » dans leur ensemble (pas seulement cet auteur donc), que ce soit la Creative Commons ou les alternatives Open Source ou Libre. Et c’est d’autant plus dommage en cette période d’actualité sur les dérives du droit d’auteur.

Je vais donc tenter de détailler un peu ce point en particulier.

Mon avis sur les licences CC et « le combat quasi politique pro Open Source »

A vrai dire, je ne sais pas pourquoi j’ai été surpris. Car cette attitude de défiance et d’incompréhension, je l’ai vécu et continue de la vivre tous les jours :

Pourquoi tu contribues au logiciel Open Source d’un autre ? C’est du travail jeter en l’air pour ne rien gagner !

Pourquoi développes-tu un logiciel Open Source ? Pourquoi fourni tu du support gratuitement à ta communauté ? Tu ferais mieux de le commercialiser : tu te rend compte de tout l’argent que tu perds/pourrais gagner?

Je ne comprend pas ces gens qui mettent à disposition du code source sur Internet ! Des grosses entreprises vont le reprendre et faire de l’argent sur le dos de l’auteur, qui n’aura rien !

A l’instar de ces phrases entendues IRL, les auteurs qui commentent l’article sur S.I.Lex ne parlent QUE d’argent.

A en croire que c’est la raison d’être de la création : faire le plus d’argent possible… Vraiment ?

Et là où Calimaq à tort à mon avis, c’est lorsqu’il entre dans ce jeu et tente de justifier économiquement le choix de l’auteur de la BD.

Alors qu’en réalité, dans ce genre de cas, il n’est pas question d’argent, de rentabilité, de rémunérer l’auteur à la juste hauteur de son travail.

On n’est sur des considérations totalement autre ! L’idée, c’est de mettre à disposition du public un univers et de le faire vivre en dehors du droit d’auteur, bien souvent trop « privateur » (et voilà : on va me traiter de militant politique pro open source maintenant).

Monde libre vs Copyright

Et du coup ça me donne une belle transition : je repense à la dernière vidéo de Léo GRASSET (DBY).

L’auteur de la vidéo nous parle de sciences citoyennes en faisant le parallèle avec Pokemon Go. Son frère (bon graphiste) incruste des animations de Pokemons… qui sont très probablement soumis au droit d’auteur !

Voilà un bel exemple de l’apport d’une licence libre sur le copyright : si Pokemon était libre de droits, DBY pourrait ajouter des Pokemons dans ces vidéos sans demander le droit préalable à « The Pokemon Company » (je simplifie volontairement les exceptions au droit d’auteur).

Dans le cadre du droit d’auteur, on pourrait imaginer que « The Pokemon Company » pourrait imposer à Dirty Biology le versement d’un compensation financière pour avoir le droit d’incruster des Pokemon (potentiellement importante) et qui aurait contraint Léo GRASSET à abandonner son idée de vidéo pourtant très bonne.

A l’inverse, moi, j’ai mis le logo de Pepper & Carrot sur cet article. La seule chose que j’ai à faire, c’est cite que l’auteur est David Revoy. Pas de contraintes de droit d’auteur, pas de notions de rémunération.

Pour ceux qui veulent creuser un peu plus loin ce point, la fondation Mozilla en parle beaucoup mieux que moi.

Autre exemple un peu facile mais que je met quand même pour le fun

J’ai envie de faire un parallèle avec un domaine que je connais mieux : l’informatique.

Linus Torvalds

Auteur il y a 25 ans d’un système d’exploitation libre (un « hobby » à la base, just saying) mis à disposition gratuitement.

Redhat

Premier éditeur de solution Open Source au monde, avec un CA annuel de 2 milliards de $.

A première vue, si on se met des œillères, c’est des gens qui vendent des logiciels gratuits.

En fait, en réalité, c’est aujourd’hui un des plus gros moteurs de l’open source au monde (sans que ce soit des philanthropes, hein, ils font du business, nous sommes d’accord).

Et avec les bénéfices qu’ils font en fournissant du support sur ces « logiciels gratuits », ils peuvent :

Contribuer à corriger/sécuriser le code de nombreux projets Open Source pour le rendre plus robuste et plus sûr
Investir en R&D pour améliorer les solutions Open Source existantes
Développeur de nouvelles solutions Open Source
Employer des milliers de personnes dans le monde (accessoirement)

Le rapport entre les deux ?

Redhat n’aurait jamais existé si Linus Torvalds n’avait pas mis à disposition gratuitement son « hobby », Linux.

Et le rapport avec Pepper & Carrot ?

Et si je fais le parallèle avec l’histoire de Pepper & Carrot et que j’applique le raisonnement de BouletCorp et consorts on obtient :

Linus Torvalds a bossé comme un fou pour pas grand chose

Redhat fait de l’argent sur le dos de Linus Torvalds

Linus Torvalds contribue à foutre sur le carreau les développeurs informatiques

Aucunes de ces phrases n’ont de sens.

Le monde libre

Au delà de Linux et Redhat, l’open source a changé ma façon de travailler. Celle de millions de gens dans le monde aussi (particuliers, écoles, associations, entreprises, développeurs, chercheurs, …), mais je suis surtout mieux placé pour parler de moi.

Et soutenir les initiatives libres ne m’empêche pas d’utiliser des logiciels propriétaires par facilité ou lorsque les alternatives Open Source ne sont pas à la hauteur. L’un n’empêche pas l’autre.

Toute démarche libre/open source à ses implications (et le droit d’auteur aussi !). Elles sont différentes selon la licence choisie et les auteurs qui font le choix d’une licence libre doivent bien sûr le faire en connaissance de cause.

En tant qu’auteur (selon la législation du droit d’auteur Français, tout ce que je créé est par défaut soumis au droit d’auteur), en fonction du contexte, je sais choisir entre :

mon droit d’auteur classique quand je fais un montage vidéo, quand je créé une image humoristique, quand j’écris un article de blog
une licence un peu solide comme la GPLv3 lorsque je souhaite contribuer du code en sachant qu’il sera peut être complexe pour un outil commercial de réutiliser mon code dans certains cas particuliers
des licences plus souples lorsque j’accepte (et même aimerait) que mon travail soit diffusé. Même dans un cadre commercial où des gens se feront peut être « de l’argent sur mon dos »

Pourquoi tant de haine ?

Cette posture agressive et cette montée aux créneaux immédiate de ces quelques auteurs du web sur cet article traduit pour moi un profond malaise entre les auteurs et les éditeurs, qui ont du mal à s’adapter (et adapter le droit d’auteur) au 21ème siècle.

Il n’est pas difficile de comprendre pourquoi des gens ont peur de modèles alternatifs lorsque le modèle actuel n’est déjà pas terrible, de peur que ce soit pire après.

Et à entendre les auteurs, la compétition est rude et il est difficile de se financer en tant qu’auteur. Dans le monde actuel, vouloir faire de l’argent en tant qu’auteur de BD sur une Creative Commons n’est probablement pas la meilleure idée.

Pour autant, je pense que les auteurs qui ont répondus dans le billet de S.I.Lex ont tort de voir une concurrence là où il n’y en a pas.

De ce que je comprendre de « Pepper & Carrot », mais plus généralement des initiatives CC, ce n’est pas la recherche un modèle alternatif pour se financer dans un secteur hautement concurrentiel.

C’est la mise à disposition, pour tout le monde, d’un travail ouvert, partagé.

Bonus

Je n’avais pas compris initialement, mais l’auteur de la BD lui-même a contribué dans les commentaires (deevad) et donne quelques infos supplémentaires dans ce lien.

Bonus 2

Un exemple tout frais de cette semaine des préjugés et de l’incompréhension de ces gens qui sont restés dans le 20ème siècle.

Développeur d’un produit Open Source de partage de fichier révolutionnaire = Pirate.

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

Accélérer le rebuild/resync d’un volume RAID mdadm

Wed, 04 Mar 2015 14:00:45 +0000

Débrider la reconstruction (resync) du RAID MDADM

Ça fait plusieurs fois que je tombe sur des articles de blogs qui détaillent que la reconstruction (resync) de leur miroir MDADM (RAID1) est trèèèès lente à cause d’un paramètre système dans /proc :

/proc/sys/dev/raid/speed_limit_min

Par défaut sous Linux (ou au moins la plupart des distribs que je côtoie), ce paramètre « min » est fixé à 1000, soit grossièrement 1Mo par seconde, ce qui est effectivement très lent, à l’heure des disques grand public de 6 To (ou 8? ou 10, je ne suis pas sûr d’être à jour).

Personnellement, je n’ai jamais été bloqué par ce paramètre comme ces personnes, au moins sur les distributions récentes (tout est relatif, en 2015 je parle de 2012 et +). Il s’agissait peut être d’un bug fixé depuis, qui sait?

Par contre, là où j’ai été effectivement bloqué, c’est plutôt par la variable /proc/sys/dev/raid/speed_limit_max.

cat /proc/mdstat
md1 : active raid1 sdc[0] sdd[1]
336592832 blocks [2/2] [UU]
[===========>.........] resync = 59.4% (199958272/336592832) finish=11.3min speed=200006K/sec

Quoi, mes disques resync à 200006K/sec? Comment dire ? C’est louche !

En effet, cette valeur est fixée par défaut à 200000, soit 200 Mo/s. Ça peut paraitre assez haut pour du RAID à la maison, mais sur du matériel d’entreprise, je n’ai pas eu de mal à atteindre cette limite.

cat /proc/sys/dev/raid/speed_limit_min
1000
cat /proc/sys/dev/raid/speed_limit_max
200000

echo 500000 > /proc/sys/dev/raid/speed_limit_max
cat /proc/mdstat
md1 : active raid1 sdc[0] sdd[1]
336592832 blocks [2/2] [UU]
[===============>.....] resync = 76.4% (257424960/336592832) finish=2.6min speed=505767K/sec

« And voila »

[Tutoriel] Cluster Oracle 11gR2 avec Redhat Cluster Suite sur CentOS 5.4 (offline)

Sun, 15 Apr 2012 07:54:09 +0000

J’avais pour objectif de proposer une architecture sous Redhat permettant d’héberger en clustering une base de données Oracle en mode actif/passif (sans RAC donc) pour un nouveau client. L’architecture actuelle/connue était à base de serveurs HP-UX fonctionnant avec un cluster HP MCSG qui fonctionnait très bien, mais pour des raisons de support sur l’ERP le passage à Linux était obligatoire.

MCSG sur Redhat n’étant pas encore (est ce que ça va changer?) supporté officiellement par Redhat et HP, et heartbeat étant une solution trop légère pour ce genre d’application critique au business, il a bien fallut que je fasse une maquette basée sur Redhat Cluster suite. Le faible nombre de blogs traitant du sujet et le nombre d’échecs parmi les rares articles que j’ai trouvés auraient du me mettre la puce à l’oreille quant à la difficulté d’installation/configuration de ce produit. Et pour cause : malgré une documentation officielle relativement bien faite, certains passages sont carrément obscur pour ceux qui rentrent dans le sujet sans expérience préalable des clusters.

Ayant galérer pour faire marcher la solution dans les grandes lignes, je pense qu’il est de mon devoir (oui oui, rien que ça :-p) de faire partager la documentation que j’ai tiré de mes diverses expérimentations :

La documentation en elle même zwindler_redhat_cluster_suite
Le fichier doc qui contient les scripts. Oui, c’est affreux mais wordpress n’autorise en upload que quelques extensions et je n’ai pas l’envie de chercher une solution de contournement…

Autre chose : au début, je pensais qu’être coupé d’Internet sur les serveurs d’un admin n’était pas monnaie courante. Avec le peu de recul que j’ai aujourd’hui, je me rend compte que je subis très régulièrement cette contrainte! Ayant été obligé de me passer du net sur ma maquette, j’ai aussi indiqué les solutions de contournement que j’ai trouvé dans la documentation, au cas où certains seraient dans la même configuration.

Cependant, dans tous les cas, je ne conseille pas l’utilisation de RHCS sur une prod si vous débutez et/ou si vous n’avez pas d’accès à Internet pour effectuer des mises à jours du système : les bugs de cette version ainsi que les erreurs de débutant que j’ai pu faire sur ma maquette auraient assez vite corrompu la base de données d’une production.

N’hésitez pas à me faire remonter toute imperfection dans la documentation, que je puisse corriger pour les suivants