4.7 KiB
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, 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.
I tried to figure out why, but then eventually [tried -Y
instead of -X
]( 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", 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 is a server which serves as a higher-level interface to PipeWire
- 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):
# under the WORK user
# ~/.config/pulse/client.conf
default-server = tcp:127.0.0.1:4713