Upgrading Xpra display and proxy servers SSH-way

[basilgello]

Today I noticed that installing a new version of package via apt or dpkg does not invoke systemctl daemon-reload nor attempts to restart / upgrade proxy servers. Upgrading Xpra display servers should be trivial in postinst hook, but xpra upgrade :14500 yields

xpra error: unrecognized command 'exit' by xpra proxy

and the Xpra proxy is not upgraded.

I suggest upgrading all known Xpra display server instances in postinst hook then restarting Xpra proxies. This will cause disconnects of cliemts, however.

Another option is to let existing Xpra display servers to operate intact after update, and instruct Xpra proxy servers to restart themselves after the last client connection goes away. This is more user-friendly but delays the update of running Xpra sessions. Update delay might be important if the updated Xpra code fixes a security vulnerability, but overall this option looks preferrable to me compared to upgrade+restart one.

[totaam]

nor attempts to restart / upgrade proxy servers

The problem with restarting proxy servers is that it can end up killing connections...

xpra error: unrecognized command 'exit' by xpra proxy

We may be able to teach the proxy server to exit without killing proxy instances sub-processes, but that would not work for threaded proxy instances which are required for encrypted connections (SSL and SSH).

I suggest upgrading all known Xpra display server instances...

Could do, but that's going to anger people that have custom sessions on TCP ports, as the upgrade command currently doesn't take over the socket so the new servers won't be accessible the same way the old ones were.
This would work for server instances started by the proxy as those don't usually have custom network options.

Another option is to let existing Xpra display servers to operate intact after update, and instruct Xpra proxy servers to restart themselves after the last client connection goes away.

Sounds good. Shouldn't be too hard.

[totaam]

#3010 and #541 will help with this.
We can then just auto-upgrade all instances and the clients should re-connect transparently in most cases.

[totaam]

Could do, but that's going to anger people that have custom sessions on TCP ports, as the upgrade command currently doesn't take over the socket so the new servers won't be accessible the same way the old ones were.

This particular blocking issue has been resolved: 8437673 and #3217

[totaam]

Despite the improved support for upgrading sessions in place whilst preserving their sockets and attributes, I am not going to force upgrade sessions during package upgrades, I'm pretty sure users would be annoyed to see their sessions re-connect and there's always the risk that bugs could take down the session.