On 03/11/15 01:47, Abdulaziz M. Aldarrab wrote: > Well, the load balancer (running on Linux) dispatches GUI job, which may or > may not start immediately depending on the resources requested. It is part of > a medium size grid that has both visualization and compute nodes, and > unfortunately a simple load balancer gimme-host.sh kinda script won't work. > Theoretically, I could have an agent that monitors the job state, then > invokes xpra client once a job in running state, but that would still be > buggy with unnecessary delays. > > I'm not familiar with Xpra proxy server (yet) but I would imagine it might > complicate things. > > It would be nice to have those two additional options (--listen, --client) > e.g. > Xpra_cmd.exe attach [ssh/tcp]: EMPTY --listen=[IP:PORT] (Waits for > server ready msg, with optional timeout. IP is provided in case a machine has > more than 1 active address, otherwise not needed) Or maybe even: xpra listen tcp:IP:port > xpra --start :XX --start-child=CMD --client=IP:PORT > > So once server is initiated successfully, it sends a triggering tcp message > to the client containing USER@SERVER :XX to be used by the client to initiate > ssh/tcp connection. This "could" be a security hazard where a bad guy > broadcasts a trigger message to clients to connect to a malicious server, but > I guess client won't connect to a server initiated by another user. If you use authentication and encryption, this can be made secure. For this use case, we may want to authenticate the server rather than the other way around. > I'm thinking of modifying Xpra in case you don't see this option in your > plans, where would be the best place to start in the source code? I'm a C++ > developer, familiar with sockets, and I can read python :) The best place to start is usually through a ticket.
Another benefit of this listen option is that you can have servers that are NATed, unreachable from regular clients, since they will be the ones initiating the connection. Cheers Antoine > > Thanks, > Abdulaziz > > -----Original Message----- > From: shifter-users [mailto:[email protected]] On > Behalf Of Antoine Martin > Sent: Saturday, October 31, 2015 9:47 AM > To: [email protected] > Subject: Re: [winswitch] Xpra Client in Listen Mode Enquiry > > On 28/10/15 17:54, Abdulaziz Aldarrab wrote: >> Good day, >> >> Current scenario, I have set of Linux servers to run applications on. The >> clients, Windows machines using Exceed (running in passive mode). Clients >> launch an application using an application launcher that: ssh Linux master >> node, then “qsub” use a schedule (UGE, PBS...etc.) to submit a job which >> will be allocated an appropriate machine based on the resources requested. >> The submission script is nothing more than setenv DISPLAY to windows client >> & application execution script. >> >> With Xpra, I couldn’t figure out a similar operation mode, where the >> windows client listens for connections coming from the Linux host as soon as >> the application starts remotely. > There is no passive mode, and none is planned. > > Since you are running the script from the windows box, can't you just have > your script tell the windows box where to connect? > Something like: > HOST=`ssh LOADBALANCER gimme-host.sh` > xpra attach ssh:$HOST > (converting this shell example into the horrible win32 batch file format left > as an exercise) > > Or you could extend the proxy server to deal with this load balancing. > The proxy server can use a simple text file to associate client connections > with their final server destination. As long as you update this file, the > client only needs to connect to the proxy server. > > Cheers > Antoine >> >> Any hint would be really appreciated, >> >> Thank you, >> Abdulaziz >> _______________________________________________ >> shifter-users mailing list >> [email protected] >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > [email protected] > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
