Différents termes sont employés dans cette section. Afin de bien comprendre les informations, lisez les définitions ci-après :

Le cycle de vie de SUSE est le suivant :

SUSE prend en charge les Service Packs précédents pendant une période de 6 mois après la sortie du nouveau Service Pack. La Figure 1.1, « Versions majeures et Service Packs » illustre certains aspects mentionnés.

Figure 1.1 : Versions majeures et Service Packs #

 

Si vous avez besoin de plus de temps pour concevoir, valider et tester vos plans de mise à niveau, le support de Service Packs à long terme peut étendre la prise en charge de 12 à 36 mois supplémentaires par incréments de 12 mois. Cela vous donne un total de 2 à 5 ans de support sur n'importe quel Service Pack. Pour plus de détails, reportez-vous à la Figure 1.2, « Support à long terme au niveau des Service Packs ».

Figure 1.2 : Support à long terme au niveau des Service Packs #

 

Pour plus d'informations, reportez-vous à la page https://www.suse.com/products/long-term-service-pack-support/.

Reportez-vous à la page https://www.suse.com/lifecycle pour plus d'informations sur le cycle de vie, la fréquence des versions et la période de prise en charge du support pack intégré.

Pour obtenir la liste des modules, de leurs dépendances et de leur cycle de vie, consultez l'Article “Modules and Extensions Quick Start”.

SUSE Linux Enterprise Server peut rechercher régulièrement les changements d'état de prise en charge de tous les produits installés et envoyer le rapport par courrier électronique en cas de modifications. Pour générer le rapport, installez le paquetage zypper-lifecycle-plugin à l'aide de la commande zypper in zypper-lifecycle-plugin.

Activez la génération du rapport sur votre système avec la commande systemctl :

> sudo systemctl enable lifecycle-report.timer

Le destinataire et l'objet du message électronique de rapport, ainsi que la période pour la génération du rapport peuvent être configurés dans le fichier /etc/sysconfig/lifecycle-report avec n'importe quel éditeur de texte. Les paramètres MAIL_TO et MAIL_SUBJ définissent le destinataire et l'objet, tandis que DAYS définit l'intervalle auquel le rapport est généré.

Le rapport affiche les modifications de l'état de prise en charge après le changement, et non pas à l'avance. Si le changement se produit juste après la génération du dernier rapport, cela peut prendre jusqu'à 14 jours avant que vous en soyez averti. Tenez-en compte lors de la définition de l'option DAYS. Modifiez les entrées de configuration suivantes pour répondre à vos besoins :

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

Le rapport le plus récent est disponible dans le fichier /var/lib/lifecycle/report. Celui-ci contient deux sections : la première informe de la fin de la prise en charge de produits utilisés ; la deuxième répertorie les paquetages avec leur date de fin de prise en charge et la disponibilité de mises à jour.

Les niveaux de support étendu sont valables entre la dixième année et la treizième année. Ces niveaux de support proposent des diagnostics permanents de niveau technique L3 et des résolutions réactives des bogues critiques. Ces niveaux de support vous permettent de recevoir des mises à jour contre les exploits racines facilement exploitables dans le kernel et d'autres exploits racines directement exécutables sans intervention de l'utilisateur. Ils prennent également en charge les workloads, les piles logicielles et le matériel existants avec une liste d'exclusion de paquetages limitée. Voir Tableau 1.1, « Mises à jour de sécurité et résolution des bogues » pour découvrir une présentation.

¹ Pour plus d'informations sur la stratégie de mise à jour de SUSE Linux Enterprise, reportez-vous à l'knowledgebase article.

