[FreeNX-kNX] Re: Problem with Nx, Fluxbox and suspended sessions

[chris at ccburton.com]

Marco Passerini <marco.passerini at csc.fi> wrote on 13/05/2011 09:32:56:
> Hi,
> 
> Look at this:
OK  ;-)
> 
> ### fresh session ##
> $ echo $XAUTHORITY
> /home/myusername/.xauth6GGIy3

So that's your cookie file for this session . . .

. . . it is named differently from the previous one, so it is probably
a computed "random" filename, but it might relate to something else.

I don't know why this is being done, or what is doing it, so you will
need to search it out yourself, in lieu of anyone else helping.

> 
> $ ls -a | grep xauth
> .xauth6GGIy3
> 
> $ cat .xauth6GGIy3
> myhostname.com/unix:10 MIT-MAGIC-COOKIE-1 **cookie**
> localhost.localdomain:1000 MIT-MAGIC-COOKIE-1 **cookie**
> myhostname.com/unix:1000 MIT-MAGIC-COOKIE-1 **cookie**

Is it a text file or did you filter the output.
What does
        file /home/myusername/.xauth6GGIy3
output ??

> 
> $ xauth  -f ~/.xauth6GGIy3 list
> myhostname.com/unix:10 MIT-MAGIC-COOKIE-1 **cookie**
> localhost.localdomain:1000 MIT-MAGIC-COOKIE-1 **cookie**
> myhostname.com/unix:1000 MIT-MAGIC-COOKIE-1 **cookie**
> 
> $ ls -a | grep Xauth
> .Xauthority
> 
> $ cat .Xauthority
> [empty]
> 
> $ xauth  -f ~/.Xauthority list
> [no result]

That isn't your cookie file . . . .

> 
> 
> ### restored session ###
> 
> $ echo $XAUTHORITY
> /home/myusername/.xauth6GGIy3
> 
> $ ls -a | grep xauth
> [no result]

It's been cleared . . . 

FreeNX runs
        xauth remove
on its display.

> 
> $ ls -a | grep Xauth
> .Xauthority
> 
> $ cat .Xauthority
> [empty]

You do have write access to
        ~/.Xauthority
don't you ??

> 
> $ xauth  -f ~/.Xauthority list
> [no result]

This hasn't been written back out !!

> 
> $ xauth list
> xauth: creating new authority file /home/myusername/.xauth6GGIy3

It will say this if the file is non existent or empty.

It won't actually create an empty one tho', if there isn't one.

> 
> $ ls -a | grep xauth
> [no result]
> 
> 
> So... apparently .Xauthority do not have any function, the only cookie 
> file used is .xauth**code**. Once I suspend the session the cookie is 
> removed and it's not generated anymore.

Yup

> 
> I made a backup of the cookie before suspending the fresh session, and I 

> restored it once the session has been restored. Once the cookie is back 
> in place, it works! I can open new windows and everything works fine!

Yup
 
> I see now where the problem is... but, how could I fix it ? Does FreeNX 
> have problems with the fact that the cookie is called .xauth*code* and 
> not .Xauthority? Or is the issue somewhere else?

FreeNX its-self uses the one in
         .nx/C-machine-port-session-no/authority
but
it doesn't set
         $XAUTHORITY
so
your session and apps etc. normally use the default,
unless
something else sets it.
but
FreeNX "should" write the contents of its own cookie file out to
        ~/.Xauthority
(and then it merges back I think, but I haven't followed it all through
and nothing gets merged on my systems)


I'm not quite sure what your setup or fluxbox are doing . . . .

You could try a bodge overwrite of XAUTHORITY in your fluxbox
launcher script 
but,
my advice is (FWIW) is
grep to find where your XAUTHORITY is computed and set
and then
try hard clearing it,
eg
        unset XAUTHORITY
 so the default is used.

Then TEST everything, because there may be other implications

Let us know if you find anything out about it.

cb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20110513/ad8a42b7/attachment.html>