Installer Openshot sous CentOS 7

Parmi tous les éditeurs vidéo du monde Linux, Openshot est sans aucun doute le plus intuitif. Sa prise en main est à peu près immédiate, il dispose juste des fonctionnalités qu’il faut sans le côté « usine à gaz » que l’on retrouve dans d’autres applications similaires.

Les versions 1.4.x souffraient malheureusement de problèmes de stabilité, qui semblent avoir été résolus par les versions 2.x subséquentes. En revanche, l’application n’existe plus que sous forme d’AppImage (ou application portable). Il m’a fallu batailler un peu pour l’installer proprement, notamment pour disposer d’une entrée de menu propre pour tous les utilisateurs du système. Cet article décrit donc l’installation de la version 2.3.4 (la dernière en date au moment où j’écris ces lignes) sur un poste de travail CentOS 7.

Une fois l’application téléchargée sur le site du projet, je range le fichier dans un endroit approprié.

# cd /usr/local/bin/
# mv /home/kikinovak/Bureau/OpenShot-v2.3.4-x86_64.AppImage .

J’attribue les permissions qui vont bien.

# chown root:root OpenShot-v2.3.4-x86_64.AppImage 
# chmod +x OpenShot-v2.3.4-x86_64.AppImage

Je crée un lien symbolique vers l’application.

# ln -s OpenShot-v2.3.4-x86_64.AppImage openshot

À partir de là, je peux lancer openshot dans un terminal en tant que simple utilisateur.

$ openshot

Au premier lancement, l’application me demande si je souhaite créer une entrée de menu (desktop file). Si je réponds par l’affirmative, le fichier sera créé dans ~/.local/share/applications comme il se doit.

Le hic, c’est qu’il n’y a pas moyen de créer un fichier global dans /usr/share/applications ou /usr/local/share/applications qui soit valable pour tous les utilisateurs. Plus exactement, on peut le faire, mais lorsqu’on lance l’application, elle vérifie si le fichier ~/.local/share/applications/appimagekit-openshot-qt.desktop est présent, et s’il ne l’est pas, il est crée.

Pour venir à bout de ce dilemme, j’ai modifié le script 04-nettoyer-menus.sh dans le répertoire el7/install/ de mon dépôt Github centos. Le script se charge d’installer une icône à l’endroit qu’il faut et remplace l’entrée de menu pour chaque utilisateur du système.

Voici l’entrée de menu revue et corrigée pour tous les utilisateurs.

Et voici l’application dans toute sa splendeur.

Openshot

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Partitionnement avec LVM sous CentOS

LVMUn système de fichiers (FS ou filesystem) est installé normalement dans une partition d’un disque dur. Il ne peut donc pas dépasser la taille de ce disque, et il est difficile de l’étendre. LVM (Logical Volume Manager) ajoute une couche d’abstraction entre le système de fichiers et les partitions du ou des disques et permet une approche plus souple. Un FS n’est pas créé dans une partition, mais dans un volume logique. Ce dernier peut s’étendre sur plusieurs disques et peut être agrandi par la suite.

Concepts de base

LVM ajoute trois niveaux entre le disque dur et le système de fichiers.

  • Physical Volumes (PV)
  • Volume Groups (VG)
  • Logical Volumes (LV)

Voyons un peu plus en détail à quoi correspond chacun de ces niveaux.

  • Physical Volume (PV) – En règle générale, un PV est une partition du disque dur gérée par LVM. Il peut s’agir d’un disque dur entier et même d’un assemblage RAID. La partition, le disque dur ou l’assemblage RAID doit être défini en tant que PV pour que les commandes LVM puissent fonctionner.
  • Volume Group (VG) – Un ou plusieurs PV peuvent être assemblés en un groupe, ce qui permet par exemple de réunir les partitions de plusieurs disques durs. Un VG constitue donc un ensemble de PV, d’un point de vue physique.
  • Logical Volume (LV) – Un Logical Volume (LV) est une partie d’un Volume Group (VG). Pour l’utilisateur, le LV fonctionne comme une partition virtuelle. C’est là où il installera le système de fichiers. Ce dernier ne sera plus créé dans une partition comme /dev/sda2 ou /dev/sda3, mais dans un LV comme par exemple /dev/mapper/vg0-root ou /dev/mapper/vg0-swap.

LVM dans la configuration par défaut de CentOS

Pour ne pas nous embrouiller dans la théorie, on partira d’un cas pratique relativement simple à comprendre. Lorsqu’on installe un serveur sous CentOS et que l’on opte pour la configuration par défaut, on obtient un schéma de partitionnement basé sur LVM. Dans l’exemple qui suit, j’ai installé CentOS dans une machine virtuelle dotée d’un disque de 20 Go, en gardant les options par défaut.

Jetons d’abord un oeil sur le partitionnement du disque dur.

# fdisk -l /dev/sda

Disque /dev/sda : 21.5 Go, 21474836480 octets, 41943040 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000cb56b

Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    41943039    19921920   8e  Linux LVM

Voyons à quoi correspond la partition /dev/sda1.

# mount | grep sda1
/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,...)

C’est donc ma partition /boot, une partition classique de type Linux (83). Elle n’est manifestement pas gérée par LVM. Le gros du système se trouve apparemment sur la partition /dev/sda2, de type Linux LVM (8e).

La commande pvs(8) me permet d’afficher les infos sur les Physical Volumes (PV) de mon système.

# pvs
  PV         VG           Fmt  Attr PSize  PFree
  /dev/sda2  cl_centosbox lvm2 a--  19,00g    0 

Ici, je dispose d’un Physical Volume (PV) défini sur /dev/sda2, d’une taille de 19 Go, et qui contient un Volume Group (VG) cl_centosbox. La commande vgs(8) me permet d’afficher les détails de ce Volume Group.

# vgs
  VG           #PV #LV #SN Attr   VSize  VFree
  cl_centosbox   1   2   0 wz--n- 19,00g    0 

De manière similaire, j’utiliserai la commande lvs(8) pour en savoir plus sur les Logical Volumes (LV) définis sur la machine.

# lvs
  LV   VG           Attr       LSize  Pool Origin Data%  ...
  root cl_centosbox -wi-ao---- 17,00g
  swap cl_centosbox -wi-ao----  2,00g

Dans le cas présent, j’ai deux Logical Volumes (LV) root et swap définis dans le Volume Group (VG) cl_centosbox. Voici comment ils sont référencés dans /etc/fstab.

