Closed Xenorf closed 2 months ago
Hey there, thank you for your reviews. I tried to implement your remarks. Don't hesitate to make more comments if you wish.
Fyi, when using macOS with XQuartz, the DISPLAY env var looks like this
/private/tmp/com.apple.launchd.FU1rU095fG/org.xquartz:0
Thank you for this information @ShutdownRepo.
Is it also like this when you SSH to the macOS environment with a command like ssh -X
?
Because the macOS DISPLAY
variable is so specific and I cannot test it, I made a change. If the host is a macOS it does not support x11 forwarding. But at least it doesn't break the previous implementation with the xhost
ACLs.
I still think this PR is valuable for the project because in your documentation you recommend to use Linux as a host to avoid Docker limitations. Here Linux distributions are fully supported and Windows might be with very few tweaks.
Thank you @Xenorf for this update ! I'll merge it in dev branch for user to test etc.
Description
This PR aims to bring support for X11 forwarding when the host is accessed by SSH from a remote location running a X server.
On top of xhost ACLs I created a secret sharing mechanism between the host and the Exegol container.
Related issues
Some people on the discord server were asking about forwarding the GUI of Exegol containers to a remote location.
Point of attention
Tested setups
I tried this solution with only 2 setups:
The following setups are yet to be tested:
Library added
I imported the subprocess library to get the output of a command. An alternative would be to create a file in the container workspace to pass the xauth cookie with
os.system()
.X11UseLocalhost limitation
The
X11UseLocalhost
directive has its importance. When it is set to "yes", the X11 server will be listening on the loopback interface only. This causes a limitation, when the network interface of an Exegol container is bridged, it won't be able to forward its GUI to the remote server.xhost ACLs
xhost ACLs need to be applied on the machine running the X server. Because it is no longer the host when accessing remotely, it is not needed. Moreover, the xhost commands cannot be executed from a SSH shell.