openSUSE Leap 15.0

Notes de version

openSUSE Leap est un système d'exploitation libre et gratuit basé sur Linux pour votre ordinateur personnel, votre ordinateur portable ou votre serveur. Vous pouvez surfer sur le web, gérer vos e-mails et vos photos, faire du travail bureautique, lire des vidéos ou de la musique, vous amuser !

Contributeurs: Guillaume GARDET, Antoine BELVIRE, Sylvain TOSTAIN, Fabien CRESPEL, Damien LOZACH, et Cyril CHARLIER
Date de publication : 2019-09-06, Version : 15.0.20190906.1f379b4

Les notes de version sont en développement permanent. Pour avoir les dernières mises à jour, consultez la version en ligne sur https://doc.opensuse.org/release-notes. Les notes de version en anglais sont mises à jour dès que le besoin s'en fait sentir. Les versions traduites peuvent être temporairement incomplètes.

Si vous mettez à niveau une ancienne installation vers cette version d'openSUSE Leap, consultez les précédentes notes de version listées ici :http://en.opensuse.org/openSUSE:Release_Notes.

Des informations sur le projet sont disponibles à l'adresse https://www.opensuse.org.

Pour rapporter des bugs relatifs à cette version, veuillez utiliser le Bugzilla d'openSUSE. Pour plus d'informations, consultez http://en.opensuse.org/Submitting_Bug_Reports.

Les principales nouvelles fonctionnalités d'openSUSE Leap 15.0 sont aussi listées sur https://en.opensuse.org/Features_15.0.

1 Installation

Cette section contient des notes à propos de l'installation. Pour des instructions détaillées sur la mise à niveau, veuillez consulter la documentation sur https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/part.basics.html.

Assurez-vous de consulter également Section 4, « Pilotes et matériel ».

1.1 Utiliser les mises à jour atomiques avec le nouveau rôle système serveur transactionnel

L'installateur propose désormais un nouveau rôle système, serveur transactionnel, qui est le résultat de l'effort produit dans le cadre d'openSUSE Kubic. Ce rôle système inclut un nouveau système de mise à jour qui est capable d'appliquer les mises à jour de manière atomique (en une seule opération) et qui permet de facilement les annuler si cela devient nécessaire. Ces fonctionnalités sont basées sur les outils de gestion de paquets sur lesquels les autres distributions openSUSE et SUSE reposent. Cela signifie que la vaste majorité des paquets RPM qui fonctionnent avec d'autres rôles système fonctionnent aussi avec le nouveau rôle serveur transactionnel.

Remarque
Remarque : Paquets incompatibles

Certains paquets modifient le contenu de /var ou de /srv dans leurs scripts RPM %post. Ces paquets sont incompatibles. Si vous tombez sur un tel paquet, merci de remplir un rapport de bug.

Afin de fournir ces fonctionnalités, le système de mise à jour repose sur :

  • les instantanés Btrfs.  Avant que la mise à jour du système démarre, un nouvel instantané Btrfs du système de fichiers racine est créé. Ensuite, tous les changements de la mise à jour sont installés sur cet instantané. Pour compléter la mise à jour, il suffit de redémarrer le système sur le nouvel instantané.

    Pour annuler cette mise à jour, démarrer simplement sur le précédent instantané.

  • Un système fichier racine en lecture seule.  Pour éviter les problèmes et la perte de données à cause des mises à jour, le système de fichiers racine ne doit pas être écrit autrement. Par conséquent, le système de fichiers racine est monté en lecture seule pendant le fonctionnement normal.

    Afin que cette configuration fonctionne, deux changements supplémentaires au niveau du système de fichiers ont été nécessaires : afin de pouvoir écrire la configuration utilisateur dans /etc, ce répertoire est automatiquement configuré pour utiliser OverlayFS ; /var est maintenant un sous-volume séparé qui peut être écrit par les programmes.

Important
Important : Un serveur transactionnel a besoin d'au moins 12 Go d'espace disque

Le rôle serveur transactionnel a besoin d'au moins 12 Go d'espace disque afin d'accueillir les instantanés Btrfs.

