So IMHO there is 2 ways to fix this:
(1) - We remove the ipv6 listen from the vhost (just like
Centos/Upstream does atm)
# nginx.vh.default.conf
server {
listen 80;
server_name localhost;
So as upstream nginx:
https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L36
This won't introduce behaviour change for those who upgrade nginx, but
it will introduce a behaviour change for those used to have ipv6 listen
in the default vhost at fresh package installation.
But IMHO, the default vhost is a starting point/example, that the admin
will anyway have to modify manually or via some orchestration tool
(ansible, chef, puppet, ...)
So this will only imply that the admin will need to update their recipe
to add the ipv6 listen in the vhost. I don't see any big blocker here.
(2) We implement a ipv6 detection as describe in the debian bug and
provide a noipv6 vhost and/or a ipv6 vhost depending if ipv6 is
[en|dis]abled on the system. But for me, that seems hacky.
I have a preference for scenario #1.
I have proposed both scenarios to debian, let's see what they say. In
the absence of response from their part, I'll have SRU scenario #1 into
Ubuntu.
I'll give debian maintainer team a week or so before.
- Eric
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1743592
Title:
NGINX fails to start/install/upgrade if IPv6 is completely disabled.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