Lors de votre inscription, le système reçoit des dépôts de la part du SUSE Customer Center (consultez la page https://scc.suse.com/) ou d'un proxy d'enregistrement local tel que SMT. Les noms de dépôts pointent vers des URI spécifiques du SUSE Customer Center. Pour répertorier tous les dépôts disponibles sur votre système, utilisez zypper comme suit :

# zypper repos -u

Vous obtenez alors la liste de tous les dépôts disponibles sur votre système. L'alias et le nom sont indiqués pour chaque dépôt. Vous pouvez également savoir si le dépôt est activé et s'il sera rafraîchi. L'option -u vous permet, en outre, de connaître l'URI d'origine.

Pour enregistrer votre machine, exécutez SUSEConnect, par exemple comme suit :

# SUSEConnect -r REGCODE

Pour annuler l'enregistrement de votre machine, vous pouvez aussi utiliser SUSEConnect :

# SUSEConnect --de-register

Pour vérifier quels produits sont installés localement ainsi que leur statut, utilisez la commande suivante :

# SUSEConnect -s

Long Term Service Pack Support (LTSS) allonge le cycle de vie de SUSE Linux Enterprise Server. Il est disponible sous forme d'extension. Pour plus d'informations sur LTSS, reportez-vous au document https://www.suse.com/products/long-term-service-pack-support/.

Si vous devez identifier la version d'une installation SLE, vérifiez le contenu du fichier /etc/os-release.

Un format de sortie XML lisible par machine est disponible avec zypper :

> zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

Les mises à niveau entre deux versions majeures de SUSE Linux Enterprise Server sont prises en charge par SUSE. Le choix d'une mise à niveau ou d'une nouvelle installation dépend de votre scénario. Si les mises à niveau impliquent moins de travail, les nouvelles installations vous permettent de bénéficier de toutes les nouvelles fonctionnalités d'une version, telles que les modifications de la disposition du disque, les fonctionnalités spécifiques au système de fichiers et d'autres améliorations. Pour tirer le meilleur parti de votre système, SUSE recommande donc de nouvelles installations dans la plupart des scénarios.

Dans les deux cas, qu'il s'agisse d'une mise à niveau ou d'une nouvelle installation, les clients doivent vérifier si les paramètres système et les valeurs par défaut correspondent toujours à leurs besoins.

Pour les mises à jour d'un Service Pack d'une version spécifique vers une autre du même flux de code, SUSE recommande de les exécuter sur place et de ne pas effectuer une nouvelle installation. Néanmoins, il peut exister des motifs et des scénarios pour lesquels un client effectuera une nouvelle installation dans ce cas également. Seul le client peut décider de l'approche la plus appropriée.

Avant d'effectuer une migration, lisez le Chapitre 3, Préparation de la mise à niveau.

Important : les mises à niveau entre architectures ne sont pas prises en charge

Les mises à niveau entre architectures, comme une mise à niveau depuis une version 32 bits de SUSE Linux Enterprise Server vers la version 64 bits, ou d'un format Big Endian vers un mode Little Endian, ne sont pas prises en charge !

En particulier, la mise à niveau de SLE 11 sous POWER (Big Endian) vers SLE 15 SP6 sous POWER (nouveauté : Little Endian) n'est pas prise en charge.

De plus, étant donné que SUSE Linux Enterprise 15 est une version exclusivement 64 bits, les mises à niveau à partir d'un système SUSE Linux Enterprise 11 32 bits vers SUSE Linux Enterprise 15 ou version ultérieure ne sont pas prises en charge.

Pour effectuer une mise à niveau entre architectures, vous devez procéder à une nouvelle installation.

Note : omission de Service Packs

Le chemin de mise à niveau le plus simple consiste à installer consécutivement tous les Service Packs. Pour la gamme de produits SUSE Linux Enterprise 15 (GA et les Service Packs suivants), il est également possible d'ignorer jusqu'à deux Service Packs lors de la mise à niveau. Par exemple, la mise à niveau de SLE 15 SP3 vers 15 SP6 est prise en charge (pour autant que SLE 15 SP3 soit pris en charge).

Figure 2.1 : Aperçu des chemins de mise à niveau pris en charge #

 

Avertissement : mise à niveau des bases de données

Les chemins de mise à niveau décrits ici s'appliquent uniquement à SUSE Linux Enterprise en tant que système d'exploitation d'une machine, et non à toutes les applications qu'il exécute. Si vous disposez de charges de travail tels que des bases de données PostgreSQL ou MariaDB, des mises à niveau intermédiaires du système d'exploitation peuvent être nécessaires pour mettre à niveau vos applications.

Avant de mettre à niveau le système d'exploitation, consultez les Release Notes pour obtenir des informations sur les versions de base de données. Si une nouvelle version majeure est livrée, reportez-vous au Chapitre 3, Préparation de la mise à niveau pour obtenir des instructions de mise à niveau.

Note : prise en charge du chevauchement de Service Packs étendu (ESPOS)

Pour certains produits, SUSE propose l'option ESPOS (Extended Service Pack Overlap Support) selon les mêmes conditions que LTSS. Pour plus d'informations sur l'option ESPOS, reportez-vous à la documentation du produit SUSE Linux Enterprise respectif et à la page Web Product Lifecycle Support Policies.

SUSE prend en charge les méthodes de mise à niveau et de migration suivantes. Pour plus d'informations sur la terminologie, reportez‑vous à la Section 1.1, « Terminologie ». Les méthodes existantes sont les suivantes :

Important : clients SUSE Manager

Si votre machine est gérée par SUSE Manager, mettez ce dernier à jour comme indiqué dans la documentation de SUSE Manager. La procédure Client Migration est décrite dans le SUSE Manager Upgrade Guide, disponible à l'adresse https://documentation.suse.com/suma/.

La mise à niveau du système est prise en charge uniquement à partir du niveau de correctif le plus récent. Assurez-vous que les dernières mises à jour système sont installées, en exécutant zypper patch ou en démarrant le module YaST Online-Update.

Note : nouvelle clé de signature de 4 096 bits pour SUSE Linux Enterprise 15

Au milieu de l'année 2023, la gamme de produits SUSE Linux Enterprise 15 est passée d'une clé de signature RSA de 2 048 bits à une nouvelle clé RSA de 4 096 bits. Cette modification concerne les paquetages RPM, les dépôts de paquetages et les signatures ISO. Les anciens dépôts qui ne sont plus mis à jour et les RPM publiés jusqu'à la date de basculement restent signés avec l'ancienne clé de 2 048 bits.

Si vous mettez à jour votre système, la nouvelle clé est automatiquement importée dans le trousseau de clés RPM à partir du paquetage suse-build-key sous SLE 15 SP4 et SP5, ainsi que dans les versions LTSS de SLE 15 SP1, SP2 et SP3.

Si la clé n'a pas encore été importée, vous pouvez l'importer manuellement avec la commande suivante :

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

Si vous exécutez une version plus ancienne de SLE ou si vous n'avez pas importé la nouvelle clé, vous serez invité à l'approuver pendant la mise à niveau. Vérifiez que l'empreinte correspond :

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

En outre, une clé RSA de réserve de 4 096 bits a été importée à des fins de reprise après sinistre :

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

Cette clé peut être importée manuellement à l'aide de la commande suivante :

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Les deux clés sont également disponibles sur le support d'installation et sur le site Web de SUSE à l'adresse suivante : https://www.suse.com/support/security/keys/.

Les notes de version fournissent une liste de toutes les modifications, nouvelles fonctionnalités et problèmes connus. Vous pouvez également trouver les notes de version sur le support d'installation dans le répertoire docu.

Les notes de version contiennent généralement uniquement les changements effectués entre deux versions successives. Si vous omettez d'installer un ou plusieurs Service Packs, consultez néanmoins les notes de version de ces Service Packs ignorés.

Consultez les notes de version pour vérifier si les conditions suivantes s'appliquent :

Avant la mise à niveau, sauvegardez vos données en copiant les fichiers de configuration existants sur un support distinct (tel qu'un périphérique à bande, un disque dur amovible, etc). Cela concerne principalement les fichiers stockés dans /etc, ainsi que certains répertoires et fichiers sous /var et /opt. Vous pouvez également écrire les données de l'utilisateur de /home (les répertoires HOME) sur un support de sauvegarde.

Sauvegardez ces données en tant qu'utilisateur root. Seul l'utilisateur root a des droits suffisants pour tous les fichiers locaux.

Si vous avez sélectionné Mettre à jour un système existant comme mode d'installation dans YaST, vous pouvez choisir d'effectuer une sauvegarde (système) ultérieurement. Vous pouvez inclure tous les fichiers modifiés, ainsi que ceux issus du répertoire /etc/sysconfig. Il ne s'agit toutefois pas d'une sauvegarde complète, dans la mesure où il manque tous les autres répertoires importants mentionnés ci-dessus. Recherchez la sauvegarde dans le répertoire /var/adm/backup.

La taille des logiciels tend à augmenter de versions en versions. Il convient donc de vérifier l'espace disponible sur la partition avant d'effectuer la mise à jour. Si vous pensez que vous allez manquer d'espace disque, sauvegardez vos données avant d'augmenter l'espace disponible en redimensionnant des partitions, par exemple. Il n'existe pas de règle précise concernant l'espace de chaque partition. L'espace requis dépend de votre profil particulier de partitionnement et du logiciel sélectionné.

Note : vérification automatique de l'espace dans YaST

Au cours de la procédure de mise à jour, YaST vérifie la quantité d'espace disque disponible et affiche un avertissement si la taille de l'installation risque de dépasser la quantité d'espace disponible. Dans ce cas, la mise à jour risque de rendre le système inutilisable ! Si vous savez exactement ce que vous faites (en ayant effectué des tests au préalable), vous pouvez ignorer l'avertissement et poursuivre la mise à jour.

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       44G    4G   40G   9% /data

Vous pouvez enregistrer une liste des paquetages installés ; par exemple pour effectuer une nouvelle installation d'une nouvelle version majeure de SLE ou pour revenir à l'ancienne version.

Note

N'oubliez pas que les paquetages installés ou dépôts utilisés ne sont pas tous disponibles dans les versions plus récentes de SUSE Linux Enterprise. Certains ont parfois été renommés et d'autres remplacés. Il se peut aussi que certains paquetages restent disponibles pour des raisons d'héritage, mais qu'un autre paquetage soit utilisé par défaut. Par conséquent, une modification manuelle des fichiers peut s'avérer nécessaire. Elle peut être réalisée avec n'importe quel éditeur de texte.

Si vous mettez à niveau un système SUSE Linux Enterprise Server avec l'extension LTSS (Long Term Service Pack Support) vers une version bénéficiant encore d'un support général, la mise à niveau échoue avec l'erreur No migration available (Aucune migration disponible). Cela se produit car zypper migration tente de migrer tous les dépôts, mais il n'existe pas encore de dépôt LTSS pour la nouvelle version.

Pour résoudre ce problème, désactivez l'extension LTSS avant la mise à niveau.

SUSE Linux Enterprise Server 15 SP6 est livré avec les versions 14 et 15 de la base de données PostgreSQL. Bien que la version 15 soit la version par défaut, la version 14 est toujours fournie via le module Legacy pour les mises à niveau à partir de versions antérieures de SUSE Linux Enterprise Server.

En raison du travail de migration requis pour la base de données, le processus de mise à niveau n'est pas automatique. De ce fait, le passage d'une version à l'autre doit être effectué manuellement.

La migration est exécutée à l'aide de la commande pg_upgrade. Elle constitue une méthode qui diffère du vidage et du rechargement classique. Par rapport à la méthode de « vidage et rechargement », la migration effectuée par le biais de la commande pg_upgrade est plus rapide.

Les fichiers programmes de chaque version PostgreSQL sont stockés dans des répertoires différents selon la version, Par exemple, dans /usr/lib/postgresql96/ pour la version 9.6, dans /usr/lib/postgresql10/ pour la version 10 et dans /usr/lib/postgres13/ pour la version 13. Notez que la stratégie de contrôle des versions de PostgreSQL a changé entre les versions majeures 9.6 et 10. Pour plus de détails, reportez-vous à la page https://www.postgresql.org/support/versioning/.

Important : mise à niveau à partir de SLE 11

Lors de la mise à niveau à partir de SLE 11, postgresql94 sera désinstallé et ne pourra plus être utilisé pour la migration de la base de données vers une version ultérieure de PostgreSQL. Par conséquent, veillez à migrer la base de données PostgreSQL avant de mettre à niveau votre système.

La procédure ci-dessous décrit la migration de la base de données de la version 12 vers la version 13. Lorsque vous utilisez une version différente comme source ou comme cible, remplacez les numéros de version en conséquence.

Pour effectuer la migration de la base de données, procédez comme suit :

Pour plus d'informations sur la mise à niveau des bases de données ou l'utilisation de méthodes alternatives telles que la réplication logique, reportez-vous à la documentation officielle de PostgreSQL à l'adresse https://www.postgresql.org/docs/13/upgrading.html.

À partir de la version 12 de SUSE Linux Enterprise, SUSE est passé de MySQL à MariaDB. Avant de lancer une mise à niveau, il est vivement recommandé de sauvegarder votre base de données.

Pour effectuer la migration de la base de données, procédez comme suit :

Par mesure de sécurité, les certificats MD5 ne sont plus pris en charge dans Java. Si vous disposez de certificats créés à l'aide de l'algorithme MD5, recréez vos certificats en procédant comme suit :

Si votre machine fait office de serveur hôte de machine virtuelle pour KVM ou Xen, veillez à arrêter correctement tous les invités de machine virtuelle actifs avant de procéder à la mise à jour. Dans le cas contraire, l'accès aux invités peut s'avérer impossible après la mise à jour.

Si la machine que vous souhaitez mettre à niveau est enregistrée comme client auprès d'un serveur SMT, procédez comme suit :

Vérifiez si la version du script clientSetup4SMT.sh sur votre hôte est à jour. Le fichier clientSetup4SMT.sh des anciennes versions de SMT ne peut pas gérer les clients SMT 12. Si vous appliquez régulièrement des correctifs logiciels sur votre serveur SMT, vous pouvez toujours trouver la dernière version de clientSetup4SMT.sh dans <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

En cas d'échec de la mise à niveau de votre machine vers une version ultérieure de SUSE Linux Enterprise Server, annulez l'enregistrement de la machine auprès du serveur SMT, comme décrit à la Procédure 3.1. Ensuite, redémarrez le processus de mise à niveau.

Pour savoir comment migrer vos profils AutoYaST, reportez-vous au Book “AutoYaST Guide”, .

Un serveur qui exécute SMT requiert une procédure de mise à niveau spéciale. Reportez-vous au Book “Repository Mirroring Tool Guide”, Chapter 3 “Migrate from SMT to RMT” du Repository Mirroring Tool Guide (Guide de RMT).

SUSE Linux Enterprise Server (SLES) permet d'installer plusieurs versions de kernel en activant les paramètres correspondants sous /etc/zypp/zypp.conf. La prise en charge de cette fonctionnalité doit pourtant être désactivée temporairement pour effectuer une mise à niveau vers un Service Pack. Une fois la mise à jour terminée, la prise en charge de plusieurs versions peut être réactivée. Pour désactiver la prise en charge de plusieurs versions, commentez les lignes correspondantes dans /etc/zypp/zypp.conf. Le résultat doit ressembler à ceci :

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Pour réactiver cette fonction après une mise à jour réussie, supprimez les signes de commentaire. Pour plus d'informations sur la prise en charge de plusieurs versions, reportez-vous à la Book “Administration Guide”, Chapter 27 “Installing multiple kernel versions”, Section 27.1 “Enabling and configuring multiversion support”.

Sur les systèmes qui ont été installés avec SUSE Linux Enterprise Server 12 ou version antérieure, la ligne de commande du kernel par défaut dans /etc/default/grub peut contenir un paramètre resume utilisant un nom de noeud de périphérique, par exemple /dev/sda1, pour faire référence au périphérique d'hibernation (sauvegarde du contenu de la mémoire vive sur le disque dur). Étant donné que les noms de noeud de périphérique ne sont pas persistants et peuvent changer entre les redémarrages, il est vivement recommandé de corriger ce problème. Sinon, le système mis à niveau risque de se bloquer au redémarrage.

Si le système n'utilise pas l'hibernation, vous pouvez simplement supprimer le paramètre resume et mettre à jour la configuration de démarrage.

La mise à niveau d'une installation SUSE Linux Enterprise sur IBM Z nécessite Upgrade=1 comme paramètre de kernel, par exemple via le fichier parmfile. Reportez-vous à la Book “Guide de déploiement”, Chapter 5 “Installation sur IBM Z et LinuxONE”, Section 5.5 “Fichier parmfile - Automatisation de la configuration du système”.

Sous SLES 12 pour IBM POWER, le gestionnaire d'affichage est configuré pour ne pas démarrer un serveur X local par défaut. Ce paramètre a été annulé sous SLES 12 SP1. Le gestionnaire d'affichage démarre désormais un serveur X.

Pour éviter des problèmes au cours de la mise à niveau, le paramètre SUSE Linux Enterprise Server n'est pas modifié automatiquement. Si vous souhaitez que le gestionnaire d'affichage démarre un serveur X après la mise à niveau, modifiez le paramètre DISPLAYMANAGER_STARTS_XSERVER dans /etc/sysconfig/displaymanager comme suit :

DISPLAYMANAGER_STARTS_XSERVER="yes"

Avant d'entamer la mise à niveau de votre système, consultez le Chapitre 3, Préparation de la mise à niveau.

Pour mettre à niveau votre système, démarrez à partir d'une source d'installation, comme vous le feriez pour une nouvelle installation. Toutefois, lorsque l'écran de démarrage apparaît, vous devez sélectionner Mettre à niveau (au lieu d'Installation). La mise à niveau peut être démarrée à partir des éléments suivants :

La procédure ci-dessous décrit le démarrage à partir d'un DVD, mais vous pouvez également utiliser un support d'installation local comme une image ISO sur un périphérique de stockage de masse USB. Le support et la méthode de démarrage à sélectionner dépendent de l'architecture système et du fait que la machine dispose d'un BIOS traditionnel ou UEFI.

Pour démarrer une mise à niveau à partir d'une source d'installation réseau, veillez à respecter les conditions suivantes :

Avant de mettre à niveau votre système, lisez d'abord le Chapitre 3, Préparation de la mise à niveau. Pour effectuer une migration automatisée, procédez comme suit :

Note : SUSE Customer Center et connexion Internet

Si le système que vous souhaitez mettre à niveau est enregistré auprès de SUSE Customer Center, assurez-vous de disposer d'une connexion Internet lors de la procédure suivante.

1. Après avoir démarré (à partir d'un support d'installation ou du réseau), sélectionnez l'entrée Mise à niveau dans l'écran de démarrage.

   

   Avertissement : un choix erroné risque de vous faire perdre des données

   Vérifiez que vous avez bien sélectionné l'option Mise à niveau à ce stade. Si vous sélectionnez Installation par erreur, votre partition de données sera écrasée par une nouvelle installation.

   YaST démarre le système d'installation.

2. Sur l'écran de bienvenue, choisissez Langue et Clavier. Cliquez ensuite sur Suivant.

   YaST recherche dans vos partitions les systèmes SUSE Linux Enterprise déjà installés.

3. Dans l'écran Sélectionner pour la mise à niveau, sélectionnez la partition à mettre à niveau et cliquez sur Suivant.

4. YaST monte la partition sélectionnée et affiche le contrat de licence du produit mis à niveau. Pour continuer, acceptez la licence.

5. Dans l'écran Dépôts utilisés précédemment, ajustez l'état des dépôts. Par défaut, tous les dépôts sont supprimés. Si vous n'avez ajouté aucun dépôt personnalisé, ne modifiez pas les paramètres. Les paquetages de la mise à niveau seront installés à partir du DVD. Vous pouvez éventuellement activer les dépôts en ligne par défaut à l'étape suivante.

   Si vous possédez des dépôts personnalisés, deux options s'offrent à vous :

   • Laissez le dépôt à l'état Supprimé. Les logiciels installés à partir de ce dépôt seront supprimés au cours de la mise à niveau. Utilisez cette méthode si aucune version du dépôt correspondant à la nouvelle version n'est disponible.

   • Mettez à jour et activez le dépôt s'il correspond à la nouvelle version. Changez l'URL en cliquant sur le dépôt dans la liste, puis cliquez sur Modifier. Activez le dépôt en cochant la case Changer l'état jusqu'à ce qu'il soit défini sur Activer.

   Ne conservez pas de dépôts de la version précédente, car le système risque d'être instable ou de ne pas fonctionner du tout. Ensuite, continuez en cliquant sur Suivant.

6. L'étape suivante diffère selon que le système mis à niveau est enregistré ou non auprès de Suse Customer Center.

   1. Si le système n'est pas enregistré auprès de Suse Customer Center, YaST affiche une fenêtre contextuelle suggérant d'utiliser un deuxième support d'installation, l'image SLE-15-SP6-Full-ARCH-GM-media1.iso.

      Si vous ne disposez pas de ce support, le système ne peut pas être mis à niveau sans enregistrement.

   2. Si le système est enregistré auprès de SUSE Customer Center, YaST affiche un résumé et les cibles de migration possibles.

      Sélectionnez une cible de migration à partir de la liste et cliquez sur Suivant.

7. Dans la boîte de dialogue suivante, vous pouvez éventuellement ajouter un support d'installation supplémentaire. Si vous possédez d'autres supports d'installation, activez l'option Je souhaite installer un autre produit complémentaire et spécifiez le type de support.

8. Vérifiez les paramètres d'installation pour la mise à niveau.

9. Si tous les paramètres vous conviennent, démarrez la procédure d'installation et de suppression en cliquant sur Mettre à jour.

   

   Astuce : échec de la mise à niveau sur les clients SMT

   Si la machine à mettre à niveau est un client SMT et que la mise à niveau échoue, reportez-vous à la Procédure 3.1, « annulation de l'enregistrement d'un client SUSE Linux Enterprise auprès d'un serveur SMT » et redémarrez la procédure de mise à niveau ultérieurement.

10. Une fois la mise à niveau réussie, effectuez les vérifications postérieures à la mise à niveau comme décrit au Chapitre 6, Fin de la mise à niveau.

Le processus de mise à niveau peut être exécuté automatiquement. Pour plus de détails, reportez-vous au Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.11 “Upgrade”.

SUSE Manager est une solution serveur pour fournir des mises à jour et des correctifs pour les clients SUSE Linux Enterprise. Il s'accompagne d'un ensemble d'outils et d'une interface utilisateur Web pour les tâches de gestion. Pour plus d'informations sur SUSE Manager, consultez l'adresse https://www.suse.com/products/suse-manager/.

Vous pouvez effectuer une mise à niveau système à l'aide de SUSE Manager. La technologie AutoYaST permet d'effectuer des mises à niveau d'une version majeure vers la suivante.

Si votre machine est gérée par SUSE Manager, mettez ce dernier à jour comme indiqué dans la documentation de SUSE Manager. La procédure Client Migration est décrite dans le SUSE Manager Upgrade Guide, disponible à l'adresse https://documentation.suse.com/suma/.

Lorsque vous effectuez la mise à niveau d'un Service Pack, vous devez modifier la configuration sur le serveur d'enregistrement pour donner accès aux nouveaux dépôts. Si le processus de mise à niveau a été interrompu ou annulé (par le biais d'une restauration à partir d'une sauvegarde ou d'un instantané), les informations sur le serveur d'enregistrement ne reflètent pas l'état du système. Dès lors, vous risquez de ne pas avoir accès aux dépôts de mise à jour ou à des dépôts incorrects utilisés sur le client.

Lorsqu'un retour à l'état initial est effectué via Snapper, le système avertit le serveur d'enregistrement pour garantir que l'accès aux dépôts appropriés est configuré au cours du processus de démarrage. Si le système a été restauré avec une autre méthode ou que la communication avec le serveur d'enregistrement échoue, déclenchez manuellement le retour à l'état initial sur le client. Cela peut se produire notamment si le serveur n'est pas accessible en raison de problèmes réseau. Pour procéder à un retour à l'état initial, exécutez :

> sudo snapper rollback

Nous suggérons de toujours vérifier que les dépôts corrects sont configurés sur le système, en particulier après le rafraîchissement du service à l'aide de la commande:

> sudo zypper ref -s

Cette fonctionnalité est disponible dans le paquetage rollback-helper.

Si le système n'était pas enregistré avant l'exécution de la mise à niveau, vous pouvez enregistrer votre système à tout moment à l'aide du module Enregistrement du produit dans YaST.

L'enregistrement de vos systèmes vous offre les avantages suivants :

SUSE publie régulièrement de nouveaux Service Packs pour la gamme de produits SUSE Linux Enterprise. Pour faciliter la migration vers un nouveau Service Pack et minimiser les temps hors service, SUSE prend en charge la migration en ligne pendant que le système est en cours d'exécution.

À partir de SLE 12, YaST Wagon a été remplacé par la migration YaST (pour l'interface graphique) et la migration Zypper (pour la ligne de commande). Les avantages sont les suivants :

Avertissement : migration en ligne non prise en charge pour les versions majeures

La migration en ligne est prise en charge uniquement pour la migration des Service Packs. La migration en ligne n'est pas prise en charge pour la mise à niveau vers les nouvelles versions majeures. Pour plus de détails, reportez-vous au Chapitre 2, Voies et méthodes de mise à niveau.

Utilisez la migration hors ligne pour mettre à niveau vers une nouvelle version majeure. Pour plus de détails, reportez-vous au Chapitre 4, Mise à niveau en mode hors ligne.

Important : mise à niveau des clients SUSE Manager

Si le système à mettre à niveau est un client SUSE Manager, l'opération ne peut pas être effectuée par la migration en ligne YaST ni par la commande zypper migration. Utilisez plutôt la procédure Client Migration. Elle est décrite dans le SUSE Manager Upgrade Guide.

Une migration de Service Pack peut être exécutée à l'aide des outils YaST, zypper ou AutoYaST.

Avant de pouvoir démarrer la migration d'un Service Pack, votre système doit être enregistré auprès du SUSE Customer Center ou d'un serveur RMT local. Il est également possible d'utiliser SUSE Manager.

Quelle que soit la méthode utilisée, la migration de Service Packs comporte les étapes suivantes :

La liste des cibles de migration dépend des produits que vous avez installés et enregistrés. Si vous avez une extension installée pour laquelle le nouveau Service Pack n'est pas encore disponible, il se peut qu'aucune cible de migration ne vous soit proposée.

La liste des cibles de migration disponibles pour votre hôte sera toujours récupérée à partir du SUSE Customer Center et dépend des produits ou des extensions installées.

La migration d'un Service Pack peut uniquement être annulée à certains stades au cours du processus de migration :

Pour effectuer une migration de Service Packs à l'aide de YaST, utilisez l'outil de migration en ligne. Par défaut, YaST n'installe pas les paquetages à partir d'un dépôt tiers. Si un paquetage a été installé à partir d'un dépôt tiers, YaST empêche le remplacement des paquetages par les mêmes provenant de SUSE.

Note : réduction de la taille de l'installation

Lorsque vous effectuez la migration de Service Packs, YaST installe tous les paquetages recommandés. En particulier dans le cas d'installations minimales personnalisées, cela peut augmenter considérablement la taille de l'installation sur le système.

Pour modifier ce comportement par défaut et autoriser uniquement les paquetages requis, réglez l'option solver.onlyRequires dans /etc/zypp/zypp.conf.

solver.onlyRequires = true

En outre, modifiez le fichier /etc/zypp/zypper.conf et changez l'option installRecommends.

installRecommends=false

Cette opération modifie le comportement de toutes les opérations de paquetages, telles que l'installation de correctifs ou de nouveaux paquetages. Afin de modifier le comportement de Zypper pour un seul appel, utilisez le paramètre --no-recommends.

Pour démarrer la migration de Service Packs, procédez comme suit :

Pour effectuer une de Service Packs à l'aide de , utilisez l'outil de ligne de commande zypper migrationzypper migration du paquetage zypper-migration-plugin.

Note : réduction de la taille de l'installation

Lorsque vous effectuez la migration de Service Packs, YaST installe tous les paquetages recommandés. En particulier dans le cas d'installations minimales personnalisées, cela peut augmenter considérablement la taille de l'installation sur le système.

Pour modifier ce comportement par défaut et autoriser uniquement les paquetages requis, réglez l'option solver.onlyRequires dans /etc/zypp/zypp.conf.

solver.onlyRequires = true

En outre, modifiez le fichier /etc/zypp/zypper.conf et changez l'option installRecommends.

installRecommends=false

Cette opération modifie le comportement de toutes les opérations de paquetages, telles que l'installation de correctifs ou de nouveaux paquetages. Afin de modifier le comportement de Zypper pour un seul appel, utilisez le paramètre --no-recommends.

Pour démarrer la migration de Service Packs, procédez comme suit :

Si votre système n'est pas enregistré parce que vous n'avez pas accès à Internet ou à un serveur d'enregistrement, la migration vers un nouveau Service Pack n'est pas possible avec la migration YaST ou zypper migration. Dans ce cas, vous pouvez toujours migrer vers un nouveau Service Pack avec la version ordinaire de Zypper et certaines interactions manuelles.

Important : pour les systèmes non enregistrés uniquement

Ce chemin de migration vers un nouveau Service Pack est uniquement pris en charge pour les systèmes non enregistrés qui ne peuvent pas accéder à Internet ou à un serveur d'enregistrement. Ce peut être le cas, par exemple, pour les machines d'un réseau bénéficiant d'une protection spéciale. Si vous disposez d'un système enregistré, utilisez la migration YaST ou Zypper.

Important : sources d'installation

Ce chemin de migration nécessite que le système que vous allez migrer ait accès aux sources d'installation. Pour ce faire, vous pouvez, par exemple, configurer un serveur RMT ou un serveur SLP.

Le système doit également avoir accès à un dépôt de mises à jour actualisé pour la version du produit installé.

Si un Service Pack ne fonctionne pas pour vous, SUSE Linux Enterprise prend en charge le rétablissement de l'état qu'il avait avant le démarrage de la migration de ce Service Pack. Vous devez toutefois disposer d'une partition racine Btrfs avec des instantanés activés (il s'agit de la valeur par défaut depuis SLES 12). Pour plus de détails, reportez-vous à la section Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper”.

Vous avez à présent réinitialisé le système à l'état capturé immédiatement avant le début de la migration du Service Pack.

SUSE Manager est une solution serveur pour fournir des mises à jour et des correctifs pour les clients SUSE Linux Enterprise. Il s'accompagne d'un ensemble d'outils et d'une interface utilisateur Web pour les tâches de gestion. Pour plus d'informations sur SUSE Manager, consultez l'adresse https://www.suse.com/products/suse-manager/.

La migration de Service Pack permet de migrer d'un Service Pack (SP) vers un autre au sein d'une version majeure (par exemple, à partir de SLES 15 GA vers SLES 15 SP6).

Si votre machine est gérée par SUSE Manager, mettez ce dernier à jour comme indiqué dans la documentation de SUSE Manager. La procédure Client Migration est décrite dans le SUSE Manager Upgrade Guide, disponible à l'adresse https://documentation.suse.com/suma/.

Vous pouvez mettre à niveau une installation openSUSE Leap vers SUSE Linux Enterprise Server. Pour connaître les versions de Leap prises en charge pour la migration, reportez-vous à la Section 2.2, « Chemins pris en charge pour la mise à niveau et la migration vers SLES 15 SP6 ».

Avertissement : certains paquetages OpenSUSE ne peuvent pas être migrés

openSUSE fournit plus de paquetages que SUSE Linux Enterprise Server. La plupart des paquetages supplémentaires sont disponibles via SUSE Package Hub et seront migrés. Tout paquetage supplémentaire qui n'est pas disponible via SUSE Package Hub ne recevra plus de mises à jour après la migration et doit donc être supprimés par la suite.

Veillez à ce que tous les paquetages dont vous avez besoin pour votre système soient disponibles dans les dépôts SUSE Linux Enterprise Server et SUSE Package Hub. Pour plus d'informations sur SUSE Package Hub, reportez-vous à l'adresse https://packagehub.suse.com/.

Utilisez zypper packages pour rechercher les paquetages orphelins et inutiles.

Les paquetages orphelins ne sont plus disponibles dans aucun des dépôts de paquetages configurés. Ils ne peuvent plus être mis à jour et finissent par ne plus être pris en charge.

Pour obtenir la liste des paquetages orphelins, exécutez la commande suivante :

> zypper packages --orphaned

Les paquetages inutiles sont des dépendances de paquetages qui ont été installés soit explicitement par l'utilisateur, soit implicitement en tant que modèle ou produit, et qui ont été supprimés entre-temps. Ils ne sont généralement plus nécessaires et doivent également être supprimés.

Pour obtenir la liste des paquetages inutiles, exécutez la commande suivante :

> zypper packages --unneeded

Astuce

Pour éviter les paquetages inutiles, utilisez zypper rm avec l'option --clean-deps ou YaST avec le paramètre Options › Nettoyer lors de la suppression de paquets activé.

Vous pouvez combiner les deux listes en une seule :

> zypper packages --orphaned --unneeded

Utilisez ces listes pour déterminer quels paquetages sont encore nécessaires et lesquels peuvent être supprimés en toute sécurité.

Avertissement : ne supprimez pas les paquetages dont vous avez besoin

Si des paquetages sont renommés ou supprimés d'un modèle ou d'un produit, zypper risque de ne plus les considérer comme étant explicitement installés et pourrait les marquer comme inutiles, même s'ils sont toujours essentiels pour votre installation.

Vérifiez attentivement la liste des paquetages que vous supprimez.

Pour supprimer tous les paquetages orphelins et inutiles avec une seule commande, exécutez :

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

Vous pouvez exclure un seul paquetage ou modèle de la désinstallation :

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

Vous pouvez exclure plusieurs paquetages définis dans un fichier texte, séparés par une retour à la ligne :

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

Recherchez tous les fichiers *.rpmnew et *.rpmsave. Lorsqu'une mise à niveau inclut des modifications d'un fichier de configuration par défaut qui a été édité après l'installation du paquetage, au lieu d'écraser le fichier, le système crée un de ces types de fichiers. Un fichier *.rpmnew contient la nouvelle configuration par défaut et laisse votre fichier édité intact ; un fichier *.rpmsave est une copie de votre fichier de configuration édité qui a été remplacé par le nouveau fichier par défaut.

Si vous trouvez l'un de ces fichiers, examinez son contenu et fusionnez les modifications souhaitées. Il n'est pas nécessaire de rechercher dans l'ensemble du système de fichiers, mais uniquement dans le répertoire /etc. Utilisez la commande suivante :

> find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

SUSE Linux Enterprise Server 15 utilise Python 3.6 par défaut. Python 3.9 a été ajouté à SLES 15 SP3 en tant qu'alternative plus récente. Cette version n'est plus prise en charge à partir de SLES 15 SP4. À la place, des versions récentes de contenant des mises à jour et des correctifs de sécurité importants sont disponibles via le module Python 3.

Si vous avez installé Python 3.9 sous SUSE Linux Enterprise Server 15 SP3, activez le module Python 3 avec :

> sudo SUSEConnect -p sle-module-python3/15.6/x86_64.

Vous pouvez également revenir à la version par défaut de Python en supprimant la version 3.9 avec zypper remove -u python39.

SUSE Linux Enterprise Server prend en charge le « format sur disque » (v5) du système de fichiers XFS. Les principaux avantages de ce format sont les sommes de contrôle automatiques de toutes les métadonnées XFS, ainsi que la prise en charge du type de fichier et d'un plus grand nombre de listes de contrôle d'accès pour un fichier.

Notez que ce format n'est pas pris en charge par les kernels SUSE Linux Enterprise antérieurs à la version 3.12, par les versions xfsprogs antérieures à la version 3.2.0 et les versions GRUB 2 antérieures à SUSE Linux Enterprise 12.

Important : le format V4 est obsolète.

XFS abandonne les systèmes de fichiers au format V4. Ce dernier a été créé par la commande suivante :

> sudo mkfs.xfs -m crc=0 DEVICE

Ce format était utilisé dans SLE 11 et les versions antérieures. Il génère actuellement un message d'avertissement émis par dmesg :

Deprecated V4 format (crc=0) will not be supported after September 2030

Si le message ci-dessus apparaît dans la sortie de la commande dmesg, il est recommandé de mettre à jour votre système de fichiers vers le format V5 :

1. Sauvegardez vos données sur un autre périphérique.

2. Créez le système de fichiers sur le périphérique.

   > sudo mkfs.xfs -m crc=1 DEVICE

3. Restaurez les données à partir de la sauvegarde sur le périphérique mis à jour.

Les développeurs en amont s'intéressent principalement à faire progresser le logiciel qu'ils développent. Souvent, ils combinent la correction de bogues et l'introduction de nouvelles fonctionnalités qui n'ont pas encore fait l'objet de tests poussés et qui peuvent, à leur tour, provoquer de nouveaux bogues.

Dans le cas des développeurs de distribution, il est important de faire la distinction entre :

D'habitude, les développeurs de distribution ne suivent pas toutes les modifications en amont lorsqu'un paquetage a intégré une distribution publiée. En règle générale, ils s'en tiennent à la version en amont qu'ils ont publiée initialement et créent des correctifs sur la base des modifications en amont afin de corriger les bogues. Cette technique est connue sous le nom de rétroportage (ou backporting en anglais).

Les développeurs de distribution ne lancent généralement une nouvelle version de logiciel que dans deux cas bien précis :

SUSE fait un usage intensif du rétroportage pour qu'il soit possible de trouver un juste équilibre entre plusieurs préoccupations formulées au sujet des logiciels d'entreprise. La principale préoccupation est la suivante :

En règle générale, aucune nouvelle version en amont d'un paquetage n'est introduite dans nos produits d'entreprise. Il ne s'agit toutefois pas d'une règle absolue. Pour certains paquetages (notamment pour les logiciels anti-virus), les problèmes de sécurité pèsent davantage que l'approche conservatrice qui est préférable sur le plan de l'assurance qualité. Dans ce cas de figure, il arrive que des versions plus récentes soient introduites dans une version publiée d'une gamme de produits d'entreprise.

Pour d'autres types de paquetages, il arrive également que l'on opte pour l'introduction d'une nouvelle version plutôt que de recourir au rétroportage. On fait appel à cette méthode lorsque la génération d'un « backport » n'est pas possible d'un point de vue économique ou lorsque l'introduction d'une nouvelle version se justifie pleinement sur le plan technique.

En raison de la pratique du rétroportage, il est tout simplement impossible de comparer des numéros de version pour déterminer si un paquetage SUSE contient un correctif pour un problème spécifique ou si une fonctionnalité donnée y a été ajoutée. Avec le rétroportage, la partie en amont du numéro de version d'un paquetage SUSE indique simplement la version en amont sur laquelle il est basé. Le paquetage peut contenir des correctifs de bogue et des fonctionnalités qui ne figurent pas dans la version en amont correspondante, mais qui ont fait l'objet d'un rétroportage.

Lorsque le rétroportage est appliqué, cette valeur limitée de numéros de version peut occasionner des problèmes au niveau des outils d'analyse de la sécurité. Certains outils de recherche des vulnérabilités en matière de sécurité (ou des tests spécifiques réalisés par ces outils) opèrent uniquement sur les informations de version. Ces outils et tests ont donc tendance à générer des « faux positifs » (lorsqu'un logiciel est faussement identifié comme vulnérable) en cas de rétroportage. Lors de l'évaluation des rapports issus d'outils d'analyse de sécurité, vérifiez toujours si une entrée est basée sur un numéro de version ou sur un test de vulnérabilité réel.

Les informations sur les correctifs de bogues et les fonctionnalités rétroportés sont stockées à plusieurs endroits :