Some questions on multiplexing

[ryunuri]

Hey there, I've been making good use of wezterm on both my local and remote environments. I typically use the command wezterm connect SSHMUX:remote to work on my remote environment from my local one and have really been enjoying wezterm's built-in remote persistence feature.

However, I've been encountering a couple of issues with multiplexing. Firstly, when I use wezterm in my remote machine, I'm having trouble attaching to the workspace that I was previously connected to from my local. Is there a way for me to attach to this workspace, and if so, could you guide me on how to do that? Furthermore, is it possible to view a list of all running workspaces on my current machine?

Secondly, I've been having some difficulty connecting to a remote server that requires a proxy jump. Does wezterm's SSHMUX connection support this feature? Any advice on these issues would be greatly appreciated!

[cseickel]

I have the same question about sharing a session between the local and remotes. That is the biggest reason that I use tmux but I'd like to drop tmux if I can.

What I normally do is that I work from a desktop most of the time but I sometimes want to continue that session from my laptop and jump back and forth at will. The SSHMUX connection works great for persisting my session (which is running on the desktop) when working from the laptop, but I don't see how I can access the same session on the desktop.

Can anyone offer advice on this?

[aplatypus]

Hi there. These questions are almost year old, in case you are still using tmux I can offer two cents worth on how the Wez-mux worked-out for me.

I had some initial trouble just using Wezterm (on Kubuntu/Wayland) and decided to ditch the flatpak and build from main. I found building locally much more rewarding. Once I became confortable with the way Wezterms works, etc. I decided to give the multiplexing a shot.

I had a bit of trial and error until my mental model solidified enough to make things sensible. I really think some nice diagram would help people like me make sense of things a bit faster.
First, my use case is to link between my desktop PC (and server) and laptop via ssh. This is what I did ...

1. I went to laptop from local Wezterm CLI that works as a plain ssh session. I do not think there's any mux going to happend that way.

   $ waypipe -c lz4=9 ssh laptop

2. I was encouraged by this tidbit:

The out-of-the-box experience with wezterm allows you to multiplex local tabs and windows which will persist until they are closed. With a little extra configuration you can enable local terminal multiplexing with features similar to those in tmux or screen.
... Multiplexing

3. So I went for the simplest option:

   $ wezterm connect laptop

   That was a bit of a bust:
   ERROR wezterm_gui > desired default domain 'toolyumuck' was not found in mux!?; terminating

4. Some further reading and I decided that I was over-complicating it and went for the SSH option:

   $ wezterm connect SSHMUX:laptop

   This was much more encouraging, still no cigar yet.

   ERROR wezterm_client::client > ssh stderr: bash: line 1: wezterm: command not found
   :
   ERROR wezterm_gui > Please install the same version of wezterm on both the client and server! ...

   • What is this all about? I have the same build on both the source (desktop) and target (laptop).
   • I wondered then about how the remote session kick-starts the Wezterm MUX daemon?
   • For example if it is a flatpak or installed manually from a local build (like mine...) how can the bash shell find the executable?

5. Long story short. I made a symlink to the wezterm build directory:

   $ ls -l /usr/bin/wezterm
   lrwxrwxrwx 1 root root 35 Jun 21 23:15 /usr/bin/wezterm -> ../../opt/apps/wezterm/home/wezterm*

   • Reasoning that /usr/bin/ is always on the $PATH when bash starts.
   • This also means I can point to a more official install later and not need to alter anything

6. So now when I go:

   $ wezterm connect SSHMUX:laptop
    ERROR  wezterm_client::client > ssh stderr: 21:14:57.055  WARN   wezterm_client::client > While connecting to Socket("/run/user/1000/wezterm/sock"): connecting to /run/user/1000/wezterm/sock.  Will try spawning the server.
    WARN   wezterm_client::client > Running: "/prod/opt/apps/wezterm/20240609-095134-f5e496eb/wezterm-mux-server" "--daemonize"

   • I am then rewaded by a nice window for Wezterm GUI from the daemon on the laptop machine.
   • When I look at the running processes, I get:

   $ ps -ef | grep -e"wezterm"
   22797   22794  0 21:14 ?        00:00:01 wezterm cli --prefer-mux proxy
   22841       1  1 21:14 ?        00:00:02 /prod/opt/apps/wezterm/20240609-095134-f5e496eb/wezterm-mux-server --pid-file-fd 9

