volted.net

A blog about openSUSE and free thoughts

Partition utilisateur dans un volume btrfs

December 12, 2018 — sogal

btrfs est un système de fichier moderne, donné pour être le remplaçant du veillissant, mais toujours très fiable et très utilisé, ext4. Il est le choix de base de la proposition de partitionnement par défaut lors de l'installation d'openSUSE pour la partition racine. La partition /home, si l'utilisateur fait le choix d'en créer une séparée, est en xfs.

On a entendu beaucoup de chose sur l'usage (ou le mésusage selon les cas) de btrfs avec notamment des problèmes dûs aux scripts de maintenance (présents dans /usr/share/btrfsmaintenance/ et lancés par leur timers systemd respectifs). Il faut reconnaître que les opérations de scrub et de balance des blocs ralentissent, parfois, considérablement le système durant un instant. Et plus on attend pour le faire (ex. d'un système n'étant pas utilisé souvent et, à chaque utilisation, recevant une grande quantité de données sur le disque), plus il y a de travail à faire et cela peut durer jusqu'à 5 minutes, durant lequel la machine est très ralentie, voire peut apparaître bloquée. Je ne vais pas revenir là-dessus, ce sujet a été abordé maintes fois à grand coup de trolls, de mauvaise foi et d'arguments non factuels à plusieurs endroits.

Dans ce billet, je voudrais juste partager un retour d'expérience, positif, sur l'usage de btrfs non seulement sur la partition racine, mais également dans ma partition /home. En effet, j'ai décidé il y a plusieurs semaines de convertir ma partition xfs (proposition de base de l'installeur openSUSE) en btrfs afin de profiter des snapshots.

Pour ce faire, j'ai commencé par passer en runlevel 3 :

init 3

J'ai fait une sauvegarde de mon /home actuel sur un disque externe :

rsync -arv --progress /home/ /run/media/user/DISK_BACKUP/

Ceci fait, j'ai démonté mon /home :

umount /home

Puis formater la partition en btrfs. Notez ici que si ça avait un système de fichier de type ext2/3/4 ou reiserfs, j'aurai pu tout simplement le convertir en btrfs, sans perte de données, via la commande btrfs-convert -p -l home /dev/partition_home. Pour formater la partition donc :

mkfs.btrfs -L home /dev/partition_home

Ceci fait, ne pas omettre de modifier le /etc/fstab pour refléter le changement de système de fichier. J'ai ensuite créé un sous-volume btrfs au nom de mon utilisateur :

btrfs subvolume create /home/user

Dans lequel j'ai activé les snapshots, but de toute l'opération :

snapper -c home create-config /home/user

Ceci va me créer une configuration pour snapper, l'utilitaire en charge de gérer la création et la suppression des snapshots, dans /etc/snapper/configs/home que j'ai adapté à mes besoins comme suit :

# nom du sous-volume dont il faut prendre un instantané
SUBVOLUME="/home/user"

# type du système de fichier
FSTYPE="btrfs"

# btrfs qgroup for space aware cleanup algorithms
QGROUP=""

# part du système de fichier que les instantanés peuvent utiliser
SPACE_LIMIT="0.5"

# utilisateurs et groupes autorisés à faire usage de cette configuration
ALLOW_USERS="user"
ALLOW_GROUPS=""

# synchroniser les droits des utilisateurs et les groupes définis ci-dessus
# avec le répertoire .snapshots
SYNC_ACL="yes"

# démarrer la comparaison des snapshots -pre et -post en arrière-plan après
# la création du snapshot -post
BACKGROUND_COMPARISON="yes"

# exécuter le nettoyage quotidien, basé sur l'algorithme du nombre d'instantané
NUMBER_CLEANUP="yes"

# limite pour le nettoyage quotidien, basé sur l'algorithme du nombre d'instantané
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"

# créer des instantanés horaires (oui, c'est bien le but de ma manœuvre)
TIMELINE_CREATE="yes"

# nettoyer les instantanés horaires après un certain temps
TIMELINE_CLEANUP="yes"