/dev/mapper/cl_centosbox-root /    xfs  defaults 0 0
/dev/mapper/cl_centosbox-swap swap swap defaults 0 0

Exemple de partitionnement LVM personnalisé

Dans l’exemple qui suit, on va installer CentOS 7 dans une machine virtuelle, en optant pour un partitionnement personnalisé basé sur LVM.

  1. Cliquer sur Destination de l’installation.
  2. Vérifier si le ou les disques durs sont bien sélectionnés.
  3. Cocher Je vais configurer le partitionnement et cliquer sur Terminé.
  4. Dans le menu déroulant, vérifier si le schéma LVM est bien sélectionné.

La partition /boot ne sera pas gérée par LVM.

  1. Cliquer sur le bouton « + » pour créer un nouveau point de montage.
  2. Créer le point de montage /boot avec une capacité de 200 MiB ou plus.
  3. Conserver le Type de périphérique Partition standard.
  4. Choisir le système de fichiers ext2 et l’étiquette boot.
  5. Confirmer Mise à jour des paramètres.

En revanche, la partition swap sera bien gérée par LVM. L’installateur propose un Volume Group cl_centosbox par défaut, nommé en fonction du nom d’hôte. On va remplacer ce VG par défaut par un VG personnalisé vg0.

  1. Cliquer sur le bouton « + » pour créer un autre point de montage.
  2. Créer le point de montage swap en spécifiant sa capacité en GiB.
  3. Garder le Type de périphérique LVM.
  4. Remplacer le Volume Group cl_centosbox par vg0.
  5. Choisir l’étiquette swap.
  6. Confirmer Mise à jour des paramètres.

La partition principale occupera l’espace disque restant et fera également partie du Volume Group vg0.

  1. Cliquer sur le bouton « + » pour créer un dernier point de montage.
  2. Créer le point de montage / sans spécifier la capacité souhaitée.
  3. Garder le Type de périphérique LVM.
  4. Garder le Volume Group vg0.
  5. Choisir le système de fichiers ext4 et l’étiquette root.
  6. Confirmer Mise à jour des paramètres, puis Terminé.

Voyons ce que donne notre installation personnalisée après le redémarrage initial. Pour le disque dur, la seule chose qui a changé, c’est la taille de la partition /boot sur /dev/sda1.

# fdisk -l /dev/sda
...
Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sda1   *        2048      411647      204800   83  Linux
/dev/sda2          411648    41943039    20765696   8e  Linux LVM

Nous disposons d’un Physical Volume (PV) sur /dev/sda, avec un Volume Group vg0.

# pvs
  PV         VG  Fmt  Attr PSize  PFree
  /dev/sda2  vg0 lvm2 a--  19,80g    0 

Ce Volume Group occupe toute la taille de la partition.

# vgs
  VG  #PV #LV #SN Attr   VSize  VFree
  vg0   1   2   0 wz--n- 19,80g    0 

Il contient deux Logical Volumes root et swap.

# lvs
  LV   VG  Attr       LSize  Pool Origin Data%  ...
  root vg0 -wi-ao---- 17,80g
  swap vg0 -wi-ao----  2,00g 

Dans /etc/fstab, ces Logical Volumes (LV) sont référencés comme ceci.

/dev/mapper/vg0-root    /    ext4  defaults  1 1
/dev/mapper/vg0-swap    swap swap  defaults  0 0

Redimensionnement à chaud de la partition principale

Prenons un cas concret tel qu’il peut se présenter dans le quotidien d’un admin. Votre serveur est installé dans une machine virtuelle, et vous souhaitez agrandir la taille du disque. Dans notre installation sous VirtualBox, nous pourrons redimensionner le disque virtuel comme ceci. Au prochain démarrage du serveur, le disque disposera d’une certaine quantité d’espace libre, comme nous pouvons le voir avec cfdisk.

LVM

Dans cet espace libre, je crée une partition logique /dev/sda5 de type Linux LVM (8e).

LVM

Ma nouvelle partition n’apparaît pas encore. Je peux utiliser la commande partprobe(8) pour informer le système d’exploitation de la modification de la table de partitions.

# partprobe

Voilà comment se présente mon disque dur.

# fdisk -l
...
Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sda1   *        2048      411647      204800   83  Linux
/dev/sda2          411648    41943039    20765696   8e  Linux LVM
/dev/sda3        41943040    83886079    20971520    5  Extended
/dev/sda5        41943103    83886079    20971488+  8e  Linux LVM

Je crée un nouveau Physical Volume (PV) dans ma nouvelle partition.

# pvcreate /dev/sda5
  Physical volume "/dev/sda5" successfully created.

J’affiche l’état de mes Physical Volumes (PV).

# pvs
  PV         VG  Fmt  Attr PSize  PFree 
  /dev/sda2  vg0 lvm2 a--  19,80g     0 
  /dev/sda5      lvm2 ---  20,00g 20,00g

J’étends mon Volume Group vg0 pour qu’il englobe également le Physical Volume (PV) /dev/sda5.

# vgextend vg0 /dev/sda5
  Volume group "vg0" successfully extended

Mon Volume Group vg0 est désormais bien réparti sur les deux Physical Volumes.

# pvs
  PV         VG  Fmt  Attr PSize  PFree 
  /dev/sda2  vg0 lvm2 a--  19,80g     0 
  /dev/sda5  vg0 lvm2 a--  20,00g 20,00

Mon Logical Volume root n’occupe actuellement que près de la moitié de l’espace disque disponible.

# lvs
  LV   VG  Attr       LSize  Pool Origin Data%  ...
  root vg0 -wi-ao---- 17,80g
  swap vg0 -wi-ao----  2,00g

Je peux étendre sa taille de manière à ce qu’il occupe le restant de l’espace disponible.

# lvextend -l +100%FREE /dev/mapper/vg0-root 
  Size of logical volume vg0/root changed 
  from 17,80 GiB (4557 extents) 
  to 37,80 GiB (9676 extents).
  Logical volume vg0/root successfully resized.

Voyons le résultat.

# lvs
  LV   VG  Attr       LSize  Pool Origin Data%  ...
  root vg0 -wi-ao---- 37,80g
  swap vg0 -wi-ao----  2,00g

Ma partition principale utilise un système de fichiers ext4. Je peux redimensionner ce système de fichiers en utilisant la commande suivante.

