I suppose this could be considered off-topic, but having finally
finished setting up my new workstation I thought I'd brain-dump some
things that I had to work out how to do. I had a devil of a time
googling for some of this stuff, and found lots of forum threads etc.
where some of the same questions I had went essentially un-answered,
so I wanted to put these tidbits out in a place where they'd be
archived and searchable. In no particular order ...
I never did get my second onboard NIC working. The ASUS P5N32-SLI
Deluxe motherboard is otherwise working fine, but the Linux drivers
aren't able to differentiate the two identical nVidia NICs; I can only
use one or the other. Hopefully that'll change soon, but I'm not
holding my breath.
Networking was broken briefly when I copied "LOCAL: ALL" (among other
things) from my old workstation's configuration into /etc/hosts.allow,
and "ALL: ALL" into /etc/hosts.deny, because "LOCAL" does not match
"localhost.localdomain" which is the first name for 127.0.0.1 in
/etc/hosts. Sendmail refused connections from the local machine
(e.g., from fetchmail) until I realized what was going on. Be sure to
list localhost.localdomain explicitly in hosts.allow.
I wanted to start some ssh tunnels automatically when I log in. I
tried putting the ssh commands directly into the Gnome "Startup
Programs" (via Applications -> Preferences -> More Preferences ->
Sessions) but that had the effect of causing logins to hang for 2+
minutes after putting up the splash screen. Eventually (see next
item) I guessed that the session manager was waiting for the
application to open a window, which of course ssh never will. The fix
is to use an iconified terminal window as the "Startup Programs"
entry, so that the session manager sees a window appear and knows that
the application has started, and run ssh in the background from that
terminal. E.g.
xterm -iconic +hold -e ssh -N -f ...
The icon appears briefly, then vanishes when ssh has backgrounded
itself. If you need to typa a password and gnome-askpass fails to put
up a dialog, omit the -iconic option. Also, it's important that the
priority of this startup item be set to a larger number than that of
metacity and gnome-panel; I chose "45".
Speaking of the session manager ... I have some applications that run
as root that need to open windows on the X server. This was failing
with:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
On my old workstation I'd fixed this by linking root's .Xauthority
file to the one in the logged-in user's home directory, but that
didn't work on CentOS 4 because something (I still haven't figured out
what) sets XAUTHORITY in root's environment to point to a
randomly-generated file name, even if "su --preserve-environment" is
used. The fix for this (which no one got right on any of some dozens
of mailing lists/newsgroups where Google turns up references to this
error) is for root to run:
xauth merge /home/otheruser/.Xauthority
However, even though the application can now open its window, it still
issues a complaint:
Warning: Tried to connect to session manager, Authentication
Rejected, reason : None of the authentication protocols specified are
supported and host-based authentication failed
To eliminate that message, root must also run:
iceauth merge /home/otheruser/.ICEauthority
Note that this must happen after the session manager has started up.
I built and installed an RPM for an older calendar application (ical)
which showed up in the Applications menu in three separate and
inappropriate places. Turns out that it had placed its ical.desktop
file in /etc/X11/applnk/ instead of /usr/share/applications/.
That's about it; I had some other things I was going to mention, but
on writing them down I decided they were too specific to my personal
environment to be worth mentioning. There are still a few things I
have questions about, but I'll leave those until I either get them
solved or run out of other places to inquire.