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.
Good catch! (related to #1105)
Seems fixed in r16382.
(unfortunately, we have to whitelist the options that do get forwarded so it is possible I've missed one)
Haven't tested yet, but there are options I didn't find in PROXY_START_OVERRIDABLE_OPTIONS:
key-shortcut, env, desktop-scaling, dpi
Options like key-shortcut, desktop-scaling are only used by the client so they don't need to be forwarded.
dpi: the client will forward it to the server on connection, which is a little bit different admittedly, so r16384 fixes that.
env and start-env added in r16383.
Important fix as part of r16502 (for #1105 mostly): we don't want to honour env when running as root. A user could potentially use this to subvert the system wide proxy service.
Closing, feel free to re-open if I've missed something.
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.
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.
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.
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:
start here since I don't use exit-with-children, but both work)
echo "start=xterm" >> .xpra/xpra.conf
xpra start --no-daemon :10
$ grep "started command" /run/user/1000/xpra/:10.log started command 'xterm' with pid 11028
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".
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.
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)
Testing with version 2.3-r17719, from the beta repository, I'm getting very different results:
~/.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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1582