Spécification du répertoire de base

Plusieurs méthodes sont disponibles pour spécifier l'emplacement de l'installation d'un package et il est important de pouvoir modifier le répertoire de base de l'installation dynamiquement lors de la phase d'installation. Lorsque cette spécification est effectuée correctement, un administrateur peut installer plusieurs versions et plusieurs architectures sans difficulté.

Cette section aborde les méthodes courantes avant de passer à des démarches permettant d'améliorer les installations sur des systèmes hétérogènes.

Fichier de valeurs d'administration par défaut

Les administrateurs chargés de l'installation des packages peuvent se servir des fichiers d'administration pour contrôler l'installation des packages. Toutefois, en tant que concepteur de package, vous devez savoir ce qu'est un fichier d'administration et de quelle manière un administrateur peut modifier l'installation prévue d'un package.

Un fichier d'administration indique à la commande pkgadd si elle doit ou non effectuer les contrôles et afficher les invites qu'elle effectue/affiche habituellement. Les administrateurs doivent pour cette raison maîtriser la procédure d'installation d'un package et les scripts qui lui sont associés avant de se servir des fichiers d'administration.

Le système d'exploitation SunOS est livré avec un fichier de valeurs d'administration par défaut que vous trouverez dans /var/sadm/install/admin/default. Il s'agit du fichier établissant le niveau de politique d'administration le plus basique en matière d'installation de produits logiciels. Le fichier tel qu'il est livré est comme suit :

#ident "@(#)default
1.4 92/12/23 SMI"	/* SVr4.0 1.5.2.1	*/ 
mail=
instance=unique
partial=ask
runlevel=ask
idepend=ask
rdepend=ask
space=ask
setuid=ask
conflict=ask
action=ask
basedir=default

L'administrateur peut modifier ce fichier afin d'établir de nouveaux comportements par défaut ou, créer un autre fichier d'administration et spécifier son existence à l'aide de l'option -a dans la commande pkgadd.

Onze paramètres peuvent être définis dans un fichier d'administration ; toutefois, certains sont facultatifs. Pour plus d'informations, reportez-vous à admin(4).

Le paramètre basedir spécifie la manière dont le répertoire de base est généré à l'installation d'un package. La plupart des administrateurs conservent la valeur default mais le paramètre basedir peut prendre une des valeurs suivantes :

• ask, qui signifie que le répertoire de base doit toujours être demandé à l'administrateur ;

• un nom de chemin absolu ;

• un nom de chemin absolu contenant $PKGINST, qui signifie que l'installation doit toujours être effectuée dans un répertoire de base généré à partir de l'instance du package.

Si la commande pkgadd est appelée avec l'argument - a none, elle demande systématiquement le répertoire de base à l'administrateur. Malheureusement, cette commande définit également tous les paramètres du fichier sur la valeur par défaut quit qui est susceptible d'engendrer des problèmes supplémentaires.

S'habituer à l'incertitude

Un administrateur contrôle tous les packages installés sur un système via l'utilisation d'un fichier d'administration. Un autre fichier de valeurs d'administration par défaut est malheureusement souvent fourni par le concepteur du package ; ce fichier ignore en effet les souhaits de l'administrateur.

Les concepteurs de package incluent parfois un autre fichier d'administration qui leur permet (et non pas à l'administrateur) de contrôler l'installation d'un package. Étant donné que l'entrée basedir du fichier de valeurs d'administration par défaut ignore tous les autres répertoires de base, elle représente une méthode simple de sélection du répertoire de base lors de la phase d'installation. Dans toutes les versions du système d'exploitation Solaris antérieures à Solaris 2.5, ceci était considéré comme la méthode la plus simple de contrôle du répertoire de base.

Toutefois, vous devez tenir compte des souhaits de l'administrateur relatifs à l'installation du produit. La présence d'un fichier temporaire de valeurs d'administration par défaut destiné à contrôler l'installation induit la méfiance chez les administrateurs. Utilisez un script request et un script checkinstall pour contrôler ces installations sous la direction de l'administrateur. Si le script request implique véritablement l'administrateur dans la procédure, l'empaquetage du System V bénéficiera à la fois aux administrateurs et aux concepteurs de package.

Utilisation du paramètre BASEDIR

Le fichier pkginfo de tout package réadressable doit contenir une entrée spécifiant le répertoire de base par défaut dans le format suivant :

BASEDIR=absolute_path

Il ne s'agit que du répertoire de base par défaut et peut de ce fait être remplacé par l'administrateur au cours de l'installation.

