4 ms·

The SSH support in the GUI application isnt very good which precludes me recommending it to my users sadly.

totaam 2y ago
Perhaps your users don't have the same abilities with ssh? The reason why xpra switched to paramiko as default ssh implementation is because it makes it possible to integrate (cross platform too) with the GUI so that asking for passphrases or passwords can be handled by the xpra process itself (it may already have the password or it may delegate to pinentry or gpg agent or putty agent or whatever). This also means that ssh errors can be handled much more gracefully - natively in the code. With openssh launched as a subprocess, the user interface is non-existent, and when the ssh process fails, all the xpra process sees is a dead process with a non-zero exit code - which is much more difficult to handle gracefully.
aidenn0 2y ago
I find it really annoying that it seems to default to paramiko for ssh support. I already have all of my ssh setup via openssh (e.g. jumphosts, identity files, connection multiplexing), and I have to pass "--ssh=ssh" to get any of that to work.
- kragen 2y ago
  this sounds like something you can fix with a two-line shell script #!/bin/sh exec /usr/bin/xpra --ssh=ssh "$@"
  - totaam 2y ago
    You're making it way more complicated than it should be. Just edit the defaults in `/etc/xpra/conf.d/40_client.conf`: https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709b32080535d52e90336/fs/etc/xpra/conf.d/40_client.conf.in#L27-L33 https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709... (or your personal defaults in `~/.config/xpra`)
    - kragen 2y ago
      hey, thanks! i'm not sure that makes it less complicated (it means the same xpra command line will work properly on one machine but not another) but it definitely looks like a solution!
  - aidenn0 2y ago
    Since xpra takes a sub-command as the first arg it's more like: : xpra_cmd="$1" shift exec /usr/bin/xpra "$xpra_cmd" --ssh=ssh "$@" And I don't see how that helps with using the GUI (like the comment I replied to). Also, defaults matter.
    - totaam 2y ago
      No, the subcommand does not need to be the first arg.
    - kragen 2y ago
      can't you put the flag before the subcommand? and can't you pass the flag when you launch the gui? i haven't been using it lately so i don't remember defaults do matter, but defaults can be changed. if it only takes a four-line shell script to change them, they don't matter much
      - aidenn0 2y ago
        > can't you put the flag before the subcommand? The manpage implies you can't, but I tested and you can. > and can't you pass the flag when you launch the gui? I just tested and passing the flag when you launch the gui has no effect.
        totaam 2y ago
        If you don't want to change the global defaults (in `/etc/xpra`), or your personal config (`~/.config/xpra`), you should be able to stick `ssh=ssh` in a `$HOST.xpra` session file and the launcher should honour it when you open the file / double-click on it. (add `autoconnect=true` and the launcher won't be seen unless the connection fails)
        kragen 2y ago
        thank you for sharing your expertise!
        aidenn0 2y ago

Perhaps your users don't have the same abilities with ssh? The reason why xpra switched to paramiko as default ssh implementation is because it makes it possible to integrate (cross platform too) with the GUI so that asking for passphrases or passwords can be handled by the xpra process itself (it may already have the password or it may delegate to pinentry or gpg agent or putty agent or whatever). This also means that ssh errors can be handled much more gracefully - natively in the code. With openssh launched as a subprocess, the user interface is non-existent, and when the ssh process fails, all the xpra process sees is a dead process with a non-zero exit code - which is much more difficult to handle gracefully.

aidenn0 2y ago

I find it really annoying that it seems to default to paramiko for ssh support. I already have all of my ssh setup via openssh (e.g. jumphosts, identity files, connection multiplexing), and I have to pass "--ssh=ssh" to get any of that to work.

kragen 2y ago
this sounds like something you can fix with a two-line shell script #!/bin/sh exec /usr/bin/xpra --ssh=ssh "$@"
- totaam 2y ago
  You're making it way more complicated than it should be. Just edit the defaults in `/etc/xpra/conf.d/40_client.conf`: https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709b32080535d52e90336/fs/etc/xpra/conf.d/40_client.conf.in#L27-L33 https://github.com/Xpra-org/xpra/blob/eedf34ecef3a04d0867709... (or your personal defaults in `~/.config/xpra`)
  - kragen 2y ago
    hey, thanks! i'm not sure that makes it less complicated (it means the same xpra command line will work properly on one machine but not another) but it definitely looks like a solution!
- aidenn0 2y ago
  Since xpra takes a sub-command as the first arg it's more like: : xpra_cmd="$1" shift exec /usr/bin/xpra "$xpra_cmd" --ssh=ssh "$@" And I don't see how that helps with using the GUI (like the comment I replied to). Also, defaults matter.
  - totaam 2y ago
    No, the subcommand does not need to be the first arg.
  - kragen 2y ago
    can't you put the flag before the subcommand? and can't you pass the flag when you launch the gui? i haven't been using it lately so i don't remember defaults do matter, but defaults can be changed. if it only takes a four-line shell script to change them, they don't matter much
    - aidenn0 2y ago
      > can't you put the flag before the subcommand? The manpage implies you can't, but I tested and you can. > and can't you pass the flag when you launch the gui? I just tested and passing the flag when you launch the gui has no effect.
      - totaam 2y ago
        If you don't want to change the global defaults (in `/etc/xpra`), or your personal config (`~/.config/xpra`), you should be able to stick `ssh=ssh` in a `$HOST.xpra` session file and the launcher should honour it when you open the file / double-click on it. (add `autoconnect=true` and the launcher won't be seen unless the connection fails)
        kragen 2y ago
        thank you for sharing your expertise!
        aidenn0 2y ago