Pour travailler avec les mises à jour transactionnelles, veuillez toujours utiliser la commande transactional-update au lieu de YaST et Zypper pour toute la gestion des logiciels :

  • Mettre à jour le système :transactional-update up

  • Installer un paquet : transactional-update pkg in NOM_DU_PAQUET

  • Supprimer un paquet : transactional-update pkg rm NOM_DU_PAQUET

  • Pour annuler le dernier instantané, c'est-à-dire les derniers changements effectués sur le système de fichiers, assurez-vous que votre système est démarré sur l'avant-dernier instantané et lancez : transactional-update rollback

    En option, ajoutez un ID d'instantané à la fin de la commande pour revenir à un ID spécifique.

Avec ce rôle, par défaut le système effectuera une mise à jour quotidienne et un redémarrage entre 3 h 30 et 5 h 00 du matin. Ces deux actions sont basées sur systemd et peuvent être désactivées si nécessaire en utilisant systemctl :

tux@linux>systemctl disable --now transactional-update.timer rebootmgr.service

Pour plus d'informations sur les mises à jour transactionnelles, voir les posts du blog d'openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ et https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

1.2 Installation minimale du système

Certaines fonctionnalités souvent attendues ne sont en réalité pas disponibles dans le mode d'installation minimal :

  • Ne contient pas d'interface de paramétrage du pare-feu. Vous pourrez installer le paquetage firewalld ultérieurement.

  • Ne contient pas YaST. Vous pourrez installer le schéma patterns-yast-yast2_basis ultérieurement.

1.3 Installation sur des disques dur avec moins de 12 Go de capacité

L'installateur proposera un schéma de partitionnement seulement si l'espace disponible sur le disque dur est plus grand que 12 Go. Si vous voulez installer, par exemple, de très petites images de machines virtuelles, utilisez le partitionneur guidé pour régler manuellement les paramètres de partitionnement.

1.4 UEFI — Unified Extensible Firmware Interface

Avant d'installer openSUSE sur un système qui démarre au moyen d'UEFI (Unified Extensible Firmware Interface) il est fortement recommandé de vérifier l'existence de mises à jour du microprogramme (firmware) recommandées par le fournisseur du matériel et, le cas échéant, d'installer de telles mises à jour. Une installation préexistante de Windows 8 ou supérieur constitue une indication forte comme quoi votre système démarre au moyen d'UEFI.

Contexte : Certains microprogrammes (firmwares) UEFI présentent des bogues conduisant à leur défaillance si un volume de données trop important est écrit dans la zone de stockage de l'UEFI. Néanmoins, personne ne sait vraiment où se trouve la limite à ce volume « trop important ».

openSUSE minimise le risque en n'écrivant que le strict nécessaire pour démarrer l'OS. Ce strict nécessaire revient à indiquer au microprogramme UEFI l'emplacement du chargeur d'amorçage d'openSUSE. Les fonctionnalités du noyau Linux qui utilisent la zone de stockage de l'UEFI pour stocker les données de démarrage et de plantage (pstore) ont été désactivées par défaut. Il est cependant recommandé d'installer toute mise à jour du microprogramme recommandée par le fournisseur du matériel.

1.5 UEFI, GPT et partitions MS-DOS

Un nouveau type de partitionnement a fait son apparition avec l'arrivée de l'EFI/UEFI : GPT (GUID Partition Table). Ce nouveau schéma emploie des identifiants globaux uniques (des valeurs sur 128 bits affichées sous forme de 32 chiffres hexadécimaux) afin d'identifier les périphériques et les types de partition.

En outre, la spécification UEFI gère également les anciennes partitions MBR (MS-DOS). Les chargeurs d'amorçage Linux (ELILO ou GRUB2) tentent de générer automatiquement un GUID pour ces anciennes partitions, et les écrivent dans le microprogramme. Un GUID de ce type est susceptible de changer fréquemment, occasionnant alors une réécriture dans le microprogramme. Une réécriture est constituée de deux opérations distinctes : l'effacement de l'ancienne entrée et la création d'une nouvelle entrée qui remplace la première.

Un microprogramme moderne dispose d'un nettoyeur qui collecte les entrées supprimées et libère la mémoire réservées aux anciennes entrées. Un problème se présente lorsqu'un microprogramme défectueux ne collecte pas et ne libère pas ces entrées. Ceci peut amener le système à ne plus pouvoir démarrer.

Pour contourner ce problème, convertissez l'ancienne partition MBR en nouvelle partition GPT.

1.6 Adaptation de l'interface graphique de l'installateur aux ordinateurs utilisant un écran High-DPI

