David,
I disagree very much. Please see my comments below...
David Johnston wrote:
> Jason Bechtel wrote:
>
>>Jim and LTSP list,
>>
>>Should this be part of the automatic and/or documented DHCP settings
>>when configuring LTSP (default, everywhere)?
>>
>>It seems like nothing is risked by giving infinite leases to fixed
>>address workstations... The only question is, what happens when you
>>replace a network card in a station and want to reassign the IP address
>>to the new MAC address? And the answer seems to be that you would need
>>to update the DHCP file anyway, and restart the DHCP server (or at least
>>get it to reread its conf file with some sort of signal). My only
>>remaining concern (no way to test it myself here) is if this would be
>>enough to "forget" the infinite lease of that IP address to another MAC.
>> Can anyone verify this? It would be a great addition to the polish
>>and stability of LTSP.
>>
>
> As I understand it, ltsp uses dhcp in part to make IP address
> assignments completely automatic. Infinite leases break this by
> preventing address recycling.
LTSP uses bootp just as well as DHCP (and bootp is anything but
automatic). It uses these services to allow each station to obtain an
IP address and the location of a kernel that it can download using tftp.
Any function offered beyond this is mere convenience.
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. The only reliable point at which to do this is at the MAC
address level.
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! One can no longer perform the most fundamental function of
LTSP! That's why 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). DHCP has superior flexibility in
its configuration file and the ability to support dynamic address
allocation for other parts of the network, so we usually use DHCP. But
for LTSP clients, there is no dynamic assignment whatsover.
> As long as the dhcp server stays up, the only downside to lease
> expirations is a few UDP packets between the workstation and the server
> at lease renewal. Most of the time, a given workstation will get the
> same address every time.
>
> In a production environment, there are many justifications for leaving
> your servers up all the time and few for leaving them down most of the
> time.
Yes, the original context of this discussion was someone who would shut
down their DHCP server after booting up his one client. This is a
strange case and obviously not relevant to corporate use. But *if* we
can satisfy all customers with one catch-all default setting (always
allowing for someone to be able to change from the default), then we
should do that.
> Jim and the other developers have done an amazing job of making LTSP
> ready to run "right out of the box". In any installation, however,
> there will be aspects of *any* system that will require some
> configuration. A checklist of likely problem points would be a great
> idea, but I don't think infinite leases are a good idea in most
> installations.
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 and how do you assure that the settings in the lts.conf file
get applied to the right client? Perhaps I'm missing something... Ah,
I just searched the docs for 3.0 and found this:
"The lts.conf file has a simple syntax, that consists of multiple
sections. There is a default section called [default] and there can be
sections for individual workstations. The workstations can be
identified by hostname, IP address or MAC address."
The ability to specify workstation sections by MAC address resolves my
confusion over *how* you might be doing it, but...
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? I can see how
if half of them are turned off and their leases expire, then perhaps
some laptops could join the network using those addresses, but what have
you gained? You could just as easily have assigned a range of dynamic
addresses for the laptops to eliminate any problems with IP address
interference.
I suppose avoiding the tedium of having to collect all of the MAC
addresses and information about their corresponding hardware would be a
good reason to do this. 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?? Also, the
nested structure of the DHCP configuration file would allow you to place
the "default-lease-time -1" clause safely inside of a "group {}" block,
isolating it to only your LTSP workstations.
Jason
PS: Sample dhcpd.conf file as an example:
<various global settings>
subnet 200.0.0.0 netmask 255.255.255.0 {
# declaration of subset of network to handle dynamically
range 200.0.0.150 200.0.0.169;
group {
filename "/lts/vmlinuz.ne2000";
use-host-decl-names on;
host ws01 {
hardware ethernet 00:50:BA:A0:6E:76;
fixed-address 200.0.0.31;
}
.
.
.
}
group {
filename "/lts/vmlinuz.tulip";
use-host-decl-names on;
host tn07 {
hardware ethernet 00:03:6D:13:81:23;
fixed-address 200.0.0.74;
}
.
.
.
}
}
_____________________________________________________________________
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
