[K12OSN] LTSP 5.2.4.5 - lts.conf is not read

[Brian Fristensky]

Burke Almquist wrote:
>> I also did the following:
>>
>> In the Firewall wizard set
>> TFTP 69/udp
>> Other ports: 177 udp xdmcp
>>      
> I think by default (at least in previous versions) the bridge br0 was a trusted interface. All traffic on a trusted interface is allowed by default. Check and make sure that is turned on (or temporarily disable the firewall) and restart it.
> Then you know if your firewall is blocking traffic.
>    
It's not a firewall issue. I did the experiment of turning off the 
firewall with the same result.
There are really two issues:

1. At least one important environment variables is  not being set: 
LDM_XSESSION. It took tremendous effort to discover that this was why 
every user would get kicked back to the
login screen at login. Messages from /var/log on the client showed that 
they were logged
into the server alright, but ldm had no way to know which desktop to 
use. I verified this by
adding the following line to lts.conf

LDM_XSESSION=gnome-session

Now, users can login. But to discover this, I had to solve problem #2. 
The point is that none of the sample lts.conf files I have seen ever had 
this line in them. So LTSP SHOULD be able to figure out which window 
manager to use without having to read lts.conf.

2. lts.conf isn't being read from the server. It was only after I copied 
lts.conf to /opt/ltsp/i386/etc, and rebuilt the image,  that this file 
had any effect.

I have done some detective work, trying
to sort through the rc scripts to figure out which script actually reads 
lts.conf, but
with no luck.

It doesn't help that the LTSP Administrator's Reference guide has not 
been updated to reflect the locations of files. Specifically, Chapter 6 
describes the steps in the boot process. Step 13 refers to /etc/event.d 
and /etc/rcS.d, neither of which exist in the chroot. In step 16,  it 
refers to the file /etc/rc2.d/ltsp-client-core, which is also not in the 
chroot. So I am a bit lost in trying to figure out which script reads 
lts.conf from the server.

I will reiterate that these problems are seen on a fresh install (not an 
upgrade) of Fedora 14. However, I discovered the problems on an existing 
F13 system.

-- 
============================================
Brian Fristensky
971 Somerville Avenue
Winnipeg MB R3T 1B4 CANADA
bfristen at shaw.ca
204-261-3960
============================================