"NameError: name 'httpd' is not defined" (w/ IPv6 partially disabled)

[nullproem]

OS/terminal used:
$ uname -oivrs
Returns: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) unknown GNU/Linux

GNU Emacs 25.1 "ansi-term"
$ echo "$TERM"
Returns: eterm-color

Note, I have tried both xterm and urxvt as well with the same result.

Error message returned when fish_config is invoked:
[Errno 97] Address family not supported by protocol
Web config started at 'file:///home/redacted/.cache/fish/web_config-VJB6UM.html'. Hit enter to stop.
Traceback (most recent call last):
File "/usr/share/fish/tools/web_config/webconfig.py", line 1135, in <module>
ready_read = select.select([sys.stdin.fileno(), httpd.fileno()], [], [])
NameError: name 'httpd' is not defined

This bug seems to be very similar to issue #3530 which was ostensibly fixed in 2.5.0. However, for me the ability to use fish_config has regressed in the transition from fish 2.4.0 to 2.5.0; 2.4.0 being the version I was last able to use the web-based configuration.

Relevant system information:
in /etc/default/grub I have ipv6 disabled (but not completely):
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet"

$ python -c "from __future__ import print_function; import platform, socket; print(platform.python_version(), '-', socket.has_ipv6);"
Returns: 2.7.9 - True

$ fish --version
Returns: fish, version 2.5.0

$ getent hosts localhost
Returns: ::1 localhost ip6-localhost ip6-loopback

$ sh -c 'env HOME=$(mktemp -d) fish'
Returns the same errorful output as above with only the web_config cache file name changing.

[faho]

I can reproduce this, and I don't get why python says ipv6 is available when it is not.

However, I can only recommend that you don't disable ipv6 this way (if you have to at all) since it will cause more issues than just this one (though this is the only one you are likely to have with fish). See https://wiki.archlinux.org/index.php/IPv6#Disable_IPv6. Use ipv6.disable_ipv6=1 instead.

Also I'm not sure why Debian doesn't ship newer minor releases of python 2.7 - 2.7.13 is available, 2.7.9 is 1.5 years old.

The fix for this is TBD - I don't quite like doing the old "try to use the socket, if it doesn't fall back" thing.

[krader1961]

@faho, Are you going to fix this? Because I'm not going to invest any effort to do so since my reaction is "Meh!". I do agree that if someone can make Python IPv6 detection work reliably we should employ that approach. But people should not be disabling IPv6 on their systems at this point in time unless they are willing to live with this type of issue. I don't think fixing this should be a priority as implied by adding this to the 2.6.0 milestone. If people are disabling IPv6 support in ways that break the Python socket.has_ipv6 check they should complain to the Python devs. I don't think it is our responsibility to deal with it.

[nullproem]

@krader1961 IPv6 shouldn't be required for localhost connections, period. The 127.x.x.x range of IP addresses are not going away just because IPv6 has a comparable address; the idea is that the 192.168.x.x and 127.x.x.x ranges will be preserved alongside IPv6 implementation for personal usage, so the idea that IPv4 shouldn't be supported at all is an overreach honestly. This becomes particularly apparent when you consider the pernicious privacy implications with IPv6 versus IPv4 (a la VPN usage), but I digress.

Why not just support IPv4 as well?

Oh, and @faho, I changed the Grub option to the one you specified, thanks.

[faho]

@faho, Are you going to fix this?

If I can figure out a proper solution, yes. So far I haven't had any luck with that.

If people are disabling IPv6 support in ways that break the Python socket.has_ipv6 check they should complain to the Python devs.

It seems that check is essentially worthless since it seems to boil down to "was this python compiled with ipv6 support" which should almost always be true nowadays.

Why not just support IPv4 as well?

We try to, that's why the check exists. Only it's not working. One thing I've been thinking about is going back and always using ipv4 - is anyone disabling that?

I don't think fixing this should be a priority as implied by adding this to the 2.6.0 milestone.

What I was trying to imply by that is that I'd want to take a look before 2.6.0, and change the milestone if it's not going to happen.

[krader1961]

IPv6 shouldn't be required for localhost connections, period.

The main reason to try IPv6 is because people have requested the ability to run the browser on a different machine than the one they ran fish_config. Primarily to make it easy to configure fish on headless servers. In which case we should use IPv6 if the system has such an address otherwise fallback to IPv4.

@faho, it is very unlikely that anyone is disabling IPv4 outside of very unusual scenarios such as someone testing what happens when only IPv6 is available. And I don't think we need to go out of our way to support that. But by the same token in 2017 I don't think we should be going out of our way to support people disabling IPv6 support either. If we can do so in a straightforward, robust, manner we should do so. Otherwise I'm inclined to say, sorry, but IPv6 is no longer a paper standard it's a de facto reality that needs to be supported.

Regarding the "pernicious privacy implications with IPv6" (see Wikipedia) I do not find that a compelling argument for complicating fish. If that's a concern for someone they can live without the ability to configure fish via a web browser. And I say that as someone who regularly reads what Bruce Schneir and other experts have to say about computer security. If I'm that paranoid then I can reasonably expect some things to break or be harder to use as a result of my security choices.

[nullproem]

@krader1961 That wikipedia article does not sufficently describe the issues concerning IPv6 which I made a passing comment on. You'll need to dig deeper, but I'd rather not continue that discussion here.

Honestly, I wouldn't mind so much that I couldn't use the fish webserver for configuration if it weren't the only recommended way to modify particular settings, leading to situations such as this:

The main reason to try IPv6 is because people have requested the ability to run the browser on a different machine than the one they ran fish_config.

Doesn't it seem a bit...odd to have to do this? For a shell?

Anyways, the main reason for posting this comment is for notifying @faho and @krader1961 that the issue with the webserver not starting was fixed with the Grub option being changed from ipv6.disable=1 to ipv6.disable_ipv6=1, # update-grub, and $ reboot. Everything seems to be fine now, so the issue could be closed.

Thanks!