Container commit doesn't support IPv6

[runcom]

Describe the bug
when serving the ostree container commit ipv6 should be supported. Likely the configuration doesn't support that

Environment

• latest
• latest

To Reproduce
Steps to reproduce the behavior:

• serve the container commit, should be available over ipv6 but it's not

Expected behavior
serving the container should be available over ipv6

Additional context
haven't fully tested the scenario, reporting the bug/issue however

cc @mrguitar

[mrguitar]

Thanks for opening this. Just to clarify we need this in the edge-container image type.

It looks like the upstream image solved this here: immich-app/immich#1577 .....but I didn't try it, nor do an extensive search. :)

[miabbott]

I think we are going to need some more details; I'm not able to reproduce this with two VMs on the same IPv6 subnet. But I'm not that great with IPv6, so please point out the error of my ways.

Given the following network config in libvirt:

<network connections='2'>
  <name>default</name>
  <uuid>ea7cacd9-e19a-4a3c-8a09-8c8dfe05a731</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:7c:de:7d'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
  <ip family='ipv6' address='dead:beef:ca2:2::1' prefix='64'>
    <dhcp>
      <range start='dead:beef:ca2:2:1::10' end='dead:beef:ca2:2:1::ff'/>
    </dhcp>
  </ip>
</network>

I booted two RHEL VMs and confirmed they had IPv6 addresses assigned and that I could ping6 them.

VM 1:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:9a:92:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.226/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0
       valid_lft 3374sec preferred_lft 3374sec
    inet6 dead:beef:ca2:2:1::fb/128 scope global dynamic noprefixroute 
       valid_lft 81036sec preferred_lft 81036sec
    inet6 fe80::5054:ff:fe9a:9211/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

VM 2:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:7d:8f:80 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.139/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0
       valid_lft 2212sec preferred_lft 2212sec
    inet6 dead:beef:ca2:2:1::4c/128 scope global dynamic noprefixroute 
       valid_lft 81551sec preferred_lft 81551sec
    inet6 fe80::5054:ff:fe7d:8f80/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

ping6 from VM2 to VM1:

$ ping6 -c3 dead:beef:ca2:2:1::fb
PING dead:beef:ca2:2:1::fb(dead:beef:ca2:2:1::fb) 56 data bytes
64 bytes from dead:beef:ca2:2:1::fb: icmp_seq=1 ttl=64 time=0.706 ms
64 bytes from dead:beef:ca2:2:1::fb: icmp_seq=2 ttl=64 time=0.512 ms
64 bytes from dead:beef:ca2:2:1::fb: icmp_seq=3 ttl=64 time=0.418 ms

--- dead:beef:ca2:2:1::fb ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2062ms
rtt min/avg/max/mdev = 0.418/0.545/0.706/0.119 ms

I started small and just confirmed that I could use http.server from python to listen on IPv6 from VM1 and curl from VM2:

$ sudo firewall-cmd --add-port 9001/tcp                                                                                                                                                                                                                                                          
success
$ python3 -m http.server --bind :: 9001                                                                                                                                                                                                                                                          
Serving HTTP on :: port 9001 (http://[::]:9001/) ...

From VM2; note that the /repo/config path is not accessible because it is not being served in this example:

$ curl -I "http://[dead:beef:ca2:2:1::fb]:9001"
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.9.16
Date: Thu, 01 Jun 2023 20:30:51 GMT
Content-type: text/html; charset=utf-8
Content-Length: 1008

$ curl -I "http://[dead:beef:ca2:2:1::fb]:9001/repo/config"
HTTP/1.0 404 File not found
Server: SimpleHTTP/0.6 Python/3.9.16
Date: Thu, 01 Jun 2023 20:30:55 GMT
Connection: close
Content-Type: text/html;charset=utf-8
Content-Length: 469

With basic connectivity confirmed, I started the edge-container on VM1 with no modifications to the config and was able to curl it from VM2:

$ podman run --rm -it -p 9001:8080 localhost/edge-container-92:latest

From VM2; note that the server is reported as nginx and the /repo/config path is accessible as expected:

$ curl -I "http://[dead:beef:ca2:2:1::fb]:9001"
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Thu, 01 Jun 2023 20:31:59 GMT
Content-Type: text/html
Content-Length: 5909
Last-Modified: Mon, 09 Aug 2021 11:43:42 GMT
Connection: keep-alive
ETag: "611114ee-1715"
Accept-Ranges: bytes

$ curl -I "http://[dead:beef:ca2:2:1::fb]:9001/repo/config"
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Thu, 01 Jun 2023 20:32:04 GMT
Content-Type: text/plain
Content-Length: 38
Last-Modified: Wed, 10 May 2023 17:53:51 GMT
Connection: keep-alive
ETag: "645bda2f-26"
Accept-Ranges: bytes