It's the end of the semester, so things have been pretty busy at work, with students working on final reports and projects, trying to get those last results in, and my having to print a whole slew (around a dozen) posters on the department's DesignJet 1055cm.
What better time, you might ask, to update one's machine? Indeed. Partly in anticipation of Tiger, and the need for having an external drive to do backups before updating, and partly out of a feeling that my workstation should be a bit more stable than it is, and partly out of sheer perversity, I decided to update my machine from CentOS 3.4 (plus a large agglomeration of miscellaneous software) to CentOS 4.0.
When I say update, here, of course, I mean “backup to another disk, put a third drive in, and then install from scratch”. I'm not a complete idiot.
Anyway, CentOS 4 installed reasonably smoothly, and had some nice new features (particularly the newer version of GNOME). What it didn't have, of course, is any of those “extra” packages that I've built over the last couple of years. Oh, and it did also come with some wacky changes.
The most notable wacky change stopped me from opening X clients on
remote machines on my workstation. Remote administration can get to
be a real pain when you can't use the tools you prefer, especially if
you're trying to edit or compare long files. I started by checking
out the SSH configuration files, comparing them with my old files, and
noticed that X11Forwarding was turned off by default in
/etc/ssh/ssh_config. That change let me connect to the
CentOS 3 machines, but I was still having problems opening windows
from my workstation (doing things like, say, trying to edit the SSH
configuration files with Emacs). Given that another change between
CentOS 3 and 4 was a move from XFree86 to Xorg, I thought that might
be where the issue was, and decided to let it lie for a bit while I
dealt with more pressing work.
I limped along for a couple of days, but between needing to print the posters (easier on Mac) and doing some web graphics (easier on a Mac) and fiddling with some CSS stuff (you guessed it), I ended up just hooking my PowerBook to my nice monitor and keyboard and using it for the last week or so. I still couldn't open X clients from my main workstation (annoying!), but at least I could open them on other machines, so I could get some of the stuff done that I needed to do.
Of course that wasn't good enough, either, so I ended up pulling the LCD out of my rack so I could put it on my workstation to do a couple of things. But I've still been too busy to really look into the issue.
I was getting by with my Mac until this past week, when suddenly nothing could connect to the Mac, either! Including my home (Debian development) machine, which had worked. I had, of course, just upgraded to Tiger, so it seemed like the problem that was affecting the CentOS 4 machine might have been the same issue on Mac OS X.
Finally, though, I got a chance to look at the CentOS mailing list, and found that someone else had asked about the same problem, which generally looks like
The program 'foo' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 287 error_code 5 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
It turns out that another, badly documented, change was to SSH
itself. In addition to setting ForwardX11 to
yes (or using the -X flag on the
ssh command line), you now also need to set the
ForwardX11Trusted key to yes, or use the
brand new -Y flag on the command line.
The OpenSSH FAQ addresses this issue, but it would have been nice if the distros including the new SSH had mentioned it, as well.
