>From: "Jeramy Eling" <[EMAIL PROTECTED]>
>> Has anyone had any luck in using a Windows 2000 DHCP Server with LTSP
>> instead of a Linux one? I am looking at Linux as a long term goal for
>> our network but for the moment I really need to stay with a Windows 2000
>> DHCP Server.
From: Alex Perry <[EMAIL PROTECTED]>
> Yeah, that's what we're using right now. [...]
There are basically four gotchas to watch out for:
1. The stupid user interface. You have to be really rigorous in selecting
the parameter options and setting values in order to get everything right.
Fill in settings for DHCP (not BOOTP) and for user client dropbox only,
then watch a client trying to boot and make guesses on what you forgot:
From: Marvin Pascual <[EMAIL PROTECTED]>
> Huh? How could you do that? I'm just curious as I was also thinking
> about how could I possibly implement it just in case there would be an
> existing Windows 2000 DHCP server. Would you mind sharing it to us your
> experience and how did you do that here?
2. There are really no diagnostics to see what goes out on the wire.
I suggest using DHCPING, TCPDUMP and DHCPDUMP running under Linux,
as this combination makes the "null insertion" bug blindingly obvious:
From: Alex Perry <[EMAIL PROTECTED]>
> There seems to be a bug in the MS DHCP server, in that a null character
> is appended to some of the parameters that get served out to its clients.
> Modify the DHCP rootpath to "server:/ltsp/i386/" and create the link
> ln -s /ltsp/i386 /ltsp/i386/000
From: "Abraham Pearson" <[EMAIL PROTECTED]>
> We also use Microsoft's NFS and TFTP servers. I called the NFS share
> /ltsp3000. Then I reference it as /ltsp3 in DHCP.
> I am glad that I was not the only one who saw the "000" appended on the
> end of the DHCP rootpath.
3. Unlike messing with Linux's DHCP, the cycle time for test is slow.
I didn't have the patience to debug post-TFTP errors at the same time
as the TFTP and pre-TFTP errors that are triggered by DHCP traffic.
I recommend using a disked workstation, adding two lilo boot options
for etherboot (i.e. the .lzlilo image option) and for linuxterminal
(i.e. local kernel and explicit nfsroot on the kernel command line).
The latter lets you prove that the linux parts of LTSP are working
properly before starting on the Windows portions using the former:
4. We don't use the reservation feature of the server, or rely on the
DNS keeping synchronized with the leases, because it is too unreliable.
The LTS.CONF file lets you identify hosts by MAC address as well as the
usual hostname or ipaddr choices, thereby eliminating that dependency.
Of course, this implies that forward and reverse lookups against the
Windows DNS server are likely to fail for some clients, so be creative.
Hope that helps ...
Alex.
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_____________________________________________________________________
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
