Migration on Zwindler's Reflection

J'ai enfin migré de Wordpress vers Hugo - partie 2

Mon, 29 Nov 2021 08:00:00 +0000

Cette article fait partie d’une suite d’articles :

Extraire les données de WordPress

Normalement si vous avez lu la première partie, vous savez qu’on a un Hugo fonctionnel (mais vide). Et que dans mon cas, l’objectif était de migrer 12 ans d’historique (350 articles tout de même) de Wordpress vers notre Hugo.

Vous vous en doutez, le but n’est pas de reprendre les articles uns par uns (sauf si vous n’en avez qu’une dizaine, ça doit se faire) mais bien de trouver une méthode pour exporter le contenu existant en markdown pour repartir comme si de rien n’était.

La documentation officielle de Hugo donne plusieurs pistes pour migrer depuis Wordpress et c’est la première que j’avais utilisé en 2019 (la première fois que j’avais tenté de migrer, sans succès). J’ai re-installé l’extension wordpress-to-hugo-exporter (je vous invite quand même à regarder les alternatives car il n’est pas impossible que ça ait évolué depuis).

wordpress-to-hugo-exporter

La première chose à faire pour installer cette extension est de vérifier que votre serveur qui héberge le WordPress dispose bien de l’extension PHP zip.so.

cat /etc/php.d/40-zip.ini
; Enable ZIP extension module
extension=zip.so

On peut ensuite cloner le projet git du plugin directement dans le dossier plugin de WordPress

cd PATH_TO_WORDPRESS/wp-content/plugins/
git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter

A partir de là, il est possible de démarrer un export soit depuis l’interface, soit via un script en PHP lancé depuis le serveur en ligne de commandes. Évidemment, dans ce genre de procédures, on arrive toujours à un moment où on se tape un timeout quelque part. Dans mon cas, les données exportées (articles + medias, environ ~1.5 Go) prenaient 500 Mo de RAM et 20 minutes d’exécution.

On oublie donc le clic dans l’interface (sauf à tuner votre nginx pour autoriser des requêtes clients avec un timeout > 60s) et on lance depuis la ligne de commande. Et bien entendu, on augmente toutes les limites possibles et imaginables, notamment celle de wordpress via le fichier wp-config.php.

// Set initial default constants including WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DEBUG, SCRIPT_DEBUG, WP_CONTENT_DIR and WP_CACHE.
wp_initial_constants();
define( 'WP_MEMORY_LIMIT', '2048M' );
define( 'WP_MAX_MEMORY_LIMIT', '2048M' );

cd PATH_TO_WORDPRESS/wp-content/plugins/wordpress-to-hugo-exporter/
php hugo-export-cli.php memory_limit=-1

Qui devrait se terminer, si tout se passe bien, par un :

This is your file!
/tmp/wp-hugo.zip

Note: on peut également exporter les commentaires, il faut modifier manuellement une ligne dans le fichier hugo-export.php (voir la doc)

A partir de là, on a une archive qui contient vos posts, vos pages et vos médias importés (grosso modo tout wp-content).

L’archive a l’arborescence suivante :

un dossier posts qui contient tous les articles (posts dans la terminologie wordpress) dans un mélange de markdown + html brut (ce qui n’aura pas été correctement converti, on y reviendra)
un dossier wp-content qui contient tous les médias
des dossiers pour chacune de vos “pages (“à propos”, “mentions légales”, etc).

Importer dans Hugo

L’arborescence de Hugo est elle un peu différente. De base, tout ce qui est markdown doit être dans content, avec des sous dossiers en fonction du type de page (post ou page).

La première petite “blaguounette” est que les posts doivent être déposés dans le sous-dossier content/post (sans S à la fin !!!).

Chaque post commence par des métadonnées encadrées par des triples tirets “—” avant et après. Ca donne quelque chose comme ça :

---
title: 'ESXi 4.0 : Explorons l&rsquo;Hidden Console Part 1'
authors:
 - zwindler
type: post
date: 2010-04-28T08:32:20+00:00
url: /2010/04/28/esxi-4-0-explorons-lhidden-console-part-1/
featured_image: https://blog.example.org/wp-content/uploads/2014/10/vmware-220x162.jpg
categories:
 - Virtualisation
tags:
 - ESX(i)
 - Hidden Console
 - SSH
---

[L'article lui même...]

Ca peut différer un peu selon les thèmes je pense, mais grosso modo les markdown des pages iront eux dans content/page.

Enfin, tout ce qui est media (dossier wp-media) va dans un dossier static. On peut garder la même arborescence que wordpress (/année/mois/) mais rien ne nous y oblige.

So far, so good

Emile et Images

Enfin… so good, c’est vite dit…

Et oui parce que l’exporter n’exporte pas hyper bien un certain nombre de choses, à commencer par l’image de garde de chaque article :

featured_image: https://blog.example.org/wp-content/uploads/2014/10/vmware-220x162.jpg

On peut remarquer plusieurs soucis avec cette variable. D’abord, la variable utilisée pour indiquer le chemin de l’image dans les métadonnées générées est featured_image alors qu’Hugo attend image. Petit sed sur vos md pour corriger ça :

sed -i "s/featured_image/image/g" fichier.md

Mais bien sûr, ce n’est pas fini ;-)

