Description of problem: Clean install of F33 snapshot from 10/13/20 on a honeycomb (NXP 16 core aarch64/A72). Initial login says:
"web console: https://localhost:9090/ or https://192.168.0.127:9090/"
The latter doesn't work because the cockpit.socket appears to only be binding ipv6.
[root@mammon-honey-f33 ~]# ip addr |grep inet
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
inet 192.168.0.127/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
inet6 fe80::250:b6ff:feea:93b7/64 scope link noprefixroute
[root@mammon-honey-f33 ~]# netstat -a |grep websm
tcp6 0 0 [::]:websm [::]:* LISTEN
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1. Install F33 Server edition.
2. [root@mammon-honey-f33 ~]# wget https://[::1]:9090
--2020-10-14 17:02:00-- https://[::1]:9090/
Connecting to [::1]:9090... connected.
ERROR: The certificate of ‘::1’ is not trusted.
ERROR: The certificate of ‘::1’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘::1’
3. [root@mammon-honey-f33 ~]# wget https://192.168.0.1:9090
--2020-10-14 17:02:20-- https://192.168.0.1:9090/
Connecting to 192.168.0.1:9090... failed: Connection refused.
The second case connects.
Looks like this is probably a systemd issue, but I don't see the systemd flags in any of the unit files to only bind ipv6..
This might be useful:
[root@mammon-honey-f33 etc]# cat /proc/sys/net/ipv6/bindv6only
[root@mammon-honey-f33 etc]# systemctl status cockpit.socket |grep List
Listen: [::]:9090 (Stream)
There might be something wrong with the firewall. A default install uses firewalld. Do you see cockpit in `firewall-cmd --list-services`? For me, I can't connect with either IPv4 or IPv6 if it's disabled, and after `firewall-cmd --add-service cockpit` I can connect with both 4 and 6.
Does connecting to https://127.0.0.1:9090 work? That's the equivalent of ::1. Your address is one from an external interface.
Can you try after "systemctl stop firewalld"? (Don't forget to re-enable it afterwards).
Next step would be to peel off the systemd activation layer:
systemctl stop cockpit.socket cockpit
and try the absolutely simplest case:
su -s /bin/sh -c '/usr/libexec/cockpit-ws --no-tls' cockpit-wsinstance
Does any of that work?
Ah, yah realized I was using the ipv4 addr above rather than the ipv4 loopback. Yes the loopback works, so its not strictly ipv4.
Turns out it was a combination of firewalling (not just the fedora's) and a bit of fat fingering IP's as seen above.
I'm going to kill this because, I thought it was some kind of socket binding problem and it was 99% PEBCAK.
Thanks, and sorry for the noise.