# limites pour le nettoyage de la timeline (les instantanés horaires)
# âge minimum de l'instantané
TIMELINE_MIN_AGE="1800"
# nombre d'instantanés horaires à conserver au maximum
TIMELINE_LIMIT_HOURLY="24"
# nombre d'instantanés journaliers à conserver au maximum
TIMELINE_LIMIT_DAILY="14"
# nombre d'instantanés hebdomadaire à conserver au maximum
TIMELINE_LIMIT_WEEKLY="4"
# nombre d'instantanés mensuels à conserver au maximum
TIMELINE_LIMIT_MONTHLY="3"
# nombre d'instantanés annuels à conserver au maximum
TIMELINE_LIMIT_YEARLY="0"

# lancement du nettoyage des paires d'instantané -pre et -post vide
EMPTY_PRE_POST_CLEANUP="yes"

# âge minimum des instantanés nettoyés par l'algorithme pre-post
EMPTY_PRE_POST_MIN_AGE="1800"

Ainsi je vais pouvoir disposer d'instantanés me permettant de remonter dans le temps si jamais je fais une fausse manip' et efface des fichiers par erreur ou autre bêtise. Et les instantanés de la partition système me permettent, depuis le menu de démarrage de GRUB de sélectionner de démarrer sur un instantané en lecture seule afin de pouvoir réparer mon système en cas de soucis.

J'utilise ce setup avec deux partitions en btrfs, une pour le système, une pour mes données, chaque d'elle disposant de leur fréquence de création d'instantanés, depuis plusieurs mois sur une machine que j'utilise au quotidien. Et je dois dire que j'en suis très content ! Je n'ai pas eu de soucis de ralentissements agaçants, les instantanés sont bien créés puis supprimés conformément à la configuration, bref, impeccable !

Tags: opensuse

openSUSE Leap 15.0 est sortie !

December 02, 2018 — sogal

Aujourd'hui vendredi 25 mai, c'est la sortie d'openSUSE Leap 15.0 !

Au menu de cette release :

  • un nouveau rôle de serveur transactionnel permettant des mises à jours atomiques ;
  • GNOME 3.26 ;
  • Utilisation de Wayland par défaut (mais Xorg reste disponible) ;
  • Un nouveau partitionnement Btrfs utilisant la libstorage-ng ;
  • firewalld remplace SuSEFirewall ;
  • bien d'autres nouveautés (voir les release notes )

Et pendant que vous lirez ces lignes, je serai à Prague, en train de visiter et d'assister la conférence openSUSE 2018 et de fêter cette sortie !

Have a lot of fun !

Tags: opensuse

Réduire la taille d'un volume système en RAID1

December 02, 2018 — sogal

Lors de l'installation de ma station de travail en openSUSE Leap 42.3, je n'avais pas créé de partition /home dédiée, n'en ayant alors pas l'utilité. Mes besoins ayant changé, me voici avec une partition racine sur un RAID1 qu'il va me falloir réduire sans perte de données, car je n'ai pas l'intention de réinstaller. Je partage ici la procédure que j'ai suivie dans l'espoir qu'elle puisse vous être utile.

Le contexte :

  • Un RAID1 nommé /dev/md127 composé de /dev/sda3 et /dev/sdb3
  • ... d'une taille de de 216 Go
  • ... contenant un système de fichiers au format btrfs
  • ... que je veux réduire à 51 Go (soit 10 Go de plus que la taille actuellement consommée)
  • ... dont les partitions débutent, sur leur disque respectif, à 8.5 Go.

Préparation :

Bien entendu, afin de pallier tout problème éventuel, j'ai fait une sauvegarde complète de mon /home :

rsync -arv --progress /home/ /run/media/sogal/MyDisk/homebak/

Et j'ai testé ma procédure par deux fois dans une machine virtuelle reproduisant le contexte énoncé précédemment.

Puis j'ai lancé l'utilitaire btrfs de défragmentation sur / au cas où :

btrfs filesystem defragment -r -v /

Ceci étant fait, je peux passer à la phase du redimensionnement proprement dit. Pour cela, il me faut un système live, j'ai pris la dernière Linux Mint, seule ISO Live récente que j'avais sous la main, avec laquelle j'ai créé une clé USB bootable.

