On 31/10/16 23:12, Mukul Agrawal wrote: > Thanks Antoine. > > Basically, I want to detect if user's app want to generate a graphical > output and then I like to automatically connect user to the xpra html5 > client. I would like to be able to capture any window creation request > whether client uses x11 API, openGL or anything else. > At this point of time, I am not worried about video, sound, mouse or > keyboard --- graphics window is the only thing that I care about. The XCreateWindow is what you are looking for, application side. The X11 server will emit a "CreateNotify" event for each new window. You can find an example code that prints each CreateNotify event it sees here: http://xpra.org/trac/browser/xpra/trunk/src/tests/xpra/x11/bindings/listen_maprequests.py?rev=14372 (requires latest xpra trunk code to be installed)
Cheers Antoine > > Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) > > > On Friday, October 28, 2016 10:01 PM, Antoine Martin > <[email protected]> wrote: > > > On 29/10/16 04:18, Mukul Agrawal wrote: >> Following is probably not a xpra specific question rather generic x11 >> question, but I would appreciate if you have any pointers regarding this. >> >> I start variety of command-line applications on a headless remote host. >> I have an xpra server running on this host and I make all applications >> to send their "potential" graphical outputs to the xpra display. Not all >> applications will generate graphical output. >> In cases, when application does try to open a graphical window on the >> xpra display, I would like to take some follow-up action. How do I >> detect that application is trying to send something to the display? > There are many ways of detecting that applications try "to send > something to the display", it really depends what "follow-up action" you > want to trigger and how reliable you want this to be. > > X11 applications will open a connection to the X11 server: > https://tronche.com/gui/x/xlib/display/opening.html > but that alone is not a guarantee that they will "show" something (they > may just interact with the clipboard, keyboard or whatever). > X11 applications that show windows will need to call XCreateWindow: > https://linux.die.net/man/3/xcreatewindow > So that's another way of detecting that they intend to show something > (but then you have to check that the window is actually mapped, visible > and displayed, etc) > Both can be intercepted with LD_PRELOAD tricks. > > Looking at it from the window manager's perspective (xpra, which > connects to the X11 server as a client), we get notifications from the > X11 server when any new window is created. That's the core of any window > manager. Then you need to reconcile this window with the process that > spawned it: > http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window > At that point, you usually also have many other window attributes you > can use ("WM_CLASS", title, etc). > > Cheers > Antoine > > > >> >> Regards, >> Mukul >> ( https://sites.google.com/site/mukulagrawal > <https://sites.google.com/site/mukulagrawal>) >> >> >> >> On Tuesday, October 11, 2016 8:18 PM, Antoine Martin >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> On 12/10/16 03:28, Mukul Agrawal wrote: >>> On Ubuntu Xenial, xpra is using the fallback option of Xvfb. >>> I will like to somehow be able to use Xdummy. >>> My specific use-case is on headless machines .... so I don't have any >>> Xorg starting by default. >>> Is there any workaround that can enable me to use Xdummy? >> Possibly, the Xdummy wiki page gives some clues about some of the >> permission changes that may be required (tested with Trusty): >> http://xpra.org/trac/wiki/Xdummy#Ubuntu >> >>> Is this expected to be a long term problem or do you expect to have a >>> solution in near term? >> Until Ubuntu fixes their packages or provides a workaround, no. >> >>> I highly doubt Ubuntu will do anything about it, even in near future LTS >>> releases. >> You should be asking the Ubuntu developers. >> They should know since they're the ones patching the upstream Xorg >> packages. Debian does not have this issue either. >> >>> Alternatively, if I rollback to Trusty, do I need to follow the >>> procedure mentioned in the link below? >>> Or will newer releases of xpra take care of it automatically? >> There is nothing we can do in our code: the broken Xorg packaging is >> Ubuntu's, not ours. >> >>> [I never followed this procedure before on Trusty but I dont recall >>> seeing Xdummy related warning before either. >> Which warning? >> I don't recall which one was the last version of Ubuntu that supported >> running Xdummy, sorry. >> >> Cheers >> Antoine >> >>> >>> Xdummy – Xpra <https://xpra.org/trac/wiki/Xdummy> >>> >>> >>> >>> >>> >>> >>> Xdummy – Xpra >>> >>> xpra - screen for X >>> >>> >>> <https://xpra.org/trac/wiki/Xdummy> >>> >>> >>> >>> >>> >>> >>> >>> Regards, >>> Mukul ( https://sites.google.com/site/mukulagrawal >> <https://sites.google.com/site/mukulagrawal>) >>> >>> >>> On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users >>> <[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>>> wrote: >>> >>> >>> Thanks for the clarifications.I simplified the setup (non-sudo user for >>> proxy; same usernames on both machines) to be able to debug. But it >>> still does not work. >>> Multifile authentication on proxy succeeds. But seems like it not using >>> correct ssh command line to connect to backened server. Logs on the >>> proxy are attached below. There are no logs on the backend xpra server. >>> The sshd logs on the backend server says that the connection was closed >>> by the proxy [preauth]. >>> 1. I now start proxy as non-sudo user1 on machine1 and attach it to >>> non-priveldged tcp port1. Give it a display number disp1. >>> >>> xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 >>> --tcp-auth=multifile:filename=path-to-multifile -d auth >>> >>> Machine1 is running newer version of XPRA (xpra proxy version > 1.0-r13637). >>> >>> multifile looks like following :- >>> user1|pswd1|1000|1000|ssh:user1@machine2 <mailto:user1@machine2> > <mailto:user1@machine2 <mailto:user1@machine2>> >> <mailto:user1@machine2 <mailto:user1@machine2> <mailto:user1@machine2 > <mailto:user1@machine2>>>:disp2|| >>> >>> >>> 2. start an xpra server on machine2 under the user account with with >>> same username user1. Give it a display number disp2. >>> >>> xpra start :disp2DISPLAY=:disp2 xeyes & >>> >>> Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if >>> this creates any problems. >>> >>> 3. Try attaching to backend server on machine2 from machine 1 using ssh >>> transport and public key authentication. >>> xpra attach ssh:user1@machine2 <mailto:user1@machine2> > <mailto:user1@machine2 <mailto:user1@machine2>> >> <mailto:user1@machine2 <mailto:user1@machine2> <mailto:user1@machine2 > <mailto:user1@machine2>>>:disp2 >>> This works fine. So seems like different versions are compatible. >>> 4. Try attaching from xpra clent running on machine3 (win7 machine). >>> >>> xpra attach --password-file=pswd.txt tcp:user1@machine1 > <mailto:user1@machine1> >> <mailto:user1@machine1 <mailto:user1@machine1>> >>> <mailto:user1@machine1 <mailto:user1@machine1> <mailto:user1@machine1 > <mailto:user1@machine1>>>:port1 >>> >>> OR >>> xpra attach tcp:user1:pswd1@machine1 <mailto:pswd1@machine1> > <mailto:pswd1@machine1 <mailto:pswd1@machine1>> >> <mailto:pswd1@machine1 <mailto:pswd1@machine1> <mailto:pswd1@machine1 > <mailto:pswd1@machine1>>>:port1 >>> >>> >>> Proxy Logs :- >>> >>> 2016-09-16 11:03:55,160 New tcp connection received from >>> IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, >>> authclass=('multifile', >>> <class'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': >>> 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 >>> 11:03:55,161 creating authenticator ('multifile',<class >>> 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': >>> 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 >>> 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 >>> 11:03:55,161 processing authentication withmulti password file, >>> response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 >>> 11:03:55,161 >>> >> > challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 >>> 11:03:55,161 Authentication required by multipassword file authenticator >>> module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using >>> hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication >>> withmulti password file, response=864f4fff84caf265599ff84726295167, >>> >> > client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 >>> 11:03:55,271 >>> mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 >>> 11:03:55,271 loaded 184 bytes from >>> 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: >>> ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m…. Something here >>> >> > …hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 >>> 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 >>> 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- >>> IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1@IP2 > <mailto:user1@IP2> >> <mailto:user1@IP2 <mailto:user1@IP2>> >>> <mailto:user1@IP2 <mailto:user1@IP2> <mailto:user1@IP2 > <mailto:user1@IP2>>>:disp2'], {}, >> {})^[[0m^[[36m2016-09-16 11:03:55,273 >>> start_proxy:proxy-virtual-display=:disp1 (ignored), user specified >>> display=None, founddisplays=['ssh:user1@IP2 <mailto:user1@IP2> > <mailto:user1@IP2 <mailto:user1@IP2>> >>> <mailto:user1@IP2 <mailto:user1@IP2> <mailto:user1@IP2 > <mailto:user1@IP2>>>:disp2']^[[0m2016-09-16 >> 11:03:55,499 proxy video >>> encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance >>> started^[[0m2016-09-16 11:03:55,499 for client tcp socket: >>> internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server >>> Pipe(ssh:user1@IP2 <mailto:user1@IP2> <mailto:user1@IP2 > <mailto:user1@IP2>> <mailto:user1@IP2 <mailto:user1@IP2> >> <mailto:user1@IP2 <mailto:user1@IP2>>>:disp2)^[[0m2016-09-16 11:03:55,500 >>> proxy instance now also availableusing unix domain >>> socket:^[[0m2016-09-16 >>> 11:03:55,500 >> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 >>> 11:03:55,503 Error: SSH connection to thexpra server >>> failed^[[0m^[[31m2016-09-16 11:03:55,504 check your username, hostname, >>> displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504 for >>> server: ssh:user1@IP2 <mailto:user1@IP2> <mailto:user1@IP2 > <mailto:user1@IP2>> <mailto:user1@IP2 <mailto:user1@IP2> >> <mailto:user1@IP2 <mailto:user1@IP2>>>:disp2^[[0m^[[31m2016-09-16 >>> 11:03:55,504 the command line used was:^[[0m^[[31m2016-09-16 >>> 11:03:55,504 ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra >>> _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra >>> _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection >>> lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket >>> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 >>> proxy instance 11703 stopped^[[0m >>> >>> >>> >>> >>> >>> Regards, Mukul ( https://sites.google.com/site/mukulagrawal >>> <https://sites.google.com/site/mukulagrawal>) >>> >>> On Thursday, September 15, 2016 10:24 AM, Antoine Martin via >>> shifter-users <[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>> >>> <mailto:[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>>>> wrote: >>> >>> >>> On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: >>>> If I want xpra proxy on machine1 to connect to xpra server on machine2 >>> using ssh with public key authentication and no password, then how >>> should I set it up? >>> I have not tested this, but SSH connections from the proxy should be >>> using the public key of the user running the proxy server process and >>> not the key of the user you authenticate as. (which may not have a user >>> account at all on the system running the proxy) >>> >>>> Public keys are already in default locations and xpra is able to >>> attach directly from machine2 to machine 1 using standard format: xpra >>> attach ssh:username@machine1 <mailto:username@machine1> > <mailto:username@machine1 <mailto:username@machine1>> >> <mailto:username@machine1 <mailto:username@machine1> > <mailto:username@machine1 <mailto:username@machine1>>>:display. >>> I thought the server you wanted to connect to was "machine 2" and not >>> the other way around? >>> >>>> But when I try to connect via proxy from client machine3, proxy is not >>> being able to authenticate. >>> Have you checked your ssh server logs for an answer? >>> >>>> It sends the challenge but then there is no log after that. >>> Please share the log sample up to that point to help clarify things. >>> >>> Note: when using SSH connections, the server does not need to use >>> another socket authentication module. That's usually just redundant. >>> >>>> I am using multifile like this :- >>>> username|pswd|1000|1000|ssh:machine1:display|| >>>> and attach command from machine3 like this:-xpra attach >>> tcp:username:pswd@machine2 <mailto:pswd@machine2> > <mailto:pswd@machine2 <mailto:pswd@machine2>> >> <mailto:pswd@machine2 <mailto:pswd@machine2> <mailto:pswd@machine2 > <mailto:pswd@machine2>>>:proxyPORT >>>> >>>> Are the usernames and passwords actually associated with login >>> accounts on the target machine or their significance is only with >>> respect to multifile resolution? >>> It depends: if the proxy server runs as root, each proxied connection >>> will run as the uid and gid you defined. (ie: 1000 above) >>> But the connection to the backend server is made before changing uid, so >>> the ssh key used will not be the one of the user specified in multifile. >>> >>> If you don't mind using SSH with passwords, you should be able to use >>> something like this (untested): >>> |username|pswd|1000|1000|ssh/username2:password2@machine2 > <mailto:password2@machine2> >> <mailto:password2@machine2 <mailto:password2@machine2>> >>> <mailto:password2@machine2 <mailto:password2@machine2> > <mailto:password2@machine2 <mailto:password2@machine2>>>/display|| >>> >>> We could also change the code to: >>> * add support for ssh options to multifile, so you could specify the >>> keyfile for each user >>> * change the ordering so the connection to the backend server happens >>> after changing uid and gid (but this would only work with the proxy >>> running as root) >>> Feel free to create tickets for this. >>> >>>> Can password be left blank for public key authentication? >>> That doesn't make sense: the password in multifile is for authentication >>> to the proxy, not to the backend server. >>> Unless you're trying to connect via ssh to your proxy? (but why?) >>> >>> Cheers >>> Antoine >>> >>> >>>> >>>> Thanks. >>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> [email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>> >>> <mailto:[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>>> >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> >>> _______________________________________________ >>> shifter-users mailing list >>> [email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>> >>> <mailto:[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>>> >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>> >>> >>> >>> _______________________________________________ >>> shifter-users mailing list >>> [email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[email protected]>> >>> <mailto:[email protected] > <mailto:[email protected]> >> <mailto:[email protected] > <mailto:[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
