Je rencontrais un problème aujourd'hui en essayant d'installer composer avec la commande ci-dessous:
curl -sS https://getcomposer.org/installer | Sudo php -- --install-dir=/usr/local/bin --filename=composer
Cela me donnait cette erreur:
curl: (7) Failed to connect to getcomposer.org port 443: Network is unreachable
J'ai googlé et trouvé cette commande :
echo ipv4 >> ~/.curlrc
J'ai couru ceci et cela a résolu le problème et composer s'est installé correctement.
Mais je ne sais pas ce que la commande ci-dessus fait, est-ce que quelqu'un pourrait l'expliquer?
Qu'est-ce qui fait est d'ajouter "ipv4" au fichier "curlrc". Exemple commençant avec un fichier vide:
$ touch 1
$ more 1
$ echo ipv4 >> 1
$ more 1
ipv4
Fondamentalement, il oblige curl à utiliser ipv4.
Le manuel a ceci à dire:
IPv6
curl se connecte à un serveur IPv6 lorsqu'une recherche d'hôte retourne une adresse IPv6 et revient à IPv4 en cas d'échec de la connexion. Les options
--ipv4
et--ipv6
peuvent spécifier quelle adresse utiliser lorsque les deux sont disponibles. Les adresses IPv6 peuvent également être spécifiées directement dans les URL à l'aide de la syntaxe
Une convention typique sous UNIX est que les programmes lisent (généralement) leur configuration de démarrage à partir de divers fichiers prédéfinis. Ceci est simplement une tradition, pas quelque chose défini par POSIX ou tout autre standard. Un programme UNIX typique, par exemple foobar
se lirait dans l'ordre de priorité suivant:
~/.foobarrc ## User specific configuration parameters
/etc/foobarrc ## Global parameters, depending on taste
## `/etc/foobar/*(.conf)' might be chosen too
Il pourrait y avoir un repli dans /usr/share/
mais ce n'est pas très courant.
Donc, curl
suit ici la convention et lit sa configuration initiale à partir de ~/.curlrc
. Et en faisant echo ipv4 >>~/.curlrc
, vous avez ajouté la chaîne ipv4
au fichier ~/.curlrc
.
La chaîne ipv4
a une signification particulière: curl
- curl
utilisera alors IPv4 pour la résolution de l'hôte. Cela revient à utiliser -4
/ipv4
en tant qu'argument de curl
à partir de la ligne de commande, mais l'enregistrement dans ~/.curlrc
rend cette modification permanente.
Comme vous avez défini ipv4
ici et maintenant tout fonctionne pour vous, vous avez probablement IPv6 configuré, et curl
utilisait précédemment IPv6 pour la résolution (réussie) de l'hôte, il n'y a donc pas de repli sur IPv4. La connexion au site échouait car tous les sites n'avaient pas leurs serveurs Web configurés pour écouter les adresses IPv6. L'appel socket()
échouait ainsi, comme nous pouvons le constater dans ce cas.