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.
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 )
>
>
>
> On Tuesday, October 11, 2016 8:18 PM, Antoine Martin
> <[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]>> 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>>: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>>: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>>:port1
>>
>> OR
>> xpra attach tcp:user1: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>>: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>>: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>>: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>>: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]>>> 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>>: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>>: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>>/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]>>
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>
>> _______________________________________________
>> shifter-users mailing list
>> [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]>>
>
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
>>
>
>
>
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
