My (new) simple system to open URLs on my desktop from remote Linux machines

September 12, 2023

I have a long standing setup where I read my email on one of our Linux login servers, instead of on my desktop. Email can include URLs that I want to open, so I need some way of opening these URLs in my desktop browser. For a long time this has been through one of two options; either I forwarded X over SSH and used Firefox's X-based remote control, or I was operating purely with text and selected the URLs in the terminal to use with my tools to open URLs in various browsers.

(Many local terminal programs can recognize URLs in text and open them for you, but I still use xterm, which doesn't try to do this.)

Firefox has been moving away from its X11 based remote control for some time, although it's not dead yet. However, recently opening URLs using the X based protocol over my DSL link got much slower (probably because of increased latency) so I decided I was going to hack together something very crude as a substitute. The result is a very simple 'pass URLs to the remote end' pair of programs that run over a SSH connection.

The 'client' end runs on the remote server. It listens on an abstract Unix domain socket, and when it gets a connection it verifies the UID that's talking to it (using Python code I already had lying around), reads a block of input from it, and prints it to standard output. The 'server' end runs on my desktop. It SSH's off to some server, runs the program for the client end, and then reads lines from the SSH connection, verifies that they are plausible URLs, and uses my existing (local) remote control scripts to open the URL. On the remote server, I use a shell script wrapping a netcat-like program I wrote to talk to the client end.

(Using an abstract Unix socket avoids a whole lot of yak shaving around managing the socket file, because an abstract socket goes away when the program that has it open exits. I do need a special client program that can talk to abstract Unix sockets, but I happened to have that lying around already.)

Including minimal comments, the two programs combined are under 120 lines of Python, and the most complicated bits were code I already had sitting around. The result is quite speedy; URLs now open more or less immediately. Although my local end is using X based remote control, it doesn't have to, so I'm insulated against the day that Firefox only supports D-Bus remote control.

(And the whole thing doesn't need me to forward X over SSH to the remote server; I could in theory open URLs this way even in remote sessions without X forwarding, although right now I think all of the programs involved would try to do other things if there was no graphical display.)

Opening URLs over remote X forwarding wasn't a fast thing even before the recent changes to my home Internet connection, so this would have been a little quality of life improvement for years. Given how simple it turned out to be, I wish I'd done it sooner.

Sidebar: Some more usage and implementation details

Right now I don't have a clever way of running the 'server' end on my local desktop; instead I open up a local xterm, manually run the server program (which sits there and doesn't go into the background or do anything clever), and iconify the window. If something goes wrong with my SSH connection or the programs, I'll re-run the server.

(There's various code to try to make sure that each end will exit if the SSH connection is cut or something goes wrong with the other end.)

On the remote end, the name of the socket includes both the login name of the person running it and the SSH client IP (taken from the $SSH_CLIENT environment variable). I include the latter because someday I may want or need to run this on both my home desktop and my office desktop at the same time, and I would like to make sure that I open URLs in the right display.


Comments on this page:

By Ian Z aka nonbrowser at 2023-09-13 15:21:47:

Isn't there a missing link here? How the the "client program" (running on your terminal server machine) know where to snarf the URL from?

By cks at 2023-09-13 15:39:43:

Oops, I left that detail out. This is for use with programs (like GUI mail readers) that have URLs and want to open them in 'my browser', and thus have a 'open URL' command or mouse click or whatever. Generally these route through xdg-open, where I've arranged for the special client script to be hooked in.

So the flow is I'm reading email in exmh on our login server (with X forwarded over SSH), I click a URL, exmh runs (my) xdg-open, that runs the a script that sends the URL to the 'client' side, the 'client' side sends it to the server side, and the server side opens the URL in my desktop Firefox. Previously, xdg-open would have run a script that used direct X property based Firefox remote control to open the URL on my desktop Firefox (via a little program), but that X property manipulation is now too slow for me.

By Ian Z at 2023-12-03 22:37:19:

I need something like this myself now, and the lovely Duck found:

https://github.com/superbrothers/opener

which seems remarkably similar to your hack! Was there any actual inspiration either way?

By cks at 2023-12-04 10:01:21:

I don't think there's inspiration in either direction; I didn't know about opener before now, and since it's much older than my take, it clearly wasn't inspired by me. The approach used by opener has the advantage that you can forward one local daemon to multiple destinations (and it can use nc because it uses a conventional filesystem based Unix socket), but I think my version has simpler cleanup if (or when) the connection goes away.

Written on 12 September 2023.
« GNU Emacs, use-package, and key binding for mode specific keymaps
A user program doing intense IO can manifest as high system CPU time »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Sep 12 22:11:06 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.