Les notes de version contiennent des informations supplémentaires sur les modifications apportées depuis la version précédente de SUSE Linux Enterprise. Vérifiez l'existence d'éléments à prendre en considération concernant le matériel ou la configuration, déterminez quels sont vos paquetages logiciels favoris qui ont fait l'objet de modifications importantes et identifiez les précautions à prendre en plus des recommandations générales de cette section. Les notes de version contiennent également des problèmes connus et des informations de dernière minute qui n'ont pas pu être intégrés dans le manuel.

La version actuelle des notes de version contenant les informations les plus récentes sur SUSE Linux Enterprise Server peut être consultée en ligne, à l'adresse suivante : http://www.suse.com/doc/sles12/#start

Avant de procéder à la mise à jour, copiez les fichiers de configuration existants sur un support distinct (comme un périphérique à bande, un disque dur amovible, etc.) pour sauvegarder les données. Cela concerne principalement les fichiers stockés dans /etc, ainsi que certains des répertoires et des fichiers de /var et de /opt. Vous pouvez également écrire les données de l'utilisateur de /home (les répertoires HOME) dans un support de sauvegarde. Sauvegardez ces données en tant que root. Seul l'utilisateur root a des droits de lecture sur 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.

Avant de commencer votre mise à jour, prenez note de la partition root. La commande df / énumère le nom de périphérique de la partition root. Dans l'Exemple 7.1, « List with df -h », la partition root à écrire est /dev/sda3 (montée en tant que /).

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

La taille des logiciels tend à « augmenter » de versions en versions. Il convient donc de vérifier l'espace de partition disponible avec df avant d'effectuer la mise à jour. Si vous estimez que vous allez manquer d'espace disque, sécurisez vos données avant d'effectuer la mise à jour, puis repartitionnez votre système. 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é.

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.

Pour pouvoir effectuer une mise à jour en ligne, les conditions suivantes doivent être réunies. Veuillez également lire la Section 7.3, « Opérations préalables à la mise à jour ».

Important : exécutez toujours une migration en ligne complète.

La migration en ligne doit toujours être effectuée du début à la fin. L'interruption de la procédure entraînera une corruption irrécupérable du système.

Lors d'une migration en ligne, la mise à jour s'effectue depuis le système en cours d'exécution. Il vous suffit d'effectuer un seul redémarrage, une fois la mise à jour terminée.

7.4.4.1 Configuration requise #

Pour pouvoir effectuer une mise à jour en ligne, les conditions suivantes doivent être réunies. Veuillez également lire la Section 7.3, « Opérations préalables à la mise à jour ».

Enregistrement du produit

Pour qu'il soit possible de se connecter aux dépôts de mise à jour, votre produit doit être enregistré. S'il ne l'est pas, vous pouvez exécuter le module Configuration de SUSE Customer Center dans YaST ou l'outil de ligne de commande suse_register pour lancer l'enregistrement.

Exécution d'une mise à jour en ligne

Assurez-vous que les correctifs les plus récents sont installés sur la version actuelle. Effectuez une mise à jour en ligne avant de procéder à une migration en ligne. Si vous utilisez une interface graphique, démarrez le module Mise à jour en ligne de YaST ou l'applet de mise à jour. Exécutez les commandes suivantes sur la ligne de commande (la dernière commande doit être exécutée à deux reprises) :

zypper ref -s
zypper update -t patch
zypper update -t patch

Redémarrez le système si nécessaire.

Reportez-vous au Chapter 1, YaST Online Update, Administration Guide ou à la Section “Updating Software with Zypper”, Chapter 6, Managing Software with Command Line Tools, Administration Guide. pour plus d'informations. sur les outils de mise à jour en ligne.

Logiciels tiers

Si votre configuration implique un logiciel tiers ou supplémentaire, testez cette procédure sur une autre machine pour vous assurer que les dépendances ne sont pas brisées par la mise à jour.

Important : exécutez toujours une migration en ligne complète.

