Hi Peter. I appreciate the time you've taken to reply to my (rather open-ended) question.
>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. I was referring to the document posted at this URL: http://www.ltsp.org/documentation/pxe.howto.html 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? >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. Yes, PXE has been configued in the BIOS of these machines as the primary boot method. If I don't do anything with LTSP at all, they display "DHCP...." at boot, and then display an IP address, assigned to it by our Windows 2000 DHCP server. Then they freeze-up. (I assume, waiting to get an image via TFTP protocol, which isn't running at this point.) >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. No, I fully understand that either Windows 2000 or Linux DHCP server can issue either dynamic or static IP addresses. The only reason I'm interested in issuing dynamic IPs to the LTSP clients is for ease of administration. I don't like having to manually set up a MAC address to IP address relationship in a config file on the LTSP server for each one of the clients I set up. (Not only that, but if someone moves a client from one location to another, I don't want to have to update its IP information so it's on the proper subnet for its new location.) 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.) 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. >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. 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. >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. Ah! Ok, that makes sense and I hadn't thought about it. That might change my entire plan right there. (If I have to set up a DHCP relay on each LAN subnet, then maybe that tells me I should be looking at setting up a seperate LTSP server with DHCP 3.0 at each of our locations. It would also solve potential issues of slow booting from our remote sites, since they only have 512K frame-relay connections back to our corporate HQ.) >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. Thanks! This is the type of information I really need, and was having a hard time locating. >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. Sorry, when I posted my last message, I still hadn't experimented as much as I probably should have. I did further testing by using the default pxe configuration (/etc/pxe.conf stuff in RedHat 7.1), and was able to get the thin-clients to display a menu of options via PXE. (Basically, choices were to install RedHat 7.1 remotely, boot it remotely, or boot locally.) Whenever I chose a menu selection from this menu though, the client immediately gave up trying to remote boot and started booting embedded NT from the local image. If it displayed an error message, it went by too quickly to see it. At this point, I have no idea if this is simply due to problems with RedHat 7.1's supplied boot images (in /tftpboot/X86/UNDI/linux-install, etc.), or if it indicates a larger problem? >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/ 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..... Thanks again! - Tom Wyrick _____________________________________________________________________ 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