# resize2fs /dev/mapper/vg0-root 
resize2fs 1.42.9 (28-Dec-2013)
Le système de fichiers de /dev/mapper/vg0-root est monté sur / ; 
le changement de taille doit être effectué en ligne
old_desc_blocks = 3, new_desc_blocks = 5
Le système de fichiers /dev/mapper/vg0-root a maintenant une taille 
de 9908224 blocs.

L’opération a bien fonctionné, et j’ai doublé l’espace disque disponible pour mon système.

# df -h
Sys. de fichiers     Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/vg0-root    38G    968M   35G   3% /
...

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Redimensionner un disque virtuel avec VirtualBox

Disque virtuelVirtualBox permet de redéfinir la taille du disque virtuel alloué à un système invité, à condition de ne pas avoir opté pour un fichier de taille fixe lors de l’installation. Le système invité doit être éteint et ne pas comporter d’instantanés.

Dans l’exemple qui suit, je dispose d’un disque virtuel CentOS.vdi rangé dans ~/VirtualBox/CentOS. La taille de ce disque est de 40 Go, et je souhaite la doubler. Pour ce faire, j’invoque la commande suivante.

$ VBoxManage modifyhd \
> /home/kikinovak/VirtualBox/CentOS/CentOS.vdi \
> --resize 81920
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Quelques remarques :

  • Je dois impérativement spécifier le chemin absolu vers mon fichier *.vdi.
  • La taille doit être exprimée en mégaoctets.
  • Si le nom ou le chemin contiennent des espaces, je dois ajouter des guillemets.
$ VBoxManage modifyhd \
> "/home/kikinovak/VirtualBox/CentOS 7/CentOS 7.vdi" \
> --resize 81920
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Par la suite, il faudra bien évidemment prendre en compte ces modifications avec les outils de partitionnement, LVM et les outils de gestion des systèmes de fichiers.

Publié dans Documentation Microlinux | Marqué avec , | Laisser un commentaire

Mettre en place un dépôt de paquets Yum local sous CentOS

RPMUne grande administration régionale m’a contacté récemment pour mettre en place l’un de leurs serveurs Intranet sous Linux. La particularité de cette machine, c’est qu’elle n’est pas reliée à Internet, ce qui pose un problème dans la mesure où je n’ai plus accès aux dépôts de paquets CentOS en ligne. La solution consiste ici à mettre en place un dépôts de paquets local.

À des fins de démonstration et pour bien expliquer la procédure, je pars d’un système CentOS 7.0 (installation minimale effectuée à partir du fichier CentOS-7.0-1406-x86_64-Minimal.iso), que je vais successivement mettre à jour par le biais d’un dépôt local.

Désactiver les dépôts en ligne

Étant donné que nous ne disposons pas de connexion Internet, la première chose à faire, c’est de désactiver les dépôts en ligne pour éviter les messages d’erreur à répétition du gestionnaire de paquets. Éditer /etc/yum.repos.d/CentOS-Base.repo et désactiver les dépôts [base], [updates] et [extras]. Le dépôt [centosplus] est déjà désactivé dans la configuration par défaut.

[base]
name=CentOS-$releasever - Base
enabled=0
...
[updates]
name=CentOS-$releasever - Updates
enabled=0
...
[extras]
name=CentOS-$releasever - Extras
enabled=0
...
[centosplus]
name=CentOS-$releasever - Plus
enabled=0

Voilà ce que ça donne.

# yum check-update
Modules complémentaires chargés : fastestmirror
Aucun dépôt n'est activé.

Récupérer les fichiers ISO

La page de téléchargement de CentOS offre plusieurs fichiers ISO au choix.

  • DVD ISO
  • Everything ISO
  • Minimal ISO

Pour la mise en place d’un dépôt local, on choisira le fichier Everything ISO. Voici tous les fichiers correspondants publiés depuis la sortie de CentOS 7.0. Chacun pèse près de 7 Go et contient l’ensemble des paquets officiels fournis par la distribution.

  • CentOS-7.0-1406-x86_64-Everything.iso
  • CentOS-7-x86_64-Everything-1503-01.iso
  • CentOS-7-x86_64-Everything-1511.iso
  • CentOS-7-x86_64-Everything-1611.iso

On notera au passage que les développeurs de CentOS ont un peu de mal à se mettre d’accord sur une convention de nommage consistante des fichiers.

Pour ma part, je range ces fichiers dans un endroit approprié comme par exemple /root/iso. Évidemment, sur une machine de production, on supprimera les anciennes versions au fur et à mesure pour ne pas encombrer le serveur inutilement.

Monter l’ISO

Créer un point de montage approprié.

# mkdir -v /mnt/iso
mkdir: création du répertoire « /mnt/iso »

Monter l’ISO avec les options qui vont bien.

# mount -o loop CentOS-7.0-1406-x86_64-Everything.iso /mnt/iso/
mount: /dev/loop0 est protégé en écriture, 
       sera monté en lecture seule

Configurer le dépôt local

Créer un fichier /etc/yum.repos.d/local.repo et l’éditer comme ceci.

[LocalRepo]
name=Local Repository
baseurl=file:///mnt/iso
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Nettoyer le cache.

# yum clean all
Modules complémentaires chargés : fastestmirror
Nettoyage des dépôts : LocalRepo
Cleaning up everything
Cleaning up list of fastest mirrors

À partir de là, Yum peut être utilisé normalement comme avec les dépôts en ligne.

Mise à jour

Démonter l’ancien ISO.

# umount /mnt/iso/

Monter le nouvel ISO.

# mount -o loop CentOS-7-x86_64-Everything-1503-01.iso /mnt/iso/
mount: /dev/loop0 est protégé en écriture, 
       sera monté en lecture seule

Vider le cache.

# yum clean all
Loaded plugins: fastestmirror
Cleaning repos: LocalRepo
Cleaning up everything
Cleaning up list of fastest mirrors

Afficher les mises à jour.

# yum check-update

Une bonne pratique consiste à s’assurer qu’on dispose bien de tous les paquets de l’installation minimale, étant donné qu’il peut y avoir quelques menus changements entre les différentes versions.

# yum group install "Minimal Install"

Il ne reste plus qu’à lancer la mise à jour.

# yum update

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Installer VirtualBox sous CentOS 7