Par défaut, l'installateur YaST n'adapte pas automatiquement l'affichage pour les écrans High-DPI. Si vous utilisez un tel écran, vous pouvez configurer YaST pour qu'il le fasse. Pour ce faire, ajouter le paramètre QT_AUTO_SCREEN_SCALE_FACTOR=1 au niveau du chargeur d'amorçage (bootloader).

2 Mise à niveau du système

Cette section liste des informations à propos de la mise à niveau du système. Pour des instructions détaillées sur la mise à niveau, veuillez consulter la documentation sur https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.update.osuse.html.

Assurez-vous de consulter également Section 4, « Pilotes et matériel ».

En outre, veuillez vérifier Section 3, « Changements relatifs aux paquets ».

2.1 Mise à niveau depuis openSUSE Leap 42.3

2.1.1 Mises à jour de paquets vers des versions inférieures lors de la mise à niveau du système

Les paquets RPM d'openSUSE Leap 15.0 contiennent une information supplémentaire indiquant la version d'openSUSE Leap. Pour cette raison, les paquets qui contiennent la même version logicielle qu'openSUSE Leap 42.3 seront affichés comme des mises à jour vers une version inférieure, même s'ils contiennent le même logiciel mais compilé avec un système d'exploitation plus récent.

2.1.2 cryptconfig a été supprimé

Les précédentes versions d'openSUSE Leap prenaient en charge le chiffrement individuel des dossiers personnels via cryptconfig. Cette fonctionnalité ainsi que le paquet cryptconfig ne sont plus disponibles dans openSUSE Leap 15.0.

Pour chiffrer des données utilisateur dans openSUSE Leap 15.0, chiffrer la partition toute entière ou le volume qui contient les dossiers personnels.

Astuce
Astuce : Déchiffrement avant mise à niveau

Nous vous encourageons à déchiffrer les répertoires personnels chiffrés avant d'effectuer la mise à niveau depuis openSUSE Leap 42.3. Bien que les répertoires personnels chiffrés existants peuvent toujours être utilisés sur openSUSE Leap 15.0 (la technologie utilisée, pam_mount, est toujours disponible), ils pourraient compliquer une mise à niveau dans le futur.

Il n'y a également aucun moyen de chiffrer individuellement les répertoires personnels des utilisateurs ajoutés après la mise à niveau vers openSUSE Leap 15.0.

2.1.3 Postfix Admin utilise un agencement de répertoire non-rétrocompatible

À partir de la version 3.2, fournie par openSUSE Leap 15.0, Postfix Admin (paquet postfixadmin) utilise un nouvel agencement de répertoire non-rétrocompatible :

  • Les fichiers de configuration sont déplacés dans /etc/postfixadmin.

  • Le code PHP est déplacé dans /usr/share/postfixadmin.

  • Le cache Smarty est déplacé dans /var/cache/postfixadmin.

Postfix Admin ne lit plus les fichiers de configuration à leurs anciennes positions et la configuration n'est pas migrée automatiquement. Par conséquent, vous devez migrer les éléments suivants manuellement :

  • Déplacer config.local.php de /srv/www/htdocs/postfixadmin vers /etc/postfixadmin.

  • Si vous aviez fait des personnalisations dans config.inc.php, idéalement il faut les fusionner dans /etc/postfixadmin/config.local.php. Nous recommandions de garder config.inc.php non modifié.

  • Dans la configuration Apache, Ajouter ou activer l'alias /postfixadmin :

    • Pour rendre l'alias disponible sur tous les hôtes virtuels, exécuter :

      tux@linux > sudo a2enflag POSTFIXADMIN && rcapache2 restart
    • Pour rendre l'alias uniquement disponible dans un hôte virtuel spécifique, ajouter l'alias à la configuration de cet hôte virtuel.

2.1.4 La mise à niveau hors-ligne échoue quand des disques chiffrés sont identifiés par des noms

L'utilisation de la mise à niveau hors-ligne sur un ordinateur avec une partition de données chiffrée, telle que /home, peut faire crasher l'installateur YaST lors de la sélection de l'installation existante.

Cela arrive quand la partition de données chiffrée est listée dans /etc/fstab par nom du mappeur de périphérique, tel que /dev/mapper/cr_home. Dans l'environnement d'installation, YaST ne peut pas associer ce chemin avec un volume automatiquement détecté.

