random-linux-woes/2025-03-27.multi-user-x11-shenanigans.md

81 lines
4.7 KiB
Markdown
Raw Permalink Normal View History

# Multi-user X11 Shenanigans _(feat. `ssh` and PipeWire)_
Generally I avoid putting any files or applications which have to do with my work on my personal computers; however, after a hardware failure and a shipping delay left my work machine unusable for several days, I realized there were some minimum tasks which _REQUIRE_ I install the chrome web browser, slack, and a couple of other efficiency / office tools.
I realized that [X11 forwarding](https://wiki.archlinux.org/title/OpenSSH#X11_forwarding), which I've used for some gui-required remote applications, might actually let me run the application _with an underprivileged user_ while still _using my same desktop_.
So: easy-peasy!
Slap the `-X` flag onto `ssh` and we _should_ be off to the races.
With google chrome securely installed to the user, `ssh -X work-user@localhost` seemed to work immediately!
I slapped this in an easy-to-find, launcher script on my `PATH` and quickly added slack and the other tools.
BONUS: I could set the _default web browser_ for this user to be google chrome and then clicking links in slack would automagically open the work user's chrome without adjusting my _personal_ defaults!
## Problems tho
At least it SEEMED like everything was working immediately.
I ran into two sticking points.
### Clipboard?
Clipboard seemed to work... one way!
Anything I copied from applications on my main user pasted just fine into the application, but I couldn't copy things _from_ google chrome.
2025-03-27 17:38:21 -06:00
I tried to figure out why, but then eventually [tried **`-Y` instead of `-X`**](https://wiki.archlinux.org/title/OpenSSH#Usage) and it just worked.
Something something trust me bro (says both X11 and the Arch Wiki), so I stopped trying to figure it out since it seemed like a WAY deeper dive than I'd hoped.
So since I wanted the clipboard forwarded (and I suppose the localhost, I'm-managing-this-user-myself level of trust seems _Fine by me_), I just swapped them all out for the `-Y`
```
# somewhere conveniently in my PATH called "slack"
#!/bin/sh
ssh -Y work-user@localhost -C slack
```
### Audio... but only on SOME setups
On one computer, audio worked just fine!
When I went to propagate this to my secondary personal, however, I ran into a weird issue where the USB audio card just wasn't available in the `ssh -Y` environment.
It took me a bit of digging through "Help me, I have no audio at all" articles (a Linux-forum CLASSIC), before I finally found some articles talking about some oddities when sharing audio through simultaneous users.
Let me just admit that I know _very little_ about the whole Linux sound ecosystem.
When the Arch Wiki told me to switch to PipeWire... I did.
Especially since there's ["support for PulseAudio"](https://wiki.archlinux.org/title/PipeWire), and it worked out-of-the-box with all the weird audio-controller scripts I've written over the years, I had little reason _not_ to mindlessly upgrade to the new, improved(?), low-level multimedia framework.
SO.
From what I understand:
- [PulseAudio](https://wiki.archlinux.org/title/PulseAudio) is a _server_ which serves as a higher-level interface to PipeWire
- [PipeWire](https://wiki.archlinux.org/title/PipeWire) is the low-level audio framework which runs a separate _session_ for every _user_, initializing PulseAudio or other servers as necessary
- _some_ audio interfaces (particularly the integrated ones) can be seamlessly used across several servers & sessions
- ... but not ALL of them
After trying the recommended "make sure everybody is in the `audio` group" and "make sure your PipeWire is configured right" and "make sure you restart all the `pipewire` and `pulseaudio` services" and what felt like dozens of useless, unhelpful suggestions, I finally landed in the right place.
Apparently my USB device was reporting "busy" to the work user's audio configuration (no thanks to the SUPER helpful error message `audio open error: Device or resource busy`).
We can _fix_ this by making sure the `pipewire` instance for the work user is configured to point to the _same_ server being used by my primary user.
Two pieces to that:
#### 1. Enable PulseAudio server forwarding
I managed this with a _PipeWire_ configuration file:
```
# under the PRIMARY user
# ~/.config/pipewire/pipewire-pulse.conf.d/share-audio-with-other-users.conf
pulse.properties = {
server.address = [
"unix:native"
"tcp:4713"
]
}
```
#### 2. Use the forwarded PulseAudio server on the other user
Since I'm literally never going to log in to this user any other way, I adjusted the default configuration (but I think you can achieve the same thing with the [`PULSE_SERVER` environment variable](https://wiki.archlinux.org/title/PulseAudio#Environment_variables)):
```
# under the WORK user
# ~/.config/pulse/client.conf
default-server = tcp:127.0.0.1:4713
```