O que "echo ipv4 >> ~ / .curlrc" faz?

Eu estava enfrentando algum problema hoje ao tentar instalar o compositor com o comando abaixo:

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

Ele estava me dando este erro:

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

Eu pesquisei e encontrei este comando :

echo ipv4 >> ~/.curlrc

Eu corri isso e ele corrigiu o problema e o compositor foi instalado corretamente.

Mas eu não sei o que o comando acima faz, alguém poderia explicar isso?

command-line ip curl

— Prashant Kumar
fonte

@Melebius Link adicionado :)

— Prashant Kumar

Respostas:

O que faz é adicionar "ipv4" ao arquivo "curlrc". Exemplo começando com um arquivo vazio:

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

Basicamente, força o curl a usar o ipv4.

O manual tem a dizer sobre isso:

IPv6

O curl se conectará a um servidor com IPv6 quando uma pesquisa de host retornar um endereço IPv6 e voltar ao IPv4 se a conexão falhar. As opções --ipv4e --ipv6podem especificar qual endereço usar quando os dois estiverem disponíveis. Os endereços IPv6 também podem ser especificados diretamente em URLs usando a sintaxe

— Rinzwind
fonte

Eu executei esse comando apenas, funcionou, então acho que está correto. Apenas uma pergunta: por que meu compositor não estava trabalhando em primeiro lugar e por que funcionou após esse comando. O que eu acho que significa, o curl anterior estava tentando usar a rede ipv6, que na verdade não está configurada. É ou algo mais?

— Prashant Kumar #

Eu diria que sim: a conexão foi recusada porque de onde você tirou o esperado do ipv6. Esta edição do arquivo força o ipv4.

— Rinzwind

mas como você disse

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 que meu sistema apenas deu erro ao tentar acessar o ipv4 sozinho, se não encontrou o ipv6.

— Prashant Kumar

.curlrcusa nomes de opções sem o primeiro -ou --.

— Chepner # 25/17

Uma convenção típica no UNIX é que os programas (geralmente) leem sua configuração de inicialização de vários arquivos predefinidos. Isso é apenas uma tradição, não nada definido pelo POSIX ou qualquer outro padrão. Um programa UNIX típico, por exemplo, foobarseria lido, na seguinte ordem de precedência:

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

Pode haver um retorno, /usr/share/mas isso não é muito comum.

Então, curlaqui , seguindo a convenção e lendo sua configuração inicial ~/.curlrc. E, ao fazer isso echo ipv4 >>~/.curlrc, você anexou a string ipv4ao arquivo ~/.curlrc.

A string ipv4tem um significado especial para curl- curlusará o IPv4 para a resolução do host. Isto é análogo a usar -4/ ipv4como curlargumento de linha de comando, mas salvando a ~/.curlrctorna este permanentes.

Como você definiu ipv4lá e agora tudo funciona para você, presumivelmente você tem o IPv6 configurado e curlestava usando o IPv6 anteriormente para a resolução (bem-sucedida) do host, portanto, não há substituto para o IPv4. A conexão com o site estava falhando porque nem todos os sites têm seus servidores da Web configurados para escutar nos endereços IPv6; portanto, a socket()chamada falharia como podemos ver neste caso.

— heemail
fonte

Na prática, porém, /etc/foobar.confseria lido primeiro, então ~/.foobarrc, para que o último pudesse substituir o anterior. Assim, se /etc/foobar.confcontém uma linha que diz frobnitz=0, e ~/.foobarrctem frobnitz=1, prevalece o valor últimos

— Monty mais dura

@MontyHarder Isso é exatamente o que eu quis dizer com ordem de precedência ...

— heemayl

Sim, ordem de precedência, não ordem de leitura.

— Monty Harder