Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable IPv6 support on uwsgi #123

Merged
merged 3 commits into from
Sep 1, 2024
Merged

Conversation

jdeluyck
Copy link
Contributor

@jdeluyck jdeluyck commented Aug 31, 2024

linuxserver.io

Closes #122


  • I have read the contributing guideline and understand that I have made the correct modifications

Description:

Enable IPV6 on uwsgi

Benefits of this PR and context:

Allows the container to be accessed over ipv6 inside the docker network.

How Has This Been Tested?

Built the container, tested it on my local installation.

Source / References:

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for opening this pull request! Be sure to follow the pull request template!

@Roxedus
Copy link
Member

Roxedus commented Aug 31, 2024

How does uwsgi handle this on hosts with ipv6 disabled in the kernel?

@thespad
Copy link
Member

thespad commented Aug 31, 2024

It breaks, as with anything using dual IPv4/IPv6 sockets. But in a choice between supporting IPv6 and supporting setups with IPv6 intentionally disabled, we should probably favour the former. Also it doesn't appear possible to bind the smtpd service to IPv6 in either case.

This needs adding to the readme changelog; it's a significant change.

@LinuxServer-CI
Copy link
Contributor

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-171f6b9047f130722a6cfece453a3ca851eb8dff-pr-123/index.html
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-171f6b9047f130722a6cfece453a3ca851eb8dff-pr-123/shellcheck-result.xml

Tag Passed
amd64-v3.5.2-pkg-183ee8f1-dev-171f6b9047f130722a6cfece453a3ca851eb8dff-pr-123
arm64v8-v3.5.2-pkg-183ee8f1-dev-171f6b9047f130722a6cfece453a3ca851eb8dff-pr-123

@jdeluyck
Copy link
Contributor Author

On a non-ipv6 network, everything works as it was:

Create ipv4 only test network

podman network create test

Executing the homebuild container

podman run -d \
  --name=healthchecks \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Europe/Brussels \
  -e SITE_ROOT="http://localhost:8000" \
  -e SITE_NAME= \
  -e SUPERUSER_EMAIL= \
  -e SUPERUSER_PASSWORD= \
  -p 8000:8000 --network=test \
  4ea49146d2c6

Inspecting the test network

podman network inspect test 
[
     {
          "name": "test",
          "id": "6f457fad19bac09590a1e200213278a49ebc10d897d1777f3735416df07233e3",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2024-08-31T15:52:00.353622718+02:00",
          "subnets": [
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "ipam_options": {
               "driver": "host-local"
          },
          "containers": {
               "5df785fa3f74d48d414dd85c2ab79cc599e09785724eb89cd8f06f3a7c8bdcb2": {
                    "name": "healthchecks",
                    "interfaces": {
                         "eth0": {
                              "subnets": [
                                   {
                                        "ipnet": "10.89.0.2/24",
                                        "gateway": "10.89.0.1"
                                   }
                              ],
                              "mac_address": "26:c4:4d:02:1f:6b"
                         }
                    }
               }
          }
     }
]

As you can see, only ipv4.

Checking inside the container

$ podman exec -ti healthchecks /bin/bash 

root@5df785fa3f74:/# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:42776         127.0.0.1:2525          TIME_WAIT   
tcp        0      0 :::8000                 :::*                    LISTEN      
tcp        0      0 ::1:48926               ::1:8000                TIME_WAIT   

root@5df785fa3f74:/# cd /app/healthchecks/
root@5df785fa3f74:/app/healthchecks# cat uwsgi.ini 
[uwsgi]
http-socket = [::]:8000
...

Starting a test nginx container on the same network

$ podman run -d nginx --network test
$ podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS        PORTS                             NAMES
5df785fa3f74  4ea49146d2c6                                          5 minutes ago  Up 5 minutes  0.0.0.0:8000->8000/tcp, 8000/tcp  healthchecks
bfba2da729ef  docker.io/library/nginx:latest  nginx -g daemon o...  3 seconds ago  Up 3 seconds  80/tcp                            tender_mclean

Connecting over the bridge network to the other container on ipv4

$ podman exec -ti tender_mclean /bin/bash

root@bfba2da729ef:/# curl -vvv 10.89.0.2:8000
*   Trying 10.89.0.2:8000...
* Connected to 10.89.0.2 (10.89.0.2) port 8000 (#0)
> GET / HTTP/1.1
> Host: 10.89.0.2:8000
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 302 Found
< Content-Type: text/html; charset=utf-8
< Location: /accounts/login/
< X-Frame-Options: DENY
< Content-Length: 0
< Vary: Cookie
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin
< 
* Connection #0 to host 10.89.0.2 left intact

@Roxedus
Copy link
Member

Roxedus commented Aug 31, 2024

podman network create test does not behave the same as if a system runs with ipv6 disabled in the kernel

@jdeluyck
Copy link
Contributor Author

People still do that?

I'll see to spin up a machine with ipv6 disabled but that'll take a bit.

@thespad
Copy link
Member

thespad commented Aug 31, 2024

With alarming regularity

@jdeluyck
Copy link
Contributor Author

Tested on a host without ipv6 enabled - it breaks spectacularly as stated.
I've updated the readme, I don't know if an IPV6 warning needs to be put anywhere?

@LinuxServer-CI
Copy link
Contributor

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-86e401e76cd07182b6f2c2551ceb69c0dc3b5b2d-pr-123/index.html
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-86e401e76cd07182b6f2c2551ceb69c0dc3b5b2d-pr-123/shellcheck-result.xml

Tag Passed
amd64-v3.5.2-pkg-183ee8f1-dev-86e401e76cd07182b6f2c2551ceb69c0dc3b5b2d-pr-123
arm64v8-v3.5.2-pkg-183ee8f1-dev-86e401e76cd07182b6f2c2551ceb69c0dc3b5b2d-pr-123

@thespad
Copy link
Member

thespad commented Sep 1, 2024

No, don't explicitly mention it breaking in the changelog; we'll see if anyone is actually affected and if there are sufficient numbers we may need to add a conditional fudge for them, but we try and avoid it when possible.

@LinuxServer-CI
Copy link
Contributor

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-40aba11df05e0bee2aa84ac2d5512398fca8c104-pr-123/index.html
https://ci-tests.linuxserver.io/lspipepr/healthchecks/v3.5.2-pkg-183ee8f1-dev-40aba11df05e0bee2aa84ac2d5512398fca8c104-pr-123/shellcheck-result.xml

Tag Passed
amd64-v3.5.2-pkg-183ee8f1-dev-40aba11df05e0bee2aa84ac2d5512398fca8c104-pr-123
arm64v8-v3.5.2-pkg-183ee8f1-dev-40aba11df05e0bee2aa84ac2d5512398fca8c104-pr-123

@thespad thespad merged commit 253322b into linuxserver:master Sep 1, 2024
3 checks passed
@alxrdn
Copy link

alxrdn commented Sep 23, 2024

Hello
I can confirm that for some reasons, there are configurations with ipv6 disabled.
This change made our healthcheck instance silently break for several weeks until we realized we had no more alerts...
Then it took us some research before understanding the Address family not supported by protocol [core/socket.c line 82] error was due to an upgrade in the linuxserver image...
Is it possible / how can we tell uwsgi to either not try to bind ipv6 or at least to fallback to ipv4 only?

edit: I tried to pass env var UWSGI_HTTP_SOCKET=:8000 from the docker-compose file, this didn't work.
It looks like it did bound to ipv4 but then still fails as is it is still also trying to bind to ipv6:

uwsgi socket 0 bound to TCP address :8000 fd 3
socket(): Address family not supported by protocol [core/socket.c line 82]

@alxrdn
Copy link

alxrdn commented Nov 4, 2024

For those who would face the same issue and since nobody answered here, the only solution until now is to manually override /defaults/uwsgi.ini and mount it as a docker volume...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

[BUG] uwsgi doesn't listen on ipv6
5 participants