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

Reply via email to