¿Qué hace "echo ipv4 >> ~ / .curlrc"?

8

Me enfrentaba a un problema hoy cuando intentaba instalar Composer con el siguiente comando:

curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

Me estaba dando este error:

curl: (7) Failed to connect to getcomposer.org port 443: Network is unreachable

Busqué en Google y encontré este comando :

echo ipv4 >> ~/.curlrc

Ejecuté esto y solucionó el problema y el compositor se instaló muy bien.

Pero no sé qué hace el comando anterior, ¿alguien podría explicarlo?

Prashant Kumar
fuente
@Melebius Enlace agregado :)
Prashant Kumar

Respuestas:

9

Lo que hace es agregar "ipv4" al archivo "curlrc". Ejemplo que comienza con un archivo vacío:

$ touch 1
$ more 1
$ echo ipv4 >> 1
$ more 1
ipv4

Básicamente obliga a curl a usar ipv4.


El manual tiene esto que decir al respecto:

IPv6

curl se conectará a un servidor con IPv6 cuando una búsqueda de host devuelva una dirección IPv6 y vuelva a IPv4 si falla la conexión. Las opciones --ipv4y --ipv6pueden especificar qué dirección usar cuando ambas están disponibles. Las direcciones IPv6 también se pueden especificar directamente en las URL utilizando la sintaxis

Rinzwind
fuente
Solo ejecuté ese comando, funcionó, así que supongo que es correcto. Solo una pregunta, por qué mi compositor no estaba trabajando en primer lugar y por qué funcionó después de este comando. Lo que creo que significa, anteriormente curl estaba tratando de usar la red ipv6, que en realidad no está configurada. ¿Es o algo más?
Prashant Kumar
Supongo que sí: la conexión se rechazó porque la obtuvo de ipv6 esperado. Esta edición del archivo fuerza ipv4.
Rinzwind
pero, como dijiste curl will connect to a server with IPv6 when a host lookup returns an IPv6 address and fall back to IPv4 if the connection fails, ¿por qué mi sistema acaba de dar un error en lugar de intentar acceder a ipv4 por sí mismo si no encontró el ipv6?
Prashant Kumar
1
.curlrcutiliza nombres de las opciones sin anteponer -o --.
chepner
5

Una convención típica en UNIX es que los programas (generalmente) leen su configuración de inicio desde varios archivos predefinidos. Esto es simplemente una tradición, no algo definido por POSIX o cualquier otro estándar. Un programa típico de UNIX, por ejemplo foobar, leería, en el siguiente orden de precedencia:

~/.foobarrc  ## User specific configuration parameters
/etc/foobarrc  ## Global parameters, depending on taste
               ## `/etc/foobar/*(.conf)' might be chosen too 

Puede haber un retroceso, /usr/share/pero eso no es muy común.

Entonces, curlaquí siguiendo la convención y leyendo su configuración inicial desde ~/.curlrc. Y al hacerlo echo ipv4 >>~/.curlrc, ha agregado la cadena ipv4al archivo ~/.curlrc.

La cadena ipv4tiene un significado especial para curl: curlutilizará IPv4 para la resolución del host. Esto es análogo al uso del argumento -4/ ipv4as curldesde la línea de comandos, pero guardarlo ~/.curlrchace que sea ​​permanente.

Como ha configurado ipv4allí y ahora todo funciona para usted, presumiblemente tiene IPv6 configurado y curlanteriormente estaba usando IPv6 para una resolución de host (exitosa), por lo que no hay respaldo para IPv4. La conexión al sitio estaba fallando porque no todos los sitios tienen sus servidores web configurados para escuchar en direcciones IPv6, por lo que la socket()llamada fallará como podemos ver en este caso.

heemayl
fuente
1
En la práctica, sin embargo, /etc/foobar.confse leería primero, luego ~/.foobarrc, para que este último pudiera anular al primero. Por lo tanto, si /etc/foobar.confcontiene una línea que dice frobnitz=0, y ~/.foobarrctiene frobnitz=1, el último valor prevalece
Monty Harder
@MontyHarder Eso es exactamente lo que quise decir por orden de precedencia ...
heemayl
Sí, orden de precedencia, no orden de lectura.
Monty Harder