I'm trying to remotely login to my Ubuntu machine from the MBP.

xnest -broadcast -geometry 1280x778

Finds my ubuntu manchine and presentes it's login screen.
I login, and from then on out, the keyboard is scrambled.

xphyer seems to do the same.

Screen Sharing seems to work fine but I need to leave the Ubuntu machine logged in for that to work.

Am I just lacking the proper configurations, or should I be looking for an additional piece of software?

Google has a cached page from Apple showing that there was an applescript for doing this, but Apple has taken it down.

I'll give that a try.

But, How did you find that article?

I tried some of the keywords like XDMCP and found nothing like that.

Well, saving the xmodmap to .xsession didn't seem to help.

Well it appears that Ubuntu 9 doesn't use the xmodmap mechanism. It has some gui driven keyboard configuration tool.

Rather than xnesting, I prefer to just use ssh to connect.

GUI apps can still be launched on command, and will display back on the local screen just fine. And with lower bandwidth than a full X(nested) session.

Cheers

Trevor,

Found what I did wrong with xmodmap.

I had to be run in an xterm that was sourced from the remote machine and displayed on the MBP. I had started an xterm on the MBP SSH'd to the server then ran xmodmap -pke.

Mark,

Sounds like good advice. I once, for about eight years, used SUN workstations at work. It seems most of what I learned has decayed or been superseded since then. Tonight I learned that the Xquartz project is setting things up where all that's needed is to start the remote program and automagically X is invocked locally to serve.

Currently when I SSH to the server, and start an app, I get a generic X herringbone screen that obscures the mac desktop. I don't yet know if that is normal, of If the remote app should just float.

Now that the .Xmodmaprc is sorted out, the command...
ssh me@remotecomputer gnome-session gives me a full ubuntu desktop. Good enough for now.

Uh, everything you need is built into MacOSX. You may not have installed the Apple X11 server, though. It should be on your install media. There's no need to download anything. Once it's installed, just run "ssh -X server" and X11.app should start automatically. Then when you run an X application, it should appear on your local machine. "xcalc" is a good ubiquitous test application.

Is this how you are doing it?

http://paininthetech.com/2005/11/07/x11-forwarding-and-ssh-on-os-x/

edit:
This does work easily, though SSH dosen't seem to care if I put -X or -Y or nothing as an option.

Yes, that's how I'm doing it.

The fact that you don't need to include an option probably just means that the ssh configuration is set up to request X11 forwarding by default.

Most of the errors I was seeing in the xterm, disappeared when I did it that way. One web page I found, said this was because a second Xserver was being invoked.

There is still one error that appears when I try to run some remote apps.

It seems that there is an Xlib extension named RandR (rotate and resize) which the error claims is missing. Not sure if that means it's missing on the Ubuntu box or the Mac.

On the Mac. Specifically, on the Mac's X server. It's possible that Xquartz supports RandR; I'm not sure. If so, you should be able to run Xquartz in place of X11.app and have everything else remain the same.

After more googling about OSX and RANDR errors, I found this.

edit: Ha! This seems to be the oldest unclosed ticket the the system.

RANDR isn't currently implemented.

Xlib: extension "RANDR" missing on display "mydisplay:0".
RandR extension missing

The whole point of extensions is that you're meant to query for their presence, and carry on (maybe missing some features) if they aren't there. Your remote apps would have to be pretty specialist (or oddly-written) to outright require XRandR -- are you sure that that was the only error, the reason why they wouldn't run?

Peter

Sorry for the miss-impression, all the apps I've tried have indeed run.

It's just that many generate the error in the xterm where they were invoked. Most of the old old unix programs don't, while almost everything gnomish does.

In the case of gnome-session, many of it's components each generate that error. Don't know exactly why they are looking for RandR. Maybe it's just something compiled in everywhere, needed or not.

Gnome constantly spews out warnings. Just ignore them.