[mythtv-users] OT: Gotcha for Mandriva users

[Mike Perkins]

This may also affect users of other OSs, YMMV, etc.

I decided to pull a copy of trunk onto a development machine to get familiar 
with 0.22 prior to release, in order to plan my upgrade, which will probably 
also involve OS upgrades.

After eventually finding all the dependencies (what fun...not) I did ./configure 
and looked at the result. It occurred to me that as my "development" box has 
very little poke I could use the resources of my big file (and LTSP) server by 
installing distcc and spreading the compilation across the two machines.

After several goes the make started and I got a number of seg faults. Having 
used way too much time on this I decided to look at the problem later and 
instead log back onto my server to get the latest mythtv mail.

No go. Nada. It just bounced me back to the gdm login screen with a cryptic 
message about "Orbit". OK, try KDE. That failed with a different obscure error. 
Shit. OK, try logging into the dev box and SSH'ing across, I know that works.

Nope, can't log into that either. Eventually, I determined that I could get into 
either box using IceWM. Plenty of room on the disks on both machines, it wasn't 
as if the failed compiles had used up all the disk space or something.

To cut a long story short, I eventually tried starting Firefox from within a 
terminal under IceWM, and got an error message something like "Can't create file 
under /var/lib/distcc/....". Eh?

It turns out that the version of distcc which comes with Mandriva sets up 
various environmental variables under /etc/sysconfig/distcc - like most other 
apps do. One of these is "SET TMP=/var/lib/distcc".

It seems that on login using Gnome or KDE, *every* file in /etc/sysconfig gets 
*sourced* into the users environment - in this case overriding TMP, which should 
point to /home/<user>/tmp. /var/lib/distcc of course doesn't have the right 
permissions. I had just to delete the SET TMP line on both hosts (and stop the 
distcc daemon) and I was good to go.

Oh, and another good'un: on my server, the "distcc" user used and overwrote the 
"ldap" user entry, thus mangling every ldap directory and file. I guess whoever 
set up distcc hard-coded the UID/GID in the package. Bad boy.

Moral of this tale - don't assume that distro suppliers test things out the way 
that you're going to.

-- 

Mike Perkins