Jason Bechtel wrote:
>
> David-
>
> >>Since many LTSP environments (do not have) uniform hardware in the
> >>workstations, one needs to specify different video, NIC, and perhaps
> >>kernel file settings for different workstations.
> > That's not so true with version 3. The autodetection seems to work
> > fairly well.
> Good point for NIC and video hardware settings, but what about different
> X settings for old monitors? Don't you run into this with all your
> doorstop workstations? Also, I know X4.2 fixes the S3 driver, but
> before 4.2 came out, how did you specify the XF86_S3 driver instead of
> 'auto' for your S3 clients?
I have to admit that I haven't run into any S3 video cards. I've also
encouraged clients to use the savings to justify purchasing modern
displays for their doorstops ;-)
> What about printers?
I avoided this issue by using network-attached printers. For small
print loads, I'd use something like an Epson 777 and a $75 to $100 print
server (Netgear, D-Link, or Linksys). Netgear's PS105 included a 4-port
ethernet hub, which made it a perfect solution because I didn't even
have to worry about an extra wire to the desk. Unfortunately, they
aren't available in the US any more.
> >>If by "address recycling" you are talking about having LTSP workstations
> >>receive effectively randomly assigned IP addresses...
> > No, that's not what I meant. One of the fundamental advantages of LTSP
> > is that the terminals can be (and generally are) old equipment. This
> > means that they are inexpensive, but prone to failure. When a terminal
> > does fail (as I expect and plan for), I want to be able to tell someone
> > to grab a spare from the closet and stick it on the desk. I want
> > terminal installation to be so simple, even a pointy-haired boss can't
> > screw it up. This lowers failure cost and downtime, which I consider a
> > major selling point for LTSP.
>
> Okay, that makes more sense... :-)
>
> If the station losing its address is not going to return to the network,
> then there is less of a problem, unless several fail together (power
> spike, bad luck) and you run out of addresses (as you explain in your
> example with the C-class network).
>
> I'm still not convinced how you avoid *all* workstation-specific
> settings, though. Oh, wait, I think I get it. You *do* specify the
> workstation-specific settings, but by MAC address. And you just don't
> care which IP/hostname the thing gets.
Exactly.
> >>...all of the LTSP setups I've been involved in have had entries that
> >>match a MAC address to a fixed IP address, hostname, and kernel (either
> >>through bootp or DHCP). ... But for LTSP clients, there is no dynamic
> >>assignment whatsover.
> > This is fine, but it increases network management, something I'm trying
> > to get away from.
> I see. I'd never considered trying for that level of automation with
> LTSP. I just assumed that LTSP clients required a lot of configuration
> in various services and that if I wanted automation, I would have to
> find more automated ways of performing the configuration steps (never
> considering the option of trying to remove those configuration steps).
>
> > I agree, one catch-all default is a good idea. We simply disagree
> > regarding the usefulness of this specific default. I still argue that,
> > in a normal work environment, dynamically assigned IP addresses with a
> > one week lease provides a good approximation of static IP addressing
> > without needing any oversight.
>
> I don't like the feeling of an arbitrarily chosen expiration time that
> "approximates" a good solution... I'm holding out hope for a lock-tight
> solution. :-)
I'd love one, and when I find it I'll jump on it. But I can't wait ;-)
> >>If you have a pool of LTSP workstations and are handling IP addresses
> >>dynamically...
> >>1) I'd love to hear how you are pulling it off. How do you assign hostnames?
> >Are they necessary?
> >You can use nsupdate at login time to map hostname=username (this one
> >has problems, of course), or you can simply name them ws001, ws002, etc,
> >based on the last octet of the IP address.
> But if the hardware/location changes for the same IP/hostname, how do
> you handle the things I mentioned above (X settings, printers, etc.)?
I don't. I try to get X settings to be the same for all terminals, and
use network printers.
> >>2) Why bother? ... a block of (static) addresses (for) LTSP clients...
> >>What do you gain with dynamic addresses
> >I assume that the terminals are going to fail regularly. I want replacing
> >it (a failed terminal) to be a no-brainer
> All you have to do is replace the MAC address in dhcpd.conf and restart
> the DHCP server. It's a 5-minute procedure at the most that you *might*
> have to perform once in a week. I agree that it does cost a finite
> amount of $$$ (or ¤¤¤), but it's not that bad.
Yes, but I'm not always available. At some sites, there's no one who I
trust with the root password.
> It sounds like you have workstations that all have the same (or all
> modern and equally capable) monitors and no local printers. In this
> situation, you might be able to get away with dynamically assigning
> addresses to your clients. But I think most people cannot depend on
> this uniformity.
I justify the expense of replacement monitors with reduced management
expense. A network with 200 workstations running Windows 98 would need
a full-time staff of three; 200 LTSP workstations can be maintained with
a part-time staff of one.
> It seems to me that the default for LTSP should be to allow for the
> flexibility. For people who want to do what you are doing, you can
> comment out the 'default-lease-time -1' setting one time when setting
> up LTSP to avoid having to perform the ongoing MAC address replacements.
> Then there is again the question of also having to manage all those MAC
> addresses, though. Hmmm...
>
> >>Then you would only need to get MAC addresses for clients who deviate
> >>from the norm. But now we're talking about making the default response
> >>of the DHCP server (regardless of the MAC address of the client) one that
> >>handles LTSP workstations. Doesn't this seem just as imposing as specifying
> >>an inifinite lease time?
> >>
> > Not quite. Assume a class C network with 250 terminals. Three failed
> > terminals, and someone who knows what they are doing (=$$$) has to clean
> > up the dhcp files before a fourth terminal can be dropped in.
> <snip (example)>
> > On the other hand, if we use weekly leases then #52's IP is available
> > about a week after failure. This is completely automatic and requires
> > no intervention, which means that, in the long run, it is cheaper to
> > maintain.
>
> Okay, so you're also assuming a subnet with *only* LTSP clients and the
> LTSP server. What about printservers, Windows PCs, other Linux servers,
> NCD X-terminals, etc.?
The example holds true for this, too. Servers get static IP addresses
(assigned in dhcpd.conf by MAC), and Windows PCs should work fine with
dynamic addresses take from the same pool of addresses as the
terminals. I have to admit, however, that so far I've managed to
segregate LTSP terminals on a separate subnet (not always on separate
wires, though), so I can't testify that Windows PCs will always work
this way.
> What about when the president of the company says, "I want a printer on
> my desk, but I don't want to pay for another printserver. Can't we hook
> it to this X-terminal thing like when it was running Windows?"
Give him the printer. Between his time and mine, it will cost the
company more than $75 for us to discuss it.
That said, a good manager isn't going to care how I get it done, just
that it works.
> As another point of view, consider the imposed hurdles to LTSP adoption.
> Requiring uniformity and network isolation raises the bar considerably.
Uniformity, yes; network isolation doesn't really cost more than $50 (my
time to set up a new set of addresses).
> Adding a default setting to the dhcpd.conf file which
> requires no more than is already required (a range of fixed addresses)
> is a much lower hurdle.
>
> I admit, the full automation possibilities are *very* tempting, but
> networks are usually too complex to allow for this level of convenience.
A separate subnet doesn't require a separate wire, just a route added to
the LTSP server.
LTSP makes intensive use of the network. A token-ring network, for
example, is going to have trouble. I've noticed that even a 10Mb
network can get into trouble. I think the network requirements are
often a bigger hurdle than details like IP addressing.
-Davdi
_____________________________________________________________________
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.openprojects.net
