allow additional options to X server invocation

[karlkleinpaste]

Is your feature request related to a problem? Please describe.
Not a problem per se. Rather, something I would like to be able to do.

Describe the solution you'd like
When starting, I would like to be able to specify more server options to be added to Xorg invocation. My specific case is that I'd like to use -query 127.0.0.1 -once when using start-desktop in order to engage XDMCP, providing for a typical login screen in the new desktop.

Describe alternatives you've considered
There really aren't any substitutes for this particular kind of use, as there's no mechanism by which to get XDMCP involved without the X server itself asking for it.

Additional context
The realm of consideration for me is quite specific, but it would be a nice generalization to allow the user to specify any desirable new options.

[totaam]

Would an environment variable be acceptable?
Something like:

xpra start-desktop --env=XPRA_XVFB_EXTRA_ARGS="-query 127.0.0.1 -once"`

[karlkleinpaste]

That would be fine with me.

[totaam]

Done.

Tested with the commit above and xpra start --env=XPRA_XVFB_EXTRA_ARGS="-query 127.0.0.1 -once" :10, I get:

/usr/libexec/Xorg-for-Xpra-:10 -noreset -novtswitch -nolisten tcp \
    +extension GLX +extension RANDR +extension RENDER \
    -auth /run/user/1000/.mutter-Xwaylandauth.KRKVN1 \
    -logfile /run/user/1000/xpra/10/Xorg.log \
    -configdir /run/user/1000/xpra/10/xorg.conf.d/291334 \
    -config /usr/local/etc/xpra/xorg.conf \
    -query 127.0.0.1 -once \
    -depth 24 :10

I assumed that it wouldn't be a problem if the extra args aren't right at the end. Works for me(tm).

[karlkleinpaste]

Thanx much. Looking forward to the beta *.rpm.

[karlkleinpaste]

Are xpra's XPRA_WHATEVER environment variables documented anywhere?

[totaam]

Are xpra's XPRA_WHATEVER environment variables documented anywhere?

This question comes up regularly. No, they are not documented.
The code and tickets such as this one are the real documentation.

A quick grep on the codebase reveals over 500 locations where such variables are looked up. Some may duplicates or mostly irrelevant, but still, that's a big number.
I am not going to start an endless documentation page which would make it twice as hard to update any code using those variables..

[karlkleinpaste]

This update works, but only so long as one is executing the xpra start-desktop command locally on the machine in question. I need to reference it via ssh://RemoteHost/N.

That is, I use a local wrapper shell script that takes a few options to simplify what I want to do, constructs an xpra command referencing a remote where I want to start the desktop, and execs that. The generated command is:

xpra start-desktop ssh://ph/7 --attach=no --resize-display=1856x960 --exit-with-children=no --env=XPRA_XVFB_EXTRA_ARGS='-query 127.0.0.1 -once'

The problem appears to be convincing the extra args content to survive the underlying ssh intact, because I can't get away from diagnostics like

xpra initialization error:
 no such option: -o
Command exited with non-zero status 1

The only -o present is part of -once. I've tried extra levels of quotation ("'-query 127.0.0.1 -once'") and backslash-escaping the spaces, neither of which does better.

Turning the command around, to make it an ssh command that invokes xpra (rather than an xpra command referencing ssh://RemoteHost), this works, but only because it's double-quoted:

ssh ph xpra start-desktop :7 --attach=no --resize-display=1856x960 --exit-with-children=no --env=XPRA_XVFB_EXTRA_ARGS="'-query 127.0.0.1 -once'"

The local shell sees double-quotes to preserve the content as one shell token, including its single-quotes, and when that arrives at the remote, its shell sees the single-quotes which again preserves everything in --env...-once as one token.

Further, for testing in the original generated command, when I remove "-query 127.0.0.1" leaving just "-once" (which makes no sense, but it would let me address the whitespace problem), so that I wouldn't need quotation at all, I get an inconsistent diagnostic:

2022-06-18 11:51:39,261 Connected (version 2.0, client OpenSSH_8.7)
2022-06-18 11:51:39,323 Authentication (publickey) successful!
2022-06-18 11:51:39,602 [ph:7]	 SSH: 'xpra initialization error:'
2022-06-18 11:51:39,602 [ph:7]	 SSH: ' exit-with-children was specified but start-child* is missing!'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/main.py", line 143, in main'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    return run_mode(script_file, cmdline, err, options, args, mode, defaults)'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/main.py", line 417, in run_mode'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    return do_run_mode(script_file, cmdline, error_cb, options, args, mode, defaults)'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/main.py", line 452, in do_run_mode'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    return run_server(script_file, cmdline, error_cb, options, args, mode, defaults)'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/main.py", line 1782, in run_server'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    return do_run_server(script_file, cmdline, error_cb, options, args, mode, display, defaults)'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/server.py", line 673, in do_run_server'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    return _do_run_server(script_file, cmdline,'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '  File "/usr/lib64/python3.10/site-packages/xpra/scripts/server.py", line 723, in _do_run_server'
2022-06-18 11:51:39,603 [ph:7]	 SSH: '    assert has_child_arg, "exit-with-children was specified but start-child* is missing!"'
2022-06-18 11:51:39,712 [ph:7]	 SSH: 'xpra initialization error:'
2022-06-18 11:51:39,712 [ph:7]	 SSH: ' failed to identify the new server display!'
2022-06-18 11:51:39,724 [ph:7]	SSH EOF on stderr of run-xpra
2022-06-18 11:51:39,731 [ph:7]	Connection failed

exit-with-children=yes is in .xpra/xpra.conf, but disabling that with --exit-with-children=no is part of the command, see above. This appears to be an actual bug.

The whitespace problem seems a general operational issue of how to reference ssh://RemoteHost using arguments containing whitespace. Suggestions for getting env.args containing whitespace to reach the remote unmangled? I'm really not sure where in the overall conversation from local to remote which component took apart the xpra arguments and left something confused.

[totaam]

Can you please file separate bugs for these issues:

• is exit-with-children not being forwarded?
• whitespace... is tricky, you can run with -d ssh to see which remote command is being executed