Je suis en train de configurer un référentiel yum et je dois déboguer certaines des URL du fichier yum.conf. J'ai besoin de savoir pourquoi Scientific Linux tente de récupérer cette URL, alors que je m'attendais à ce qu'elle en saisisse une autre:
# yum install package
http://192.168.1.100/pub/scientific/6.1/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: sl. Please verify its path and try again
La page de manuel yum.conf (5) fournit des informations sur ces variables:
Variables
Vous pouvez utiliser un certain nombre de variables pour faciliter la maintenance des fichiers de configuration de yum. Ils sont disponibles dans les valeurs de plusieurs options, y compris name, baseurl et commandes.
$ releasever Ceci sera remplacé par la valeur de la version du paquet indiqué dans distroverpkg. Ceci est la version par défaut du paquetage 'redhat-release'.
$ arch Ceci sera remplacé par votre architecture listée par os.uname () [4] en Python.
$ basearch Ceci sera remplacé par votre architecture de base en yum. Par exemple, si votre $ arch est i686, votre $ basearch sera i386.
$ YUM0- $ YUM9 Celles-ci seront remplacées par la valeur de la variable d'environnement shell du même nom. Si la variable d'environnement shell n'existe pas, la variable du fichier de configuration ne sera pas remplacée.
Existe-t-il un moyen d'afficher ces variables à l'aide de l' yum
utilitaire de ligne de commande? Je préférerais ne pas traquer la version du paquetage 'redhat-release', ou obtenir manuellement la valeur de os.uname () [4] en Python.
/etc/redhat-release
n'est pas la même chose que la $releasever
variable. La question ici est de savoir ce que Yum remplace à la place de ces variables. Que se passe-t-il par programmation?
rpm -qf /etc/issue
est la méthode canonique, et aurait été la méthode dans LSB sauf SuSE n'a pas bougé dans les réunions FSStnd. YARLY.
cat /etc/redhat-release
En fait, utilisezcat /etc/system-release
plutôt, puisqu'il s'agira d'un lien symbolique vers / etc / redhat-release, / etc / centos-release, / etc / oel-release, / etc / <quelles que soient les utilisations scientifiques de Linux>, selon le cas.