Le logiciel du système d'exploitation (SE) Solaris est livré et installé avec des packages SVR4. Les packages contiennent un ou plusieurs fichiers installables ainsi que des informations de configuration propres au package. Ces informations définissent les attributs de ces objets. Elles indiquent également comment et où les packages doivent être installés. Le package contient généralement aussi des scripts de préinstallation et de post-installation pour vérifier que les fichiers sont correctement délivrés.
Un patch ajoute, actualise ou supprime un ou plusieurs de ces fichiers sur votre système en mettant à jour les packages installés. Le patch proprement dit est physiquement composé de packages sparse ainsi que d'un certain nombre de scripts pré et post patch et de scripts d'action par classe.
Un package sparse est une version minimaliste d'un package normal. Il ne délivre que les fichiers actualisés.
Un script d'action par classe définit un ensemble d'actions à exécuter pendant l'installation ou la suppression d'un package ou d'un patch.
Oui, vous pouvez appliquer les patchs Solaris 10 à toutes les versions de Solaris 10.
Chaque version commerciale possède un ensemble de patchs. Par exemple, la version commerciale Solaris 8 possède un ensemble de patchs Solaris 8, une version Solaris 10 un ensemble de patchs Solaris 10, et ainsi de suite.
L'ensemble de patchs de chaque version comprend toutes les versions comprises dans la version commerciale. Par exemple, la version Solaris 10 3/05 est la première version commerciale de Solaris 10. Un certain nombre de versions lui ont fait suite, notamment Solaris 10 1/06, Solaris 10 6/06, etc. L'ensemble de patchs est applicable à toutes ces versions de Solaris 10. Le même patch Solaris 10 peut être appliqué à la version Solaris 10 3/05, Solaris 10 1/06, Solaris 10 6/06, et ainsi de suite.
Vous ne pouvez pas appliquer de patch entre différentes versions commerciales de Solaris. Par exemple, vous ne pouvez pas appliquer un patch Solaris 10 à une version de Solaris 9.
Certains clients souhaitent effectuer une mise à niveau en installant tous les patchs produits depuis la version installée sur leur système. Les patchs publiés après la mise à disposition générale d'une version comme Solaris 10 1/06, contiennent les caractéristiques et les correctifs délivrés dans la version Solaris 10 1/06.
La réponse est non. Vous pouvez obtenir une partie d'une version ultérieure avec les patchs qui lui font suite, mais vous n'avez aucune garantie d'actualiser l'intégralité de la version.
Une version de Solaris comme Solaris 10 6/06 contient des patchs du code existant et des nouveaux packages. Tous les changements de code pré-existant, y compris les changements de caractéristiques, sont délivrés dans les patchs. Si vous appliquez un patch de niveau égal ou supérieur à la version, comme Solaris 10 6/06, vous obtenez tous les correctifs du code pré-existant contenu dans cette version. Vous pouvez également obtenir certaines nouvelles caractéristiques, entièrement contenues dans les patchs.
Bien que les patchs puissent contenir de nouveaux objets, les caractéristiques importantes introduisent généralement de nouveaux packages. Ces dernières sont habituellement disponibles uniquement en installant ou en mettant à niveau l'image de la version Solaris. Par conséquent, il est impossible d'obtenir des fonctionnalités identiques à celles d'une version comme Solaris 10 6/06 par application de patchs successifs.
Les temps d'installation varient en fonction de différents facteurs :
Les clusters de patch recommandés peuvent être très lourds et certains patchs, comme celui du noyau, ont tendance à grossir. Par exemple, le patch du noyau Solaris 10 11/06, 118833-36, représente environ 136 Mo. Le patch du noyau Solaris 10 8/07, 120011-10, représente environ 166 Mo. Les plus gros patchs sont les plus lents à installer.
Sur les systèmes qui possèdent des zones non globales, l'opération de patch est actuellement effectuée séquentiellement pour chaque zone, une par une.
Sun travaille à l'amélioration de ces problèmes. Voir CR 6318693.
Historiquement, l'intention a toujours été d'éviter de produire des patchs lourds et encombrants en fournissant un patch par "composant" de logiciel. Par exemple, vous pouvez avoir un patch UFS pour le sous-système UFS et un patch libc pour la bibliothèque libc.
Ces limites disparaissent lorsque des correctifs et en particulier les changements de caractéristiques, touchent le code de différents sous-systèmes du système d'exploitation. Par conséquent, des dépendances peuvent survenir, qui forcent un ou plusieurs patchs ensemble, afin que le changement soit délivré de façon cohérente.
Parfois la dépendance est "logicielle" et nous pouvons maintenir les patchs séparés en notant simplement dans le fichier LISEZ-MOI du patch que plusieurs patchs peuvent être nécessaires pour obtenir un correctif complet. Une dépendance logicielle est une caractéristique ou un correctif incomplet, mais dont la nature incomplète ne produit pas un état incohérent du système.
Remarque : pour en savoir plus sur les dépendances des patchs (notamment les dépendances logicielles et matérielles) consultez l'article Sun BluePrints Solaris Patch Management Recommended Strategy (pdf) et reportez-vous à la section, "Patch Interrelationships."
La première est qu'éviter de produire des patchs trop lourds conduit à en produire davantage de plus petits.
De plus, la gamme de logiciels Sun comprend un grand nombre de produits et certains d'entre eux, Solaris en particulier, peuvent être ciblés par un certain nombre de patchs différents correspondant à divers sous-systèmes du produit.
Application de patch en mode mono et multiutilisateurs
Le fichier LISEZ-MOI du patch indique lesquels doivent être installés en mode monoutilisateur. Bien que les outils du patch ne vous obligent pas à utiliser le mode monoutilisateur, il convient de respecter le LISEZ-MOI. L'application de patch en mode monoutilisateur garantit que le système est passif. Il importe de réduire l'activité du système. Certains patchs actualisent les composants couramment utilisés du système. L'emploi du mode monoutilisateur préserve la stabilité du système et réduit les risques d'utilisation de ces composants pendant qu'ils sont actualisés.
L'emploi du mode monoutilisateur est essentiel pour les patchs système comme le patch du noyau. Si vous appliquez un patch au noyau en mode multiutilisateurs, vous augmentez considérablement le risque d'incohérence du système.
Si le mode monoutilisateur était nécessaire pour appliquer le patch, oui, vous devez utiliser ce mode. Les propriétés du patch s'appliquent aussi bien à son installation qu'à son retrait. Les changements apportés au système sont aussi importants, quelle que soit la direction dans laquelle ils sont effectués, par exemple à l'installation par rapport au retrait.
Vous penseriez que changer votre niveau d'exécution avec la commande init S suffirait. Toutefois, en pratique, il n'est pas garanti que tous les processus et applications exécutés sur un système s'arrêtent lorsque vous passez du mode multiutilisateur au mode monoutilisateur de cette manière. Les applications d'autres origines sont particulièrement concernées. L'utilisation de la commande init ne rend pas le système aussi passif que possible pour les patchs qui spécifient une installation en mode monoutilisateur. Par conséquent, si l'installation en mode monoutilisateur est spécifiée dans le LISEZ-MOI du patch, Sun recommande vivement de démarrer dans ce mode pour effectuer les opérations relatives au patch.
Ce problème connu est généralement dû au fait que les systèmes de fichiers de zone non globale ne sont pas montés en mode monoutilisateur. Voici un exemple de message d'erreur susceptible de s'afficher :
Preparing checklist for non-global zone check...
Checking non-global zones...
ERROR: unable to boot zone: problem running on zone :
error 1 zoneadm: zone 'myzone': can't stat /zones/full1/root: No such file or
directory
zoneadm: zone 'myzone': call to zoneadmd failed
Can not boot non-global zone myzone
Solution : pour s'assurer que tous les systèmes de fichiers locaux sont montés, exécutez mountall -l avant d'installer les patchs.
Sun travaille actuellement à la résolution de ce problème.
Le fichier LISEZ-MOI de certains patchs spécifie qu'un redémarrage est nécessaire après installation ou retrait du patch. Si vous avez des doutes sur ces instructions, consultez le fichier patchinfo dans le répertoire du niveau supérieur du patch. Les instructions de redémarrage y sont clairement indiquées. Cette demande de redémarrage peut contenir deux instructions de redémarrage :
La première est de "redémarrer après" l'application du patch pour voir la correction. Cette instruction n'implique pas de contrainte temporelle, car il s'agit simplement d'un rappel que certains changements ne sont pas activés jusqu'au prochain redémarrage.
La deuxième instruction est de "redémarrer immédiatement" après l'application du patch. Le redémarrage doit être effectué rapidement car le système est dans un état incohérent et doit être redémarré pour stabiliser le système en cours d'exécution. Par conséquent, le système doit être redémarré dès que possible, de préférence dès que vous avez terminé les opérations relatives au patch.
Par exemple, un patch peut délivrer de nouveaux binaires au noyau et une nouvelle bibliothèque libc. Une fois les nouveaux binaires du noyau installés sur le disque, ils sont toujours inactifs car ils sont chargés au prochain redémarrage du système. La nouvelle bibliothèque libc peut contenir des changements d'interface ou de comportement qui dépendent du nouveau noyau. Mais la nouvelle libc peut être liée et appelée n'importe quand après son installation dans le système de fichiers. Cette différence de version peut être à l'origine de l'état incohérent du système, qui peut potentiellement provoquer des problèmes sérieux.
Rien. Lorsqu'un patch nécessite un redémarrage, vous ne pouvez pas l'éviter. Tôt ou tard vous devez redémarrer pour activer les changements introduits par le patch. Vous pouvez toutefois choisir l'une de deux stratégies pour reporter le redémarrage à un moment plus opportun.
L'une des méthodes consiste à utiliser Solaris Live Upgrade, qui permet d'installer les patchs alors que vous êtes en production. Vous pouvez éviter le mode monoutilisateur et utiliser le mode multiutilisateur. Vous redémarrez ensuite simplement dans l'environnement patché à un moment plus opportun.
Remarque : à l'heure actuelle, Solaris Live Upgrade ne supporte pas très bien les systèmes de fichiers racine (/) Veritas encapsulés. Le système de fichiers racine (/) peut être un volume Veritas Volume Manager (VxVM). Si des volumes VxVM sont configurés dans votre système actuel, la commande lucreate peut créer un nouvel environnement de démarrage. Lorsque les données sont copiées dans le nouvel environnement de démarrage, la configuration de système de fichiers Veritas est perdue et le système UFS est créé dans le nouvel environnement de démarrage.
Une autre approche présentant des avantages similaires avec Solaris Live Upgrade consiste à utiliser des volumes RAID-1 (mise en miroir du disque) avec Solaris Volume Manager. Dans ce scénario, vous pouvez fractionner le miroir, monter le système de fichier racine (/) inactif et appliquer les patchs à la copie avec la commande patchadd -R. L'option -R vous permet de spécifier un emplacement racine alternatif. L'option -R est généralement destinée à une utilisation avec des clients sans disque, mais peut aussi servir à retarder le démarrage.
Print-friendly Version