La procédure :

  1. Démarrer sur la clé USB ;

  2. Installer les utilitaires de gestion RAID nécessaires :

    apt-get install mdadm
    
  3. Charger les modules nécessaires :

    modprobe mdio
    modprobe linear
    modprobe multipath
    modprobe raid0
    modprobe raid1
    modprobe raid5
    modprobe raid6
    modprobe raid10
    
  4. Chercher les volumes RAID présents :

    mdadm --examine --scan
    
  5. Activer les volumes RAID trouvés :

    mdadm -A --scan
    
  6. Monter le volume RAID1 à réduire :

    mount /dev/md127 /mnt
    
  7. Redimensionner le système de fichiers :

    btrfs filesystem resize -165G /mnt
    

    Cette opération a pris un bon moment, laisser le travail se faire !

  8. Une fois le système de fichiers btrfs réduit, démonter le volume RAID1 :

    umount /mnt
    
  9. Mettre une des partitions en échec :

    mdadm /dev/md127 --fail /dev/sda3
    
  10. Puis la retirer du RAID :

    mdadm /dev/md127 --remove /dev/sda3
    
  11. Redimensionner la partition un poil plus grand que le système de fichiers :

    parted /dev/sda → resizepart 3 → end 60GB→ Yes → quit
    
  12. Vérifier le système de fichiers :

    btrfs check /dev/sda3
    

    Il va renvoyer une série de messages qui ne veulent pas dire que le système de fichiers est corrompu, pour s'assurer de la réussite du test, vérifier son code de retour :

    echo $?
    

    si c'est 0, c'est tout bon.

  13. Réduire le volume RAID1 à une taille légèrement inférieure à celle des partitions qui le composent (j'ai mis 500 Mo de moins) :

    mdadm --grow /dev/md127 --size=xxxx
    

    où xxxx = taille souhaitée en GB * 1024 * 1024

  14. Rajouter le disque au RAID :

    mdadm /dev/md127 --add /dev/sda3
    
  15. Attendre la reconstruction du volume RAID1, visible en lançant :

    cat /proc/mdstat
    
  16. Faire pareil avec l'autre partition (/dev/sdb3 dans mon cas) (étapes 8 à 14 mais pas la 13 !)

  17. Agrandir le volume RAID1 au maximum de la nouvelle taille des partitions qui le composent :

    mdadm --grow /dev/md127 --size max
    
  18. Redémarrer sur votre système habituel :

    reboot
    

Le résultat :

Au redémarrage sur ma Leap, rien à signaler, mes disques /dev/sda et /dev/sdb disposent maintenant d'un espace libre de 165 Go dans lequel j'ai pu créer, respectivement les partitions /dev/sda4 et /dev/sdb4 que j'ai ajouté à un nouveau volume RAID1 (chiffré pour le coup) dans lequel j'ai transféré mon /home.

Enjoy !

Tags: tips, opensuse

openSUSE en quelques questions

November 30, 2018 — sogal

De retour des JDLL, une petite présentation reprenant les questions qui revenaient le plus souvent sur openSUSE. Les 24 et 25 mars derniers, je tenais le stand openSUSE aux Journées du Logiciel Libre et force est de constater que cette distribution est très mal connue en France, aussi bien des débutants (ce qui peut sembler normal) que d'utilisateurs avec plus d'expériences de l'univers GNU/Linux. À l'issue du week-end, j'ai donc fait une présentation .odp présentant (très rapidement, ce n'est pas du tout exhaustif) les deux distributions créées par le projet openSUSE ainsi que leurs points forts les plus saillants.

Le .pdf de la présentation est disponible ici :

2018-Presentation_openSUSE.pdf

Enjoy !

Tags: opensuse

Comment sont choisies les versions du kernel d'openSUSE Leap ?

November 30, 2018 — sogal

Linux

La prochaine version d'openSUSE Leap, numérotée 15, pointe son nez et on sait d'ores et déjà qu'elle bénéficiera du noyau Linux en version 4.12. Cela pourrait en étonner plus d'un et on serait en droit de se demander pourquoi un tel choix alors que la version courante du noyau est 4.15 ou si, au court de sa vie, le noyau de Leap 15 pourra être mis à jour afin de ne pas rester avec un noyau jugé trop ancien.

Cette question a été posée sur la liste de diffusion opensuse-factory et un des participants très informé à bien voulu prendre le temps de donner une réponse claire et complète qu'il paraît important de retransmettre. Le texte qui suit en est donc une traduction et une adaptation au format « article » libres.

Pourquoi Leap 15 aura le noyau 4.12 au lieu de la version 4.14 (ou ultérieure) ? (par Peter Linnell)

