7 La fin de la procédure de mise à niveau de distribution signifie qu'une migration minimale a été effectuée (un ensemble minimal de paquetages a donc été mis à jour vers le niveau SP4 le plus récent). Ignorez cette étape si vous n'avez pas l'intention d'effectuer une migration complète.
Pour effectuer une migration complète (mise à jour de tous les paquetages vers le niveau SP4 le plus récent), exécutez la commande suivante : zypper update -t patch
8 La mise à niveau vers SP4 ayant été effectuée, vous devez réenregistrer votre produit : suse_register -d 2 -L /root/.suse_register.log
9 Pour terminer, redémarrez votre système.
Votre système a été mis à jour vers le Service Pack 4.
7.7.1.4 Mise à jour au moyen d'un démarrage à partir d'une source d'installation
Au lieu de procéder à une 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 4 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 » (p. 279).
7.8 Code source du rétroportage
L'utilisation du rétroportage est largement répandue dans SUSE. Comparer les numéros de version afin d'évaluer les problèmes et fonctionnalités d'un logiciel peut s'avérer trompeur. Cette section vous aide à comprendre pourquoi.
Mise à jour de SUSE Linux Enterprise 181
7.8.1 Pourquoi recourir au rétroportage ?
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 :
• les corrections de bogues avec un potentiel limité en ce qui concerne la perturbation des fonctionnalités et
• les modifications susceptibles de perturber les fonctionnalités existantes.
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 :
• lorsque les modifications entre leurs paquetages et les versions en amont sont devenues à ce point importantes que le rétroportage n'est plus possible ;
• pour les logiciels qui, par nature, vieillissent mal, comme par exemple, les logiciels de lutte contre les programmes malveillants.
7.8.2 Arguments en faveur du rétroportage
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 :
• Disposer d'interfaces (API) stables sur lesquelles les éditeurs de logiciels peuvent compter lors de la création de produits à utiliser sur les solutions d'entreprise de
SUSE.
182 Guide de déploiement
• S'assurer que les paquetages utilisés dans la version des produits d'entreprise de
SUSE présentent une qualité optimale et ont fait l'objet de tests intensifs, tant en interne que dans le cadre du produit d'entreprise dans son intégralité.
• Gérer les différentes certifications des produits d'entreprise de SUSE par d'autres
éditeurs, telles que les certifications pour les produits Oracle ou SAP.
• Permettre aux développeurs de SUSE de s'atteler au développement d'une nouvelle version du produit qui soit aussi bonne que possible, plutôt que de se disperser sur un grand nombre de versions.
• Assurer un suivi clair de ce que contient une version d'entreprise particulière, de manière à ce que notre service de support puisse fournir des informations précises et opportunes.
7.8.3 Arguments contre le rétroportage
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.
7.8.4 Implications du rétroportage sur l'interprétation des numéros de version
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
Mise à jour de SUSE Linux Enterprise 183
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.
Les informations relatives à ces correctifs et fonctionnalités sont stockées à divers endroits :
• Journal des modifications du paquetage : rpm -q --changelog name-of-installed-package rpm -qp --changelog packagefile.rpm
La sortie documente brièvement l'historique des modifications du paquetage.
• Le journal des modifications du paquetage peut contenir des entrées telles que bnc#1234
faisant référence à des bogues présents dans le système de suivi Bugzilla de Novell ou des liens vers d'autres systèmes de suivi de bogues. (Il se peut que vous ne puissiez pas accéder à l'ensemble de ces informations en raison des politiques de confidentialité en vigueur.)
• Un paquetage peut comporter un fichier /usr/share/doc/package name/README.SUSE
ou README.SuSE contenant des informations générales et de haut niveau spécifiques au paquetage SUSE.
• Le paquetage source RPM contient les correctifs qui ont été appliqués lors de la création des RPM binaires ordinaires sous la forme de fichiers distincts qu'il est possible d'interpréter si vous êtes rompu à la lecture de code source. Pour de plus amples informations, consultez le livre Maximum RPM [ http:// www.rpm.org/max-rpm/
].
• Pour les correctifs des bogues de sécurité, consultez les Annonces de sécurité de
SUSE [ https://www.suse.com/support/security/#1
]. Les bogues sont généralement désignés par des noms standard, tels que CAN-2005-2495, dont la gestion est assurée dans le cadre du projet Common Vulnerabilities and
Exposures [ http://cve.mitre.org
].
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.
184 Guide de déploiement