VirtualBoxCet article décrit l’installation de VirtualBox sur un poste de travail CentOS 7. VirtualBox (« machine virtuelle ») est un logiciel de virtualisation de systèmes d’exploitation. En utilisant les ressources matérielles de l’ordinateur (système hôte), VirtualBox permet la création d’un ou de plusieurs ordinateurs virtuels dans lesquels s’installent d’autres systèmes d’exploitation (systèmes invités). Les systèmes invités fonctionnent en même temps que le système hôte, mais seul ce dernier a accès directement au véritable matériel de l’ordinateur.

VirtualBox

La procédure d’installation n’est pas forcément compliquée, mais étant donné qu’elle est très mal documentée et que bon nombre d’infos erronées et/ou obsolètes circulent sur le web, j’ai décidé de rédiger mon propre topo sur la question.

Configuration du dépôt d’Oracle

Oracle fournit un dépôt de paquets dédié pour VirtualBox pour tous les utilisateurs de Red Hat Enterprise Linux et dérivés. Sur le site de VirtualBox, suivre le lien Downloads > Linux distributions et repérer le lien vers le fichier virtualbox.repo en bas de la page. Une fois qu’on a téléchargé ce fichier, on va le ranger dans /etc/yum.repos.d/.

[virtualbox]
name=Oracle Linux / RHEL / CentOS-$releasever / ... - VirtualBox
baseurl=http://download.virtualbox.org/.../$releasever/$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc

Installer les dépendances

VirtualBox a besoin d’une série d’outils de construction pour s’installer correctement. Certains sont déjà présents sur le système, d’autres doivent être récupérés.

# yum install gcc make kernel-devel kernel-headers dkms

Si jamais l’installation échoue à cause d’un paquet manquant, on le saura très vite, auquel cas il suffit de rectifier le tir et de relancer /sbin/vboxconfig.

Installer VirtualBox

À l’heure actuelle, on a le choix entre trois branches de VirtualBox.

# yum search virtualbox
...
VirtualBox-4.3.x86_64 : Oracle VM VirtualBox
VirtualBox-5.0.x86_64 : Oracle VM VirtualBox
VirtualBox-5.1.x86_64 : Oracle VM VirtualBox

On va opter pour la branche la plus récente.

# yum install VirtualBox-5.1

L’installation crée un groupe vboxusers. Il faudra ajouter les utilisateurs de VirtualBox à ce groupe.

# usermod -a -G vboxusers kikinovak

Là, il suffirait de quitter la session et de se reconnecter. Dans le doute, je redémarre le système pour être sûr que tous les modules nécessaires à l’exécution de VirtualBox soient correctement chargés.

Installer le VirtualBox Extension Pack

Certaines fonctionnalités comme la gestion de l’USB 2.0 et 3.0 nécessitent l’installation du VirtualBox Extension Pack. Télécharger le fichier *.extpack correspondant à la version installée de VirtualBox. Pour installer le Pack, lancer VirtualBox et ouvrir Fichier > Paramètres > Extensions.

VirtualBox Extension Pack

À partir de là, VirtualBox est prêt à l’utilisation.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Migrer vers un autre hyperviseur KVM

Migration ServeurJ’ai une série de machines virtuelles dans un hyperviseur KVM tournant sous Slackware Linux 14.1 64-bits (alphamule). Je souhaite les migrer vers un nouvel hyperviseur, un serveur HP Proliant tournant sous CentOS 7 (nestor). La procédure n’est pas tout à fait triviale, mais j’ai réussi au bout d’une matinée de tentative et échec.

Avant d’entreprendre quoi que ce soit, il faut bien évidemment éteindre toutes les machines virtuelles. Voici la liste complète.

# virsh list --all
ID Nom État
----------------------------------------------------
- MLED-14.1-32bit fermé
- MLED-14.1-64bit fermé
- MLED-14.2-32bit fermé
- MLED-14.2-64bit fermé
- MLES-14.0-32bit fermé
- MLES-14.0-64bit fermé
- MLES-14.1-32bit fermé
- MLES-14.1-64bit fermé
- MLES-14.2-32bit fermé
- MLES-14.2-64bit fermé

Pour commencer, je vais tenter de migrer la machine MLES-14.2-32bit. Je dois d’abord copier l’image disque vers le nouveau serveur.

# cd /var/lib/libvirt/images/
# scp MLES-14.2-32bit.qcow2 nestor:/var/lib/libvirt/images/

J’effectue un dump de la configuration, et je la copie également sur la nouvelle machine.

# virsh dumpxml MLES-14.2-32bit > /tmp/MLES-14.2-32bit.xml
# scp /tmp/MLES-14.2-32bit.xml nestor:/tmp/

Je me connecte au nouveau serveur. Dans un premier temps, je règle les permissions de mon image disque.

# cd /var/lib/libvirt/images/
# chown qemu:qemu MLES-14.2-32bit.qcow2

Je sauvegarde la configuration de l’ancienne machine.

# cd /tmp/
# cp MLES-14.2-32bit.xml MLES-14.2-32bit.xml.orig

J’essaie d’importer telle quelle l’ancienne configuration, ce qui se solde par une erreur.

# virsh define MLES-14.2-32bit.xml
erreur :Impossible de définir le domaine depuis MLES-14.2-32bit.xml
erreur :Cannot check QEMU binary /usr/bin/qemu-kvm: Aucun fichier ou
        dossier de ce type

Mon système MLES-14.2-32bit est basé sur Slackware Linux 14.2 32-bits. L’approche pragmatique consiste ici à installer un tel système sur le nouvel hyperviseur et d’exporter la configuration au format XML, ce qui permettra de comparer les différentes options sur l’ancienne et la nouvelle machine. À partir de là, je peux éditer MLES-14.2-32bit.xml en rectifiant le tir pour les options qui posent problème.

Le nombre de processeurs passe de 8 à 2.

<vcpu placement='static'>2</vcpu>

Je rectifie le type de machine.

<os>
  <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
  <boot dev='hd'/>
</os>

Je supprime une paire de fonctionnalités non supportées.

<features>
  <acpi/>
  <apic/>
  <pae/>
  <vmport state='off'/>
</features>

J’adapte le modèle de processeur.

<cpu mode='custom' match='exact'>
  <model fallback='allow'>phenom</model>
</cpu>

Le chemin vers l’exécutable qemu-kvm n’est pas le même sur les deux systèmes.

