[K12OSN] LTSP 5.2.4.5 - lts.conf is not read
Brian Fristensky
bfristen at shaw.ca
Sat Mar 26 17:34:38 UTC 2011
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
============================================
More information about the K12OSN
mailing list