Afin de pouvoir utiliser la fonctionnalité de mise à niveau hors ligne, avant de démarrer la mise à niveau, modifiez /etc/fstab pour utiliser des UUID au lieu des noms de périphériques. Afin de déterminer les UUID corrects, utilisez la commande suivante :

tux@linux >blkid | grep "DEVICE_MAPPER_NAME"

La sortie de la commande contiendra un UUID entre guillemets après la chaîne de caractères UUID=.

2.1.5 GPG a un nouveau format de base de données de clés

openSUSE Leap 42.3 embarquait GPG 2.0 tandis qu'openSUSE Leap 15.0 inclut GPG 2.2. Entre ces deux versions de GPG, un nouveau format a été introduit pour la base de données de clés. GPG 2.2 mettra à jour automatiquement votre jeu de clés vers le nouveau format. Toutefois, le jeu de clés une fois mis à jour ne pourra plus être utilisé par les anciennes versions de GPG.

Si vous avez besoin de garder l'ancienne version de votre base de données de clés, sauvegardez le répertoire ~/.gnupg avant de démarrer la mise à niveau vers openSUSE Leap 15.0.

2.1.6 ntpd a été remplacé par Chrony

Le démon de synchronisation avec des serveurs de temps ntpd a été remplacé avec le démon Chrony, plus moderne.

Ce changement implique que les fichiers AutoYaST avec une section ntp_client doivent être mis à jour vers le nouveau format pour cette section. Pour plus d'informations sur le format ntp_client, consultez https://doc.opensuse.org/projects/autoyast/#Configuration.Network.Ntp.

Afin de synchroniser l'heure périodiquement, YaST installe un fichier de configuration cron. Depuis openSUSE Leap 15.0, ce fichier de configuration appartient au paquet yast2-ntp-client (alors que précédemment il n'appartenait à aucun paquet). Il a été renommé de novell.ntp-synchronization en suse-ntp_synchronization par souci de consistance vis-à-vis des autres fichiers de configuration cron. La mise à niveau depuis les précédentes versions d'openSUSE Leap est effectuée automatiquement : si un fichier avec l'ancien nom est trouvé, il sera renommé et ses références à ntpd seront remplacées par des références à chrony.

3 Changements relatifs aux paquets

3.1 Paquets obsolètes

Les paquets obsolètes sont toujours fournis par la distribution mais sont prévus pour être supprimés dans la prochaine version d'openSUSE Leap. Ces paquets existent pour faciliter la migration, mais leur utilisation est déconseillée et ils peuvent ne pas recevoir de mise à jour.

Pour vérifier si des paquets installés ne sont plus maintenus : assurez-vous que lifecycle-data-openSUSE est installé puis utilisez la commande :

tux@linux > zypper lifecycle

3.2 Paquets supprimés

Les paquets supprimés ne font plus partie de la distribution.

4 Pilotes et matériel

4.1 Blocage sur machines avec GPU Nvidia et graphiques hybrides

Avec le noyau livré dans openSUSE Leap 15.0 GM, le pilote Nouveau pour cartes graphiques Nvidia peut se bloquer lors du redémarrage, de l'arrêt ou d'actions de gestion de l'alimentation à l'exécution. Ce bug survient principalement sur un système avec des graphiques hybrides, tels que les ordinateurs portables qui intègrent des graphiques Intel et une carte graphique Nvidia distincte.

Le bug sera corrigé dans une mise à jour de maintenance pour le noyau. Cependant, comme l'image d'installation n'est pas mise à jour, ce problème peut se produire lors de l'installation ou du premier démarrage, même après le déploiement de cette mise à jour. Dans ce cas, en guise de solution de contournement temporaire, démarrez avec l'option nouveau.modeset=0. Une fois le noyau incluant le correctif installé, vous pourrez supprimer cette option à nouveau.

4.2 KDE sur Wayland n'est pas compatible avec le pilote propriétaire Nvidia

La session Wayland de KDE Plasma n'est pas compatible avec le pilote propriétaire Nvidia. Si vous utilisez KDE et le pilote propriétaire Nvidia, restez avec la session X.

5 Bureau

Cette section liste les problèmes et les changements liés au environnement de bureau dans openSUSE Leap 15.0.

5.1 Pas de touche Compose par défaut

