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.