Il faut tout d'abord rappeler que la distribution openSUSE Leap bénéficie d'une base de code partagée avec la version professionnelle SLE (Suse Linux Enterprise), base dont le noyau fait partie. À cet égard, il faut beaucoup de temps pour que le noyau obtienne les certifications requises pour fonctionner sur les matériels des clients de Suse et avec les logiciels d'autres éditeurs professionnels. Toutes les étapes permettant une telle certification pour le noyau 4.12 auraient dû être retardées ou bien recommencées pour la version 4.14 si celle-ci avait été choisie en finalité. Le travail à fournir afin d'obtenir une telle certification est colossal et coûteux, il nécessite la mobilisation de nombreux ingénieurs et requiert d'avoir à disposition les différents matériels pour lesquels la distribution doit être certifiée.

L'auteur de la réponse initiale rapporte l'exemple du processus de certification d'un serveur type « lame » et d'une armoire de stockage. Il a fallu pour cela mobiliser 3 ingénieurs durant plusieurs jours, assurer le déplacement au travers des États-Unis de 2 experts SUSE (dont l'auteur) pour un total estimé à plus de 10 000 $. Le tout pour certifier un seul type de matériel !

Les membres de la communauté openSUSE ne sont sûrement pas tous conscients du genre de matériel pour lequel est certifiée la SLE (SUSE Linux Enterprise) (ndt: et donc le noyau de la Leap) mais il s'en trouve parmi eux de très exotiques et très chers. On peut citer deux exemples :

  1. Les serveurs SAP HANA qui tournent quasi exclusivement sous SLES (SUSE Linux Enterprise Server). Une image système de 32 To peut absorber jusqu'à 5 ou 6 fois ce volume de données compressées et les contenir en mémoire. Nous parlons là de 150 à 180 To de données disponibles en RAM afin de réaliser des analyses en temps réel ! Pratiquer des tests sur ce genre de monstres nécessite d'une part des semaines d’ingénierie et d'autre part que le fabriquant mette à disposition une machine de plusieurs millions de dollars.

https://www.hpe.com/us/en/solutions/sap-hana.html

  1. Les systèmes SGI, une entreprise rachetée par HPE. Il s'agît de systèmes NUMA (« non uniform memory architecture » ou architecture mémoire non uniforme) pouvant théoriquement gérer jusqu'à 64 To de RAM avec un seul noyau Linux.

https://www.hpcwire.com/2016/05/11/t...life-sciences/

En ce qui concerne les logiciels, certaines piles logicielles éditées par les fabricants peuvent prendre des semaines pour être certifiées. Les fabricants eux-mêmes peuvent réaliser des tests de résistance ou des contrôles qualité afin de s'assurer que tout est conforme. Après tout, les éditeurs de logiciels fournissent un certain niveau de garantie à leurs clients en ce qui concerne la compatibilité et la stabilité qu'ils se doivent de maintenir. Un problème dans leurs logiciels pourrait entraîner un manque à gagner considérable pour leurs clients.

Donc, du point de vue de l'entreprise, la décision que telle version du noyau sera utilisée met en branle une machinerie complexe, requérant une grande coordination, en interne mais aussi avec les clients et partenaires. Ce genre de décision n'est donc pas pris à la légère.

En tant que membres de la communauté openSUSE, nous avons donc de la chance de bénéficier d'une telle ingénierie. Ce sont littéralement des millions de dollars d'investissement qui, non seulement sont mis à disposition dans Leap, mais qui démontre bien la volonté affirmée de SUSE de voir openSUSE réussir et de l'intérêt que l'entreprise porte à notre communauté.

Pour conclure, il faut rappeler, si besoin, que le noyau, bien qu'en version 4.12 bénéficiera des rétro-portages (« backports ») tout au long de sa durée de vie en vue d'apporter des correctifs et d'améliorer la prise en charge matérielle et logicielle.

Tags: opensuse

openSUSE Leap 42.3 est sortie !

November 29, 2018 — sogal

openSUSE Leap 42.3 est sortie officiellement aujourd'hui. Cette version est une version mineure de la série 42, elle apporte peu de changement dans la base du système mais rafraîchit l'ensemble de paquets. Pas de révolution donc pour Leap, la version "conservatrice" de la distribution au caméléon, mais ses points forts le sont encore plus !

Voici quelques extraits de l'annonce de sortie :

Toujours plus stable : Après avoir déjà ajouté de code source de SLE 12 dans Leap 42.2 par rapport à la 42.1, Leap 42.3 va plus loin en intégrant encore d'avantage de paquets de SLE 12 SP 3 et en synchronisant de nombreux paquets communs. Prête à être utilisée comme serveur : openSUSE Leap 42.3 offre la possibilité de sélectionner un profil Serveur durant l'installation. Sans environnement graphique, une installation serveur de Leap est prête à effectuer tout ce que vous attendez.

Idéale pour les développeurs et surtout les administrateurs systèmes.

Pour tous les utilisateurs : elle intègre des versions stabilisées et éprouvées des environnements de bureaux les plus répandus, dont principalement KDE Plasma 5.8 LTS et GNOME 3.20. Aucun problème pour jouer sous Linux, Steam et PlayOnLinux peuvent être installés très simplement.

Pour fêter ça, j'ai arboré fièrement mon plus beau t-shirt 😄 :

openSUSE Tshirt

et j'ai fait la mise à jour de mon poste de travail, directement en ligne par le réseau (certains préfèrent passer l'ISO) :