Dans les précédentes versions d'openSUSE, la touche Compose permettait de saisir des caractères qui ne faisaient pas partie de l'agencement du clavier standard. Par exemple, pour produire « å », vous pouviez appuyer et relâcher MajCtrl droit puis appuyer sur a deux fois.

Dans openSUSE Leap 15.0, il n'y a plus de touche compose prédéfinie car MajCtrl droit ne fonctionne plus comme avant.

  • Pour définir une touche Compose au niveau du système, utilisez le fichier/etc/X11/Xmodmap et cherchez les lignes suivantes :

    [...]
    !! Third example: Change right Control key to Compose key.
    !! To do Compose Character, press this key and afterwards two
    !! characters (e.g. `a' and `^' to get 342).
    !remove  Control  = Control_R
    !keysym Control_R = Multi_key
    !add     Control  = Control_R
    [...]

    Pour décommenter le code en exemple, supprimer le caractère ! en début des lignes. Cependant, veuillez noter que la configuration dans Xmodmap sera réécrite si vous utilisez la commande setxkbmap.

  • Pour définir une touche Compose pour un utilisateur spécifique, utilisez l'outil de configuration du clavier de votre bureau ou l'outil en ligne de commande setxkbmap :

    tux@linux > setxkbmap […] -option compose:TOUCHE_COMPOSE

    Pour la variable COMPOSE_KEY, utilisez votre touche préférée, par exemple Alt droit, Super gauche, Super droit, menu, Ctrl droit ou Verr maj.

  • Autrement, utilisez une méthode de saisie IBus qui permet de saisir les caractères dont vous avez besoin sans touche Compose.

5.2 Use update-alternatives to Set Display Manager and Desktop Session

In the past, you could use /etc/sysconfig or the YaST module /etc/sysconfig Editor to define the display manager (also called the login manager) and desktop session. Starting with openSUSE Leap 15.0, the values are not defined using /etc/sysconfig anymore but with the alternatives system.

Pour changer les réglages par défaut, utilisez les alternatives suivantes :

  • Display manager: default-displaymanager

  • Session Wayland : default-waylandsession.desktop

  • Session de bureau X : default-xsession.desktop

Par exemple, pour vérifier la valeur de default-displaymanager, utilisez :

tux@linux > sudo update-alternatives --display default-displaymanager

Pour changer default-displaymanager vers xdm, utilisez :

tux@linux > sudo update-alternatives --set default-displaymanager \
  /usr/lib/X11/displaymanagers/xdm

Pour activer la gestion graphique des alternatives, utilisez le module YaST Alternatives qui peut être installé avec le paquet yast2-alternatives.

5.3 Pas de verrouillage d'écran en utilisant GNOME Shell sans GDM

En utilisant GNOME shell avec un gestionnaire de connexion autre que GDM, tel que SDDM ou LightDM, l'écran ne se mettra pas en veille ni ne se verrouillera. De plus, changer d'utilisateur sans se déconnecter n'est pas possible.

Pour pouvoir verrouiller l'écran depuis GNOME Shell, activez GDM en tant que gestionnaire de connexion :

  1. Assurez vous que le paquet gdm est installé.

  2. Définissez GDM comme gestionnaire de session :

    tux@linux > sudo update-alternatives --set default-displaymanager \
      /usr/lib/X11/displaymanagers/gdm
  3. Redémarrez.

5.4 Mise à l'échelle de SDDM pour les ordinateurs avec des écrans haute résolution

Le gestionnaire de connexion par défaut de KDE, SDDM, ne met pas à l'échelle son interface pour les écrans haute résolution par défaut. Si vous avez un ordinateur avec un écran haute résolution, vous pouvez configurer SDDM pour mettre à l'échelle son interface automatiquement en utilisant le fichier de configuration /etc/sddm.conf :

[X11]
EnableHiDPI=true
ServerArguments=-nolisten tcp -dpi VALEUR_DPI

Remplacez VALEUR_DPI par une valeur de DPI appropriée, telle que 192. Pour un meilleur résultat de mise à l'échelle, utilisez une valeur de DPI multiple de la valeur par défaut de 96 DPI.

5.5 Mise à l'échelle de YaST pour les ordinateurs avec des écrans haute résolution

YaST ne met pas à l'échelle son interface pour les écrans haute résolution par défaut. Si vous avez un ordinateur avec un écran haute résolution, vous pouvez configurer YaST pour mettre à l'échelle son interface automatiquement. Pour ce faire, configurer la variable d'environnement QT_AUTO_SCREEN_SCALE_FACTOR=1.

5.6 Utiliser la mise à l'échelle automatique dans les applications Qt sur des installations mélangeant des écrans à haute résolution et à résolution normale

Qt prend en charge la mise à l'échelle automatique par écran sur X. Il utilise la valeur DPI de l'écran virtuel de X pour calculer la taille de la police pour l'écran principal. Par défaut, cette valeur est de 96 DPI. Il utilise le DPI relatif du moniteur principal pour dériver la police DPI pour tous les autres moniteurs.

Deux bureaux très utilisés ignorent ce comportement de Qt, donc cette remarque ne s'applique pas à eux :

  • GNOME définit Xft.dpi sur le multiple configuré de 96 DPI.

  • KDE Plasma désactive la mise à l'échelle automatique de Qt et utilise une configuration de mise à l'échelle manuelle.

Sur d'autres bureaux, ce comportement de Qt peut conduire à des situations indésirables telles que : si l'affichage principal est à haute résolution (>= 144 DPI), les polices des applications Qt qui requièrent une mise à l'échelle, telles que VLC, sont effectivement mises à l'échelle à la moitié de la taille désirée sur tous les moniteurs. Les applications qui ne requièrent pas de mise à l'échelle, telles que YaST (avec les paramètres par défaut), utilisent la même valeur DPI sur tous les moniteurs. Par conséquence, elles sembleront plus petites sur le moniteur à haute résolution.

Vous pouvez utiliser l'une des solutions de contournement suivantes pour ce problème :

  • Utilisez un moniteur avec résolution normale comme moniteur principal. Les applications qui demandent une mise à l'échelle seront alors mises à l'échelle de manière appropriée sur le moniteur haute résolution.

  • Définissez un DPI de police approprié (Xft.dpi). Vous pouvez le faire avec l'utilitaire de configuration de votre bureau. Sinon, après chaque connexion, exécutez la commande suivante :

    tux@linux > echo Xft.dpi:VALEUR_DPI | xrdb -nocpp -merge

    Remplacez VALEUR_DPI par une valeur DPI appropriée pour le moniteur principal.

5.7 Le partage d'écran ne fonctionne pas avec Firefox ou Chromium sous Wayland

Firefox et Chromium autorisent normalement les outils web tels que les applications de vidéoconférence à partager l'écran entier ou des fenêtres individuelles d'applications. Cette fonctionnalité n'est actuellement pas gérée par ces navigateurs lors d'une session Wayland.

Pour pouvoir partager votre écran avec Firefox ou Chromium, utilisez une session X à la place.

5.8 Lecture des fichiers multimédia MP3

Les codecs pour lire les fichiers MP3 sont distribués dans le dépôt standard.

Pour utiliser ce décodeur dans les applications et frameworks basés sur gstreamer, tel que Rhythmbox ou Totem, installez le paquet gstreamer-plugins-ugly.

5.9 Polices Type-1 non gérées dans LibreOffice

LibreOffice 5.3 et plus récent ne gèrent plus les anciennes polices de caractères Type-1 (extensions de fichiers .afm et .pfb). La plupart des utilisateurs ne devrait pas être affecté par cela, car les polices actuelles sont disponibles au format TrueType (.ttf) ou au format OpenType (.otf).

Si vous êtes affecté par cela, convertissez les polices Type-1 dans un format supporté, comme TrueType puis utilisez les polices converties. La conversion est faisable avec l'application FontForge (package fontforge) qui est inclus dans openSUSE. Pour savoir comment automatiser ces conversions, consultez https://fontforge.github.io/en-US/documentation/scripting/.

5.10 Changements de rendu des polices FreeType

FreeType 2.6.4 a un nouvel interpréteur de hinting des caractères (version 38) qui est plus proche des autres systèmes d'exploitations mais qui peut paraître « plus flou » pour certains. Pour restaurer le comportement précédent de FreeType, configurez la variable d'environnement suivante au niveau (système, utilisateur ou application) de votre choix :

FREETYPE_PROPERTIES="truetype:interpreter-version=35"

5.11 Activation de l'intégration des navigateurs avec KDE Plasma

L'intégration Plasma des navigateurs pour Firefox et Chromium/Chrome permet le contrôle multimédia et des téléchargements avec les outils systèmes KDE et donne un accès rapide aux onglets via la barre Exécuter une commande du bureau KDE Plasma.

La fonctionnalité d'intégration des navigateurs consiste en deux parties devant travailler ensemble :

Veuillez noter que cette fonctionnalité est encore officiellement en développement et qu'openSUSE Leap 15.0 en fournit une version préliminaire.

5.12 Chargement du module psgml d'Emacs

En raison de conflits avec les modules Emacs de l'installation par défaut, openSUSE Leap 15.0 ne peut plus charger le module pgsml automatiquement. Pour plus d'informations, lisez le fichierREADME du paquet psgml.

6 Sécurité

Cette section liste les changements des fonctions de sécurité d'openSUSE Leap 15.0.

6.1 GPG ne supporte plus les clés GPG V3, déclenchant des avertissements de la part de Zypper/rpm

openSUSE Leap 42.3 embarquait GPG 2.0 tandis qu'openSUSE Leap 15.0 inclut GPG 2.2. Entre ces deux versions de GPG, la prise en charge des clés GPG V3 a été supprimée. Si la base de données de clés de votre système contient encore des clés GPG V3, vous pouvez recevoir des avertissements par rapport à cela lors de l'exécution de commandes Zypper ou rpm car ces commandes vérifient l'intégrité de la base de données de paquets. Ces avertissements prennent la forme suivante : warning: Unsupported version of key: V3.

Ces avertissements sont le plus souvent bénins et liés à des clés utilisés par des dépôts soit désactivés, soit ayant reçu des mises à jour de clés. Toutefois, si des clés sont toujours actives et utilisées par un dépôt distant, elles doivent être remplacées le plus rapidement possible :

  • Les outils de gestion de paquets dans openSUSE Leap 15.0 ne peuvent plus les utiliser pour vérifier l'intégrité des paquets.

  • Ces clés ne sont pas sûres. Ainsi, même si des outils de gestion de paquets plus anciens les utilisent pour vérifier l'intégrité des paquets, le résultat de cette vérification ne peut plus être considéré comme digne de confiance.

Pour supprimer de telles clés, effectuez les actions suivantes :

  1. Exécutez une commande rpm avec un haut niveau de verbosité et vérifiez sa sortie :

    tux@linux > rpm -vv -qf /etc
    ufdio: 1 reads, 18883 total bytes in 0.000006 secs
    [...]
    D: read h# 168 Header sanity check: OK
    warning: Unsupported version of key: V3
    [...]

    Dans cet exemple, l'en-tête 168 est associé avec une clé obsolète – l'avertissement apparaît directement après le message indiquant que cet en-tête est en train d'être vérifié.

  2. Trouvez le numéro de la clé associée à cet en-tête :

    tux@linux > rpm -q --querybynumber EN-TÊTE

    Remplacez EN-TÊTE avec le numéro de l'en-tête Dans cet exemple, ce serait 168.

    Cette commande retourne un identifiant de clé commençant par gpg-pubkey-.

  3. (Optionnelle) Utilisez cet identifant (KEY_ID) pour en savoir plus sur la clé :

    tux@linux > rpm -qi KEY_ID
  4. Supprimez la clé du système :

    tux@linux > sudo rpm -e KEY_ID
  5. Si vous continuez de voir des avertissements lors de l'utilisation d'outils de gestion de paquets pour d'autres clés, répétez la procédure.

6.2 systemctl stop apparmor ne fonctionne pas

Par le passé, il pouvait y avoir une confusion entre les deux sous-commandes reload et restart de systemctl pour AppArmor :

  • systemctl reload apparmor rechargeait proprement tous les profils AppArmor. (Cela était et continue d'être le moyen recommandé pour recharger les profils AppArmor.)

  • systemctl restart apparmor stoppait AppArmor, et donc déchargeait tous ses profils, puis le redémarrait en laissant les processus existants non confinés. Seuls les processus lancés après le redémarrage d'AppArmor étaient confinés.

Malheureusement, systemd ne fournit pas une solution dans son format de description des services par rapport au problème posé par le scénario du restart.

À partir d'AppArmor 2.12, la commande systemctl stop apparmor ne fonctionne plus. En conséquence, systemctl restart apparmor ne recharge plus correctement les profils AppArmor.

Pour décharger tous les profils AppArmor, utilisez plutôt la nouvelle commande aa-teardown qui adopte l'ancien comportement de systemctl stop apparmor.

Pour plus d'informations, voir https://bugzilla.opensuse.org/show_bug.cgi?id=996520 et https://bugzilla.opensuse.org/show_bug.cgi?id=853019.

7 Aspects techniques

7.1 Nouveau partitionnement Btrfs

openSUSE Leap 15.0 introduit un nouveau partitionnement Btrfs avec pour missions :

  • Des instantanés et des annulations simplifiés

  • La prévention de la perte accidentelle de données

  • De meilleures performances pour les bases de données et les images de machines virtuelles stockées dans /var

Au lieu d'utiliser plusieurs sous-volumes Btrfs pour différents répertoires de /var, openSUSE Leap 15.0 définit un seul sous-volume pour tout /var. Ce nouveau sous-volume a la fonctionnalité de copie sur écriture désactivée.

Il n'y a pas de façon officiellement supportée de migrer vers ce nouveau partitionnement Btrfs. Ainsi, si vous voulez en profiter, préférez une nouvelle installation plutôt qu'une mise à niveau.

Pour plus d'informations sur le nouveau partitionnement Btrfs, rendez-vous sur https://en.opensuse.org/SDB:BTRFS.

7.2 Wicked : Utiliser le client-id DHCPv4 de la RFC 4361 sur de l'Ethernet

La RFC 4361 met à jour le client-id défini dans la RFC 2132, section 9.14, afin d'être compatible avec le client-id DHCP 6 (duid). L'utilisation de la RFC 4361 est obligatoire sur Infiniband (RFC 4390) et est également requise sur Ethernet pour mettre à jour les enregistrements DNS pour des adresses IP DHCP 4 et DHCP 6 dans la même zone.

Dans openSUSE Leap 15.0 :

  • Le serveur ISC DHCP 4.3.x prend en charge la nouvelle RFC 4361 (requise pour la mise à jour des DNS)

  • Wicked fournit une option pour envoyer un tel client-id et pour utiliser automatiquement en DHCPv4 un client-id basé DHCPv6 (utilisé sur Infiniband).

Pour envoyer le client-id pendant l'installation, utilisez linuxrc (voir aussi https://en.opensuse.org/SDB:Linuxrc) avec l'ifcfg suivant :

ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67,DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67

Pour plus d'informations, consultez la documentation pour les options dhcp4 "create-cid" et dhcp6 "default-duid" dans man 5 wicked-config, wicked duid --help et wicked iaid --help.

Le client-id utilisé traditionnellement en DHCPv4 sur Ethernet dans le cadre de la RFC 2132 est construit à partir du type de matériel (01 pour de l'Ethernet) et de l'adresse matérielle (l'adresse MAC). Par exemple :

01:52:54:00:02:c2:67

Le client-id de la RFC 4361 commence par 0xff au lieu du type de matériel et est suivi de l'IAID DHCPv6 (l'ID d'association interface-adresse qui décrit l'interface sur la machine) puis du DUID DHCPv6 (le client-id qui identifie la machine).

En utilisant le DUID (de type LLT par défaut), basé sur le type de matériel et sur l'adresse matérielle, le client-id DHCPv4 de la nouvelle RFC 4361 serait :

  • En utilisant les derniers octets de l'adresse MAC comme IAID : ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • Quand l'IAID est un simple nombre incrémenté : ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

Le xx:xx:xx:xx dans le DUID-LLT est l'horodatage de création. Un DUID-LL (00:03:00:01:MAC) ne contient pas d'horodatage.

8 Plus d'informations et de retours

  • Veuillez lire les documents README sur le support de stockage.

  • Voir les informations détaillées du journal de modifications à propos d'un paquet particulier à partir de RPM :

    tux@linux > rpm --changelog -qp NOM_DU_PAQUET.rpm

    Remplacez NOM_DU_PAQUET par le nom du paquet RPM.

  • Vérifiez le fichier ChangeLog à la racine du support de stockage pour un historique chronologique de toutes les modifications apportées aux paquets mis à jours.

  • Retrouvez plus d'informations dans le dossier docu sur le support de stockage.

  • Pour une documentation supplémentaire ou mise à jour, consultez https://doc.opensuse.org/.

  • Pour les dernières nouvelles sur openSUSE, consultez https://www.opensuse.org .

Copyright © SUSE LLC

Imprimer cette page