Bien que certains packages requièrent plusieurs répertoires de base, l'avantage que présente ce paramètre pour le placement du package est que le répertoire de base est déjà créé et prêt à être utilisé dès le lancement de l'installation. Le chemin d'accès approprié au répertoire de base du serveur et du client est mis à la disposition de tous les scripts de procédure sous la forme de variables d'environnement réservées. La commande pkginfo -r SUNWstuf affiche la base d'installation actuelle du package.

Dans le script checkinstall, BASEDIR est le paramètre tel qu'il a été défini dans le fichier pkginfo (non encore déterminé). Afin de vérifier le répertoire de base cible, la construction ${PKG_INSTALL_ROOT}$BASEDIR est nécessaire. Ceci signifie que le script request ou checkinstall peut remplacer la valeur de BASEDIR dans l'environnement d'installation avec des résultats prévisibles. Le temps que le script preinstall soit appelé, le paramètre BASEDIR a été remplacé par le pointeur entièrement conditionné du répertoire de base actuel sur le système cible, même si le système est un client.

Le script request se sert du paramètre BASEDIR différemment selon la version du système d'exploitation SunOS. Afin de tester un paramètre BASEDIR dans un script request, le code suivant doit être utilisé pour déterminer le répertoire de base alors utilisé.

# request script
constructs base directory
if [ ${CLIENT_BASEDIR} ]; then
	  LOCAL_BASE=$BASEDIR
else
	  LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR
fi

Utilisation des répertoires de base paramétriques

Si un package nécessite plusieurs répertoires de base, vous pouvez les créer à l'aide de noms de chemin paramétriques. Cette méthode est devenue assez populaire bien qu'elle présente les inconvénients suivants :

• Un package contenant des noms de chemin paramétriques se comporte généralement comme un package absolu mais est traité par la commande pkgadd comme un package réadressable. Le paramètre BASEDIR doit être défini même s'il n'est pas utilisé.

• L'administrateur ne peut pas déterminer la base d'installation du package avec les utilitaires du System V (la commande pkginfo -r ne fonctionne pas).

• L'administrateur ne peut pas se servir de la méthode établie pour réadresser le package (il est qualifié d'adressable mais se comporte comme un package absolu).

• L'installation de plusieurs architectures ou de plusieurs versions nécessite de prévoir des plans d'urgence pour chacun des répertoires de base cible, ce qui se traduit souvent par l'utilisation de scripts d'action de classe complexes.

Bien que les paramètres qui déterminent les répertoires de base soient définis dans le fichier pkginfo, ils peuvent être modifiés par le script request. Cette caractéristique est une des raisons principales de la popularité de cette approche. Les inconvénients sont cependant chroniques et il est recommandé de n'utiliser cette configuration qu'en dernier ressort.

Exemples : Utilisation des répertoires de base paramétriques

Fichier pkginfo

# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/
EZDIR=/usr/stuf/EZstuf
HRDDIR=/opt/SUNWstuf/HRDstuf
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert980707141632

Fichier pkgmap

: 1 1758
1 d none $EZDIR 0775 root bin
1 f none $EZDIR/dirdel 0555 bin bin 40 773 751310229
1 f none $EZDIR/usrdel 0555 bin bin 40 773 751310229
1 f none $EZDIR/filedel 0555 bin bin 40 773 751310229
1 d none $HRDDIR 0775 root bin
1 f none $HRDDIR/mksmart 0555 bin bin 40 773 751310229
1 f none $HRDDIR/mktall 0555 bin bin 40 773 751310229
1 f none $HRDDIR/mkcute 0555 bin bin 40 773 751310229
1 f none $HRDDIR/mkeasy 0555 bin bin 40 773 751310229
1 d none /etc	? ? ?
1 d none /etc/rc2.d ? ? ?
1 f none /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

Gestion du répertoire de base

Tout package disponible en plusieurs versions ou destiné à plusieurs architectures doit être conçu de sorte à pouvoir, le cas échéant, parcourir le répertoire de base. Le parcours d'un répertoire de base signifie que si une version précédente ou une architecture différente du package sur le point d'être installée se trouve déjà dans le répertoire de base, ce package résout le problème, en créant par exemple un nouveau répertoire de base sous un nom légèrement différent. Les scripts request et checkinstall de Solaris 2.5 et des versions compatibles sont en mesure de modifier la variable d'environnement BASEDIR. Ceci n'est pas le cas des versions précédentes du système d'exploitation Solaris.

Même dans les versions plus anciennes du système d'exploitation Solaris, le script request pouvait redéfinir les répertoires au sein de la base d'installation. Le script request est en mesure d'effectuer cette opération d'une manière prenant en charge la plupart des préférences d'administration.