Ensuite, on remarque qu’on a un chemin est une URL complète et non pas relative. Si vous gardez les média dans le chemin static/wp-content/uploads/YYYY/MM ça marchera, mais je trouve ça moche.

2 solutions :

on supprime /wp-content/uploads avec un bête sed -i "s!/wp-content/uploads!!g fichier.md
on passe en relatif en supprimant carrément toute la première partie de l’URL https://yourblog.example.org/wp-content/uploads

Si vous choisissez la 2ème solution (mon choix), faites quand même bien attention. En fonction de comment vous rédigez votre expression régulière, ça pourrait affecter aussi toutes les autres images que vous auriez en lien dans vos articles. Ce n’est pas forcément une mauvaise chose (moi j’aime mieux les liens relatifs car c’est plus flexible) mais ça demande un travail supplémentaire.

Images intermédiaires

Toujours dans les images, vous remarquerez aussi que l’image “mise en avant” (dans les métadonnées) possède un suffixe de type -111x222 juste avant l’extension. En fait, chaque fois que vous importez une image dans wordpress, celui ci la convertie en plusieurs tailles pour accélérer le chargement des pages.

Sauf que le wordpress-to-hugo-exporter choisi une des plus petites résolution pour l’image en tête de l’article. Ca sera souvent hyper moche…

Là encore, j’ai donc passé un gros sed pour virer tous les suffixes -111x222 avant l’extension, puis je n’ai copié QUE les images originales dans le dossier static (regex non triviale) :

cd PATH_TO_EXPORT/wp-content/uploads
for i in `seq 2010 1 2021`; do
 find $i -mindepth 1 -type f -regextype posix-egrep -not -iregex ".*/.*-[0-9]{1,4}x[0-9]{1,4}.*\..*" -exec cp {} PATH_TO_HUGO/static/{} \;;
done

Nettoyer les caractères spéciaux HTML

Si vous avez bien lu l’exemple de métadonnées exportées que j’ai donné, vous aurez peut être remarqué la présence d’un caractère spécial encodé ’ dans le titre.

Dans une page HTML, ce n’est pas grave, mais Hugo lui, ne les interprète pas comme tel dans le markdown. Il faut donc leur faire la chasse et tous les convertir 🤦. Et encore, il faut faire attention, car certains de ces caractères pourraient être légitimement écris en HTML (si vous faite un tuto sur HTML, ce n’est pas impossible par exemple)…

J’ai pour ma part lancé un gros sed (une fois de plus) sur tous mes articles mais prudence !

sed -i "s/&rsquo;/’/g" $1
sed -i "s/&#8211;/--/g" $1
sed -i "s/&#8230;/.../g" $1
sed -i "s/&gt;/>/g" $1
sed -i "s/&lt;/</g" $1
sed -i "s/&#8212;/-/g" $1
sed -i "s/&#8217;/'/g" $1
sed -i "s/&#215;/×/g" $1

Je n’ai pas osé modifier les caractères suivants, très souvent présents dans les URLs :

&#038
&#039
&quot;

Mais c’est quand même une bonne idée de faire une grosse recherche avec votre éditeur de texte favori pour voir s’il ne reste pas des &# qui traînent dans votre contenu.

HTML désactivé

Au delà des caractères spéciaux, il arrive aussi que l’exporter est un peu de mal avec les différents types d’éditeurs que Wordpress a pu avoir au fil du temps.

Typiquement, beaucoup du contenu “non texte” que j’ai ajouté au fil des années s’est retrouvé non converti par ce que j’ai rédigé s’est retrouvé exporté tel quel, en HTML brut inséré dans mon markdown.

C’est hyper traître car Hugo ne renvoie aucune erreur. Il manque “juste” des bouts ! On peut les retrouver en allant voir le code source de la page, qui affiche alors les commentaires HTML suivants :

<!-- raw HTML omitted -->

En attendant de nettoyer tout ça à grand coup de sed, on peut résoudre une partie des problèmes en “réactivant le support du code HTML dans le markdown dans votre config.yaml.

markup:
 goldmark:
 renderer:
 ## Set to true if you have HTML content inside Markdown
 unsafe: true

Ca permet de sauver les meubles mais ce n’est pas suffisant…

Markdown hates HTML

