-
Notifications
You must be signed in to change notification settings - Fork 93
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
Filter out X11 servers running inside containers to avoid showing bogus "Desktop" tab when X11 isn't available #225
base: master
Are you sure you want to change the base?
Conversation
…ly ever scan for X11 servers running on the host itself. Containerized servers (e.g. Xvfb inside of an LXC container) cannot be accessed by MeshAgent and would thus result in a "Desktop" tab that is non-functional. The control group for the candidate process should provide the necessary information to make this distinction. If the control group is either non-existent or if it is a user-session without any container namespace, then this is a process that belongs to the host. On the other hand, if the agent sees a namespace for a container (e.g. "0::/lxc/XXXX/ns"), it should ignore the process.
what virtualization host are you running? i just want to replicate this before merge |
I use ProxmoxVE as the virtualization host. If you aren't familiar with it, it's essentially a Debian distribution that uses LXC (but not Ubuntu's LXD daemon) to handle containers. In other words, it uses the same low-level containerization framework that is commonly used on Linux these days but puts its own user interface on top. I would expect that you can replicate this behavior with any LXC, LXD, or Incus containerization system, but I haven't verified that myself. So, in the easiest case, just use an Ubuntu system as they ship with LXD by default. If you have difficulty reproducing, please let me know and I'll see what I can do. I then installed Ubuntu/LTS (Jammy 22.04) inside of the container, and I configured Google's Chrome Remote Desktop to give the container a GNOME desktop environment. Finally, I installed MeshAgent outside on the host (I also installed it in the container; but that shouldn't be relevant for this bug). When I connect to the agent that is running on the host, it erroneously picks up the virtualized X server running inside the LXC container. If you just want a quick way of reproducing the bug without having to go to the trouble of installing Google's Chrome Remote Desktop, I believe you could run this command inside the container. It should be good enough to trip up the heuristics in the agent:
Afterwards, restart the agent on the host and see if I picked up our process inside of the container, mistaking it for an X server. N.B.: I haven't actually checked whether that works in order to reproduce the bug, as I no longer have any unpatched agents that exhibit the faulty behavior. But since it's so easy to do, that single-line command would be a good first step to try before going the much more complex route of trying to reproduce a full X environment. Let me know if you are making progress with these instructions or if you need anything else from me. |
ahhh right ok! i dont use LXC i use VMs with my proxmox! |
i cant get it to show the desktop tab at all?
does your proxmox host have VGA/HDMI output or graphics cards? |
Let me try to establish a Google Chat connection with your GMail account. This might be something that is easier to sort out interactively. Expect an incoming chat request shortly. |
I fixed a minor nuisance that I encountered with the agent. Feel free to either pull outright, or edit and apply your own fix. This is a one-liner.
When installing the agent on my virtualization host, I was presented with a "Desktop" tab that never worked. This didn't make much sense, as the host is headless and doesn't even have an X11 server. We should never even see the "Desktop" tab on this system.
Turns out, the mesh agent erroneously detected a program running inside one of my containers and thought it might be an X11 server. Filtering by control group is an easy way to exclude these false positives.
A minor complication is that on modern Linux systems, control groups are used both by the containerization system (e.g. LXC) and for the management of user sessions. So, an X11 server running on the host could either be lacking a control group (if this was a really old system) or it could have a control group that starts with 0::/user.slice/... (if this is modern Linux system using control groups for session management). A regular expression allows us to catch these different options.
On the other hand, a process running inside a container would have something like 0::/lxc/XXXX/ns/ as its control group.