De nombreuses personnes utilisent le référentiel de packages d'extension ** "EPEL" ** dans les distributions basées sur RHEL. L'auteur l'a également présenté à plusieurs reprises dans des articles précédents. Cependant, la situation est légèrement différente dans le cloud. J'ai donc décidé de résumer comment l'utiliser.
1-1. TL;DR
La procédure d'utilisation d'EPEL est simple. Si vous souhaitez installer immédiatement ["3. Activer le référentiel EPEL"](https://qiita.com/yamada-hakase/items/fdf9c276b9cae51b3633#3-epel%E3%83%AA%E3%83%9D % E3% 82% B8% E3% 83% 88% E3% 83% AA% E3% 82% 92% E6% 9C% 89% E5% 8A% B9% E3% 81% AB% E3% 81% 99% E3 Veuillez passer à% 82% 8B). Cette section décrit les grandes lignes de l'EPEL et les précautions à prendre pour son utilisation.
EPEL (Extra Packages for Enterprise Linux) est un groupe de packages optionnels pour les distributions Linux Red Hat Enterprise Linux (RHEL) construites par des volontaires du projet Fedora. ** Soyez le premier choix pour les sources de packages qui ne sont pas incluses dans les supports Linux ou les référentiels Yum. ** **
Un référentiel fourni par une personne autre que la société de distribution d'origine, comme EPEL, est appelé «référentiel tiers». Outre EPEL, les référentiels suivants sont également célèbres.
La raison est simple: "L'application que vous souhaitez utiliser n'est pas incluse dans le référentiel Yum standard" ou "Même si elle est incluse, la version est ancienne". C'est une raison pour le support de distribution.
Ces problèmes peuvent être améliorés avec les collections de logiciels (SCL) jusqu'à RHEL7 et AppStream de RHEL8, mais tous les problèmes ne sont pas résolus.
Certaines personnes vont construire à partir de la source lorsque ces problèmes se produisent. L'installation à partir du code source n'est pas refusée, mais les avantages du système de gestion des paquets sont compromis. Vous ne devriez le faire que si vous avez une bonne raison.
** Inconvénients lors de la construction à partir de la source **
Le tableau ci-dessous résume les versions du noyau et de la glibc pour chaque version de RHEL. Dans la même version majeure, la version du package ne change pas même si le package de mise à jour est appliqué. </ font>
Distribution | kernel | glibc |
---|---|---|
RHEL6 | 2.6.32 | 2.12 |
RHEL7 | 3.10.0 | 2.17 |
RHEL8 | 4.18.0 | 2.28 |
Amazon Linux 2 | 4.14 | 2.26 |
Le package RPM est nommé comme suit. Pour les composants de base tels que le noyau et la glibc, c'est le numéro de version donné après la version qui change lorsque yum update
est exécuté.
La raison de l'écriture si persistante est que les composants de base tels que le noyau et la glibc sont extrêmement importants pour garantir le fonctionnement des applications.
** Donc, n'utilisez pas un référentiel errant dont vous ne savez pas d'où il vient, et ne vous forcez pas à installer le package RPM pour RHEL6 sur RHEL7. ** </ font>
** En dehors </ font> ** Il y a une histoire d'horreur que j'ai vécue. Cela s'est produit lorsque je vérifiais les paramètres de RHEL6 avec le soutien d'un certain obstacle. Certaines commandes de base ne fonctionnent pas. J'ai pensé que c'était étrange, et quand j'ai cherché des paquets autres que Red Hat avec la commande suivante, beaucoup sont sortis.
Commande permettant à Vender d'afficher des packages autres que Red Hat
rpm -qa --qf "%{name} %{vendor}\n" | grep -v "Red Hat"
Les composants de base tels que la glibc sont Fedora et Scientific Linux. Ce n'est pas le numéro de version mais le numéro de version. Il semble que vous ayez installé quelque chose que vous ne pouviez pas installer avec nodeps
ou force
. Si vous faites une telle force brute, il est naturel que cela ne fonctionne pas correctement. Il n'est pas étonnant qu'il bougeait au contraire.
Pour utiliser EPEL, installez le package ʻepel-release`. Cependant, il existe les notes suivantes en fonction du service cloud et de la distribution Linux utilisés. Voir aussi site Web EPEL.
et ʻextras
codeready-builder
Installez ʻepel-release` dans "Lors de l'utilisation de RHEL ou CentOS dans le cloud" ou "Environnement sur site". C'est la base.
** Système d'exploitation Linux 8 séries **
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
** Système d'exploitation Linux série 7 **
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y
** Système d'exploitation Linux série 6 **
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y
Amazon Linux 2 dispose d'une commande dédiée pour activer EPEL. Même dans AWS, RHEL et CentOS utilisent la méthode ci-dessus.
sudo amazon-linux-extras install epel
Si l'installation réussit, les référentiels ** "amzn2 extra-epel" ** et ** "epel" ** seront ajoutés.
$ yum repolist enabled
repo id repo name status
amzn2-core/2/x86_64 Amazon Linux 2 core repository 19791
amzn2extra-docker/2/x86_64 Amazon Extras repo for docker 28
amzn2extra-epel/2/x86_64★ Amazon Extras repo for epel 1
epel/x86_64★ Extra Packages for Enterprise Linux 7 - x86 13141+192
repolist: 32961
Je crains que le nombre de paquets dans le référentiel amzn2extra-epel soit de 1. Quand je l'ai recherché, il ne contenait que epel-release.
Si vous vérifiez la définition du fichier de référentiel, il fait référence au site miroir EPEL et il n'y a pas de site miroir spécifique à AWS dans le cloud. Lorsque je vérifie le journal, il est obtenu à partir de cloudfront.
:/etc/yum.repos.d/epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch ★ Obtenir le site miroir
failovermethod=priority
Oracle Linux 7 d'Oracle Cloud Infrastructure dispose d'un référentiel EPEL dédié appelé ** "ol7_developer_EPEL" **. Par conséquent, aucun travail supplémentaire n'est requis, mais d'autres systèmes d'exploitation utilisent la méthode ci-dessus.
Vous pouvez vérifier si le référentiel EPEL est activé avec la commande suivante.
$ yum repolist
repo id repo name status
ol7_UEKR5/x86_64 Latest Unbreakable Enterprise Kernel Rele 217
ol7_addons/x86_64 Oracle Linux 7Server Add ons (x86_64) 433
ol7_developer/x86_64 Oracle Linux 7Server Development Packages 1349
ol7_developer_EPEL/x86_64 ★ Voici les packages de développement Oracle Linux 7Server 32336
ol7_ksplice Ksplice for Oracle Linux 7Server (x86_64) 7356
ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64) 18986
ol7_oci_included/x86_64 Oracle Software for OCI users on Oracle L 321
ol7_optional_latest/x86_64 Oracle Linux 7Server Optional Latest (x86 13984
ol7_software_collections/x86_64 Software Collection Library release 3.0 p 14564
repolist: 89546
Si vous vérifiez la définition du fichier de référentiel, il fait référence à l'EPEL unique d'Oracle préparé pour chaque région.
:/etc/yum.repos.d/oracle-epel-ol7.repo
[ol7_developer_EPEL]
name=Oracle Linux $releasever Development Packages ($basearch)
baseurl=http://yum$ociregion.oracle.com/repo/OracleLinux/OL7/developer_EPEL/$basearch/
Lorsque je vérifie le paquet pwgen
installé à partir de ** ol7_developer_EPEL **, l'hôte de construction (hôte de construction) et le fournisseur (fournisseur) ne sont pas " fedora ". Par conséquent, on peut voir que le paquet source est obtenu à partir d'EPEL et reconstruit.
$ rpm -qi pwgen
Name : pwgen
Version : 2.08
Release : 1.el7
★ Omis
Source RPM : pwgen-2.08-1.el7.src.rpm
Build Date : Tue Aug 14 22:24:07 2018
Build Host : x86-ol7-builder-01.us.oracle.com ★
Relocations : (not relocatable)
Vendor : Oracle America ★
URL : http://sf.net/projects/pwgen
Summary : Automatic password generation
★ Omis ci-dessous
** important </ font> ** EPEL et ol7_developer_EPEL ne sont pas exactement le même binaire car ils suivent la procédure "obtenir le paquet source depuis EPEL et le construire". De plus, il existe une possibilité de décalage temporel comme la version. </ font>
Si l'installation du package dans ol7_developer_EPEL échoue en raison d'une dépendance, etc., essayez de passer à EPEL. </ font>
Lors de l'utilisation d'un référentiel supplémentaire, non limité à EPEL, il existe deux méthodes, "Toujours activer" et "Activer temporairement". Il est courant de toujours activer EPEL une fois que vous commencez à l'utiliser, mais si vous souhaitez distinguer explicitement les packages EPEL, vous pouvez les distinguer en les "activant temporairement".
** Toujours activer **
Il est activé lorsqu'il est affiché avec yum repolist
. De plus, le fichier repo est ʻenabled = 1`.
** Activer temporairement ** Cette méthode désactive EPEL et ne l'active qu'en cas de besoin.
sudo yum-config-manager --disable epel
--enablerepo
uniquement lors de l'installation / mise à jour de packages dans EPEL.sudo yum --enablerepo=epel install <nom du package>
** Programmé pour écrire lorsqu'il y a de la capacité disponible **