> Ok, after reading the latest "how to" on PXE using Etherboot, as well as all
> the messages here - I'm once again attempting to make the LTSP project work
> in our Windows 2000 environment.

Which doc have you read? AFAIK there is no PXE howto as such (I'd really
like to know if you've found one) - I'm in the process of doing a PXE
mini howto, and so I'm answering your email as part of that exercise.
I'd also like to know what information is needed, for a site with
existing MS servers, so that I can make sure that it's all in the
mini-howto.

> All of the clients I'm working with have PXE built into their existing BIOS.

Is it enabled as the "normal" boot mechanism? 3Com 905Cs have PXE in
their boot roms, but it is NOT enabled by default (there are 2 other
boot methods). If you see messages about PXE versions when the machine
boots, you can probably assume that it is.

> One thing I haven't seen mentioned yet is this; Can I use our existing
> Windows 2000 DHCP server to issue dynamic IP addresses from a pool of
> available IPs, rather than hard-code static IPs to specific MAC addresses of
> clients?

Don't confuse static vs dynamic allocation with Linux vs MS DHCP
servers. It seems to be a common misconception that Linux/UNIX must only
use static addresses and that MS must only use dynamic. Moreover, some
people seem convinced that "dynamic is better" in some way. If your
local network has no practical limit on address space, then dynamic
addresses are not *necessary* at all; the advantage is that you don't
need to allocate an address for every machine. There's nothing magic
about PXE, either - it just describes how to write DHCP clients which
are kicked off before a normal OS boot. I would flash Etherboot into ROM
everywhere I have the chance, as many of the PXE implementations are
very poor, and Etherboot is much faster.

> We have several locations around the country, all on different subnets.
> (For example, our corporate HQ has all the internal machines behind the
> firewall set up as 1.254.201.xxx addressing, while our Cleveland, Ohio
> location has 8.254.201.x addressing.)  The locations can only communicate
> amongst each other by going through a default gateway.  Ours is
> 1.254.254.254, and Cleveland's is 8.254.254.254, etc.

It is a VERY BAD idea to use internal addresses other than the official
allocations, e.g. 10.0.0.0 and 192.168.0.0.

> For my purposes with LTSP, I'd like to have only one RedHat Linux server
> that serves the X environment to the clients, running here at corporate HQ.
> We have a DHCP server running Windows 2000 at each of our locations which
> will give clients the proper address and default gateway info so they could
> talk to my RedHat server.
> 
> The first thing I did was disable the DHCP service completely on the RedHat
> box.  (Is there any reason I can't do this, and just use the DHCP services
> on the Win2000 machines?)

If you really want to, you can probably do all your DHCP admin on the
windows box. Don't expect much support from this list if you do; I
recommend that you experiment with your first client machine using ISC
DHCP on Linux (just tell the local MS DHCP server to ignore its MAC
address while you are testing). Equally you could support the MS boxes
from a Linux server running ISC DHCPD.

You can also run multiple DHCP servers for different purposes
simultaneously by using VCIs to indicate who is who. If you are using
Etherboot/PXE you'll need to use VCIs anyway (and you'll need ISC DHCP
v3.0 from www.isc.org). The only thing which you can't do is have a
common lease space (i.e. your Linux box won't know which addresses your
MS box has allocated and vice versa). This is no hardship when you have
a huge address space - which you do, because you are using internal
addresses. Tell the Linux DHCP server that it can only use e.g.
10.1.237.0, and tell the MS server not to use that block.

Compile Etherboot with REQUIRE_VCI_ETHERBOOT so that it ignores any
server which does not set a VCI beginning "Etherboot:". Tell ISC DHCP to
reply only to requests with VCIs matching "Etherboot:" or "PXE:", and
for PXE only if the MAC address of your client matches.

BTW, if you are expecting to boot a client from a server which is the
other side of router (gateway), then the first DISCOVER will be
*broadcast*, and hence not forwarded by the router; you will need to run
a DHCP relay on the local LAN. 

> Then, I tried adding additional options to the scope on our Windows 2000
> DHCP servers, such as "Option 067, Boot File Name:  /lts/vmlinuz.ltsp" and
> "Option 066, Boot Server Host Name:  chqlinux"  (the name of my RedHat
> server).

Setting a server *name* is unlikely to have any effect. You should
understand what the options do, and also how clients interpret them,
don't just guess at likely ones.

You need to set the server *address* (siaddr) for the PXE client to use;
ISC dhcpd's "next-server" directive set this correctly.

> Still, the clients seem to be unable to do anything when they try to boot
> via PXE protocol.  They just report "no image available to boot from" and
> skip past the PXE boot sequence.   The tftp service seems to be properly
> configured and running on my RedHat server.... 

WHEN do they report this? If you report errors to, please give a
verbation copy of all the text, before and after. From the above, we
can't tell if your machine has not bound an address, bound an address
but couldn't find the tftp server, or found the tftp server but couldn't
get the file. We simply know that it failed to load one.

> Can anyone tell me if what I've described is workable, or am I going about
> this all wrong?

You have the right idea, and it's perfectly workable, but you seem to be
expecting a great deal first time round. Baby steps, please: try getting
the details right on a private network - a crossover cable between 2
linux boxes. Read Marty's recipe; try a sample config like his.
http://www.geocrawler.com/archives/3/5299/2001/7/100/6129709/

When you can get Etherboot/PXE working in a simple environment like
this, use VCIs to ensure that only the correct client and server respond
to each other - maybe add an MS machine to the test network to verify
that the server will ignore it. OK, NOW try it on your big scary network
- local LAN first. Then branch out to booting across routers etc.

If you do get this working on a large scale, let me know. I'd love to
hear of a medium to large site using Etherboot/PXE in a big way, just
for my own satisfaction.



_____________________________________________________________________
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

Reply via email to