John, Sorry it didn't work for you, but it does work for many people.
If you'd like to see changes to the docs, or the install scripts, hey, we do accept patches. You need to understand that this is a volunteer effort, and we are all extremely busy. I do appreciate your comments, but what would really help is for someone to jump in and update the docs to reflect the changes you have highlighted. The source for the docs is out there on the download site. Jump in, make the changes, and send me the patches. As for your comments about logging in as super user, the config script for LTSP-4 does handle that issue, and it will complain if the path is not setup properly. Look for that to be released in the next couple of months. Thanks, Jim McQuillan [EMAIL PROTECTED] On Mon, 16 Jun 2003, John Reiser wrote: > I decided to try LTSP after being enticed by a recent article: > http://www.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=134&page=1 > and the claim on the LTSP home page that Redhat 9 was supported. After a > couple days of trying, my conclusion is that the claim is overoptimistic. > In fact, a default install of the latest ltsp-3.0.x onto a default install > of Redhat 9 Workstation is guaranteed to fail: no client box can ever connect, > unless significant changes are made. The trouble-shooting guide (Chapter 6 > of the documentation) provides only marginal help. Newbies should not even > attempt it. > > My network has a mixture of linux/x86, macintosh/ppc, and windows/x86 boxes > connected via ethernet behind a consumer-grade firewall+router+switch that > provides DHCP+NAT (and nothing else: no DNS, no tftp, no bootp, ...). This > is used because of small physical size, low power dissipation, low cost, and > no fan noise. [Each computer is powered down daily; the ethernet is not.] > Changing the basic network is not an option. Thus it was very mysterious > how to run a second DHCP server on the same network. After searching the > archives of ltsp-discuss and some experimenting, I found _an_ answer for > _my_ /etc/dhcpd.conf: > -----[various snips: beware of context] > not authoritative; > > shared-network WORKSTATIONS { > subnet 192.168.0.0 netmask 255.255.255.0 { > range dynamic-bootp 192.168.0.40 192.168.0.59; > ping-check true; > deny unknown-clients; > } > } > > host ws001 { > hardware ethernet xx:xx:xx:xx:xx:xx; > fixed-address 192.168.0.20; > } > ----- > where the important pieces are the "not authoritative;", "deny unknown-clients;", > and the fixed-address being outside the dynamic-bootp range. The lstp > documentation ought to cover this; networks like mine are not uncommon. > > The /opt/ltsp/templates/ltsp_initialize script fails for the common > situation of 'chkconfig' not being found in $PATH, even though the > shell has superuser privileges. This happens when doing "su" > instead of "su -". The directions say "login as root", but many "remote" > boxes have the reasonable restriction that root may not login remotely. > If ltsp_initialize determines that chkconfig is not in $PATH, then the > script should give a warning message, add /sbin to the $PATH, and try > once more. > > Now for the most serious reason that ltsp fails: The default Redhat 9 > Workstation installation has an iptables firewall that blocks every > port needed by ltsp. [This is also true for Redhat 8.0.] Yet > ltsp_initialize blithely ignores this! Not only that, the documentation > doesn't even contain an explicit list of all the ports that matter! > It may be tedious to get everything correct, but the install must > at least try, and issue detailed, explicit messages in case of doubt. > Check for the existence of service iptables (links below /etc/rc.d, > and/or file /var/lock/subsys/iptables), and/or its rules (default file > /etc/sysconfig/iptables}, and respond. > > My experients showed that these ports matter: 69 (tftp: udp and tcp), > 111 (portmapper: udp and tcp), 177 (xdmcp: udp and tcp), 514 (syslog: udp), > 2049 (nfs: tcp and udp). Also, the current NFS-HOWTO (August, 2002) > http://www.tldp.net/HOWTO/NFS-HOWTO/server.html#SERVERINTRO > says that /etc/hosts.allow must contain "mountd: 192.168.0." > After enabling all those ports, finally a client box could connect. > > Please give the complete list of ports that LTSP uses, > along with example rules that work for iptables [and for ipchains], > and discuss at least the first level of security exposures and counter- > measures. In particular: exhibit a _good_ set of iptables rules for > serving ltsp clients (on the single behind-the-external-firewall ethernet > with other non-ltsp machines), and explain how they are any less secure > than a separate ethernet for ltsp service only (but the ltsp server > is on both networks, and gateways between the ltsp clients and the other > network), assuming only that there are no bugs in iptables. > > Now to try some real work using an ltsp client ... > > Regards, > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net > -- ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
