FRANCISATION DE REDO BACKUP & RESTORE

Un Live CD va booter sur un Filesystem spécial ; celui-ci est un «unionFS» avec une partie en lecture seule et l'autre en lecture/écriture en RAM (pouvant être sur un disque dur par exemple pour les UnionFS utilisés hors Live CD). Le nom unionFS vient du principe d'union en C permettant de stocker dans un même espace mémoire deux variables différentes.

union mon_union
{
 int entier ;
 double reel ;
}

Le système réservera pour cette union l'espace mémoire qu'exige la plus grande des deux variables, soit dans notre cas 8 octets (car un int prend 4 octets sur une machine 32 bits, et un double 8 octets).

En appelant mon_union.entier, le contenu sera traité comme un entier, en appelant mon_union.reel, celui-ci sera traité comme un réel double précision. Appeler l'un puis l'autre n'aura aucun sens, la valeur sera erronée, c'est soit l'un ou soit l'autre, les deux pseudovariables occupant le même espace mémoire.

Si nous appliquons cela à l'unionFS :

Deux points de montage distincts sont reliés de façon à être vus comme un seul. Ils se superposent. Dans le cas d'un Live CD, une partie est en lecture seule et une seconde en lecture/écriture, en RAM.

Tant qu'aucune modification n'est effectuée, c'est la partie lecture seule qui est utilisée. Si un fichier est modifié, celui-ci sera écrit dans le point de montage dédié à l'écriture et c'est la nouvelle version qui sera « vue » par le système (la version d'origine, toujours présente dans la partie en lecture seule, est alors masquée par la nouvelle version dans la zone lecture/écriture). La suppression d'un fichier est gérée en le renommant avec le préfixe .whcc, ce qui permet de le cacher au système. Les fichiers préfixés de cette façon ne seront pas visibles..

Pour plus d'information : https://fr.wikipedia.org/wiki/Union_File_System.

SquashFS est un FileSystem qui est compressé et en lecture seule. La décompression s'effectue à la volée lors de son utilisation.

Pour plus d'information : https://fr.wikipedia.org/wiki/SquashFS.

Les Live CD récents couplent un SquashFS avec AuFS, qui fonctionne comme UnionFS.

Nous renommons les fichiers d'origine de Redo Backup dans notre copie :

mv /mnt/contenu/sbin/redobackup /mnt/contenu/sbin/redobackup.orig
mv /mnt/usr/share/redo/redobackup.glade /mnt/usr/share/redo/redobackup.glade.orig

Dans notre point de montage /mnt, nous avons les fichiers redobackup traduits dans le dossier fr, nous copions le contenu aux endroits adéquats :

cp /mnt/fr/redobackup /mnt/contenu/sbin
cp /mnt/fr/redobackup.glade /mnt/contenu/usr/share/redo

Une fois le nouveau squashFS généré, nous remplaçons l'ancien dans notre copie du CD :

mv /mnt/fileseystem.squashfs /mnt/cd/casper/

Isolinux est la version boot sur CD du bootloader Syslinux. Il est équivalent à Grub ou Lilo. Il est relativement simple à modifier. Sa configuration se trouve dans le fichier isolinux/isolinux.cfg.

Nous allons le modifier de façon à forcer l'utilisation du clavier français, et en profiter pour traduire le menu.

Nous éditons simplement la version de notre copie de CD avec l'éditeur de texte intégré : LeafPad.

Pour avoir le clavier français nous avons ajouté «locale=fr_FR console-setup/layoutcode=fr» sur la ligne APPEND (avant les « -- » de fin de ligne) comme vu ici.

Pour générer l'image ISO, nous utiliserons genisoimage, déjà intégré dans le Live CD. Comme nous aurons à effectuer plusieurs fois la gravure, nous allons créer un script dans notre partition.

#!/bin/sh
cd /mnt/cd
genisoimage -o /mnt/redobackup_fr.iso -b isolinux/isolinux.bin -c isolinux/boot.cat --no-emul-boot --boot-load-size 4 --boot-info-table -r -J ./

Une fois le CD généré, nous récupérons le fichier ISO dans l'hôte en SCP après avoir installé SSH.

La page Wikipédia d'OpenBox précise qu'il y a trois fichiers de configuration :

• ~/.config/openbox/menu.xml
• ~/.config/openbox/rc.xml
• ~/.config/openbox/autostart.sh

Dans ces fichiers, nous ne trouvons pas trace des entrées de menu présentes à savoir :

• Accessories
• System tools
• Settings