<devices>
  <emulator>/usr/libexec/qemu-kvm</emulator>
  <disk type='file' device='disk'>

L’interface réseau a également changé de nom.

<interface type='bridge'>
  <mac address='52:54:00:00:00:07'/>
  <source bridge='virbr0'/>
  <model type='virtio'/>

Je retente le coup.

# virsh define MLES-14.2-32bit.xml
Domain MLES-14.2-32bit defined from MLES-14.2-32bit.xml

Je lance Virt-Manager et je démarre la machine virtuelle. À présent, tout fonctionne parfaitement.

Publié dans CentOS, Documentation Microlinux, Slackware | Marqué avec , , , | Laisser un commentaire

Virtualisation avec KVM sous CentOS

Virtualisation KVMJ’ai parfois besoin de construire des paquets pour différentes distributions Linux, avec des versions et des architectures qui peuvent également varier. Les solutions multiboot ne sont pas ce qu’il y a de plus simple à mettre en oeuvre, sans oublier le manque de flexibilité. J’ai également testé la virtualisation avec VirtualBox, qui pose d’autres contraintes. La meilleure solution consiste ici à mettre en place une série de machines virtuelles avec Qemu/KVM et LibVirt.

Dans cet article, je décris la mise en place d’un hôte KVM (également appelé hyperviseur) dans mon réseau local et d’une série de machines virtuelles installées sur cet hôte. Nous allons éviter de nous compliquer la vie avec les myriades d’options en ligne de commande de Qemu. Au lieu de cela, nous allons profiter des fonctionnalités de LibVirt et de Virt-Manager, qui nous faciliteront considérablement la tâche.

Il serait aisé d’écrire un ou même plusieurs gros livres sur le sujet de la virtualisation avec KVM, ce qui a d’ailleurs été fait. Ce tutoriel est conçu avant tout pour une prise en main de KVM par la pratique.

Prérequis

La virtualisation doit être activée dans le BIOS. Sur mon serveur HP, l’option correspondante est bien cachée dans le sous-menu Security > System Security > Virtualization Technology du BIOS. Dans certains cas, l’option peut même se trouver dans le sous-menu Power. Dans un cas comme dans l’autre, il faudra choisir Enable.

Pour que Qemu/KVM ait des performances acceptables, il faut vérifier que notre processeur soit compatible avec les extensions de virtualisation. Sous Linux, il est facile de vérifier cela avec la commande suivante.

$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo >/dev/null && echo OK
OK

Le serveur peut donc supporter la virtualisation hardware.

Attention tout de même, ça ne marche pas sur une Dedibox SC de chez Online. Le processeur VIA affiche des capacités KVM sans en être capable dans la pratique. Cette anomalie fâcheuse m’a coûté un après-midi entier à m’arracher les cheveux face à une série de plantages inexplicables.

Installation côté serveur

CentOS fournit certes un groupe de paquets Virtualization, mais je préfère voyager léger, et je n’installe que le minimum syndical sur le serveur.

# yum install qemu-kvm libvirt

Un redémarrage n’est pas vraiment nécessaire, mais je le fais quand-même pour voir si le module kvm est chargé automatiquement.

# lsmod | grep kvm
kvm_amd                64937  0 
kvm                   554609  1 kvm_amd
irqbypass              13503  1 kvm

Bien évidemment, rien n’empêche de charger le module manuellement.

# modprobe kvm

Lancement initial

Activer et démarrer libvirtd et afficher l’état du démon.

# systemctl enable libvirtd
# systemctl start libvirtd
# systemctl status libvirtd

Le journal affiche une erreur quant à l’interface réseau utilisée. Sans trop rentrer dans les détails, nous devons remédier à cela en créant un pont.

Création d’un bridge

Dans la configuration par défaut, mon serveur dispose de deux interface réseau.

  • enp2s0 côté Internet
  • enp3s0 côté réseau local

Pour créer un pont (ou bridge), je vais d’abord éditer /etc/sysconfig/network-scripts/ifcfg-enp3s0.

DEVICE=enp3s0
TYPE=Ethernet
ONBOOT=yes
BRIDGE=virbr0

Ce bridge recevra la configuration de l’ancienne interface enp3s0. Pour ce faire, il faudra créer un fichier /etc/sysconfig/network-scripts/ifcfg-virbr0 et l’éditer comme ceci.

DEVICE=virbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.2.1
NETMASK=255.255.255.0

Étant donné que l’interface réseau côté LAN s’appelle désormais virbr0 et non plus enp3s0, il faudra modifier la configuration du serveur en conséquence, en l’occurrence le pare-feu et la configuration de Dnsmasq.

J’ai supprimé le pare-feu à la sauce Red Hat firewalld, que j’ai remplacé par un simple script iptables. Ce script sera donc modifié comme ceci.

#!/bin/sh
#
# firewall.sh

# Commandes
IPT=/usr/sbin/iptables
MOD=/usr/sbin/modprobe
SYS=/usr/sbin/sysctl
SERVICE=/usr/sbin/service

# Internet
IFACE_INET=enp2s0

# Réseau local
IFACE_LAN=virbr0
IFACE_LAN_IP=192.168.2.0/24

Je procède de même avec Dnsmasq et je renomme l’interface côté réseau local.

# /etc/dnsmasq.conf
domain-needed
bogus-priv
interface=virbr0
dhcp-range=192.168.2.100,192.168.2.200,24h

À partir de là, je peux redémarrer le serveur.

Régler un problème avec rpcbind

Le redémarrage se solde par l’erreur suivante.

# systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
● rpcbind.socket loaded failed failed RPCbind Server Activation 
  Socket

Après une recherche Google, le problème s’avère être lié à la désactivation de l’IPv6 sur mon serveur. La solution consiste ici à forcer la reconstruction du disque mémoire initial.

# dracut -f

Au prochain redémarrage, le problème semble être résolu.

# systemctl status
● nestor
    State: running

Préparer les images ISO

Sur le serveur, on utilisera principalement des fichiers ISO pour installer les machines virtuelles. Dans la configuration par défaut, ces images sont censées être rangées dans le répertoire /var/lib/libvirt/images. On pourra les attribuer à l’utilisateur système qemu et au groupe système du même nom.