Même comme ça, on grosse partie du HTML sera HS… Tous les tableaux (table/tr/td) et listes (ul/li) HTML sont pétés car l’exporter laisse des sauts de lignes entre les blocs, que le markdown interprète mal. Il faudra supprimer tous les sauts de lignes en trop (ou réécrire en markdown)

<table class="Content" border="0" width="750">
<tr>
<td class="LargeBold">
SEND_CUSTOM_SVC_NOTIFICATION
</td>
</tr>
<tr>
<td class="MediumBold">
Command Format:
</td>
</tr>

Sachez également que toutes les “videos embedded” Youtube disparaîtront purement et simplement, et que pour les tweets, vous aurez une version très moche du tweet, sans l’image…

<blockquote class="twitter-tweet" data-width="550" data-lang="en" data-dnt="true" data-partner="jetpack">
 <p lang="fr" dir="ltr">
 [[#SAPHANA](ht tps://tw itter.com/hashtag/SAPHANA?src=hash&ref_src=twsrc%5Etfw)] Finies les mises à jour incompatibles avec votre plateforme, optez pour la simplicité et la tranquillité, chez SAP : on collecte, on connecte, ça marche : [t.co/2AdCCEQ97L](https://t.c o/2AdCCEQ97L) [pic.twi tter.com/yy7moMnZmC](ht tps://t.c o/yy7moMnZmC)
- SAP France (@SAPFrance)

 [October 8, 2018](ht tps://twiter.com/SAPFrance/status/1049286253533962241?ref_src=twsrc%5Etfw)
</blockquote>

J’en avais peu heureusement, j’ai donc pris des captures d’écran et ajouté des liens.

Balises de code, pre, etc.

Une autre grosse catégorie de code “mal exporté” est le “code”. Je donne souvent des bouts de scripts ou de code ou tout simplement des commandes à passer sur des serveurs. Et au fil des années, j’ai (& wordpress) changé plusieurs fois la façon d’afficher du code dans mes articles.

D’abord avec des balises HTML <pre></pre>, puis des balises <code></code>, puis via des extensions (pour avoir la coloration syntaxique), puis via du markdown via Jetpack, puis de nouveau via les extensions…

Autant dire que le HTML généré par Wordpress ne ressemble à rien…

Il a fallut faire un gros gros boulot pour détecter toutes les balises de code ouvrantes et fermantes pour les convertir en ``` de markdown…

Quelques exemples que j’ai rencontré :

<pre>

<pre class="brush: plain; title: ; notranslate" title="">
<pre class="brush: perl; collapse: false; title: ; wrap-lines: false; notranslate" title="">

<pre class="EnlighterJSRAW" data-enlighter-language="null">
<pre class="EnlighterJSRAW" data-enlighter-language="generic">
<pre class="EnlighterJSRAW" data-enlighter-language="generic" data-enlighter-theme="" >
... et bien d'autres encore

Final words

Je m’arrête là car l’article est déjà très long, mais il y a eu d’autres petits problèmes du même style, plus sporadiques…

Vous voyez donc qu’exporter le blog sur Hugo n’aura pas été de tout repos, dans mon cas. Et encore ! Je n’ai pas exporté les commentaires historiques (plus de 1600) !

Cependant, si vous avez un blog plus petit que celui ci, vous devriez avoir moins de mal et les conseils que je donne ici devraient vous permettre de régler rapidement 90% des problèmes.

Enjoy !

J'ai enfin migré de Wordpress vers Hugo - partie 1

Mon, 22 Nov 2021 08:00:00 +0000

Cette article fait partie d’une suite d’articles :

Plus de 2 ans et demi

Ca fait plus de 2 ans et demi que je râle que j’en ai ma claque de Wordpress.

Stack LEMP à maintenir, perfs bof (j’ai du mettre un cache pour passer sous la seconde, wtf…), plugins aux MAJs hasardeuses, failles de sécu, pas de support propre du markdown, éditeur à ch*** (Gutenberg, je te hais), … you name it.

Après 12 ans de blogging, il était temps de faire l’effort et de quitter Wordpress pour quelque chose qui me convient mieux : un moteur de blog statique (rien de dynamique dans ce que je poste) en markdown (parce que de toute façon c’est comme ça que j’écris mes articles à la base). Le tout dans git pour historiser tout ça.

Et j’ai choisi Hugo pour des raisons que je détaille dans l’article 2019 “Comment migrer de Wordpress à Hugo” si ça vous intéresse.

Forcément, c’est pas si facile

J’en parlais déjà dans l’article de 2019 : migrer de Wordpress à Hugo, forcément ce n’est pas si facile. D’ailleurs, j’avais même abandonné l’idée devant l’ampleur da tâche !

Ce n’est pas tant la partie technique (installation de Hugo, export du blog existant) le problème. En quelques minutes, on a un blog fonctionnel, l’export prend guère plus de temps. Rajouter l’outillage pour automatiser certaines tâches prend un peu de temps mais rien d’incroyable.

Mon problème était plutôt que je voulais obtenir au moins aussi bien que ce que j’avais avant, existant inclus.

Et c’est là que le bat blesse : wordpress, avec mes 12 ans (350 articles) d’historique, c’est au fil des années 15 façons différentes d’afficher du HTML… que le plugin d’export gère comme il peut ! Nous y reviendrons.

Je vais donc vous guider un peu sur la partie technique, puis j’aborderai ensuite les points pénibles du nettoyage du markdown, qui m’a pris un bonne partie de mes vacances (plusieurs journées à ~2-3 heures par jour). Il y aura aussi, plus tard, des articles sur l’outillage à mettre en place pour se faciliter la vie au quotidien.

Installation

L’installation en elle même est triviale. On a un binaire compilé en go packagé dans un .deb (ou les sources si vous voulez le builder vous même) disponible sur github. Fin.

sudo apt update
sudo apt upgrade

export VER="0.88.1"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_${VER}_Linux-64bit.deb
# ou https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_extended_${VER}_Linux-64bit.deb
sudo apt install ./hugo*_0.88.1_Linux-64bit.deb

A noter que dans mon cas, je n’ai pas téléchargé la version ci dessus, mais la version “extended”, nécessaire pour le thème que j’ai choisi, mais le principe est le même.

Initialisation du site et du dépôt git

Hugo est maintenant disponible sur votre machine.

A partir de là, je vous invite fortement à versionner tout ce que vous allez faire avec votre blog. C’est bien entendu optionnel mais pourquoi se priver de toute la puissance du couple markdown + git ?

On commence par créer un dossier puis on génère un squelette de site vierge avec hugo new site :

mkdir hugo && cd hugo
hugo new site toto
Congratulations! Your new Hugo site is created in toto.
Just a few more steps and you're ready to go:
1. Download a theme into the same-named folder.
Choose a theme from https://themes.gohugo.io/ or
create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".
Visit https://gohugo.io/ for quickstart guide and full documentation.

A partir de là, on va pouvoir initialiser notre dépôt git

cd toto
git init

Bon, si jamais vous lancez la génération du blog avec simplement la commande de preview hugo server, vous allez être assez déçus, ça donne une page blanche. Mais, ça marche !

hugo server
Start building sites …
hugo v0.88.1-5BC54738+extended linux/amd64 BuildDate=2021-09-04T09:39:19Z VendorInfo=gohugoio
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

 | EN
-------------------+-----
 Pages | 3
 Paginator pages | 0
 Non-page files | 0
 Static files | 0
 Processed images | 0
 Aliases | 0
 Sitemaps | 1
 Cleaned | 0

Built in 1 ms
Watching for changes in /toto/{archetypes,content,data,layouts,static}
Watching for config changes in /toto/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Ajout d’un thème

Avant même de commencer à ajouter du contenu, il est probable que vous allez vouloir choisir un thème. Il existe une liste de thèmes, plus fournie qu’en 2019, disponible ici.

Une fois le thème choisi, on va l’ajouter au site à l’aide de la (très utile) commande git git submodule qui va nous permettre de gérer notre thème et ses mises à jour avec git sans pour autant commiter tous les fichiers.

Dans mon cas j’ai choisi le thème “stack” mais le principe est grosso modo le même pour tous (à quelques détails d’implémentation près) :

cd themes/
git submodule add https://github.com/CaiJimmy/hugo-theme-stack.git
cd ..

Avant le premier article !

Si on veut bosser un peu proprement, on va vouloir éviter de commiter n’importe quoi. Comme hugo est un générateur de blog statique, on va bien entendu éviter de commiter le code statique généré par la commande hugo.

On utilise simplement un fichier .gitignore à la racine du projet pour ignorer tout ce qui est technique ou qui n’est pas du code :

cat > .gitignore << EOF
themes
resources/_gen
assets/jsconfig.json
public
EOF

On va aussi vouloir paramétrer a minima notre site. Vous aurez peut être remarqué qu’il existe un fichier config.toml généré par défaut par la commande hugo new site. Il s’agit de “l’ancienne” manière de faire de la configuration Hugo, mais surtout d’un fichier agnostique du thème utilisée. Généralement, il vaut mieux le supprimer et repartir du fichier d’exemple inclus avec votre thème.

Dans mon cas, il s’agit du fichier theme/hugo-theme-stack/config.yaml que j’ai donc copié à la racine du projet et modifié pour correspondre à mon site et mes besoins.

baseurl: https://blog.zwindler.fr
languageCode: fr-fr
theme: hugo-theme-stack
title: "Zwindler's Reflection"
[...]

Le premier commit

C’est un petit moment agréable dans n’importe quel projet informatique. Le premier commit.

Bon moi, comme j’ai hébergé le dépôt sur Github et qu’ils ont décidé de renommer master en main dans le nom de la branche par défaut on a un peu de gymnastique à faire, mais pourquoi pas.

git add .
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:zwindler/example.org.git
git push -u origin main

Le “code” de notre (absence de) blog est publié Internet :)

Et en prod ?

Vous pouvez donc commencer à écrire (dans content/post), tester votre blog en local, puis pousser le code sur git. Mais si jamais vous voulez héberger votre site ailleurs que sur votre laptop (et je parie que c’est le cas) ?

Et bien c’est là où c’est chouette d’utiliser git et un dépôt accessible depuis Internet. Vous n’avez qu’à reproduire l’installation de hugo, ajouter votre dépôt, initialiser les submodules (notre thème) et le tour est joué !

export VER="0.88.1"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_${VER}_Linux-64bit.deb
# ou https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_extended_${VER}_Linux-64bit.deb
sudo apt install ./hugo*_0.88.1_Linux-64bit.deb

git clone https://github.com/zwindler/toto.git
git submodule init
git submodule update

hugo

Normalement, le site devrait se générer, comme en local. Si vous n’avez pas d’historique à migrer, comme moi, vous êtes donc l’heureux propriétaire d’un blog statique fonctionnel :-). La classe !

Sinon, dans le prochain article, j’aborderai un plus gros morceau, à savoir l’export et le nettoyage du markdown depuis un Wordpress existant.

Migration CentOS + KVM vers Proxmox VE

Sat, 21 Nov 2015 11:30:53 +0000

Juste après avoir sorti un article qui traite de la migration de KVM/Ubuntu vers KVM/RHEL, voilà que je migre ENCORE pour ProxMox !?! Mais c’est parce qu’en fait j’avais juste beaucoup de retard sur ces précédents articles ;-).

Présentation de la solution

Cette fois ci, il s’agit donc de vous donner les clés pour migrer sans stress votre serveur sous KVM (Ubuntu, Debian, RHEL, Whatever …) vers Proxmox VE.

Pour ceux qui ne connaissent pas Proxmox VE, il s’agit d’une distribution Debian adaptée pour faire de la virtualisation full (qemu/KVM) et par conteneur (anciennement via openVZ, maintenant via LXC). LE gros plus de la solution, c’est l’interface graphique et l’installation clé en main d’un hyperviseur disposant de fonctionnalités qu’on retrouve chez les grands du marché.

Pour être honnête, j’étais très content de mon KVM pour ce qui est des performances et de la consommation de ressources (point faible d’un ESXi à la maison), mais pas du tout satisfait des manières que j’avais pour l’administrer. J’ai testé plusieurs interfaces graphiques (web ou pas) sans jamais en trouver une à ma convenance (même les usines à gaz comme oVirt, la base de RedHat Entreprise Virtualisation).

Installation

Comme beaucoup d’hyperviseur clés en main, l’étape d’installation est particulièrement soignée pour être simple et rapide. On récupère un ISO, on le copie sur une clé USB, on boot dessus. Quelques écrans et moins de 5 minutes plus tard le serveur reboot et on nous invite à nous connecter à la console web.

Ah ! Ça fait du bien !

La première chose à faire est de créer des pools de stockages (un local est créé par défaut). On peut choisir s’il s’agit d’un pool dédié aux VMs, à la sauvegarde, aux fichiers ISOs. C’est assez pratique.

RAID logiciel MDADM

Sous ProxMox, le RAID logiciel via MDADM Linux n’est pas supporté (voir wiki officiel). Seuls les RAID Hardware sont supportés.

Dans l’interface, vous ne pourrez donc pas le configurer (ni même pendant la phase d’installation). Depuis la version 3.4, vous pouvez cependant installer ProxMox sur un espace ZFS, avec notamment tous les niveaux de RAID/RAIDZ que vous souhaitez. Mais mon petit doigt me dit qu’il s’agit probablement de ZFSonLinux et j’ai déjà donné ;-).

Cette absence de RAID logiciel est une des raisons pour lesquels j’étais initialement réfractaire à ProxMox par rapport à un linux classique avec qemu. Cependant, ce n’est pas parce ce n’est pas supporté que vous ne pouvez pas le faire ! Après tout, il s’agit d’une Debian customisée donc il n’y a rien qui vous retient.

Voici deux articles que j’ai sélectionnés qui vous guideront pas à pas pour le faire (à vos risques et périls, comme d’habitude).

[Edit]

Attention : la partie amorçage ne fonctionnera pas si vous avez un boot EFI (Proxmox 4+). Il faudra trouver une autre technique. Vous pouvez lire cet article qui explique comment faire en général sur Debian :

www.debian-fr.org/t/raid-logiciel-linux-et-amorcage-en-uefi/64655

La partie du tutoriel traitant de lvm pour ProxMox (3ème partition) contenant le / et les données importantes peut par contre bien être suivie. C’est vraiment uniquement le boot EFI qui va nous enquiquiner.

[/Edit]

Migrer ses VM existantes

Nous voici maintenant dans le vif du sujet. Selon la documentation officielle, voici ce qu’on doit faire pour migrer une machine KVM dans ProxMox.

D’abord, on nous dit de créer une nouvelle machine virtuelle. Jusque là tout va bien. On lui affecte les options par défaut et pas de CD-ROM dans le lecteur.

Ensuite ça se gâte. En effet, on veut supprimer le disque dur par défaut puis ajouter notre disque importé de l’ancien système KVM. On va donc dans les propriétés de la machine virtuelle nouvellement créée.

Et là, blague… Pas de bouton « Parcourir » pour aller chercher notre disque virtuel à importer !

On peut trouver la solution assez vite sur les forums, mais c’est quand même assez frustrant, surtout quand on voit la malheureuse ligne donnée dans le wiki en guise de procédure…

Dans ce thread et ce thread, on apprend que pour chaque banque de données, chaque VM dispose d’un dossier dans lequel il faut déposer le disque. Dans le bon dossier ! Par exemple :

pour le stockage local, la VM avec l’id 100 a un dossier /var/lib/vz/images/100/
pour le stockage NFS nommé de manière originale NFS_VM, il y a un dossier /mnt/pve/NFS_VM/images avec des sous dossiers pour chaque VM qui dispose d’un disque sur ce partage NFS.

A partir de là, on copie donc nos fichiers dans les bons dossiers en fonction de ce qu’on veut faire. Dans le cas présent je copie les fichiers sur le stockage local, dans un premier temps.

cp MaVM.qcow2 /var/lib/vz/images/100/

Une fois que c’est fait, les disques apparaissent dans la page spécifique de la banque de données.

Mais le disque virtuel n’apparaît toujours pas dans la machine virtuelle. Il faut aller éditer à la main le fichier de configuration de la VM, situé dans /etc/pve/nodes/xxx/qemu-server/[VMID].conf.

vi /etc/pve/nodes/xxx/qemu-server/100.conf
bootdisk: ide0;
cores: 2
ide2: none,media=cdrom
memory: 1024
name: bck-xxx-xxx
net0: e1000=7A:FA:D6:DC:06:70,bridge=vmbr0
numa: 0
ostype: l26
smbios1: uuid=ae5d66d6-724f-46cd-a85b-24eda7b9ecec
sockets: 1
ide0: local:100/xxx-xxx-flat.vmdk
ide1: local:100/xxx-xxx_1-flat.vmdk
unused0: local:100/vm-100-disk-1.vmdk
unused1: local:100/vm-100-disk-2.qcow2,size=32G

A partir de là, les disques apparaissent dans la VM au niveau de ide0 et ide1 dans mon cas. On progresse.

Cas des disques QCOW2

Dans le cas des disques QCOW2 (et les QCOW2 uniquement, pas les RAW), il sera nécessaire d’ajouter également un argument « taille » du disque, sans quoi la VM peut ne pas démarrer. Il faudra rajouter en fin de ligne la taille du disque (xxx,size=yyG).

Astuce : si vous ne la connaissez pas, supprimez le disque de la VM (qui passera en inutilisé), puis éditer le (edit) pour l’ajouter à nouveau. Le fichier de configuration devrait se recréer avec les bonnes options automatiquement.

Cas des disques RAW

A l’inverse, la taille du disque en argument dans la configuration d’une VM pour une image RAW ne semble pas nécessaire.

Par contre, pour les disques raw, il faut savoir qu’il faut ABSOLUMENT les nommer en « .raw » pour qu’ils soient visibles dans la liste des disques (mes disques provenant de KVM étaient nommés par défaut en « .img »).

Si vous ne les renommez pas, les disques seront présents dans la VM, mais elle refusera de démarrer avec l’erreur suivante :

unable to parse volume filename

Il faudra prendre soin de tous les renommer, puis de modifier la configuration de la machine virtuelle en tenant compte de cette modification.

Migration KVM Ubuntu vers Redhat et problème /usr/libexec/qemu-kvm: No such file or directory

Sun, 04 Oct 2015 19:20:58 +0000

Je suis en train de migrer de KVM vers ProxMox. Et du coup, je ressors de mes tiroirs tous les articles que je n’ai pas eu pris le temps d’écrire à propos des problèmes que j’ai pu rencontrer, notamment lors de ma migration VMware ESXi vers KVM/Uubuntu puis KVM/Ubuntu vers KVM/CentOS.

Processsu de migration (à froid)

On pourrait penser que migrer une machine virtuelle KVM Ubuntu vers une machine virtuelle KVM sous RHEL/CentOS ne pose pas de problème particulier puisqu’il s’agit d’une même technologie : qemu. Et pourtant !

Lorsque j’ai voulu passer sous CentOS pour des questions d’habitude d’administration (et aussi parce que la philosophie RHEL me plait plus que celle d’Ubuntu), je me suis rendu compte que ça n’est pas tout à fait vrai.

Voici la procédure que j’ai suivi pour migrer :

copie de mes machines virtuelle sur un volume séparé, ainsi que dump de leur fichiers de configuration
réinstallation from scratch de l’OS de l’hyperviseur, j’en ai profité pour passer sur un OS installé en RAID1 pour plus de sécurité
récupération des machines virtuelles et réimport de leur configuration

Pour ceux qui ne sont pas familier avec l’import/export de configuration de machines virtuelles via virsh, voici un petit aparté sur la marche à suivre :

virsh list #affiche la liste des machines virtuelles actives sur le serveur
virsh list --all #affiche toutes les VMs enregistrés sur l'hôte, même celles inactives
virsh dumpxml GuestID > guest.xml #dump XML du fichier de configuration pour sauvegarde ou import futur
virsh define guest.xml #réimporter le fichier de configuration XML (sans démarrer la VM à la suite)

En cas d’erreur No such file or directory lors de l’import

Lors qu’on importe la machine virtuelle, on peut avoir l’erreur suivante :

virsh define MaVM.xml
error: Failed to define domain from MaVM.xml
error: Cannot find QEMU binary /usr/bin/kvm: No such file or directory

La première chose à vérifier bien entendu est que tous les packages sont bien installés mais dans mon cas c’était bien le cas (le package qemu contenant l’émulateur KVM était bien installé).

Sur Ubuntu, l’émulateur est stocké dans le binaire /usr/bin/kvm. A l’inverse, sur RHEL ou CentOS, il n’est pas situé dans le même dossier, et ne s’appelle même pas kvm mais /usr/libexec/qemu-kvm !

On doit donc passer sur chaque fichier XML de configuration de machine virtuelle pour modifier le chemin vers le binaire. On en profitera également pour mettre à jour le chemin vers le disque dur virtuel si jamais l’arborescence de stockage n’est pas la même entre les deux serveurs.

vim MaVM.xml
<emulator>/usr/bin/kvm</emulator>

A partir de là, vous pouvez importer correctement vos VMs et les démarrer !

Pour aller plus loin

A noter, par défaut sous RHEL/CentOS les fichiers sont répartis de la façon suivante :

/etc/libvirt/qemu/ pour tous les fichiers de configuration VM, storage, etc.
/var/log/libvirt/qemu/ pour les fichiers journaux des machines virtuelles
/var/run/libvirt/qemu/ contient les fichiers de fonctionnement de la machine, à avoir le .pid pour stocker le PID du process maitre de ma VM, ainsi qu’un fichier XML contenant une copie de la configuration de la VM en fonctionnement
/var/lib/libvirt/qemu/ contient des fichiers permettant de suivre les performances de la VM, de stocker les éventuels dump/snapshots/sauvegardes

Un peu de documentation clairement expliquée sur l’utilisation de virsh sur la communauté Ubuntu : Virsh

Et pour aller plus loin dans le Troubleshooting, voici un guide de RedHat listant les erreurs courantes avec Qemu/KVM.

[Tutoriel] Migrer facilement son blog de WordPress.com vers un hébergement mutualisé OVH

Sat, 11 Apr 2015 21:23:20 +0000

Petit aparté avant le début de ce tutoriel, je rédige le premier article de mon blog géré par moi même (hébergé sur OVH). Ce matin même, j’étais encore hébergé en tant que blog gratuit chez WordPress.com. J’ai décidé de sauter le pas cars je trouvais le compte wordpress.com trop bridé, notamment au niveau de la limite pour les médias et l’impossibilité d’ajouter de plugins ou de toucher au CSS sans devoir mettre la main au porte monnaie.

Et puis bon… cela fait plus sens de gérer moi même mon blog sachant que je passe mon temps à bidouiller sur mes OS et que j’administre tout à la maison ;-)

Ce n’est pas pour faire de la pub pour OVH, mais il faut reconnaître que leurs offres « premier prix » sont vraiment bon marché. Entre 2 et 5€ par mois, on peut avoir un hébergement « web » en mutualisé, un VPS, voire même un serveur physique dédié (kimsufi en Atom, mais quand même!). Imbattable (enfin, allez quand même vérifier, hein?).

Si vous êtes sur ce tuto, c’est probablement que vous voulez que la migration se passe le plus simplement possible. Du coup, même si les trois options que je cite sont toutes viable, la plus simple est quand même à mon avis est d’ouvrir un compte pour de l’hébergement mutualisé, qui bénéficie chez OVH d’un module « 1-clic » dédié à WordPress.

En réalité, il y a un peu plus d’un clic pour réussir votre migration. Je vais vous guider.

Création de l’instance de base de données pour WordPress

La première chose à faire est de se connecter sur votre Manager OVH, de sélectionner votre nouvel hébergement mutualisé.

La partie hébergement mutualisé se gère dans la partie « Plateforme » sous les noms de domaine.

OVH a beau proposer des module « 1-click » pour installer WordPress, en réalité il faut quand même d’abord commencer par créer l’instance de base de données pour stocker le tout.

Dans l’offre d’éhbergement la moins chère d’OVH, on dispose d’une instance de 200 Mo, avec au choix MySQL ou PostgreSQL. C’est largmeent suffisant pour un blog, même avec beaucoup d’articles, car les médias (photos, vidéos) ne sont pas stockées en base.
Professionnellement parlant, je préfère PostgreSQL, mais pour pouvoir utiliser le module 1-click de votre hébergement, il faut donc absolument créer une instance de type MySQL.

Une fois la création de la base de données validée, le message suivant s’affiche.

On doit également avoir la ligne suivante dans les Tâches en cours.

Comme toutes les opérations chez OVH, ce n’est pas immédiatement opérationnel, il faut attendre quelques secondes voire quelques minutes selon l’opération. Une fois que c’est terminé, on peut procéder à l’installation de WordPress à proprement parler.

Déploiement du nouveau WordPress

Ouvrir l’onglet « Modules en 1 clic » et cliquer sur Ajouter

Le processus d’installation est relativement simple à suivre

Dans le cas où la base de données à été mal créée ou n’est pas encore opérationnelle, vous obtiendrez le message suivant en étape 2

A l’inverse, si tout est bien paramétré, vous pourrez rentrer les informations de connexion à la base de données de votre compte OVH.

Et voilà le message qui indique que tout s’est bien passé

Une fois l’email reçu, vous pouvez vous connecter sur votre nouveau WordPress, qui sera vite (mis à par l’utilisateur d’administration et quelques pages d’exemple).

Export des données existantes

Pendant que le WordPress est installé par OVH, on peut se connecter sur l’ancien blog et récupérer les données existantes.

Ce n’est pas la première migration que je fais. J’avais débuté ce blog sur une page perso Free (pendant très peu de temps, encore plus bridé que wordpress à l’époque) et j’avais migré rapidement vers wordpress.com. A l’époque, il faut savoir qu’il n’était pas possible de réaliser la bascule inverse. Quand vous étiez chez WordPress.com, vous étiez ferrés (sauf probablement si vous étiez prêt à payer, j’imagine). Mais aujourd’hui c’est possible et même très simple. Il suffit d’ouvrir les outils dans la partie wp-admin.

Une fois le menu ouvert, laisser les options par défaut et sauvegarder le fichier XML généré.

Prise en main du nouveau blog, mise à jour et création d’un nouvel utilisateur

Le temps qu’on réalise cette opération, le site web est probablement installé et vous avez du recevoir l’email d’OVH pour vous dire que tout est prêt. Connectez vous sur votre nouveau site.

La première chose qui saute aux yeux lorsqu’on se connecte pour la première fois, c’st WordPress qui nous indique que la mise à jour vers la dernière version a été faite, mais qu’il reste les extensions à mettre à jour. C’est un bon conseil ;-)

Par souci de sécurité là encore, je préfère toujours séparer le compte d’administration (déjà créé lors de l’installation) du compte que j’utilise tous les jours.

Ainsi, ce n’est pas le même compte que j’utilise pour administrer le site (et il n’est pas « visible » car il ne poste jamais) et le compte moins privilégié qui lui poste les articles.

Je vous conseille de le faire également.

Import des données dans le nouveau WordPress

Ça y est, le plus urgent a été fait! On peut maintenant réutiliser le fichier XML pour réimporter les pages, les posts, les commentaires.

Tout ce qui est « média » n’est pas présent dans le fichier XML, mais on pourra tout de même le récupérer grâce à une option lors de l’import. Pratique !

Lorsqu’on tente d’importer, WordPress nous redirige vers le module permettant de le faire. Il faut l’installer et l’activer avant de pouvoir importer notre XML.

Ce message indique de l’installation s’est bien passée. N’oubliez pas de cliquer sur « Activer l’extension & lancer l’importateur » !

Récupérer le fichier XML, cocher l’option « Download and import file attachments » si vous voulez récupérer les fichiers « Média » présents sur vos pas (typiquement, toutes les photos, images, vidéos, … que vous avez importé et intégré à votre blog sur WordPress.com).

Dernière astuce, dans cette même page vous pouvez également indiquer à WordPress de changer l’auteur des posts au moment de l’import. Même si c’est modifiable après coup, c’est très pratique si vous ne voulez pas que l’auteur de TOUS les posts soit signés comme provenant de l’utilisateur « admin » que vous avez utilisé pour réaliser l’import.