Si on clique avec le bouton droit sur la barre en bas (celle de l'accès au menu et de l'affichage de l'heure), et que l'on sélectionne « Preferences », le titre de la fenêtre affiche AdeskBar. Nous allons rechercher de ce côté.

AdeskBar est un lanceur d'applications pour OpenBox, écrit en Python.

Le dossier ~/.config/adeskbar contient un fichier default.cfg, mais dont le contenu ne correspond pas aux entrées de la barre de menu.

Sur les autres distributions de notre connaissance, les lanceurs sont des fichiers .desktop stockés dans ~/.local/share

En regardant dans ce dossier, nous trouvons un dossier contenant les fichiers correspondant aux applications. En éditant le fichier « File Manager » (file-manager.Desktop), et en modifiant la ligne « Name=… » pour y inscrire « Gestionnaire de fichiers », nous constatons, après avoir redémarré AdeskBar en tuant le processus, que cela a été pris en compte dans le menu. Nous modifions donc le nom des différentes entrées.

Nous nous occupons ensuite des titres de menus.

Dans le dossier ~/.local/share, nous trouvons un dossier desktop-directories contenant « Settings » et « System Tools », mais pas « Accessories ». Après modifications des deux entrées trouvées et redémarrage de ADeskBar, les modifications sont prises en compte.

Nous recherchons ensuite un fichier contenant « Accessories » dans le dossier de l'utilisateur courant :

grep -r Accessories .

Cette commande nous retourne des entrées dans le fichier .config/menu/applications.menu

Nous modifions le texte et redémarrons ADeskBar. Nous nous retrouvons avec deux entrées, un menu Accessoires contenant deux des cinq entrées du menu, et un menu « Accessories » contenant les trois autres. Ce n'est donc pas la bonne méthode.

En effectuant une recherche depuis la racine :

find . -name "*,directory"

nous trouvons un dossier /user/share/desktop-directories contenant un fichier Accessories. Après modification et redémarrage de ADeskBar, cela fonctionne.

Nous avons recopié les fichiers /root/.local/share dans le dossier etc/skel/.local/share de notre copie du squashFS, car dans un Live CD les comptes utilisateurs sont crées à la volée à partir de etc/skel tout comme pour la création d'un utilisateur sur un système standard. Le fichier Accessoires modifié dans /usr/share/dektop-directories a également été copié au même niveau.

Une fois le CD régénéré (comme présenté dans la partie 5Modification du Live CD), nous avons bien les éléments du menu traduit.

Traduction du système et des outils.

Recherche de francisation du système.

Nous avons tout d'abord tenté de trouver des solutions à la francisation du système de Redo Backup en cherchant :

• dans la documentation sur LXDE et OpenBox disponible sur Internet ;
• sur les forums autour de la question des problèmes de traduction de LXDE et d'OpenBox ;
• dans la documentation plus générale concernant la traduction des distributions Linux.

Ces pistes ont permis de trouver des solutions partielles. En installant un paquet de langues par :

apt-get install language-pack-gnome-fr

et en créant un fichier /etc/default/locale contenant :

LANG="fr_FR.UTF-8"

le système en lui-même est francisé (les messages dans un terminal), ainsi que la date et l'heure, des éléments du menu et de l'interface graphique, mais pas tous. L'interface graphique OpenBox demeure essentiellement en langue anglaise.

Nous décidons alors de faire appel à une démarche méthodique basée sur l'émission d'hypothèses et leur vérification en travaillant directement sur la distribution de Redo Backup installée de façon complète sur une partition en dur. Le principe d'une installation en dur est le même que dans la partie Préparation du Live CDPréparation (décompression du fichier squashFS). Il faudra de plus créer un répertoire /boot dans lequel on insérera les deux fichiers vmlinuz et initrid.lz qui se trouvent dans le répertoire /casper du CD. Si cette installation se fait en multiboot, on pourra démarrer sur la partition de Redo Backup en faisant un update-grub à partir du système principal si l'on est sous Linux.

Les bibliothèques de traduction sont-elles toutes bien présentes ?

Regardons du côté des fichiers ajoutés avec language-pack-gnome-fr. Ils se trouvent dans
/usr/share/locale-langpack/fr.

Nous y trouvons un dossier LC_MESSAGES dans lequel sont présents de nombreux fichiers avec l'extension .mo et des noms qui évoquent des fonctions ou applications du système. Ces fichiers ne sont pas lisibles avec un éditeur de texte.

Une recherche sur Internet nous permet de voir que ces fichiers .mo sont des fichiers de traduction, dans un format compilé. On peut les décompiler pour retrouver le fichier dans un format .po éditable avec un éditeur de texte (voir :http//www.allili.net/tutoriaux/convertir-les-fichiers-mo-et-po).

Nous essayons de décompiler un de ces fichiers, par exemple le fichier file-roller.mo, par la commande :

msgunfmt /usr/share/locale-langpack/fr/LE_MESSAGES/file-roller.mo > ~/file-roller.po

En regardant le contenu du fichier texte obtenu, nous voyons qu'il s'agit bien d'un fichier de traduction, et ici qu'il s'agit de la traduction du logiciel d'archivage.

Les bibliothèques de traduction semblent donc bien présentes.

Le système fait-il correctement le lien vers ces fichiers de traduction ?

Le système étant traduit en mode texte comme on peut le voir en utilisant un terminal, on peut donc supposer que c'est au niveau de l'interface graphique que pourrait se situer le problème. La saisie de la commande :

locale

dans un terminal nous montre que les variables d'environnement sont correctement définies. Ce n'est donc pas à ce niveau qu'il y a problème.

Si nous regardons du côté des fichiers de configuration de l'interface graphique, ils se situent dans /etc/xdg/openbox et comportent trois fichiers qui peuvent être surchargés dans une session utilisateur dans ~/.config/openbox.

Tout ce qui concerne l'environnement graphique peut également se situer dans /etc/x11.

Nous nous appuyons sur une distribution Lubuntu, basée sur lxde et Openbox, afin de comparer les deux distributions et tenter de déceler ce qui pourrait manquer à Redo Backup. Les trois fichiers de /etc/xdg/openbox sont présents dans les deux distributions, et rien, dans leur contenu, ne permet d'envisager un problème de ce côté.

On examine /etc/x11. Seule différence essentielle, la présence d'un lien symbolique pointant vers /usr/bin/Xorg dans Redo Backup.

Dans le sous-répertoire xinit, on voit que deux répertoires existent sous Lubuntu et non sous Redo Backup. Le répertoire xinitrc.d de Lubuntu contient un fichier, 50-systemd-user.sh, faisant appel à un élément d'environnement. Nous copions ce répertoire à la même place dans Redo Backup afin de voir s'il y a des changements.

Nous lançons dans une console sous Redo Backup le fichier 50-systemd-user.sh qui est un script. On obtient un message d'erreur informant d'un fichier manquant, systemctl. Nous allons donc le localiser dans Lubuntu par :

find /chemin/Lubuntu -name "systemctl"

Nous le copions dans le répertoire équivalent de Redo Backup, puis nous relançons 50-systemd-user.sh.

Nous avons un nouveau message d'erreur indiquant qu'il manque la bibliothèque libgcrypt.so.20.

Une recherche sur Internet montre qu'il s'agit d'une bibliothèque utilisée pour la cryptographie. Cela ne présente donc pas d'intérêt quant à notre problème.

Nous trouvons un autre sous-répertoire absent dans Redo Backup : xinput.de.
L'analyse de son contenu laisse supposer qu'il a pour rôle la prise en charge des langues asiatiques. Cela ne nous concerne donc pas.

Nous savons que c'est dans le dossier LC_MESSAGES que se trouvent les bibliothèques de traduction. Voyons donc s'il y a des différences entre Lubuntu et Redo Backup dans les fichiers pouvant faire appel à ce dossier. Nous saisissons dans un terminal :

sudo grep -rn "LC_MESSAGES" /etc/*

pour chacune des distributions. Nous ne voyons pas de différences au sein du dossier /etc.

Nous cherchons maintenant dans LC_MESSAGES de Lubuntu une bibliothèque d'une application également présente dans Redo Backup afin de vérifier si les menus de cette application sont traduits. Cela nous permettra de vérifier si le système renvoie bien vers les fichiers de traduction. Nous trouvons un fichier gparted.mo, et en lançant Gparted dans Redo Backup, nous constatons que l'application graphique est correctement traduite.

Le renvoi vers les traductions se fait correctement. Nous pouvons formuler une nouvelle hypothèse.

Les traductions se font également ailleurs que dans le seul dossier  /usr/share/locale-langpack/fr/LC_MESSAGE

Soit il y a présence de bibliothèques du même type dans d'autres dossiers, soit les traductions se font dans les binaires des applications.

Nous tentons une copie d'un binaire de Lubuntu à la place de celui équivalent de Redo Backup, par exemple celui du file manager PCManFM. Nous effectuons l'opération et lançons :

pcmanfm

sous Redo Backup à partir d'une console. Un message d'erreur nous indique qu'il manque la bibliothèque libfm-gtk.so.4. Donc nous saisissons :

apt-get update

puis :

apt-get install libfm-gtk

Nous obtenons un message nous indiquant qu'il est impossible de trouver le paquet.

Une recherche sur Internet nous apprend que ce paquet fait partie du paquet libfm-gtk4 qui reste lui-même introuvable pour Redo Backup. Nous nous heurtons en fait ici à un problème de version entre Lubuntu et Redo Backup : 15.10 pour Lubuntu, 12.04 pour Redo Backup.

Nous allons donc télécharger et installer une Lubuntu 12.04. Ceci fait, nous tentons à nouveau le remplacement du fichier binaire de PCmanFM par celui d'une Lubuntu 12.04, correctement traduit. Le lancement sous Redo Backup se fait sans problème, mais les menus de l'application sont toujours en anglais. Ce n'est donc pas dans le binaire que se font les traductions.

Nous tentons maintenant de trouver un fichier de traduction de PCManFM dans la Lubuntu 12.04 en faisant une recherche sur tous les fichiers .mo présents :

find /usr -name "*.mo"

Comme nous obtenons un très grand nombre de fichiers, nous affinons en filtrant ceux qui sont en rapport avec la langue française :

find /usr -name "*.mo" | grep "fr"

Nous découvrons un autre dossier, /usr/share/locale/fr/LC_MESSAGES, dans lequel se trouvent des fichiers au nom explicite : pcmanfm.mo, openbox.mo, etc.

Nous nous apercevons que ce dossier existe dans Redo Backup, mais il est vide. Nous y copions donc les fichiers de Lubuntu 12.04.

Nous redémarrons sur notre distribution Redo Backup et… elle est maintenant complètement francisée.

Cette démarche nous a permis de cerner où se situaient les problèmes de traduction. Certains fichiers manquants sont donc à reconstituer. La démarche suivante va expliquer comment y parvenir.

Après ces essais, nous passons à la réalisation proprement dite de la traduction.

Nous entrons en chroot dans la copie du squashFS du Live CD Redo Backup d'origine (comme vu au chapitre 5.8Modification du système source).

Commençons par regarder les locales :

locale

La commande nous retourne les erreurs suivantes :

locale: cannot set LC_CTYPE to default locale: no such file or directory
locale: cannot set LC_MESSAGES to default locale: no such file or directory
locale: cannot set LC_COLLATE to default locale: no such file or directory

suivies des différents champs LC. Les champs LANGUAGE et LC_CTYPE sont vides, les autres champs sont bien positionnés sur fr_FR.UTF-8.

Régénérons les locales :

locale-gen "fr_FR.UTF-8"

Puis ensuite :

dpkg-reconfigure locales

l'appel à la commande locale ne déclenchera plus d'erreur.

Pour la forme :

apt-get update

Nous en profitons pour mettre à jour le fuseau horaire :

dpkg-reconfigure tzdata

Régénérons le squashFS puis le CD et voyons le résultat.

Au boot, aucun changement.

Pour faire des tests, nous essayons ensuite de réinstaller l'éditeur de texte leafpad :

apt-get --reinstall install leafpad

Après régénération du CD, même problème.

Nous remarquons, en fin de retour de la commande de réinstallation de leafpad, les messages suivants :

localpurge: Disk space freed in /usr/share/locale: 272KiB
localpurge: Disk space freed in /usr/share/man: 0KiB
localpurge: Disk space freed in /usr/share/gnome/help: 0KiB
localpurge: Disk space freed in /usr/share/omf: 0KiB

L'application «localpurge»  ne nous effacerait-elle pas automatiquement les fichiers de traduction ?

Désinstallons localepurge :

apt-get remove localepurge

Puis réinstallons leafpad.

Regardons le contenu des locales :

ls /usr/share/locale/fr/LC_MESSAGES

leafpad.mo

Très bon signe.

Régénérons le CD pour voir le résultat.

Cela fonctionne. Appliquons la méthode aux autres applications des menus :

apt-get --reinstall install pcmanfm
apt-get --reinstall install chromium-browser
apt-get --reinstall install baobab
apt-get --reinstall install gparted
apt-get --reinstall install system-config-lvm
apt-get --reinstall install lxrandr
apt-get --reinstall install lxappearance
apt-get --reinstall install lshw-gtk
apt-get --reinstall install obconf

Après régénération du CD et reboot, certains programmes restent non traduits (Gparted, utilitaire de disque). Il semblerait qu'il s'agisse de programmes Gnome.

Essayons ceci :

apt-get install language-pack-gnome-fr

Cela résout le problème.

Reste non traduit Photorec dont il n'existe pas de version française.

Chromium nous a également posé problème, résolu en installant le paquet «chromium-browser-l10n» :

apt-get install chromium-browser-l10n

root@ubuntu:~# chromium-browser
[1971:1971:0330/111614:FATAL:setuid_sandbox_client.cc(282)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/chromium-browser/chrome-sandbox is owned by root and has mode 4755.

chmod u+s /usr/lib/chromium-browser/chrome-sandbox