Trying to set up a reverse VNC installation as described in https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_VNC_Vncconnect, I cannot start it because the installation always starts locally, see the video. The installation runs in a virtual machine that uses the 192.168.122.* network, where the vncviewer runs on the host machine (192.168.122.1). The VNC listens on port 5500, which is correctly set up in the kernel paramater as `install.vncconnect=192.168.122.1:5500`. No errors are visible anywhere, but the installation does not start on the host, but locally in the virtual machine. Reproducible: Always Steps to Reproduce: 1. Follow the procedure mentioned in the above described test. Actual Results: Installation starts locally. Expected Results: Installation should start in a VNC window on the host.
Created attachment 1976870 [details] Video of the procedure
I propose this as a beta blockers based on the following criterion: When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. https://fedoraproject.org/wiki/Basic_Release_Criteria#Installation_interfaces
Uh, it's `inst.vncconnect=`. Not `install.vncconnect=`. You also have to pass `inst.vnc`. Again, if you're investigating the openQA failures, I already did that, and the cause is https://bugzilla.redhat.com/show_bug.cgi?id=2223795 .
Yeah, mea culpa. I used inst.vncconnect= but ommited the inst.vnc. Now, I am using it correctly, but I am still unable to establish the connection: On my host machine, I am using `vncviwere -listen 5500` On the VM, I am using the `inst.vnc inst.vncconnect=192.168.122.1:5500`, but Anaconda reports trying the connection but does not succeed. The 5500 port is opened in Firewall (as is the default). A ping to 192.168.122.1 works just fine inside the VM and the host machine can also be SSHed into. Just the VNC does not catch up. I was not trying to report the openQA failures. I was trying to fill in the holes in the matrices and ran into VNC installation problems.
Please, the typos I have produced in the above comment are not the reason it is not working for me.
well, vncconnect can be a bit tricky to figure out, but it's not broken, it is working in openQA. the test is only failing on the systemd issue, the VNC connection works fine. In the openQA test we actually take down the firewall entirely, I don't recall why, but maybe try that?
Ok, when I switch off firewall entirely, this reverse vnc installation works ok. However, this should not be needed. Please, could someone from Anaconda tell me, which ports should be accessible and opened on the host machine, so that this would work with Firewall still on? Because we will need to update our test description to adapt to the reality.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
OK, I played with this locally, and I think I can guess the problem. You mention you were testing with a VM. Connections between a (default) libvirt VM and the host do not come under the zone that regular connections to the system use - the zone the regular network interface for the system is in, called "FedoraWorkstation" on a Workstation install. A default libvirt VM will connect to the virbr0 interface on the host (if you check `ip addr`, you'll probably see it's virbr0 that has the IP address 192.168.122.1), which is in the 'libvirt' zone. The 'libvirt' zone does *not* have port 5500 open by default. If you use firewall-cmd or firewall-config to open port 5500 in the libvirt zone, I bet it will work.
-4 in https://pagure.io/fedora-qa/blocker-review/issue/1170 , marking rejected. Please re-propose if I'm wrong about the firewall config and it seems there's really a bug to be fixed here that needs to block Beta.
Based on what little I could find, I can not see why this would not work. Primarily I'd second AdamW's note about opening the port on the right interface. ---- If you add an actual port to the option, as you did, it should be used as-is. The code in anaconda is clear that it uses the same port number as passed in the option: > pyanaconda/vnc.py:175 > vncconfigcommand = [self.root + "/usr/bin/vncconfig", "-display", ":%s" % constants.X_DISPLAY_NUMBER, "-connect", hostarg] (X_DISPLAY_NUMBER = 1) Anaconda docs state that the default vnc port is 5900, which contradicts the Xvnc manpage, it should be 5900 + display number. However an explicit value should be used exactly as specified. The manpage does not say that value is incremented. (I think avoiding the +1 is why you have the port specified explicitly in the test.) If you wish to eliminate the possibility that the port is parsed incorrectly from the option, just go for the default 5900 explicitly. If you wish to eliminate the possibility that the port is incremented to 5501 or 5901, try opening that instead.
Hello VNC, can you please advise on a correct firewall setup? tl;dr: - In a guest VM, installer runs /usr/bin/vncconfig -display :1 -connect <ip>:<port> - On the host, human runs vncviewer -listen <port> - Is the port numbering correct? - What should be opened in the firewall? Relevant details likely in comment 0, comment 7, comment 9.
I mean, I don't think we need to worry too much. I tested myself and was able to get it to work, it's not that difficult. I'm pretty sure Lukas just got the firewall config wrong. Lukas, can you try this again and see whether you still think there's a problem?
Yeah, I was able to set it up correctly in the end.