Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Dec 2006 08:17:13 -0600
From:      Lane <lane@joeandlane.com>
To:        Matthew Seaman <m.seaman@infracaninophile.co.uk>
Cc:        FreeBSD Questions <questions@freebsd.org>, Christopher Cowart <ccowart@rescomp.berkeley.edu>
Subject:   Re: xorg on a headless, mouseless, keyboardless box
Message-ID:  <200612170817.13819.lane@joeandlane.com>
In-Reply-To: <4585218A.4030207@infracaninophile.co.uk>
References:  <200612161224.14708.lane@joeandlane.com> <200612161744.01856.lane@joeandlane.com> <4585218A.4030207@infracaninophile.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 17 December 2006 04:52, Matthew Seaman wrote:
> Lane wrote:
> > I can, in fact, run a gui root process on the remote machine, now.
> >
> > Unfortunately I still can't run qemu so that I can get the console.  I
> > get:
> >
> > X Error of failed request:  BadWindow (invalid Window parameter)
> >   Major opcode of failed request:  25 (X_SendEvent)
> >   Resource id in failed request:  0x3e
> >   Serial number of failed request:  18
> >   Current serial number in output stream:  21
> >
> >
> > Any advice on how to setup the remote (headless, mouseless, and
> > keyboardless) server to run X?  My brain is fried trying to track down a
> > HOWTO, and the wiki is just a half millimeter left of useless.
>
> The quickest and easiest method would be to run this on your desktop
> *before* SSH'ing to the other machine:
>
>     xhost +LOCAL:
>
> That means that any user on the same machine (technically, any user
> accessing your display via the local domain socket /tmp/.X11-unix/X0)
> can pop up windows on your X display.  Because of the way SSH X-
> forwarding works, all the processes on your remote machine appear to
> the local X server as if they were running on your local desktop, so
> that command will work for them too.
>
> Obviously this has security implications on machines where you do not
> trust all of the users -- for instance it would be fairly trivial for
> anyone else with access to either of those machines to be able to capture
> all of your keyboard input including any passwords you needed to type.
> You need to be able to trust implicitly both your local desktop and the
> remote server you're logging into.
>
> You can have more fine-grained control by using xauth to copy the access
> tokens for your display into the .Xauthority file in another users' home
> directory:
>
>    xauth nextract - $DISPLAY | su - otheruser -c "xauth nmerge -"
>
> You should only need to do that one time per $DISPLAY, but if you're
> doing X forwarding over SSH, you may need to do that at least once
> for each desktop machine you log in from, even if you get the same
> $DISPLAY setting each time.  ssh, when doing X forwarding, does pretty
> much that internally to forward your credentials so commands on the
> remote machine can display on the desktop in front of you.
>
> Note: $DISPLAY is set automatically for you when you enable X forwarding
> and SSH in.  You may need to quietly eliminate misguided attempts to set
> $DISPLAY in the shell startup scripts of otheruser --- it should inherit
> the value from your environment if you become that user by su(1) or
> sudo(1).
>
> See xauth(1) for more information about what you can do with it -- quite
> a lot more really.
>
> 	Cheers,
>
> 	Matthew
Matthew,

Thanks for the details on $DISPLAY and all of the other information.

This certainly opens up a number of possibilities in remote system use and/or 
management.

Unfortunately it does not provide me the ability to get the "console" from 
qemu ... which is very odd, I think.

There was one instant yesterday after Chris recommended the use of

su -m

when my konsole was presented with an ASCII representation of the 
Windows "loading" screen.  But I cannot seem to repeat the event.  Each 
attempt fails with:

X Error of failed request:  BadWindow (invalid Window parameter)
 Major opcode of failed request:  25 (X_SendEvent)
 Resource id in failed request:  0x3e
 Serial number of failed request:  18
 Current serial number in output stream:  21

Thanks for all the input - But I think I'm just gonna bite the bullet and copy 
the img file, do the repair, and copy it back out.

Lane



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612170817.13819.lane>