David-
>>Since many (probably the great majority of) LTSP environments are not
>>done with 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? What about printers?
>>If by "address recycling" you are talking about having LTSP workstations
>>receive effectively randomly assigned IP addresses (and therefore
>>hostnames via DNS/hosts) then the functionality of the lts.conf file is
>>broken.
>>
> 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. If you keep monitors with
clients, this solves the X settings problem. But what about local
printers? Hmmm... I think I'm getting confused. Can I see your
dhcpd.conf file and your lts.conf file?
>>...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. :-)
>>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.)?
>>2) Why bother? Just set aside a block of addresses to be assigned
>>statically to your LTSP clients. What do you gain with dynamic address
>>allocation if you always have the same number of clients?
>>
> See my comments above. I am assuming that, since they are doorstops I
> rescued from the trash, the terminals are going to fail regularly. When
> they do fail, I want replacing it to be a no-brainer; in particular, I
> don't want to have to give anyone a password so they can muck around in
> my dhcp config or lease files.
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.
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. 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.? 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?"
As another point of view, consider the imposed hurdles to LTSP adoption.
Requiring uniformity and network isolation raises the bar
considerably. 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.
Jason
_____________________________________________________________________
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