# ls -lh /var/lib/libvirt/images/
total 18G
-rw-r--r--. 1 qemu qemu 2,3G 11 mai 11:32 slackware-14.0.iso
-rw-r--r--. 1 qemu qemu 3,6G 11 mai 11:34 slackware-14.1.iso
-rw-r--r--. 1 qemu qemu 2,7G 11 mai 11:34 slackware-14.2.iso
-rw-r--r--. 1 qemu qemu 2,3G 11 mai 11:35 slackware64-14.0.iso
-rw-r--r--. 1 qemu qemu 3,7G 11 mai 11:36 slackware64-14.1.iso
-rw-r--r--. 1 qemu qemu 2,6G 11 mai 11:37 slackware64-14.2.iso

Installation côté client

Le serveur ne dispose pas d’interface graphique, et nous allons éviter de nous compliquer la vie en gérant les machines virtuelles en ligne de commande. Au lieu de cela, nous allons confortablement piloter Qemu/KVM en mode graphique depuis un poste client tournant sous CentOS 7 et muni de l’environnement de bureau KDE. Virt-Manager constitue sans doute l’interface la plus confortable.

# yum install virt-manager openssh-askpass ksshaskpass

Fermer et relancer la session KDE pour permettre l’intégration de Virt-Manager avec KWallet.

Créer une machine virtuelle

Démarrer le gestionnaire de machines virtuelles.

Configurer une connexion à l’hyperviseur via Fichier > Ajouter une connexion. Dans mon réseau, la connexion s’établit depuis un poste client.

KWallet nous permettre d’éviter les saisies de mots de passe à répétition.

Ce n’est pas la peine de cocher Remember password, étant donné qu’il s’agit uniquement de la confirmation (yes) pour la clé publique du serveur.

Saisir et confirmer le mot de passe pour une première utilisation de KWallet.

Cocher Remember Password, puis saisir le mot de passe de root sur le serveur.

La connexion à l’hyperviseur est établie.

Un clic droit sur l’hôte permet de créer une nouvelle machine virtuelle.

Pour installer notre machine virtuelle, nous utiliserons un fichier ISO rangé sur le serveur.

Nous choisissons l’image ISO dans la liste des fichiers disponibles.

Slackware Linux ne figure pas dans la liste des systèmes d’exploitation. Je garde donc la dénomination Generic.

Je définis la quantité de RAM et le nombre de processeurs pour ma machine virtuelle.

Je procède de même pour l’espace disque disponible.

La fenêtre subséquente me permet de choisir un nom pour ma machine virtuelle. Je prends soin de cocher Personnaliser la configuration avant l’installation pour peaufiner quelques détails importants. Le pont virbr0 constituera l’interface réseau partagée entre l’hôte et la machine virtuelle.

La vue d’ensemble sur la configuration de la machine virtuelle s’affiche.

Je spécifie le périphérique virtio pour la carte réseau. J’ai également la possibilité de personnaliser l’adresse MAC de la carte réseau.

Je remplace la carte vidéo QXL définie par défaut par un modèle VGA.

Une astuce consiste ici à ajouter une tablette graphique à la machine virtuelle, ce qui évite les mouvements de souris saccadés et aléatoires si jamais on utilise une interface graphique.

Il ne reste plus qu’à cliquer sur Commencer l’installation en haut à gauche de la fenêtre.

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Serveur de sauvegardes avec Rsnapshot sous CentOS

SauvegardeCet article décrit la mise en place d’un serveur de sauvegardes incrémentales avec Rsnapshot sous CentOS. Rsnapshot est une solution de sauvegarde robuste et efficace écrite en PERL et basée sur Rsync. En combinaison avec SSH, Rsnapshot permet d’effectuer des sauvegardes à distance. Une fois que la première synchronisation des données est effectuée, les sauvegardes se font de manière incrémentale moyennant une série de liens durs (hard links), ce qui évite la duplication inutile.

Rsnapshot tourne sur le serveur de sauvegardes. Les machines dont il faut sauvegarder les données sont totalement passives, il faut juste qu’elles aient un serveur SSH activé.

Prérequis

Le serveur de sauvegardes doit pouvoir se connecter via SSH aux machines distantes. Il faut donc configurer l’authentification par clé SSH au préalable.

Installation

Rsnapshot est fourni par le dépôt EPEL, qu’il faudra donc activer en conséquence.

# yum install rsnapshot

Configuration sur un serveur dédié

Rsnapshot se configure par le biais du fichier /etc/rsnapshot.conf. Le fichier fourni par défaut est amplement commenté et pourra servir de point de départ. La page de manuel rsnapshot(1) fournit la référence complète. Au lieu d’éditer le fichier /etc/rsnapshot.conf, nous allons le renommer et repartir de zéro.

# cd /etc
# mv rsnapshot.conf rsnapshot.conf.orig

Éditer une configuration personnalisée comme ceci, par exemple.

# /etc/rsnapshot.conf

# Version
config_version  1.2

# Emplacement des sauvegardes
snapshot_root   /srv/backup

# Programmes externes
cmd_cp              /usr/bin/cp
cmd_rm              /usr/bin/rm
cmd_rsync           /usr/bin/rsync
cmd_ssh             /usr/bin/ssh
cmd_logger          /usr/bin/logger
cmd_du              /usr/bin/du
cmd_rsnapshot_diff  /usr/bin/rsnapshot-diff

# Fréquence des sauvegardes
retain  hourly  6
retain  daily   7
retain  weekly  4
retain  monthly 3

# Affichage des infos
verbose 2

# Logs
loglevel        3
logfile /var/log/rsnapshot

# Fichier de verrouillage
lockfile        /var/run/rsnapshot.pid

# Fichiers à ne pas sauvegarder
exclude_file    /etc/rsnapshot_exclude.list

# sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/etc            sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/home           sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/var/named      sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/var/www/vhosts sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/usr/local/sbin sd-48975.dedibox.fr
backup  root@sd-48975.dedibox.fr:/sqldump        sd-48975.dedibox.fr