The good news is that spawning a new tab in the remote window, opens another ssh session to the laptop machine. Brilliant!

I lost my wifi connection on the laptop. When it came back I reissued the :

$ wezterm connect SSHMUX:laptop

command and magically my open tabs on the laptop were restored. Not just that the connections for each tab were preserved, and also the terminal display buffers seem to have been preserved. I am curious to know if that context information is kept on the initiating machine or on the remote box. I'm keen to walk about in the source code and find out.

Also that little error I showed ERROR wezterm_client::client > ssh stderr: 21:14:57.055 WARN ... isn't normal. I think that has something to do with rebooting my laptop today and that probably killed the suspended ssh sessions. I don't normally see that when sessions resume.

There it is. The key takeaways are:

1. Ensure that bash can kick-start wezterm say by putting the executable somewhere on the default path.
2. Have the same version on both ends. (At least for the time being).

In my case things probably go better because the domain names (e.g. laptop or desktop) are symbolic hosts set-up in the ~/.ssh/config file with ssh-key credentials. So a ssh config is recommended. Keeps things simple(-er)

[MartyMcFlyInTheSky]

I'm also thinking about ditching tmux. However the problem is that wezterm is not installed on our production machines. Is there a way to do an ad-hoc install of the daemon when I connect to it or could I use the unix / tls domain for this? I'm not really clear on what the advantage of using these over the ssh-variant is, however only the ssh domain section states that:

A compatible version of wezterm must be installed on the remote system in order to use SSH domains

Does this mean that the other domains do not need wezterm to be installed on remote?

Also I'm looking for a way to start nvim locally and then just on save drop the buffer into the remote files, so I can work on remotes using my local nvim installation. Maybe this could be done with one of these protocols? Just dropping this in here.

[MartyMcFlyInTheSky]

Thx! How would I ensure that it uses my installed copy? Do I just copy the binary over on ssh login? This would not need to happen all the time but only when I want to use the mutliplexer though, so I kinda want to avoid the overhad of copying a 28MB binary over in every case.

[abdelbk]

Hi there. I'm encountering the same problematic. I want to use Wezterm multiplexing in a remote server to which I don't have full permissions. I tried to install Wezterm from source but the build fails because the server has neither Wayland nor x11 (which I believe handle the GUI part and are not needed in the multiplexing part).

Did you manage to find a way to install only the multiplexing daemon ?

[Lenbok]

@abdelbk when I need to use remote servers for which I don't have full permissions, I locally build wezterm/wezterm-mux-server in a docker container, and copy the resulting binaries my user bin directory on the destination server. A rough recipe (assuming you have wezterm source checked out at the version you're interested in):

  docker run -v $PWD:/opt -ti --entrypoint /bin/bash amazonlinux:2
  yum update
  curl https://sh.rustup.rs -sSf | sh -s
  . "$HOME/.cargo/env"
  rustup update
  #rustup default 1.79.0  # An old wezterm tag I built needed an earlier version of rust
  cd /opt
  ./get-deps
  cargo clean && cargo build --release --bin wezterm-mux-server --bin wezterm
  exit

If your target OS is not in the set supported by get-deps out of the box (as in this particular case), you first need to extend get-deps so that it takes the appropriate path.

[abdelbk]

@Lenbok Thank you for the response !
I was able to make it work recently by following pretty much the same steps you listed above.

[MartyMcFlyInTheSky]

@Lenbok I have some trouble getting this to crosscompile for RHEL9 and debian. The problem in the RHEL ubi seems to be that some of the upstream yum packages are not available (e.g. flatpak-builder), while in Debian the compilation just fails with errors (using a tar.gz of the newest release 20240203-110809-5046fc22 ?