Comment 27 for bug 1743592

I found this thread when trying to simplify automated nginx installation on Ubuntu 20.04. In my case, IPv6 is disabled with ipv6.disable=1, which breaks a fresh nginx installation from proceeding with "nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)". Specifically, apt fails when trying to install nginx, which break the automation workflow.

The workaround that works for me and can be easily automated:

1. Manually create sites-available/default without a "listen [::]:80 default_server;" directive _before_ installing nginx so that the problematic file is not created and the workflow is not broken.
2. Install nginx with apt. Because sites-available/default does not contain the problematic directive, the installation finishes successfully.
3. Delete sites-available/default (and corresponding sites-enabled/default).
4. Proceed with the rest of the configuration.

This workaround is definitely clumsy and I would appreciate if the fresh nginx install did not fail when IPv6 is disabled. Nginx failing to start with the default config when IPv6 is disabled is perfectly fine, however this bug breaks the installation process itself, which is not fine.

Regarding ipv6.disable=1 should not be supported, let me politely disagree with this assessment. RFC6540/IETF BCP177 says that new IP stack implementations must support IPv6, should support 4/6 dual-stack and must not require IPv4 stack for IPv6 operation. It does not require dropping application support for IPv4-only systems at all. IPv4 is not nearly EOL yet.

There are legitimate use cases when IPv6 must be disabled, for example in IPv4-only environments that do not use IPv6, such as in many if not most corporate networks behind the NAT. Disabling unused systems and protocols is a long-standing best practice, both from infosec and operational perspectives and is still required by the infosec policies in many organisations.

Is it feasible to re-open the bug and fix it to the level so that the nginx installation completes successfully on an IPv4-only system and does not fail when nginx is simply unable to start with the default site? The nginx itself unable to start with the default configuration is perfectly fine and expected.