This content is submitted by a BigAdmin user. It has not been reviewed for technical accuracy by Sun Microsystems, though it may have been lightly edited to improve readability. If you find an error or would like to comment on the article, please contact the submitter or use the comment field at the bottom of the article.
Community submissions may not follow Sun trademark guidelines. For information on Sun trademarks, please see http://www.sun.com/suntrademarks/.
Derek Olsen, janvier 2008
Présentation
Ces conseils techniques décrivent pkgman, un utilitaire de gestion de packages destiné à maintenir ces derniers dans un état voulu sur les hôtes qui exécutent le SE Solaris 8, 9, ou 10 pour les plates-formes SPARC ou x86. Ces conseils techniques illustrent comment utiliser pkgman en installant GTK+, une boîte à outils multi plate-forme pour créer des interfaces graphiques, qui est disponible sur Sunfreeware.com.
Remarque: les exemples de ce document utilisent le SE Solaris 10.
Ajouter ou supprimer des packages d'un hôte Solaris est une tâche légère. Toutefois, si vous avez un grand nombre d'hôtes exécutant différentes versions du SE Solaris avec des conditions requises uniques, ces tâches peuvent être lourdes.
Qu'advient-il lorsqu'un hôte a démarré avec jumpstart et qu'une requête arrive pour installer un package logiciel supplémentaire ? Avez-vous une source sûre pour vérifier si vous utilisez déjà ce logiciel quelque part ? Ou bien la résolution de la requête dépend-elle de qui y réagit ? Comment pourrez-vous vérifier que la même version de l'instance du package est installée pour limiter la dérive dans la configuration de vos hôtes ? Et si vous devez déployer des mises à jour, par exemple de PostgreSQL, à travers le développement, le test et la production ? Disposez-vous d'une procédure documentée pour ce faire ? C'est peut-être le cas, et j'ai perdu mon temps à élaborer pkgman.
Dans ma propre expérience d'administrateur Solaris, j'ai lutté avec une solution élégante aux questions précédentes, et j'ai rencontré d'autres personnes dans le même cas. Le problème dans mes approches précédentes de gestion de packages résidait dans la complexité de la solution. Ceci m'a conduit à une situation où j'étais le seul qui pouvait facilement déployer les nouveaux packages, mettre à jour les packages ou les rappeler. Comme je souhaitais pouvoir prendre des vacances ou me faire porter malade, je suis revenu vers ma planche à dessin.
L'objectif de ce document consiste à démontrer comment installer et configurerpkgman pour gérer les packages. L'installation du package GTK+ (2.12.0) de Sunfreeware.com est au coeur de notre exemple. L'installation du package GTK+ constitue un bon exemple pratique pour vous aider à déterminer si l'utilisation de pkgman est intéressante dans votre cas.
Conditions requises pour pkgman
Nous commencerons par les conditions requises pour pkgman, car dans chaque entreprise il existe certains paramètres dans les limites desquelles il faut fonctionner.
Ruby version 1.8.X est nécessaire pour exécuter pkgman. (Je prévois de tester avec Ruby 1.9.X en janvier 2008.)
Les packages Solaris à installer doivent être au format flux de données.
Les packages à installer doivent être disponibles localement via HTTP.
Installation de pkgman
Si les conditions requises ne vous ont pas fait peur, passons à l'installation de pkgman :
Téléchargez l'archive tar marquée "dernière version stable" dans la liste de téléchargements sur http://code.google.com/p/pkgman/downloads/list. L'archive tar s'intitule pkgman-<release number>.tar.gz.
Décompressez l'archive tar. Vous obtenez un répertoire intitulé pkgman-<release number>.
Vous pouvez aussi utiliser une sous-version pour vérifier le référentiel pkgman. La commande suivante vérifie le référentiel de sous-version pkgman dans un répertoire intitulépkgman :
Changez de répertoire pour la racine du répertoire pkgman.
Le script setup utilise /usr/local comme préfixe de déploiement de pkgman. Ainsi l'exécutable est transféré dans/usr/local/bin et le fichier de configuration dans /usr/local/etc. Le script setup script modifie également la ligne shebang pour correspondre au chemin vers Ruby sur votre hôte.
ruby setup.rb
---> bin
<--- bin
---> conf
<--- conf
---> bin
<--- bin
---> conf
<--- conf
rm -f InstalledFiles
---> bin
mkdir -p /usr/local/bin/
install pkgman.rb /usr/local/bin/
<--- bin
---> conf
mkdir -p /usr/local/etc/
install pkgman.yaml /usr/local/etc/
<--- conf
Si vous voulez installerpkgman dans un autre répertoire, procédez comme suit. Ici, je change le préfixe du répertoire de/usr/local pour mon répertoire personnel :
ruby setup.rb all --prefix=$HOME
---> bin
<--- bin
---> conf
<--- conf
---> bin
<--- bin
---> conf
<--- conf
rm -f InstalledFiles
---> bin
mkdir -p /users/deet/bin/
install pkgman.rb /users/deet/bin/
<--- bin
---> conf
mkdir -p /users/deet/etc/
install pkgman.yaml /users/deet/etc/
<--- conf
Installation des packages GTK+
Maintenant que pkgman est disponible sur /usr/local/bin/pkgman.rb (où là où vous l'avez placé), nous pouvons nous concentrer sur la tâche importante, qui consiste à installer les packages !
Vous devez déterminer quel miroir sunfreeware.com est le mieux adapté pour télécharger vos packages. Consultez la liste de miroirs disponibles.
Eu égard aux coûts en termes de bande passante, il est préférable de télécharger vos packages sur votre site local et de les rendre disponibles localement par HTTP. Au moment où j'écris (décembre 2007), les packages et les versions des logiciels que vous devez télécharger pour exécuter GTK+ sont les suivants :
N'oubliez pas que ces packages exigent l'objet partagé libgcc. Dans cet exemple, je suppose que le logiciellibgcc est déjà installé.
Si vous devez installer libgcc, pour pouvez ajouter l'enregistrement du package libgcc après avoir vu comment le fichierconfig est configuré.
Une fois les packages nécessaires téléchargés, vous devez les rendre disponibles par HTTP. De plus, les packages doivent être décompressés car pkgman ne prend pas en charge les packages compressés pour le moment. Une demande d'amélioration pour suivre le traitement des fichiers compressés existe.
Pour décompresser les packages gzippés, vous pouvez exécuter la commande suivante dans le répertoire où ces packages résident :
for f in `ls *gz`; do gunzip $f; done
Construction du fichier de configuration pkgman.yaml
Nous allons maintenant construire le fichier de configuration pkgman.yaml.
J'ai éliminé les commentaires du fichierpkgman.yaml qui sont installés pour maintenir cette section du document aussi peu encombrée que possible. Le fichier de configuration contient des informations sur les packages à installer ou supprimer, ainsi que les paramètres du script. Les paramètres du script se composent d'éléments comme l'emplacement des packages et comment enregistrer les activités.
Voici l'aspect de la section des paramètres de script du fichier pkgman.yaml dans mon environnement :
Dans la plupart des environnements, il vous suffit de changer les clés http_host, http_port et http_uri.
Par exemple, si l'URL que vous utilisez pour consulter le référentiel du package sur votre site est http://10.30.1.22/solaris/support/extras, votre section de paramètres pkgman.yaml présentera l'aspect suivant :
A ce stade, je ne vais pas creuser trop profondément les détails du fichier pkgman.yaml, mais la section "CONFIG FILE" du fichier README sur http://pkgman.googlecode.com/svn/trunk/README contient des informations plus détaillées.
Maintenant que la section des paramètres est terminée, nous devons construire les enregistrements pour chaque package à installer. Les informations nécessaires pour ce faire sont le nom du package, sa version, le nom de fichier et les hôtes auxquels l'enregistrement s'applique.
Commençons par le package logiciel atk. Vous pouvez déterminer le nom du package en utilisant la commande pkginfo. Ici, j'interroge le fichier de package atk-1.18.0-sol10-sparc-local pour déterminer le nom et la version du package :
Vous pouvez aussi obtenir la version du package par l'intermédiaire de la commande pkgparam comme suit :
[root@jumpstart /jumpstart/pkgs/sfw]$ pkgparam -f \
atk-1.18.0-sol10-sparc-local
VERSION
1.18.0
Nous savons maintenant que le nom du package est SMCatk, que sa version est 1.18.0, et que le nom du fichier est atk-1.18.0-sol10-sparc-local. Nous plaçons donc ces informations dans un enregistrement de package dans le fichier pkgman.yaml.
L'enregistrement d'installation du package SMCatk se présente comme suit :
Nous utiliserons la valeur default pour la clé hosts. Les valeurs prises en charge pour la clé hosts sont détaillées dans le fichier README.
Pour lier la section des paramètres et l'enregistrement de package, regardons à quoi ressemble notre fichier pkgman.yaml actuel. En d'autres termes, le fichier pkgman.yaml suivant indique que le package logiciel SMCatk version 1.18.0 doit être installé sur tous les hôtes exécutantpkgman. Le nom de fichier du package est atk-1.18.0-sol10-sparc-local, et il peut être téléchargé sur http://jumpstart:1080/jumpstart/pkgs/sfw/atk-1.18.0-sol10-sparc-local.
De plus, toute sortie sera journalisée parsyslog en utilisant la prioritédaemon.notice. Si la journalisation est configurée sur "syslog," les journaux n'iront que vers syslog, et aucune information ne sera envoyée à votre terminal.
Nous devons maintenant ajouter les packages restants au fichier pkgman.yaml.
Pourquoi ne pas choisir un ou deux packages, construire l'enregistrement de package et comparer vos résultats avec le contenu du fichier complet pkgman.yaml suivant ? L'ordre des packages importe peu car l'ensemble du contenu finit en un ensemble non trié.
Maintenant que pkgman est installé et qu'un fichier de configuration initial est paramétré, voyons ce que nous pouvons faire.
Pour commencer, laissez-moi aborder les options de la ligne de commande pkgman et leur signification.
[root@jtest ~]$ which pkgman
/usr/local/bin/pkgman
[root@jtest ~]$ pkgman
Usage: /usr/local/bin/pkgman [ -n ] -f pkgman.yaml
-f [ /path/to/pkgman.yaml | http://server/path/to/pkgman.yaml ]
-n Just print what would happen without making any changes
-h print usage and exit
L'argument -n est facultatif et indique que vous souhaitez exécuter pkgman en mode simulation. En mode simulation, aucune modification n'est apportée au système. Vous pouvez utiliser le mode simulation pour voir quels packages seraient installés ou supprimés d'un hôte avant d'exécuter pkgman pour de bon.
L'argument -f est obligatoire et suivi de l'emplacement du fichier pkgman.yaml. Le fichier peut être sur le système de fichiers local ou disponible par HTTP. Certains sites n'utilisent pas cfengine ni un outil similaire pour transmettre les fichiers à leurs hôtes, c'est pourquoi j'ai pensé qu'il serait utile d'avoir le fichier pkgman.yaml disponible par HTTP.
Exécutons maintenant pkgman en le pointant vers notre fichier de configuration. Oh !
Dans ce premier exemple, je vais exécuter pkgman en mode simulation. J'utilise la configuration de journalisation par défaut, qui envoie tout vers /var/adm/messages. Nous pouvons constater que tous les packages voulus sont marqués pour l'installation.
Poursuivons cet exemple et effectuons les installations réelles en exécutant pkgman sans l'indicateur de simulation. D'après la sortie de journalisation, tout semble s'être déroulé correctement.
[root@jtest /]$ pkgman -f \
http://jumpstart:1080/jumpstart/pkgs/sfw/pkgman.yaml
[root@jtest ~]$ tail -16 /var/adm/messages
Dec 11 17:33:40 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCatk> was successful.
Dec 11 17:33:44 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCcairo> was successful.
Dec 11 17:33:45 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCexpat> was successful.
Dec 11 17:33:51 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCfontc> was successful.
Dec 11 17:33:54 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCftype> was successful.
Dec 11 17:34:08 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCglib> was successful.
Dec 11 17:35:00 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCgtk> was successful.
Dec 11 17:35:02 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCjpeg> was successful.
Dec 11 17:35:04 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCliconv> was successful.
Dec 11 17:35:06 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMClibpng> was successful.
Dec 11 17:35:12 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCpango> was successful.
Dec 11 17:35:13 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCrender> was successful.
Dec 11 17:35:14 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCrenpro> was successful.
Dec 11 17:35:19 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCtiff> was successful.
Dec 11 17:35:21 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCxrend> was successful.
Dec 11 17:35:23 jtest pkgman[10494]: [ID 702911 daemon.notice] \
Installation of <SMCzlib> was successful.
Exécutons pkgman encore une fois en mode simulation pour voir ce qui se passe.
Cette fois, je change l'entrée de "journalisation" dans le fichier pkgman.yaml. La ligne indiquait préalablement :logging: syslog. Maintenant elle indique : logging: console. Toutes les tâches à effectuer seront ainsi signalées au terminal.
Rien n'a été signalé car les packages voulus sont déjà installés. Toutefois, pour les sceptiques, nous allons effectuer une vérification croisée de la base de données pour nous assurer que les packages ont effectivement été installés.
Tout semble en ordre ici. Nous disposons maintenant d'un hôte avec GTK+ et les packages dépendants requis installés.
Vous pouvez maintenant réitérer facilement les installations de package sur n'importe quel hôte sur lequel vous souhaitez installer GTK+.
Script post installation de JumpStart
La partie qui suit de mon script JumpStart post installation (utilisant des archives Flash) démontre comment j'ai intégré pkgman dans JumpStart.
J'ai dit que j'installais juste le cluster de SE voulu avec JumpStart, mais ce n'est pas totalement vrai, car j'ajoute le package Ruby au SE avant de créer mon archive Flash.
J'exécute pkgman une fois la réinitialisation d'installation terminée, car tous les packages n'ont pas été créés pour honorer une installation root alternative. Les chemins codés en dur dans les scripts de pré installation ou de post installation peuvent ne pas fonctionner.
En outre, j'effectue d'autres tâches de configuration dans le script de post installation ; c'est donc l'emplacement logique pour inclure l'exécution de pkgman. Pendant une installation Flash, tous les scripts situés dans /etc/flash/reboot sont exécutés pendant la première initialisation. Le processus supprime le répertoire de réinitialisation et son contenu après l'exécution du script, ce qui est plus agréable que de créer des scripts init temporaires.
Une fois l'exécution initiale post JumpStart de pkgman terminée, les futures exécutions de pkgman sont déclenchées par cfengine. J'ai configuré cfengine pour exécuter pkgman lorsqu'un certain fichier de déclenchement n'existe pas sur l'hôte (/etc/.run_pkgman).
Lorsque je dois déployer des modifications de package, les hôtes destinataires tendent à s'aligner avec mes groupes cfengine. Par exemple, lorsque je veux envoyer les packages GTK+ aux stations de travail Solaris, j'utilise cfengine pour atteindre le fichier de déclenchement sur tous les hôtes de mon groupe '"stations de travail" cfengine.
Voici le snippet de mon fichier cfengine qui commande l'exécution de pkgman :
J'utilise un fichier cfengine dédié pour les tâches uniques, comme atteindre les fichiers déclencheurs. Pour déclencher pkgman sur toutes les stations de travail, j'ajoute ce qui suit au fichier cfengine utilisé pour les tâches uniques. N'oubliez pas de supprimer la tâche après avoir envoyé les modifications de cfengine.
Nous avons fait le tour de pkgman. Notre objectif consistait à installer les packages GTK+ depuis sunfreeware.com, ce que nous avons accompli.
J'espère avoir fourni suffisamment d'informations à travers cet exemple pour que vous décidiez si pkgman mérite une étude plus poussée. Consultez le fichier README pour des informations plus détaillées.
Derek est administrateur de système UNIX/Linux de longue date. Au fil du temps, il a développé une fascination spéciale pour les installations JumpStart personnalisées, la gestion des packages et des configurations. Il vit et travaille à Portland, Oregon (États-Unis) et consacre ses loisirs à bricoler avec le SE Solaris, boire des bières et s'auto convaincre qu'il est responsable de son chien, et non l'inverse.
The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.
Comments (latest comments first)
Discuss and comment on this resource in the BigAdmin Wiki
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
Print-friendly Version