Quelques remarques.

  • Il faut impérativement utiliser les tabulations comme séparateurs. Si l’on utilise l’éditeur Vim, l’option :set list permettra d’afficher les tabulations dans le fichier. Si l’on a activé l’option :set expandtab qui remplace les tabulations par une série d’espaces, il faut également la désactiver grâce à :set noexpandtab.
  • L’emplacement des sauvegardes spécifié par la directive snapshot_root sera créé au besoin par Rsnapshot.
  • Les commandes correspondent à un système CentOS 7, et plus généralement à la plupart des distributions Linux.
  • La directive retain hourly 6 correspond à une sauvegarde complète toutes les quatre heures.
  • Le fichier spécifié dans la directive exclude_file contiendra éventuellement les types de fichiers et de répertoires sur lesquels on pourra faire l’impasse.
  • Dans l’exemple ci-dessus, on spécifie les arborescences de données à sauvegarder, plutôt que de choisir l’ensemble du système à la louche pour ensuite exclure les parties du système que l’on ne veut pas sauvegarder.
  • Les bases de données sont récupérées par le biais d’un script sqldump.sh installé sur la machine distante, qui range les sauvegardes SQL soigneusement ficelées dans un répertoire /sqldump. Voir la fin de l’article sur MySQL/MariaDB pour plus de détails.

Tester la configuration

Une fois qu’on a édité la configuration, on peut vérifier si l’on n’a pas fait d’erreurs de syntaxe.

# rsnapshot configtest
Syntax OK

L’option -t permet ensuite de simuler une sauvegarde. Dans ce cas, Rsnapshot nous affiche toutes les opérations qu’il effectuerait, sans réellement les exécuter.

# rsnapshot -t hourly

Synchronisation initiale

Si le serveur distant contient quelques centaines de gigaoctets de données, la première synchronisation peut être assez longue. La bonne politique consiste à effectuer cette première opération à la main, comme ceci.

# rsnapshot hourly

Dans une deuxième console, on peut se faire une idée de la progression du transfert.

# watch ls -lh /srv/backup

Au bout de l’opération, on pourra vérifier si tout s’est bien déroulé.

# less /var/log/rsnapshot

[2016-12-22T18:18:11] /usr/bin/rsnapshot hourly: started
[2016-12-22T18:18:11] echo 8430 > /var/run/rsnapshot.pid
[2016-12-22T18:18:11] mkdir -m 0700 -p /srv/backup/
[2016-12-22T18:18:11] mkdir -m 0755 -p /srv/backup/hourly.0/
[2016-12-22T18:18:11] /usr/bin/rsync -a --delete ...
                        ...
[2016-12-22T18:42:49] touch /srv/backup/hourly.0/
[2016-12-22T18:42:50] rm -f /var/run/rsnapshot.pid
[2016-12-22T18:42:50] /usr/bin/rsnapshot hourly: completed

Définition des tâches automatiques

Une fois que la synchronisation initiale s’est correctement déroulée, on peut songer à mettre en place une série de tâches automatiques.

# crontab -l
...
# Rsnapshot
0  */4 * * *  /usr/bin/rsnapshot hourly
45 3   * * *  /usr/bin/rsnapshot daily
30 3   * * 1  /usr/bin/rsnapshot weekly
15 3   1 * *  /usr/bin/rsnapshot monthly

Utilisation au quotidien

Au bout de quinze jours, voilà à quoi ressemble le répertoire des sauvegardes.

# ls -l /srv/backup/
total 60
drwxr-xr-x 3 root root 4096 janv. 20 04:00 daily.0
drwxr-xr-x 3 root root 4096 janv. 19 04:00 daily.1
drwxr-xr-x 3 root root 4096 janv. 18 04:00 daily.2
drwxr-xr-x 3 root root 4096 janv. 17 04:00 daily.3
drwxr-xr-x 3 root root 4096 janv. 16 04:00 daily.4
drwxr-xr-x 3 root root 4096 janv. 15 04:00 daily.5
drwxr-xr-x 3 root root 4096 janv. 14 04:00 daily.6
drwxr-xr-x 3 root root 4096 janv. 21 08:00 hourly.0
drwxr-xr-x 3 root root 4096 janv. 21 04:00 hourly.1
drwxr-xr-x 3 root root 4096 janv. 21 00:00 hourly.2
drwxr-xr-x 3 root root 4096 janv. 20 20:01 hourly.3
drwxr-xr-x 3 root root 4096 janv. 20 16:01 hourly.4
drwxr-xr-x 3 root root 4096 janv. 20 12:01 hourly.5
drwxr-xr-x 3 root root 4096 janv.  8 04:00 weekly.0
drwxr-xr-x 3 root root 4096 janv.  1 04:00 weekly.1

L’option du permet d’afficher un rapport détaillé sur l’espace disque occupé par les sauvegardes.

# rsnapshot du
23G	/srv/backup/hourly.0/
76M	/srv/backup/hourly.1/
298M	/srv/backup/hourly.2/
76M	/srv/backup/hourly.3/
412M	/srv/backup/hourly.4/
553M	/srv/backup/hourly.5/
838M	/srv/backup/daily.0/
964M	/srv/backup/daily.1/
991M	/srv/backup/daily.2/
833M	/srv/backup/daily.3/
829M	/srv/backup/daily.4/
815M	/srv/backup/daily.5/
761M	/srv/backup/daily.6/
50G	/srv/backup/weekly.0/
1,2G	/srv/backup/weekly.1/
82G	total

Configuration pour un réseau local

Dans mon réseau local, la configuration de Rsnapshot est quelque peu différente. J’effectue une seule sauvegarde par jour, et je conserve les données pendant une semaine.

# Fréquence des sauvegardes
retain  daily   7

Voici la définition des sauvegardes distantes.

# alphamule.microlinux.lan
backup  root@alphamule:/etc      alphamule
backup  root@alphamule:/home     alphamule
backup  root@alphamule:/root/sql alphamule

# balthazar.microlinux.lan
backup  root@balthazar:/etc      balthazar
backup  root@balthazar:/home     balthazar

La sauvegarde quotidienne doit être lancée à 13h00.

# crontab -l
# Rsnapshot
00 13 * * * /usr/bin/rsnapshot daily

Téléchargement

Des modèles de fichiers de configuration pour Rsnapshot sont disponibles dans mon dépôt Github, dans le répertoire centos/el7/rsnapshot.

$ git clone https://github.com/kikinovak/centos
Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Récupérer un système CentOS qui ne démarre plus

Récupération systèmeAujourd’hui, j’ai installé CentOS 7 en software RAID 5 sur un HP Proliant muni de quatre disques durs, et j’ai réussi à rendre mon système inutilisable en faisant une erreur dans la configuration du chargeur de démarrage. Pour l’anecdote, le fichier /etc/default/grub comporte une série d’options relatives à la grappe RAID, et un petit démon en moi tenait absolument à savoir si ces options étaient réellement indispensables.

