[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Diety / Apt Questions.

hospedales  <hospedales@wow.net> writes:
>> IF you are not running multiple X displays on your machine then a
>> simple technique is to 'su' in an xterm,
>> 'cp /home/<user>/.Xauthority /root'
>> which will then let root open things on your display.
h> So does root get to keep my user's .Xauthority file permanently
h> then? Or is .Xauthority periodically generated?

The .Xauthority file (or at least, the part of it that pertains to
your local server) gets regenerated whenever you log in via xdm.
Symlinking the .Xauthority files means that root will always have the
same cookies as <user>.

h> (Man -k xauthority and variations thereof return nothing. :(...)

Try 'man xauth'.

h> And what does the .Xsession file that someone was talking about do?

It specifies X clients that should be run; when the .xsession file
(lowercase x) exits, you return to the xdm login prompt.  In mine, I
set up some environment variables, load X resources, set up a
background window, and finally exec fvwm2.  .xsession isn't really
relevant to this particular problem.

>> BTW, unless I am mistaken, you never need to do the 'export DIPLAY'
>> command unless you are trying to open a display on a display OTHER
>> than the on that you are using to issue the command.
h> So if I am logged into a remote computer telnet, could I do xhost
h> +remotecomputer on mine, and export DISPLAY=myipaddr on remote, and
h> then start some X program on remote and have it send the display to
h> my Xserver?

Subject to the other rules about who may connect to the X server
(xhost/xauth access control), yes.  xauth really is a better way to do 
this than xhost; see the xauth man page for an example.

/                             \       "Dad was reading a book called
|          David Maze         |     _Schroedinger's Kittens_.  Asexual
|         dmaze@mit.edu       |  reproduction?  Only one cat is in the box."
| http://donut.mit.edu/dmaze/ |               -- Abra Mitchell

To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: