<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> I have attempted numerous installs of LTSP 5.2.4.5, obtained from the repo at <a class="moz-txt-link-freetext" href="http://www.dageek.co.uk/ltsp/x86_64/">http://www.dageek.co.uk/ltsp/x86_64/</a> To summarize, two things seem to be a problem: 1. ltsp will not read /var/lib/tftpboot/ltsp/i386/lts.conf from server when the thin client boots. The only way to fix this problem is to copy the lts.conf file to /opt/ltsp/i386/etc/lts.conf. That means that each time this file is changed, we need to rerun ltsp-update-image. 2. The reason this is a problem is that the ldm client on the TC seems to be missing important environment variables. At the very least, we need to include in lts.conf a line reading <pre> LDM_XSESSION=gnome-session</pre> Unless this line is present, ldm tries to start an X session, but doesn't know which one to start. The result is that after the user types their password, they get kicked back to the login prompt. (This one is a separate issue that needs attention.) Finding these things out took about a day, and required adding debug statements to the following scripts: /opt/ltsp/i386/usr/share/ldm/ldm-script /opt/ltsp/i386/usr/share/ldm/rc.d/S01-setup-xauth /opt/ltsp/i386/usr/share/ldm/rc.d/X95-run-x-session It is not straightforward to figure out how LTSP sets its critical environment variables. The PDF administrator's guide is obsolete, in terms of telling which scripts read the remote lts.conf. For example, /opt/ltsp/i386/usr/share/ltsp/ltsp_config first tries to read /etc/lts.conf, then also looks for /var/cache/getltscfg-cluster/lts.conf <pre># Read in lts.conf entries. if [ -f /etc/lts.conf ]; then eval $(getltscfg -a) || true fi</pre> <pre>if [ -f /var/cache/getltscfg-cluster/lts.conf ]; then eval $(getltscfg -a -c /var/cache/getltscfg-cluster/lts.conf) || true fi</pre> So maybe the question is, what is keeping ltsp_config from reading lts.conf? I have been able to reproduce these results on Fedora 13 and 14. I did a "from scratch" install of F14 on a laptop yesterday. In addition to following the install instructions on the Wiki at <a href="https://fedorahosted.org/k12linux/wiki/InstallGuide">https://fedorahosted.org/k12linux/wiki/InstallGuide</a> I also did the following: In the Firewall wizard set TFTP 69/udp Other ports: 177 udp xdmcp I have turned off SE linux, which always seems to mess up LTSP. The result is that now users can login, but that doesn't solve the problem of why lts.conf isn't being read from the /var.... directory. One thing that is slowing me down is that on Fedora 14 I can't set a password on the TC to allow me to login as root on the TC. Usually, this is as simple as going into the chroot and then typing 'passwd'. However, when I try to run passwd I get: <pre>passwd: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 is not authorized to change the password of root</pre> My gut feeling is that this is an SE_Linux message, but I've disabled SE_Linux. Does this message look familiar to anyone? Brian Fristensky P.S. For those wanting to try LSTP on Fedora 14 you must install it from the repo listed above, and NOT the from the Fedora repo, which is an old broken version. You also need to copy the files described in comments 15 and 16 of bug 652896 at bugzilla.redhat.com. </body> </html>