I was browsing here, and came across Ulfnic’s Terminal Tuesday thread. And while I don’t understand a lot of it, it got me thinking. I have a headless server, but it rips my CDs and DVDs for use with Jellyfin. I had been using the commandline, but couldn’t get the rip I wanted.
Turns out, if you run
ssh -x you can then run programs like
handbrake-gtk FROM your server but ON your local machine! This helped me try several different audio/video options to get Handbrake right, and let me use Picard to quickly relabel/rename a few CDs that all got uploaded as Title1.mp3 instead of the right name when I ripped it.
Ah, I’ve never tried this before. Cool. The server has to have X11 running I presume.
Never knew you could do that. Thank you for the info. This will come in very handy!
I’ve no idea. I did some searching to see how to tell if X is running, and it looks like it isn’t. For instance
$ ps -e | grep x
319 ? 00:00:00 ext4-rsv-conver
986 ? 00:00:00 lxcfs
I do have
X11 Forwarding yes in
/etc/ssh/sshd_config and looking at this post it seems like that is all you need. If I run
sudo apt-get install xorg it does find a lot of X packages and dependencies to install. So based on that and the previous command, it seems like it can somehow pass X11 instructions onto my laptop since it’s running X.
Super cool! Thanks for checking that out.
I’ve started using this technique in the last couple days. It’s brilliant. From my laptop in my kitchen I can view all the virtual machines that I have on my workstation in the basement.
I’m using a Core2 Duo machine and it was getting crushed by running a VNC and a Zoom call at the same time.
SSH -X seems to use practically no CPU so a Zoom call on top should be easily manageable. It has the added bonus of managing windows as if they were completely native which is less confusing and more responsive than a VNC virtual desktop.
Glad you enjoy it! It seems to use the host resources, and basically none of the client’s. Let me know how the Zoom bit works, that would open up more use cases for me too!
Usually X is running as Xorg
$ ps ax | grep Xorg
What’s going on here is that an Xorg desktop is a client-server situation. The X server gives you the graphics mode, and input methods (keyboard, mouse). The programs we run are X clients. In order to display a window, the client connects to the server, and tells the server how to draw the window using a communication protocol. This can be done over unix sockets, or a network protocol. X Windows has always worked this way. The server and client have never needed to be on the same computer, as you’ve seen.
SSH simply makes a tunnel and makes the remote computer think that a display server is running there. When you run a program, it is running on the remote system, using the resources of that system, and telling the X server how to draw its windows, just like always. This is why resource utilization is low on your local machine. It’s just getting a string of instructions on how to draw windows from the client on the remote machine, and sending inputs (keyboard and mouse) to the client. Doesn’t take a lot of local processing power to do that.
You can even do a full-screen desktop session this way (using XNest and XDMCP). No VNC required, although, VNC is a faster option than XDMCP and X11 forwarding.
You say that it manages as if they were completely native. Well, they are completely native.
Thanks for explaining how this works!