GRUB_CMDLINE_LINUX="rd.md.uuid=16cf0747:ff424ef7:2d4a4be5:abeca5bb \
                    rd.md.uuid=23279930:daa818f6:e7002b9b:9255a52c \
                    rd.md.uuid=ba3c8e6b:45d2781e:9c57935f:60098517 \
                    nomodeset \
                    quiet \
                    vga=791"

Réponse brève : oui, elles le sont. Il suffit de les supprimer pour que le système bloque très tôt au démarrage. Cela faisait longtemps que je ne m’étais pas tiré dans le pied de manière aussi magistrale.

Mon installation était fraîche, c’était donc plus simple de tout refaire. Le problème, c’est que la grappe RAID a mis une éternité à faire sa synchronisation initiale, et je ne voulais pas passer un après-midi à tourner les pouces. Il fallait donc récupérer le système.

J’avais une clé USB d’installation de Slackware64 14.1 sous la main, et je me suis dit que ça tombait bien. Slackware 14.1 utilise un kernel de la série 3.10.x tout comme CentOS 7, ce qui me permettait d’effectuer un chroot.

J’ai donc démarré dessus (boot: huge.s vga=791), j’ai choisi ma disposition clavier et je me suis connecté en tant que root pour avoir un shell minimaliste.

La première chose à faire, c’est d’identifier mes grappes de disques. Lorsque j’effectue une installation, j’ai l’habitude de créer une partition /boot, une partition swap et une partition principale. Le hic avec les assemblages multi-disques, c’est que je ne sais plus qu’est-ce qui correspond à quoi. Évidemment, rien n’empêche de les monter l’un après l’autre pour voir ce qu’ils contiennent, mais c’est là où je me rends compte que c’était une bonne idée d’étiqueter mes grappes de disques pendant l’installation.

# cd /dev/disk/by-label/
# ls -l root
lrwxrwxrwx. 1 root root 11  3 mai   10:33 root -> ../../md127
# ls -l boot
lrwxrwxrwx. 1 root root 11  3 mai   10:33 boot -> ../../md125
# ls -l swap
lrwxrwxrwx. 1 root root 11  3 mai   10:33 swap -> ../../md126

Maintenant que les disques sont identifiés, je peux les monter. Mon environnement comporte un point de montage /mnt prédéfini, c’est là où je vais monter le système.

Pour commencer, je monte la partition principale.

# mount /dev/md127 /mnt

Ensuite, je monte la partition /boot.


# mount /dev/md125 /mnt/boot

Je lie les systèmes de fichiers /proc, /dev et /sys du système de restauration et du système installé.

# mount --bind /proc /mnt/proc
# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys

À partir de là, je peux chrooter dans mon système CentOS.

# chroot /mnt /bin/bash

J’effectue les modifications nécessaires, en l’occurrence la reconfiguration de GRUB. Une fois que j’ai terminé, je reviens vers le système de récupération.

# exit

Je démonte un par un les système de fichiers montés.

# umount /mnt/sys
# umount /mnt/proc
# umount /mnt/dev
# umount /mnt/boot
# umount /mnt

Il ne me reste plus qu’à redémarrer.

# reboot

Notez en passant que je peux très bien faire l’économie du démontage manuel des partitions, étant donné que l’arrêt du système de récupération se charge du démontage propre des systèmes de fichiers.

J’aurais très bien pu me servir d’une clé USB d’installation de CentOS. Dans ce cas, j’aurais opté pour Troubleshooting > Rescue a CentOS Linux system, et au démarrage j’aurais choisi l’option 3) Skip to shell. Dans la configuration par défaut, le clavier de la console est en QWERTY américain, ce que l’on peut corriger grâce à la commande loadkeys.

# loadkeys fr (ch-fr)

L’installateur de CentOS comporte déjà deux points de montage /mnt/install et /mnt/sysimage. On va donc devoir créer un point de montage distinct /mnt/hd avant de monter le système.

Publié dans CentOS, Documentation Microlinux, Slackware | Marqué avec , , | Laisser un commentaire

Verrouiller KDE en mode kiosk

kiosk-iconL’environnement KDE 4.14 livré avec CentOS 7 est un remplacement idéal pour Microsoft Windows 7, 8 ou 10. C’est un environnement flexible et configurable, et c’est là aussi son talon d’Achille. En effet, il peut arriver que l’on tombe sur des utilisateurs un peu moins doués, qui ont la curieuse habitude de se tirer dans le pied et rendre leur poste de travail inutilisable en supprimant des composants essentiels de leur bureau.

De temps en temps, un utilisateur aura la mauvaise idée de déverrouiller les composants graphiques du bureau et de supprimer le tableau de bord inférieur du bureau. Du coup, plus de menu, plus de lanceur, plus d’accès aux applications, et pas la moindre idée de ce qu’il faut faire pour rétablir tout cela.

kiosk-01La solution consiste donc à verrouiller ces parties essentielles du bureau pour qu’elles ne soient plus exposées à un clic malencontreux, tout en gardant la flexibilité nécessaire pour que le système reste adaptable aux besoins des utilisateurs. L’équipe de KDE fournit une documentation exhaustive sur le mode kiosk, avec des directives à n’en plus finir, et qui épuise aussi bien le sujet que le lecteur.

Heureusement pour nous, la solution à notre problème est d’une simplicité déconcertante. La configuration KDE de chaque utilisateur est stockée dans une multitude de fichiers rangés dans l’arborescence ~/.kde/share/config. Pour verrouiller le bureau d’un utilisateur, il suffit d’éditer le fichier plasma-desktop-appletsrc en ajoutant la directive [$i] dans une ligne au tout début du fichier, comme ceci :

[$i]
[ActionPlugins]
MidButton;NoModifier=paste
RightButton;NoModifier=contextmenu
wheel:Vertical;NoModifier=switchdesktop
...

kiosk-02Une fois que l’on a quitté KDE et qu’on s’est reconnecté, le bureau est verrouillé de telle sorte que ses composants essentiels ne peuvent plus être déverrouillés. L’utilisateur peut toujours modifier son fond d’écran et définir ses applications préférées dans les Favoris du menu Kickoff. En contrepartie, il ne peut plus supprimer par mégarde les composants essentiels de son bureau comme le tableau de bord ou l’aperçu du bureau.

Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire