> I was referring to the document posted at this URL:
>
> http://www.ltsp.org/documentation/pxe.howto.html
Ah, Marty's recipe made into a web page. That will go into the HOWTO, if
Marty is willing. I just wondered if someone else was also working on
any more (and have just discovered a PXE for Red Hat kickstart doc).
> After reading it over, though, I'm not sure that it's the best/most
> efficient way of making PXE clients work with LTSP? What I mean is, it
> looks like the author patched something together that works by using PXE to
> load up and launch etherboot code. That, in turn, connects to the LTSP
> server using the more conventional, non-PXE method. I don't see why I can't
> just boot directly from PXE protocol and skip the step of loading etherboot
> code?
PXE is designed to do the job in 2 steps. This is a feature. :) The
first file loaded by a PXE client is REQUIRED to be 32k or less; it is
this which the loads the "proper" OS.
You can use pxelinux instead of Etherboot/PXE (it will do the job fine),
but it's still a 2 stage process (PXELINUX gets its 2nd stage config via
TFTP, not DHCP, but it's still a 2 stage process). The point about
Etherboot is that you can flash it into your nic's boot rom and it works
the same way however you start it. Courtesy of the LinuxBIOS project,
you can even flash Etherboot into your's system BIOS flash if the
motherboard is co-operative.
Vasil and I *never* intended that Etherboot/PXE be The Right Way to do
things - we did it because we had a prospective customer who wanted to
use PXE, and I discovered that there wasn't a trivial way to do
everything we wanted AND have the ability to flash bios where we could.
If your boot rom is flashable, then it's possible to boot a small image
which via PXE which just flashes Etherboot - then reboot straight from
the flash.
> Yes, PXE has been configued in the BIOS of these machines as the primary
> boot method.
Sorry, had to ask...
> As for flashing etherboot into ROM on as many clients as possible, I can see
> why that might generally be a good idea - but probably not in my particular
> case. The machines I'm trying to use with LTSP are "Netier XL2000"
> thin-clients. They originally came configured with embedded NT 4.0 on a
> flash-disk chip. They have integrated 10/100 ethernet (Realtek 8139) and
> supposedly come with a pretty complete PXE implementation for those who want
> to bypass the flash disk and remote boot them from a server. (Our
> motivation for bypassing embedded NT is two-fold. #1, the commercial
> "Rapport" software designed to manage the thin clients is expensive. #2,
> embedded NT takes an awful long time to boot up - and it seems like overkill
> when all we want to do is launch a Citrix ICA client afterwards.)
If flashing the roms is impractical, then Etherboot/PXE is fine for you;
this is exactly the kind of config that we had in mind.
But wow, if you can get LinuxBIOS in the flash chips... they reckon to
get to the start of multiuser boot in <3 seconds.
> 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.
>
> Yes, I've had this discussion with our administrators before... but in
> reality, it works because everything is completely hidden behind a Cisco PIX
> firewall that does NAT through a single IP assigned by our ISP. They prefer
> leaving it as-is, since the current IP scheme has been in place for close to
> 10 years now and everyone is familiar with it.
So how do you communicate with addresses out on the net starting with
[1..9]? They exist. Anyway, if you are using DHCP, there's no reason why
you can't change client addresses dynamically...
> If I had my way, I'd be running Linux instead of 2000 for DHCP as well as
> several other things... but like many businesses, I have to work within
> lines that are already drawn-up. It seems like it's only logical to use the
> existing Win2000 DHCP server for this project if it's already issuing all
> the other IP addresses on our network. I didn't expect lots of support from
> the list for this, but I guess I hoped someone else might have had a similar
> situation already, and perhaps figured out how to integrate Win2K DHCP into
> the LTSP picture.
I understand. Many people will use LTSP via PXE precisely because they
want to get Linux into an existing MS shop without frightening the
horses. Just because you can't use a Linux DHCP server in production
doesn't you can't use one in development and testing; you'll get much
more help given that the recipes and experience of list members will be
Linux oriented. It's a general rule with this sort of thing that once
something works you should only tweak one variable at a time, and always
test the recently tweaked element against a known-working examples.
> Ok, I'll do a lot more reading + experimenting before I post again. I
> probably am trying to do too much, too quickly. I just needed some
> validation that my "grand plan" for deploying this is feasible. Otherwise,
> there's no point in my proceeding to do such things as make it work within
> our local subnet, if it's not capable of booting across our routers.....
Don't let me put you off posting; precisely the opposite - I'd be
interested in your step by step progress, and I guess others will be.
Post even small things which would have made life easier had you known
them beforehand: they're likely to find their way into docs.
_____________________________________________________________________
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
