J'utilise le tutoriel d'Amazon pour l'installation d'un serveur LAMP . Les premières instructions impliquent l’utilisation de yum
, mais chaque fois que j’ai essayé de le faire, il en est résulté le même message. J'ai trouvé quelques autres questions récentes sur le même problème, dont aucune ne change rien à ma configuration.
Voici le message:
Loaded plugins: priorities, update-motd, upgrade-helper
Could not retrieve mirrorlist http://repo.us-east-1.amazonaws.com/latest/main/mirror.list error was
12: Timeout on http://repo.us-east-1.amazonaws.com/latest/main/mirror.list: (28, 'Connection timed out after 10001 milliseconds')
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Disable the repository, so yum won't use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
--enablerepo for temporary usage:
yum-config-manager --disable <repoid>
4. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a Nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: amzn-main/latest
J'ai déjà fait la même chose auparavant sans rencontrer aucun problème, en utilisant le même tutoriel, mais c'était il y a plusieurs mois. Je ne sais pas ce qui a changé, mais ma maigre expérience m'empêche de le comprendre.
On dirait que l'hôte a du mal à contacter le serveur yum. Assurez-vous que l'instance dispose d'un accès Internet sortant (vérifiez les groupes de sécurité, etc.). Si l'instance est dans un VPC et que les groupes de sécurité ont bonne apparence, vous devrez peut-être utiliser un appareil nat ou attacher une adresse IP élastique.
Bonne chance-
Si vous avez un point de terminaison S3 sur votre VPC, cela entraînera un échec de yum car le fichier repo est stocké dans S3. Pour résoudre ce problème, ajoutez la stratégie suivante à S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": [
"arn:aws:s3:::repo.eu-west-1.amazonaws.com",
"arn:aws:s3:::repo.eu-west-1.amazonaws.com/*"
]
}
]
}
Remplacez eu-west-1 par le code de région approprié dans lequel se trouve votre terminal S3.
Beaucoup d'utilisateurs novices d'Amazon EC2 sont confrontés à ce problème. D'après mon expérience, cela est généralement dû à la non définition des connexions sortantes autorisées sur le groupe de sécurité de leur instance. Le didacticiel d'Amazon pour la configuration des instances Amazon Linux ne mentionne que la configuration des connexions entrantes. Il est donc facile d'oublier que vous ne définissez jamais les connexions sortantes autorisées. Le simple fait d'autoriser les demandes HTTP
et HTTPS
à n'importe quelle adresse IP devrait résoudre le problème.
J'ai le même problème et était lié à la résolution de nom. J'ai utilisé ce qui suit pour corriger:
L'instance EC2 n'a pas de DNS public
Voici la bonne explication de Mat:
attribuez simplement le groupe de sécurité par défaut à celui que vous avez éventuellement créé. Cela a résolu mon problème. ;)
Avec le commentaire de chadneal. Il est nécessaire de régler le Résolution DNS sur Oui .
ne vous inquiétez pas c’est une simple erreur ..__il n’est pas connecté internet aussi.
juste pour créer un nouveau fichier avec l'éditeur vi:
vi /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
puis tapez ceci pour quitter vi: :wq
De plus, si vous ne parvenez pas à faire fonctionner un DNS, vérifiez votre jeu d'options DHCP. J'avais laissé un ancien en place et lorsque j'ai nettoyé un projet impliquant des intégrations Active Directory, il s'est effondré. La solution consiste simplement à revenir aux options d'origine/enregistrées.
J'ai exécuté la commande suivante avec Sudo (vous ne pouvez pas faire tout seul si vous n'êtes pas root) et le problème a été résolu.
yum-config-manager --save --setopt=dev.mysql.com_downloads_repo_yum_.skip_if_unavailable=true
Je recevais exactement le même message d'erreur pour yum que décrit dans la question. Dans mon cas, j'avais une liste de contrôle d'accès qui autorisait tout le trafic sortant mais limitait le trafic entrant à HTTP/HTTPS, SSH et All ICMP. Étant donné que les NACLS sont sans état, la tentative d'exécution de yum a échoué car les connexions éphémères entrantes utilisées par yum n'étaient pas explicitement autorisées et ont donc été abandonnées.
J'ai rencontré le même problème, mais ce n'était pas mon groupe de sécurité ou NACL.
Fond: J'ai ajouté un nom de domaine via Route53. Le nom de domaine continue d’être hébergé avec DiscountASP.net. Le VPC a été créé manuellement (pas d’assistant ni par défaut). J'ai créé un jeu d’options DHCP avec mon nom de domaine et les 4 adresses IP des serveurs que Route53 m’a données.
Analyse: Premièrement, je devais prouver que le problème n'était pas le groupe de sécurité ou la NACL. Je l'ai fait en associant le jeu d'options DHCP par défaut à mon nouveau VPC. Cela a fonctionné! Je pourrais faire la mise à jour de yum et "curl http://www.google.com ". Aucun problème.
J'ai ensuite créé un nouvel ensemble d'options DHCP à l'aide de mon nom de domaine et des serveurs DNS DNS de Google . 8.8.8.8 & 8.8.4.4 Cela a également fonctionné.
J'ai ensuite pris l'une des 4 adresses IP des serveurs DNS fournies par Route 53 et je l'ai utilisée avec mon nom de domaine dans un nouveau jeu d'options DHCP . J'ai exécuté un test et celui-ci a échoué. J'ai répété le même test avec 2 des 4 adresses IP de serveur DNS restantes, créant deux jeux d'options DHCP distincts .. J'ai exécuté des tests et les deux ont échoué.
Après avoir vérifié l'orthographe de mon nom de domaine, je ne pouvais que conclure que le problème était lié aux serveurs de noms de domaine.
Solution: Guide de l'utilisateur Amazon Virtual Private Cloud (PDF page 221) Serveur Amazon DNS (Sous-sujet)
"Lorsque vous créez un VPC, nous créons automatiquement un ensemble d’options DHCP et les associons au VPC. Cet ensemble comprend deux options: domain-name-servers = AmazonProvidedDNS et domain-name = nomdomaine pour votre nom. region. AmazonProvidedDNS est un serveur Amazon DNS et cette option active DNS pour les instances devant communiquer sur la passerelle Internet du VPC. La chaîne AmazonProvidedDNS est mappée sur un serveur DNS s'exécutant sur une adresse IP réservée. adresse située à la base de la plage de réseau VPC IPv4, plus deux, par exemple, le serveur DNS d’un réseau 10.0.0.0/16 est situé à 10.0.0.2. " _
A partir de la page 221: DHCP: serveurs de noms de domaines
Nom de l'option Description "Les adresses IP de quatre serveurs de nom de domaine au maximum, ou AmazonProvidedDNS. Le jeu d'options DHCP par défaut spécifie AmazonProvidedDNS. Si vous spécifiez plus d'un serveur de noms de domaine, séparez-les par des virgules. "
Les adresses IP auxquelles il fait référence sont destinées à des serveurs de noms de domaine externes (à l’exclusion de la possibilité que vous ayez créé un DNS personnalisé).
J'ai donc créé mon ensemble d'options DHCP final en utilisant mon nom de domaine et domain-name-servers = AmazonProvidedDNS. Ça a marché! En passant, la résolution DNS du VPC = yes et le nom d’hôte DNS = non.
J'ai eu le même problème. Dans mon cas, j'ai supprimé par erreur les règles sortantes de mon groupe de sécurité. L'ajout d'une règle sortante pour autoriser tout le trafic a résolu le problème.
J'ai eu le même problème, il s'avère qu'un autre administrateur système a décidé d'acheminer le trafic Internet sortant via un proxy. J'ai trouvé ceci en remarquant des paramètres d'env proxy fatigués, un peu plus profond, puis une entrée dans mon fichier /etc/yum.conf.
Commenté la ligne proxy = et tout a encore fonctionné.
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=23&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release
#proxy=http://pos-proxy-in-my-way-of-doing-actual-real-work:666
Le problème peut se produire aux deux niveaux des groupes de sécurité et des NACL. Dans mon cas, j'ai découvert que même après la modification du groupe de sécurité, la mise à jour avait échoué. Cependant, lors de la modification des NACL, la mise à jour a réussi
veuillez suivre l'étape ci-dessous
Étape 1: accédez à AWS-VPC
Étape 2: rechercher option DHCP
Etape 3: si vous n’avez pas deDHCPoptions créez un nouveauDHCP
Étape 4: ajoutez le nom de domaine = ap-south-1.compute.internal
(si vous utilisez une autre région, veuillez utiliser un autre nom de région)
Étape 5: ajouter un serveur de noms de domaine = AmazonProvidedDNS
Étape 6: sélectionnez ensuite vos actionsVPC->-> modifiez votre jeu d'options DHCP -> Sélectionnez le jeu DHCP que vous venez de créer -> Sauvegarder
Étape 7: Ensuite/ Redémarrez votre instance
Etape 8: Connectez votre instance Ensuite, tapez simplement yum list installed
-> Cela vous donnera la liste des choses installées
Je vous remercie