IPv6 related issue in configurable-http-proxy

JupyterHub Zero to JupyterHub on Kubernetes
1

Since I upgraded to a zero2jupyterhub (actually binderhub) release containing this PR:

I get:

08:27:19.388 [ConfigProxy] info: Adding route / -> http://hub:8081
08:27:19.398 [ConfigProxy] info: Proxying http://:::8000 to http://hub:8081
08:27:19.399 [ConfigProxy] info: Proxy API at http://:::8001/api/routes
08:27:19.409 [ConfigProxy] error: Uncaught Exception: listen EAFNOSUPPORT: address family not supported :::8000
08:27:19.409 [ConfigProxy] error: Error: listen EAFNOSUPPORT: address family not supported :::8000
    at Server.setupListenHandle [as _listen2] (net.js:1300:21)
    at listenInCluster (net.js:1365:12)
    at doListen (net.js:1502:7)
    at processTicksAndRejections (internal/process/task_queues.js:85:21)
08:27:19.410 [ConfigProxy] error: Uncaught Exception: listen EAFNOSUPPORT: address family not supported :::8001
08:27:19.410 [ConfigProxy] error: Error: listen EAFNOSUPPORT: address family not supported :::8001
    at Server.setupListenHandle [as _listen2] (net.js:1300:21)
    at listenInCluster (net.js:1365:12)
    at doListen (net.js:1502:7)
    at processTicksAndRejections (internal/process/task_queues.js:85:21)
08:27:19.411 [ConfigProxy] info: Route added / -> http://hub:8081

@manics suggested, that I should try [square brackets].
But this seems to be hard coded in the helm chart template:
See:

1 Like
2

Hi @g-braeunlich,

as the original author of this PR, I might be to blame for this.

As mentioned by @manics in the PR, it might be caused by the missing square brackets around the::.
But I find it a bit strange that this issue only arises now.

Can you please verify that your kernel supports IPv6?
(https://www.golinuxcloud.com/linux-check-ipv6-enabled/)

Also, some more details about your setup would be benefitial for debugging (OS, Distro, Config File, …).

Cheers

3

Hi @stv0g
Thanks for your answer!
We run an own k8s cluster with disabled ipv6 support.
Is zero2jupyterhub requiring ipv6 support as of now?

4

No, you can continue to use IPv4 in your cluster. However, your kernel might require IPv6 support.

Can you please check if it is supported (see link above) and provide the missing details of your setup?

Cheers

5

OK. So here some more details:

It is a 3 nodes cluster.
All nodes are

LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	RedHatEnterpriseServer
Description:	Red Hat Enterprise Linux Server release 7.8 (Maipo)
Release:	7.8
Codename:	Maipo

Which config files do you want?
We have a lot of things configured, which maybe are not relevant (we are basically running this helm chart with own modifications: GitHub - gesiscss/persistent_binderhub: A Helm chart repo to install persistent BinderHub)

I guess IPv6 is disabled in the kernel, but I will make sure

6

We have enabled IPV6 support in the nodes kernels:

CONFIG_IPV6=y

But

$ cat /sys/module/ipv6/parameters/disable
1
7

@stv0g So far it is not clear if we are able to change our environment.
Do you think, it would make sense to make it configurable to use IPV4?

8

Hi @g-braeunlich,

in fact it is using IPv4. It just also requires and IPv6 capable kernel.
Can you give any insights why IPv6 is disabled in you environment?

I would say that usually we can assume that most systems should have it activated.

Cheers,
Steffen

9

The only insight I can give you atm:
Our cluster lives in a rather conservative university environment.
The only answer I got from the sysadmins so far was, that this would not be that trivial.
Waiting since then for an answer why this is so difficult.

10

Hey Steffen
No updates from the side of our sysadmins. Honestly I have no idea why this should be that difficult (maybe they have lots of other high priority tasks).

I would say that usually we can assume that most systems should have it activated.

So you wont care about the few clusters out there who dont have it activated?
In my view it seem like a very small change.

11

@stv0g we just hit the same exact issue on our Kubernetes cluster, which has IPv4 disabled on the nodes. Due to standard security practices, things that are not used are disabled to reduce any attack surface. I completely understand the need to support dual-stack, but it really shouldn’t come at the expense of IPv4 only users!

12

@alex-vmw Maybe, you already found a solution to your issue.
If not: this is what I currently do, to work around:
I am appending --post-renderer ipv6-patch.sh to helm upgrade / helm install.
Content of ipv6-patch.sh:

#!/bin/bash

sed -e "s/-ip=::/-ip=0.0.0.0/g"
13

Thanks @g-braeunlich. We have just switched to using a local helm chart and backed out the check-in that @stv0g did.