Vérification des dépôts actifs :

zypper lr -u

Suppression des dépôts inutiles :

zypper rr n°_du_dépôt

Ou désactivation :

zypper mr -d n°_du_dépôt

Copie des anciennes sources (au cas où) :

cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old

Changement de version des dépôts :

sed -i 's,42\.2,42.3,g' /etc/zypp/repos.d/*

Rafraîchissement des dépôts et des clés GPG :

zypper --gpg-auto-import-keys ref

Là je suis passé en console (tty) puis en runlevel 3 (par précaution) :

init 3

Et on lance la mise à jour :

zypper dup

Enfin, on redémarre :

reboot

Une heure après environ, c'était fait et me voilà avec un système mis à jour de façon complètement transparente, sans rien casser ni dérégler, j'ai pu reprendre mon travail dans la foulée.

J'utilise openSUSE quasi exclusivement depuis 8 mois maintenant, au travail comme à la maison, et je dois dire que j'en suis ravi. La facilité avec laquelle j'ai effectué cette mise à jour me conforte encore dans ce choix et dans mon impression de distribution professionnelle. Elle est malheureusement trop peu représentée en France et je trouve cela dommage. J'encourage donc les utilisateurs, particuliers ou professionnels, à la recherche d'un système d'exploitation fiable, stable sans être trop longtemps figé, simple à prendre en main et à gérer (merci Yast) à télécharger cette nouvelle version, à la tester et à rejoindre la communauté des utilisateurs francophones .

Enjoy !

Tags: opensuse

Changer de distrib : un comparo Debian / CentOS / openSUSE

November 29, 2018 — sogal

En recherchant il y a quelques mois une nouvelle distribution pour mon ordinateur professionnel, j'ai (re)découvert openSUSE. Quelques mois après, je vous propose ici mon retour d'expérience.

Pourquoi changer ?

Jusqu'à présent j'utilisais Debian, ma distribution de choix depuis 2012. J'en étais jusqu'à très content, j'ai passé plus de 2 excellentes années sous Wheezy, version grâce à laquelle j'ai appris et expérimenté énormément de choses, puis 1 an et demi sous Jessie. J'ai rencontré un peu plus de petits désagréments avec Jessie. Rien de grave mais je me suis moins éclaté qu'avec Wheezy. Bref, depuis début 2016, la société dans laquelle je travaille utilise Fedora sur les postes clients. Avec plusieurs mois de retard, je me suis mis, j'ai d'ailleurs rédigé un billet là-dessus. Ce n'est pas un mauvais système mais 2 choses principalement m'ont déplu :

  • le cycle de release, trop rapide. Qui a dit "obsolescence programmée" ? ;)
  • le gestionnaire de paquet, dnf, que je n'apprécie pas, le trouvant trop pataud.

Je voulais donc autre chose, une distribution équilibrée, avec un cycle de release décent (annuel, pas moins) tout en disposant d'ensemble de paquets pas trop vieux et contenant tous les outils professionnels dont j'ai besoin.

Choisir et tester :

Avec ces considérations en tête, le tour a été relativement vite fait et j'ai établi un comparatif entre 3 distributions :

  • Debian (stable évidemment) ;
  • CentOS 7 ;
  • openSUSE Leap 42.2 (qui était alors à 2 semaines de sa sortie en stable).

J'ai monté 3 machines virtuelles, établi une grille de critères reprenant, entre autres ceux, énoncés ci-dessus et essayé ces 3 systèmes dans tous les sens, avec des configurations égales (autant que possible) et en essayant les mêmes paquets.

Dépôts Debian

Le projet Debian fournit très clairement l'ensemble de paquets le plus complet et le plus cohérent (j'entends par là qu'ils sont tous dans un seul dépôt (jusqu'à 3 si on active contrib et non-free).

Dépôts CentOS

Les dépôts de base de CentOS m'ont paru plus "pauvres" mais contiennent la très grande majorité des outils nécessaires sur un poste de travail. La "fraîcheur" des versions est variable, mais à l'image d'une Debian stable dans l'ensemble. Un certain nombre d'outils plus spécifiques requièrent l'ajout du dépôt EPEL. Je n'ai pas apprécié l'utilisation de yum que je trouve assez lent dans l'ensemble, surtout comparé à apt (apt-get) qui est tout de même très rapide.

Dépôts openSUSE

Les dépôts d'openSUSE se répartissent en 4 catégories :

  • les dépôts officiels, avec des branches libres et non-libres, équivalentes à main et non-free chez Debian ;
  • les dépôts communautaires qui contiennent des paquets ne pouvant être incorporés dans les dépôts officiels, souvent pour des raisons de licences, par exemple le dépôt Packman qui contient les codecs nécessaires pour lire des vidéos (aux formats mp4, avi etc...) ;
  • les dépôts "spécialisés" qui regroupent des paquets de même catégorie (applis pour environnement Gnome, applis pour graphisme, applis en console etc...) ;
  • les dépôts "home", équivalents aux dépôts Copr de Fedora, qui hébergent les paquets créés par des particuliers.

Le dépôt officiel libre contient tous les logiciels dont j'aurai besoin donc pas besoin d'avoir recours aux autres, à l'exception de Packman. Concernant ce dernier, il est amusant de constater que certains projets séparent les codecs "litigieux" (mp3, mp4 etc...) et d'autres non, c'est le cas de Debian par exemple.

Les installeurs

Un des aspects importants lorsqu’on installe un OS c’est... l’installeur pardi ! Installer successivement ces trois distributions fut l’occasion de comparer les installeurs et ils sont vraiment très différents !

L’installeur Debian est simple et direct (je l’utilise en mode texte mais le mode graphique est similaire et n’offre rien de plus). Il ne permet pas de paramétrer grand chose, juste l’essentiel. Et surtout il ne faut pas avoir à installer en comptant sur une connexion wifi. C’est un peu la croix et la bannière pour tenter de fournir un pilote de carte wifi via un supporte externe durant le processus d’installation. Cela dit, il est rapide et en gros, ça s’installe en cliquant successivement sur la touche Entrée.

L’installeur de CentOS, Anaconda, qui est le même que celui de Fedora, est pareil, basique, très axé serveur. Il propose plusieurs profils d’installation pour serveurs spécialisés ou pour stations de travail, ce qui est sympa pour fournir une base prête à l’emploi. J’ai moins apprécié la partie partionnement que j’ai trouvé moyennement intuitive.

L’installeur d’openSUSE est de très loin le plus complet. C’est le plus long à se lancer mais il permet de tout configurer avant installation. On peut ainsi configurer finement la partie réseau, l’outil de partitionnement est très complet (c’est le même module qu’on retrouve par la suite dans Yast). Et chose très appréciable, il permet également de choisir chacun des paquets à installer. Pour l’exemple j’ai sélectionné une base «Bureau Gnome» puis j’ai ajouté tous les logiciels complémentaires que je veux et retiré ceux qui me sont inutiles. J’ai vraiment apprécié cette possibilité, ça évite d’installer des paquets pour les supprimer 5 minutes plus tard et de démarrer avec un système contenant tous les outils que l’on veut.

Sur chacune des machines virtuelles j’ai tenté de reproduire une configuration identique, à base de bureau Gnome et de tester avec quelle facilité je pouvais installer les logiciels que je voulais. À ce jeu, Debian s’en sort le mieux au vu de la taille de sa logithèque, suivi d’openSUSE qui dispose de nombreux paquets et peut être facilement étendue via des dépôts communautaires. CentOS est assez loin derrière et tout n’était pas toujours disponible.

Ce qui m’amène à évoquer brièvement les gestionnaires de paquets.

Les gestionnaires de paquets

Debian avec apt est le «flash» de l’équipe. Il se lance et exécute les actions très rapidement. Le rafraîchissement des sources est rapide également. Yum de CentOS est à l’opposé, il est lent à se rafraîchir et parfois semble se bloquer plusieurs longues secondes à la fin d’une installation, avant de rendre la main. Zypper dans Leap est relativement rapide, moins qu’apt, mais j’ai trouvé que c’était le plus lisible. La coloration syntaxique permet de bien se repérer dans les noms de paquets (la première lettre de chaque est en couleur) et les informations importantes relatives aux modifications apportées sont bien mises en avant.

Bon, faut se décider !

J’utilisais Debian depuis 4 ans et j’avais, il faut bien le dire, envie de changer et de découvrir (vraiment, pas juste le temps d’un test d’une heure en VM) une autre distribution. Les tests semblaient montrer qu’openSUSE pourrait répondre à mes besoins alors pourquoi pas. J’avais déjà fait usage au travail d’openSUSE en 13.1 et 13.2. Je n’avais pas été 100% conquis alors mais les retours lus ici et là sur cette nouvelle mouture qu’est la Leap m’ont conforté dans ce choix, c’est donc parti pour l’installation en réel.

Here we go !

L’installation s’est très bien passée. Bien que je déplore l’existence de pilotes privateurs pour les cartes wi-fi (les seuls qui m’importent vraiment, n’étant pas un joueur assidu sur PC), force m’est de reconnaître qu’il est difficile de s’en passer et leur inclusion par défaut dans l’installeur d’openSUSE m’a facilité la vie. Le gestionnaire de partitionnement est très complet et j’ai pu configurer très simplement mes volumes LVM chiffrés. C’est lors du résumé des options d’installation que j’ai pu choisir plus finement mes paquets, en supprimant les paquets qui me sont inutiles (jeux, gnome-document, gnome-musique etc...) et ajouter ma sélection (notamment Terminator, CherryTree et Keepassx). Un dernier clic et c’est parti, l’installeur fait son boulot et lorsque je reviens 20 min plus tard, mon PC a redémarré et est prêt à l’emploi !

Et alors, c’est bien openSUSE ?

La Leap 42.2 est une distribution moderne et stable. Donc oui, c’est bien, ça fait son travail, ça s’allume le matin, s’éteint le soir et entre les deux je n’ai pas eu de problèmes. En parlant de Gnome, je tiens à signaler l’excellente intégration de celui-ci. Historiquement openSUSE est considérée comme une distribution pro-KDE mais Gnome est parfaitement intégré et très bien fini. Le fait que la SLE (Suse Linux Entreprise) utilise Gnome (dans sa version Classique) comme bureau n’y est peut-être pas étranger. J’ai notamment apprécié de trouver l’ensemble des outils visant à configurer le système directement intégrés aux Paramètres Gnome :

Yast dans Gnome

Yast, l’outil historique d’openSUSE permettant de configurer son système graphiquement, est intéressant. Je ne suis pas particulièrement pro « utilitaires monolithiques et graphiques de configuration » car ils ont tendance à masquer la réalité et ne permettent pas d’apprendre à bien éditer des fichiers de configuration, à avoir les bonnes pratiques dans ce cas (faire une copie avant édition...). Néanmoins, sa présence n’oblige pas à l’utiliser d’une part et n’empêche pas du tout l’édition directe des fichiers de configurations d’autre part. Ainsi un-e débutant-e pas encore à l’aise pourra quand même gérer aisément certains aspects de son système. Sur ce point, je trouve que le nombre de modules Yast inclus par défaut dans une installation de type « Desktop » un poil trop important. Qui a besoin de gérer des périphériques ISCSI ou des clients NIS sur son portable perso ? Yast est en revanche très pratique lorsqu’on reprend l’administration de serveurs.

En conclusion, ce changement et ces tests m’ont permis de bien définir mes besoins et les logiciels y répondant, de comparer 3 distributions majeures et toutes très bonnes. Si je prends autant de plaisir à utiliser openSUSE c’est surtout qu’elle sait se faire complètement oublier, me permettant ainsi de me consacrer à mon travail.

J'espère que ce petit tour d'horizon vous aura donné envie de tester l'une de ces trois distributions et notamment openSUSE, distribution de qualité mais moins connue en France. Des membres de la communauté openSUSE France en expliquent les raisons dans une interview accordée à Framasoft : OpenSUSE, une distribution méconnue.

Tags: linux, opensuse