Registration Xpra sessions via proxy

[louis-mulder]

Is your feature request related to a problem? Please describe.

No it is not problem however if we want to use a proxy-server on more subnets for example within Kubernetes , Docker swarm or full bare-metal/virtual server a form of registration is desired.
Suggestion is to use Mariadb or per default Sqlite.
Key is the username and a list of sessions containing the name of the docker-instance/pod/servername followed by a '@' ip-address [: display number] (optional if not specified default :0). In case of sqlite you can place the DB on a shared storage so when a number of Xpra-proxy servers are active loadbalancing will be possible. Or DB layout like Mdns.
Updating the database can be done by creation of session or when user gives a shutdown. Only in case of hard kill/crash a process is needed to inpect the database and sessions on regular times the sessions still exist. If not update the DB.
Another option is the session will registrate itself in a DB.

Describe alternatives you've considered
A file with the data placed in case of more proxy-instances but probably you run into locking issues.

Regards Louis

[totaam]

Please describe the use-case rather than an implementation.
How is this different from #2125?

[totaam]

Not heard back.

[louis-mulder]

Antoine,

Running Xpra under Kubernetes can be done. With the SSH protocol and a pod with a Ansible-container and a separate SSH-container it creates a pod running a Xpra seamless or desktop session. To attach the running session can be done on two ways:
If the pod is multi-homed ( using Multus and a DHCP-server) a user can access the pod directly with SSL or SSH.
Indirectly via a K8-service with SSH and then SSH proxy will use a trusted ssh key between the session pod and the proxy pod. Lookup of the desired session-pod will be done also via Ansible. So the traffic form the starting point to the session pod is encrypted. Another trick is using socat I also played with this solution however the disadvantage is by using directly SSL a user must login twice first the SSH session and then he/she must give the password for the SSL session in the seconf pod. Indirect it possible to bind a port in the session pod on localhost and use socat with SSL . Using iptables in the pod will block unwanted direct access.
A more safe solution is using from the starting point not using SSH but SSL. Avoiding the use of SSH tunneling. Therefore a modification is probably needed in the proxy_server (new_session) not creating locally a Xpra session but creating a pod with the session and using a encrypted connection between the proxy-pod and the session pod.

I will keep you informed about the progressing...
Regards Louis