8

I was facing some issue today when trying to install composer with the below command:

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

It was giving me this error:

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

I googled and found this command:

echo ipv4 >> ~/.curlrc

I ran this and it fixed the problem and composer installed just fine.

But I don't know what the above command does, could anyone explain it?

9

What is does is add "ipv4" to the file "curlrc". Example starting with an empty file:

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

Basically it forces curl to use ipv4.


The manual has this to say about it:

IPv6

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. The --ipv4 and --ipv6 options can specify which address to use when both are available. IPv6 addresses can also be specified directly in URLs using the syntax

  • I ran that command only, it worked so I guess it is correct. Just one question, why my composer wasn't working in first place and why it worked after this command. Which I think means, earlier curl was trying to use ipv6 network, which actually is not configured. Is it or something else? – Prashant Kumar May 25 '17 at 12:01
  • I would assume that was it yes: connection refused beciause where you got it from expected ipv6. This edit of the file forces ipv4. – Rinzwind May 25 '17 at 12:03
  • but as you said 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 then why my system just given error instead trying to access ipv4 by itself if it didn't found the ipv6. – Prashant Kumar May 25 '17 at 12:05
  • 1
    .curlrc uses option names without the leading - or --. – chepner May 25 '17 at 12:54
5

A typical convention in UNIX is that programs (usually) read their startup configuration from various predefined files. This is merely a tradition, not anything defined by POSIX or any other standard. A typical UNIX program e.g. foobar would read, in the following order of precedence:

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

There might be a fallback in /usr/share/ but that is not very common.

So, curl here following the convention and reading it's initial configuration from ~/.curlrc. And by doing echo ipv4 >>~/.curlrc, you have appended the string ipv4 to the file ~/.curlrc.

The string ipv4 has a special meaning to curl -- curl will use IPv4 for host resolution then. This is analogous to using -4/ipv4 as curl's argument from command line, but saving to ~/.curlrc makes this permanent.

As you have set ipv4 in there and now everything works for you, presumably you have IPv6 configured, and curl were previously using IPv6 for (successful) host resolution, so no fallback to IPv4. The connection to the site was failing because not all sites have their webservers configured to listen on IPv6 addresses, so the socket() call would fail as we can see in this case.

  • 1
    In practice, however, /etc/foobar.conf would be read first, then ~/.foobarrc, so that the latter could override the former. Thus if /etc/foobar.conf contains a line that says frobnitz=0, and ~/.foobarrc has frobnitz=1, the latter value prevails – Monty Harder May 25 '17 at 15:47
  • @MontyHarder That's exactly what I meant by order of precedence... – heemayl May 25 '17 at 16:09
  • Yes, order of precedence, not order of reading. – Monty Harder May 25 '17 at 17:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.