La migration en ligne doit toujours être effectuée du début à la fin. L'interruption de la procédure entraînera une corruption irrécupérable du système.

7.4.4.2 Migration en ligne avec YaST Wagon #

Remarque

La migration en ligne avec YaST Wagon n'est disponible qu'avant SUSE Linux Enterprise Server 12.

1. Lorsque toutes les conditions requises sont réunies (voir la Section 7.4.4.1, « Configuration requise »), l'applet de mise à jour affiche un message dans la barre système qui indique la disponibilité d'une mise à niveau de distribution. Cliquez sur celui-ci pour démarrer YaST Wagon. Une autre solution consiste à exécuter /usr/sbin/wagon en tant qu'utilisateur root à partir de la ligne de commande.

2. Confirmez la boîte de dialogue Bienvenue en cliquant sur Suivant.

3. Si Wagon détermine que des conditions requises ne sont pas réunies (des mises à jour de maintenance requises sont disponibles, mais n'ont pas encore été installées), il procède à une mise à jour automatique, ce qui peut nécessiter un redémarrage. Suivez les instructions à l'écran.

4. Choisissez la méthode de mise à jour dans la boîte de dialogue suivante. Sélectionnez Novell Customer Center pour utiliser la configuration par défaut (recommandé).

   Cliquez sur URL personnalisée pour choisir manuellement les dépôts logiciels utilisés pour la migration en ligne. La liste des dépôts est affichée. Vous avez alors la possibilité d'activer, de désactiver, d'ajouter ou de supprimer manuellement des dépôts. Ajoutez la ou les sources de mise à jour SP2. Il peut s'agir du support d'installation SP2 ou des dépôts SP2-Core et SP2-Updates. Cliquez sur OK pour revenir à la boîte de dialogue Méthode de mise à jour.

   Si vous souhaitez passer en revue les modifications apportées à la configuration des dépôts par la procédure de mise à jour, sélectionnez Vérifier les modifications de dépôts automatiques.

   Cliquez ensuite sur Suivant.

5. Le système va être réenregistré. Au cours de cette procédure, les dépôts SP2-Core et SP2-Updates seront ajoutés au système (pour plus d'informations, reportez-vous à la Section 7.7.2, « Modèle de dépôt »). Confirmez l'ajout des dépôts.

6. Si vous avez sélectionné l'option Vérifier les modifications de dépôts automatiques dans la boîte de dialogue Méthode de mise à jour, la liste des dépôts s'affiche. Elle vous offre la possibilité d'activer, de désactiver, d'ajouter ou de supprimer manuellement des dépôts. Dès que vous avez terminé, appuyez sur OK.

7. Choisissez le type de migration :

   Migration complète

   Met à jour tous les paquetages vers le niveau SP2 le plus récent.

   Migration minimale

   Met à jour un ensemble minimal de paquetages vers le niveau SP2 le plus récent.

   Cliquez sur Avancé afin de sélectionner manuellement les dépôts utilisés pour la mise à niveau.

   Confirmez votre sélection.

8. L'écran Paramètres de mise à niveau de la distribution s'ouvre. Il présente un résumé de la configuration de mise à jour. Les sections suivantes sont disponibles :

   Produits complémentaires

   Vous pouvez ajouter des produits complémentaires SUSE Linux Enterprise Server ou des produits tiers à cet emplacement.

   Options de mise à jour

   Cette section affiche la liste des actions qui seront effectuées au cours de la mise à jour. Vous pouvez soit télécharger tous les paquetages avant de les installer (option par défaut recommandée), soit les télécharger et les installer un par un.

   Paquetages

   Aperçu statistique de la mise à jour.

   Sauvegarde

   Vous pouvez définir les options de sauvegarde.

   Cliquez sur Suivant et Démarrer la mise à jour pour continuer.

   

   Important : interruption de la migration en ligne

   Vous pouvez interrompre la procédure de migration en ligne en toute sécurité sur cet écran avant de cliquer sur Démarrer la mise à jour, ainsi que sur tous les écrans précédents. Cliquez sur Interrompre pour abandonner la procédure de mise à jour et rétablir le système dans l'état dans lequel il se trouvait avant le démarrage de YaST Wagon. Suivez les instructions à l'écran et effectuez un réenregistrement avant de quitter Wagon, afin de supprimer les dépôts SP2 de votre système.

9. Les opérations suivantes sont effectuées pendant la procédure de mise à jour :

   1. Les paquetages sont mis à jour.

   2. Le système est redémarré (appuyez sur OK).

   3. Le système qui vient d'être mis à jour est réenregistré.

10. Votre système a été mis à jour vers le Service Pack 2.

Au lieu de procéder à une migration en ligne (pour plus d'informations, voir la Section 7.4.4, « Migration en ligne »), vous pouvez mettre à jour votre système en le démarrant à partir d'une source d'installation : soit un DVD, soit une source d'installation réseau. La mise à jour démarre comme une installation normale.

Les images ISO du Service Pack 2 sont disponibles à l'adresse suivante : http://download.suse.com/. Vous pouvez soit les graver sur un DVD, soit préparer une source d'installation réseau en suivant la procédure décrite à la Section 14.2, « Configuration du serveur qui contient les sources d'installation ».

Au lieu de télécharger les mises à jour pour chaque système client à partir du serveur de mise à jour SUSE, il est possible d'utiliser l'outil SMT (Subscription Management Tool) pour SUSE Linux Enterprise afin de mettre en miroir les mises à jour sur un serveur local.

Cet outil fait office de proxy SUSE Customer Center pour les enregistrements de clients et de dépôt de mises à jour logicielles. Vous trouverez, dans la documentation du SMT, accessible à l'adresse http://www.suse.com/doc/smt11/, un aperçu de ses fonctionnalités, ainsi que des instructions sur sa mise en oeuvre.

SUSE Manager est une solution serveur destinée à fournir des mises à jour, ainsi que des correctifs de sécurité et autres 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.

Vous trouverez, dans la documentation de SUSE Manager, accessible à l'adresse http://www.suse.com/doc/suse_manager/, un aperçu de ses fonctionnalités, ainsi que des instructions sur la configuration du serveur et des clients.

Vous pouvez mettre à niveau votre système en effectuant un démarrage à partir d'une source d'installation, qu'il s'agisse d'un DVD local ou d'une source réseau, comme si vous effectuiez une nouvelle installation. Il vous suffit alors de sélectionner « Mettre à niveau » au lieu de « Installer » dans l'écran de démarrage, pour mettre à niveau le système.

Pour effectuer une migration automatisée, procédez comme suit :

Exécutez multi-update. Cette commande exécute zypper dans un environnement chroot et met à jour l'autre système, quel que soit celui qui est actif. Son menu de démarrage affiche l'heure de démarrage par défaut.

Si le chargeur de démarrage du système mis à jour est endommagé après la mise à jour, vous devez modifier l'indicateur « Actif » et le définir pour la partition root de l'autre système afin de le démarrer.

Si le système mis à jour ne démarre pas du tout, vous devez accéder au menu du chargeur de démarrage et sélectionner l'autre système.

Pour plus d'informations sur GRUB 2, reportez-vous au Chapter 12, The Boot Loader GRUB 2, Administration Guide.

La partition root doit être montée par nom, par ID ou d'une autre manière. Le montage par UUID de partition ou par libellé n'est pas pris en charge.

Pour plus d'informations, reportez-vous au fichier situé sous /usr/share/doc/packages/multi-update-tools/README fourni avec le paquetage multi-update-tools.

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. Ils appliquent des mises à jour de sécurité à tout exploit racine banal dans le kernel ou tout autre exploit racine directement exécutable sans l'intervention de l'utilisateur. Ils prennent également en charge les environnements système, les piles logicielles et le matériel avec une liste d'exclusion de paquetage limitée. Voir Tableau 7.1, « Mises à jour de sécurité et résolution des bogues » pour découvrir une présentation.

La disposition des dépôts correspond aux cycles de vie des produits. Le Tableau 7.2, « Disposition des dépôts pour SUSE Linux Enterprise 11 SP2 et SP3, et SUSE Linux Enterprise 12 » contient la liste de tous les dépôts de SUSE Linux Enterprise 11 SP2 vers SUSE Linux Enterprise 12.

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
    SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
    SLES11-SP2-Core SLES11-SP2-Updates \
    SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
    SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
    https://nu.novell.com/repo/\$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

Les développeurs en amont s'intéressent principalement à faire progresser le logiciel qu'ils développent. Bien souvent, ils mènent de front 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 :

Dans la plupart des cas, les développeurs de distribution ne suivent pas toutes les modifications en amont dès qu'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. Les principales préoccupations sont les suivantes :

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 une catégorie de paquetages limitée (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/tests ont donc tendance à générer des « faux positifs » (détection erronée d'un logiciel vulnérable) lorsque le rétroportage est appliqué. Lors de l'analyse de rapports émanant des outils d'analyse de la sécurité, il convient de déterminer si une entrée est basée simplement sur un numéro de version ou sur un test d'existence d'une vulnérabilité réelle.

Les informations relatives aux correctifs et fonctionnalités ayant fait l'objet d'un rétroportage sont stockées à divers endroits :

La recherche des scripts s'effectue dans le répertoire /var/lib/YaST2/wagon/hooks/. Le nom de script doit être au format step_seq_prefix_name, où :

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

Le script doit renvoyer la valeur de sortie 0. En cas d'échec (toute valeur de sortie non nulle), un message d'erreur s'affiche dans Wagon. Il est alors possible de redémarrer le script, d'ignorer l'erreur (et de poursuivre avec d'autres scripts) ou d'annuler complètement les points d'insertion pour l'étape en cours.

Les scripts hook peuvent potentiellement être exécutés à plusieurs reprises (lorsque vous basculez entre les différentes boîtes de dialogue de Wagon, il se peut que ce dernier redémarre automatiquement ou que certaines étapes soient exécutées plusieurs fois dans le workflow de migration). Les scripts doivent donc faire face à ce genre de situation (ils peuvent vérifier, au départ, si l'action doit être exécutée ou si elle l'a déjà été, ou encore créer un simple fichier stamp temporaire ou bien résoudre correctement plusieurs exécutions).

Certains points d'insertion sont facultatifs (car ils dépendent des résultats précédents ou de valeurs sélectionnées par l'utilisateur). Certains d'entre eux sont appelés à plusieurs reprises (l'enregistrement, par exemple, est appelé avant et après la migration). Voici la liste des points d'insertion pris en charge (noms des étapes) dans l'ordre d'exécution :

Des points d'insertion spéciaux sont appelés lorsque l'utilisateur interrompt la migration. Ils peuvent être appelés à n'importe quelle étape du workflow de migration. L'ordre d'exécution ne peut donc pas être garanti. Les scripts doivent vérifier l'état actuel s'ils dépendent des résultats d'autres points d'insertion.

Ces points d'insertion sont appelés lorsque Wagon effectue un redémarrage automatique.

La liste des points d'insertion est relativement volumineuse, mais l'utilisation de nombre d'entre eux ne se justifie que dans des cas bien spécifiques. Dans les cas d'utilisation normaux, il est conseillé d'accorder la préférence aux points d'insertion suivants :

Les versions antérieures de Wagon ne prenaient en charge que deux scripts hook, à savoir : /usr/lib/YaST2/bin/wagon_hook_init et /usr/lib/YaST2/bin/wagon_hook_finish. Le problème était dû au fait qu'un seul script pouvait être exécuté comme point d'insertion et qu'il était impossible de placer directement ces points dans des paquetages RPM.

Ces anciens scripts hook sont toujours pris en charge dans les versions plus récentes de Wagon pour des raisons de rétrocompatibilité, mais les nouveaux points d'insertion before_init et before_exit doivent être utilisés au lieu des points obsolètes.