Opened 5 years ago
Last modified 16 months ago
#1582 new defect
User config ignored if started via proxy
Reported by: | psycho_zs | Owned by: | Marc Ordinas i Llopis |
---|---|---|---|
Priority: | critical | Milestone: | 2.3 |
Component: | server | Version: | trunk |
Keywords: | Cc: | mail@… |
Description
using 2.1-20170715r16357-1, when server is started via system service, user config is ignored. When starting with --start-via-proxy=no, user config is successfully applied.
Change History (14)
comment:1 Changed 5 years ago by
Status: | new → assigned |
---|
comment:2 Changed 5 years ago by
Owner: | changed from Antoine Martin to psycho_zs |
---|---|
Status: | assigned → new |
Seems fixed in r16382.
(unfortunately, we have to whitelist the options that do get forwarded so it is possible I've missed one)
comment:3 Changed 5 years ago by
Haven't tested yet, but there are options I didn't find in PROXY_START_OVERRIDABLE_OPTIONS:
key-shortcut, env, desktop-scaling, dpi
comment:4 Changed 5 years ago by
comment:5 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:6 Changed 4 years ago by
Cc: | mail@… added |
---|
User config is still ignored in v2.2-r17607, but I'm not sure if it is the intended behavior.
To test, just add a ~/.xpra/xpra.conf file for an user with "start-child = xterm" and start a server through a proxy system service, the user configuration file is ignored.
If this is the intended behavior, maybe there should be a proxy setting to allow users to use their own config files.
comment:7 Changed 4 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Ah. The config loading runs as root, very early on, before parsing the command line, and before changing uid...
Not sure if that can be fixed.
comment:8 Changed 4 years ago by
Milestone: | 2.1 → 2.3 |
---|---|
Owner: | changed from psycho_zs to Antoine Martin |
Status: | reopened → new |
comment:9 Changed 4 years ago by
Priority: | major → critical |
---|
DOH. I've just remembered how this is supposed to work: the xpra start --start-child=XX
command does the command line parsing and forwards all command line options to the system proxy server, so there is no need to fiddle with the early command line parsing.
comment:10 Changed 4 years ago by
Owner: | changed from Antoine Martin to Marc Ordinas i Llopis |
---|
To test, just add a ~/.xpra/xpra.conf file for an user with "start-child = xterm" and start a server through a proxy system service, the user configuration file is ignored.
I cannot reproduce the problem:
- add start option (using
start
here since I don't useexit-with-children
, but both work)echo "start=xterm" >> .xpra/xpra.conf
- try with a non-proxied start:
xpra start --no-daemon :10
- and verify that the xterm got started (can also attach to verify visually):
$ grep "started command" /run/user/1000/xpra/:10.log started command 'xterm' with pid 11028
- now try via proxy:
xpra stop :10 xpra start --start-via-proxy=yes :10
And run those same checks again.
Everything checks out.
@Marc Ordinas i Llopis: if you still have problems, please follow wiki/ReportingBugs so that I can have enough details to reproduce the problem.
Otherwise this ticket will be closed as "fixed".
comment:11 Changed 4 years ago by
I'm using the same version on the client (Linux Mint 18.3) and the server (Ubuntu 17.10), the deb package 2.2.1-r17715 from the winswitch repository.
I start the system proxy server using systemctl start xpra
, this launches an xpra proxy instance with this command line:
/usr/bin/python /usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=sys --ssl-cert=/etc/xpra/ssl-cert.pem --ssl=on --bind=none --auth=peercred --socket-dirs=/run/xpra --socket-permissions=666 --log-dir=/var/log --pidfile=/run/xpra.pid --debug=
The contents of ~\.xpra/xpra.conf
are simply
start=xterm
Then, from the client, I start a new server:
client$ xpra start ssl://user:passwd@server.tld:14500
This gets to the proxy, who starts a new xpra process as the user with this command line:
/usr/bin/python /usr/bin/xpra start --video-decoders=all --packet-encoders=rencode, bencode, yaml --video-encoders=all --encodings=all --compressors=lz4, lzo, zlib --csc-modules=all --attach=no --start-via-proxy=no --env=XPRA_PROXY_START_UUID=6aa0e8f44f674598908cf47f3c7b747c --daemon=yes --systemd-run=no --uid=1000 --gid=1000 --displayfd=16
This also starts the X and pulseaudio servers, but not xterm as set in ~/.xpra/xpra.conf
.
The problem may be related to the deb packaging and not to the code. Or maybe this is the intended behavior when using a system proxy server, but I'm not sure from the documentation.
I can provide logs of all the above if needed.
comment:12 Changed 4 years ago by
Thanks, I must have done something different when I tested, as I managed to reproduce the problem immediately with your steps. The fixes are in r17718 + r17719.
Unfortunately, those fixes are the intrusive kind that normally makes me nervous about backporting, so I am tempted to call this a "known issue" in 2.2 and only carry the fix forward for the next release. That way it will get more testing before being released into the wild.
Note: at present, if the client specifies start=xterm
, it will override any start=whatever
that the server might have had. One could reasonably argue that we should append to the list. Problem with this approach is that it then becomes impossible to override the server's start
option - which could be seen as a feature too.
@Marc Ordinas i Llopis: does that work for you? (new beta builds pushed)
comment:13 Changed 4 years ago by
Testing with version 2.3-r17719, from the beta repository, I'm getting very different results:
- Using the proxy system service, the user's
~/.xpra/xpra.conf
still isn't followed. Enabling the debug function in source:/trunk/src/xpra/scripts/config.py#L19, it seems like it's the proxy system process the one that reads the configuration files, not the user's xpra server instance. - Starting directly from the client, using SSH, appends the
start
options, that is, executes both those in/etc/xpra/conf.d
and in~/.xpra/xpra.conf
. This may not be related, I'm just mentioning it because you noted that wouldn't be the case.
I'm testing by having an start = xeyes
in /etc/xpra/conf.d
and start = xterm
in ~/.xpra/xpra.conf
. Using the proxy server, only xeyes appears. Using SSH, both xeyes and xterm are started.
comment:14 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1582
Good catch!
(related to #1105)