Prise en compte du réadressage
La possibilité de sélectionner un répertorie de base unique à une architecture et à une version pour chaque package installé se traduit malheureusement par des niveaux hiérarchiques de répertoires superflus. Par exemple, pour un produit conçu pour les processeurs SPARC et x86, vous pouvez organiser les répertoires de base par processeur et par version comme illustré ci-dessous.
|
Répertoire de base |
Version et processeur |
|---|---|
|
/opt/SUNWstuf/sparc/1.0 |
Version 1.0, SPARC |
|
/opt/SUNWstuf/sparc/1.2 |
Version 1.2, SPARC |
|
/opt/SUNWstuf/x86/1.0 |
Version 1.0, x86 |
Cette organisation est faisable. Elle suppose toutefois que ces noms et numéros aient une signification pour l'administrateur. Une meilleure approche consiste à effectuer automatiquement cette opération après avoir fourni des explications à l'administrateur et avoir obtenu son autorisation.
Ceci vous permet d'effectuer toute l'opération dans le package sans que l'administrateur ait besoin de le faire manuellement. Vous pouvez attribuer le répertoire de base de manière arbitraire, puis établir clairement les liens client appropriés dans un script postinstall. Vous pouvez également utiliser la commande pkgadd pour installer tout au partie du package sur les clients dans le script postinstall. Vous pouvez même demander à l'administrateur la liste des utilisateurs ou clients devant connaître l'existence de ce package et mettre automatiquement à jour les variables d'environnement PATH et les fichiers /etc. Ceci est tout à fait acceptable tant que toutes les opérations effectuées au cours de l'installation du package sont annulées lors de sa désinstallation.
Parcours des répertoires de base
Vous pouvez vous servir de deux méthodes pour contrôler le répertoire de base lors de la phase d'installation. La première est la mieux adaptée aux nouveaux packages qui ne peuvent être installés que sur Solaris 2.5 et des versions compatibles ; elle offre à l'administrateur des données très utiles ; elle prend par ailleurs en charge l'installation de plusieurs versions et architectures et ne nécessite qu'un minimum de travail particulier. La deuxième méthode peut être utilisée par tous les packages et fait appel au contrôle des paramètres de développement inhérent aux scripts request pour assurer le bon déroulement des installations.
Utilisation du paramètre BASEDIR
Le script checkinstall peut sélectionner le répertoire de base approprié lors de la phase d'installation, ce qui permet de placer le répertoire de base très près de la racine de l'arborescence de répertoires. L'exemple suivant incrémente le répertoire de base de manière séquentielle, ce qui se traduit par des répertoires aux formats /opt/SUNWstuf, /opt/SUNWstuf.1 et /opt/SUNWstuf.2. L'administrateur peut se servir de la commande pkginfo pour déterminer quelles architecture et version sont installées dans chaque répertoire de base.
Si le package SUNWstuf utilise cette méthode, ses fichiers pkginfo et pkgmap ressemblent aux suivants :
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=/opt/SUNWstuf VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none daemon PSTAMP=hubert990707141632 |
Fichier pkgmap
: 1 1758 1 d none EZstuf 0775 root bin 1 f none EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none HRDstuf 0775 root bin 1 f none HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 f daemon /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 1 i i.daemon 509 39560 752978103 1 i r.daemon 320 24573 742152591 |
Exemple : Analyse de scripts parcourant un BASEDIR
Supposons que la version x86 de SUNWstuf est déjà installée sur le serveur dans /opt/SUNWstuf. Lorsque l'administrateur utilise la commande pkgadd pour installer la version SPARC, le script request doit détecter l'existence de la version x86 et interagir avec l'administrateur pour l'installation.
Remarque –
Le répertoire de base peut être parcouru sans l'interaction de l'administrateur dans un script checkinstall ; toutefois, lorsque des opérations arbitraires de ce type se produisent trop souvent, les administrateurs n'ont plus confiance dans la procédure.
Les scripts request et checkinstall d'un package gérant cette situation peuvent ressembler aux suivants :
Script request
# request script
for SUNWstuf to walk the BASEDIR parameter.
PATH=/usr/sadm/bin:${PATH} # use admin utilities
GENMSG="The base directory $LOCAL_BASE already contains a \
different architecture or version of $PKG."
OLDMSG="If the option \"-a none\" was used, press the \
key and enter an unused base directory when it is requested."
OLDPROMPT="Do you want to overwrite this version? "
OLDHELP="\"y\" will replace the installed package, \"n\" will \
stop the installation."
SUSPEND="Suspending installation at user request using error \
code 1."
MSG="This package could be installed at the unused base directory $WRKNG_BASE."
PROMPT="Do you want to use to the proposed base directory? "
HELP="A response of \"y\" will install to the proposed directory and continue,
\"n\" will request a different directory. If the option \"-a none\" was used,
press the key and enter an unused base directory when it is requested."
DIRPROMPT="Select a preferred base directory ($WRKNG_BASE) "
DIRHELP="The package $PKG will be installed at the location entered."
NUBD_MSG="The base directory has changed. Be sure to update \
any applicable search paths with the actual location of the \
binaries which are at $WRKNG_BASE/EZstuf and $WRKNG_BASE/HRDstuf."
OldSolaris=""
Changed=""
Suffix="0"
#
# Determine if this product is actually installed in the working
# base directory.
#
Product_is_present () {
if [ -d $WRKNG_BASE/EZstuf -o -d $WRKNG_BASE/HRDstuf ]; then
return 1
else
return 0
fi
}
if [ ${BASEDIR} ]; then
# This may be an old version of Solaris. In the latest Solaris
# CLIENT_BASEDIR won't be defined yet. In older version it is.
if [ ${CLIENT_BASEDIR} ]; then
LOCAL_BASE=$BASEDIR
OldSolaris="true"
else # The base directory hasn't been processed yet
LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR
fi
WRKNG_BASE=$LOCAL_BASE
# See if the base directory is already in place and walk it if
# possible
while [ -d ${WRKNG_BASE} -a Product_is_present ]; do
# There is a conflict
# Is this an update of the same arch & version?
if [ ${UPDATE} ]; then
exit 0 # It's out of our hands.
else
# So this is a different architecture or
# version than what is already there.
# Walk the base directory
Suffix=`expr $Suffix + 1`
WRKNG_BASE=$LOCAL_BASE.$Suffix
Changed="true"
fi
done
# So now we can propose a base directory that isn't claimed by
# any of our other versions.
if [ $Changed ]; then
puttext "$GENMSG"
if [ $OldSolaris ]; then
puttext "$OLDMSG"
result=`ckyorn -Q -d "a" -h "$OLDHELP" -p "$OLDPROMPT"`
if [ $result="n" ]; then
puttext "$SUSPEND"
exit 1 # suspend installation
else
exit 0
fi
else # The latest functionality is available
puttext "$MSG"
result=`ckyorn -Q -d "a" -h "$HELP" -p "$PROMPT"`
if [ $? -eq 3]; then
echo quitinstall >> $1
exit 0
fi
if [ $result="n" ]; then
WRKNG_BASE=`ckpath -ayw -d "$WRKNG_BASE" \
-h "$DIRHELP" -p "$DIRPROMPT"`
else if [ $result="a" ]
exit 0
fi
fi
echo "BASEDIR=$WRKNG_BASE" >> $1
puttext "$NUBD_MSG"
fi
fi
exit 0
|
Script checkinstall
# checkinstall script for SUNWstuf to politely suspend grep quitinstall $1 if [ $? -eq 0 ]; then exit 3 # politely suspend installation fi exit 0 |
Cette approche ne serait pas très efficace si le répertoire de base était simplement /opt. Ce package doit faire référence à BASEDIR de manière plus précise car le parcours de /opt pourrait s'avérer difficile. En fait, selon le schéma de montage, l'opération peut même s'avérer impossible. L'exemple parcourt le répertoire de base en créant un nouveau répertoire sous /opt, ce qui ne crée aucun problème.
Cet exemple utilise un script request et un script checkinstall, bien que les versions antérieures à Solaris 2.5 ne puissent pas exécuter de script checkinstall. Le script checkinstall de cet exemple est utilisé afin de suspendre poliment l'installation en réponse à un message privé sous la forme d'une chaîne quitinstall ». Si ce script s'exécute sous Solaris 2.3, le script checkinstall est ignoré et le script request suspend l'installation en affichant un message d'erreur.
N'oubliez pas que pour les versions antérieures à Solaris 2.5 et versions compatibles, le paramètre BASEDIR est un paramètre en lecture seule qui ne peut pas être modifié par le script request. Pour cette raison, lorsqu'une ancienne version du système d'exploitation SunOS est détectée (en recherchant une variable d'environnement CLIENT_BASEDIR conditionnée), le script request n'a que deux possibilités : poursuivre ou abandonner l'opération.
Utilisation de chemins paramétriques relatifs
Si votre produit logiciel a des chances d'être installé sur d'anciennes versions du système d'exploitation SunOS, le script request doit effectuer toutes les opérations requises. Cette approche peut également être utilisée pour manipuler plusieurs répertoires. Si des répertoires supplémentaires sont nécessaires, ils doivent toutefois être inclus dans un seul répertoire de base afin que le produit reste simple à gérer. Bien que le paramètre BASEDIR n'offre pas le niveau de granularité offert par la toute dernière version de Solaris, votre package peut malgré tout parcourir le répertoire de base à l'aide du script request pour manipuler les chemins paramétriques. L'exemple suivant illustre un fichier pkginfo et un fichier pkgmap :
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=/opt SUBBASE=SUNWstuf VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none daemon PSTAMP=hubert990707141632 |
Fichier pkgmap
: 1 1758 1 d none $SUBBASE/EZstuf 0775 root bin 1 f none $SUBBASE/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none $SUBBASE/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none $SUBBASE/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none $SUBBASE/HRDstuf 0775 root bin 1 f none $SUBBASE/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none $SUBBASE/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none $SUBBASE/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none $SUBBASE/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 f daemon /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 1 i i.daemon 509 39560 752978103 1 i r.daemon 320 24573 742152591 |
Cet exemple n'est pas parfait. Une commande pkginfo -r renvoie /opt comme base d'installation, ce qui est assez ambigu. Bon nombre de packages se trouvent en effet dans /opt mais il s'agit au moins d'un répertoire précis. Tout comme l'exemple précédent, l'exemple suivant prend parfaitement en charge plusieurs architectures et plusieurs versions. Le script request peut être personnalisé afin de répondre aux besoins d'un package spécifique et de résoudre toute dépendance applicable.
Exemple : Script request parcourant un chemin paramétrique relatif
# request script
for SUNWstuf to walk a parametric path
PATH=/usr/sadm/bin:${PATH} # use admin utilities
MSG="The target directory $LOCAL_BASE already contains \
different architecture or version of $PKG. This package \
could be installed at the unused target directory $WRKNG_BASE."
PROMPT="Do you want to use to the proposed directory? "
HELP="A response of \"y\" will install to the proposed directory \
and continue, \"n\" will request a different directory. If \
the option \"-a none\" was used, press the <RETURN> key and \
enter an unused base directory when it is requested."
DIRPROMPT="Select a relative target directory under $BASEDIR/"
DIRHELP="The package $PKG will be installed at the location entered."
SUSPEND="Suspending installation at user request using error \
code 1."
NUBD_MSG="The location of this package is not the default. Be \
sure to update any applicable search paths with the actual \
location of the binaries which are at $WRKNG_BASE/EZstuf \
and $WRKNG_BASE/HRDstuf."
Changed=""
Suffix="0"
#
# Determine if this product is actually installed in the working
# base directory.
#
Product_is_present () {
if [ -d $WRKNG_BASE/EZstuf -o -d $WRKNG_BASE/HRDstuf ]; then
return 1
else
return 0
fi
}
if [ ${BASEDIR} ]; then
# This may be an old version of Solaris. In the latest Solaris
# CLIENT_BASEDIR won't be defined yet. In older versions it is.
if [ ${CLIENT_BASEDIR} ]; then
LOCAL_BASE=$BASEDIR/$SUBBASE
else # The base directory hasn't been processed yet
LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR/$SUBBASE
fi
WRKNG_BASE=$LOCAL_BASE
# See if the base directory is already in place and walk it if
# possible
while [ -d ${WRKNG_BASE} -a Product_is_present ]; do
# There is a conflict
# Is this an update of the same arch & version?
if [ ${UPDATE} ]; then
exit 0 # It's out of our hands.
else
# So this is a different architecture or
# version than what is already there.
# Walk the base directory
Suffix=`expr $Suffix + 1`
WRKNG_BASE=$LOCAL_BASE.$Suffix
Changed="true"
fi
done
# So now we can propose a base directory that isn't claimed by
# any of our other versions.
if [ $Changed ]; then
puttext "$MSG"
result=`ckyorn -Q -d "a" -h "$HELP" -p "$PROMPT"`
if [ $? -eq 3 ]; then
puttext "$SUSPEND"
exit 1
fi
if [ $result="n" ]; then
WRKNG_BASE=`ckpath -lyw -d "$WRKNG_BASE" -h "$DIRHELP" \
-p "$DIRPROMPT"`
elif [ $result="a" ]; then
exit 0
else
exit 1
fi
echo SUBBASE=$SUBBASE.$Suffix >> $1
puttext "$NUBD_MSG"
fi
fi
exit 0
|
- © 2010, Oracle Corporation and/or its affiliates