I've done some more research and I'm coming to the conclusion there's no way to nicely run OTC and WDS side-by-side (on the same machines or separated)
Problem with running on the same machine: WDS depends on the WDS and TFTPD services. WDS basically works as a PXE proxy; when the PXE client contacts the WDS server, a bootloader is downloaded (WDSNBP.COM) and that bootloader downloads something else that loads up the OSChooser interface (STARTROM.COM in my case). As far as I can tell, there's no way to tell WDSNBP to look to a TFTP server at a different IP. So it ALWAYS uses the TFTP server configured on the local machine. OTC works in a similar fashion. A bootloader is downloaded (PXELINUX.0) and that bootloader is what loads up linux. Now, you can hack WDS to use pxelinux.0. You do this by putting the pxelinux.0 file in \RemoteInstall\Boot\x86. In that same folder, rename wdsnbp.com to wdsnbp.0 (this is super important!) then create a subfolder called pxelinux.cfg and in that folder create a file named "default". Edit the "default" file with the following: PROMPT 1 TIMEOUT 30 LABEL ris KERNEL wdsnbp.0 keeppxe LABEL linux KERNEL <whatever linux kernel you want> APPEND intrid=<initrd file> Save the file and finally, open the WDS managment console, goto the properties of the server and in the "Boot" tab specify \Boot\x86\pxelinux.0 for the "x86 architecture" box. Restart the WDS service and the next time you boot a PXE client, you'll (hopefully) be presented with a "Boot:" prompt where, if you type "ris" or "linux" (no quotes), it will boot into your ris or linux server. Now, if you stop just the TFTPD service on the machine, so you only have WDS and OTC running, the PXE client still wants to download pxelinux.0 from the WDS service which bypasses OTC's nice per-computer configuration scheme. If you configure WDS to NOT listen on port 67 (DHCP), it will boot from the OTC service. And if you edit the template.txt file in \RemoteInstall\openthinclient\server\default\data\nfs\root\tftp to use the wdsnbp.0 kernel file as described previously, it will start to load WDS however it will fail since it can't find it's TFTPD server and it can't download startrom.com. Perhaps getting both to run on the same machine would work if the OTC TFTP daemon could be configured to handout the startrom.com file. However, I get the feeling that that file is dependent on being in the OSChooser\i386 directory to find the OSC files. Problem with getting OTC and WDS to work together on separate physical machines: So on SERVER1 I have WDS installed and on SERVER2 I have OTC. I've DHCP option 66 (Boot Server Host Name) I've configured for the WDS server SERVER1. When I boot my PXE client (in this case a VMware machine) it always boots to the WDS server. Even if I configure 66 for SERVER2, my OTC server. When I load up Wireshark and capture the DHCP exchange, my regular DHCP server, SERVER1 and SERVER2 all respond. The client gets an IP and then ALWAYS looks to SERVER1 for PXE boot. If I totally disable WDS on SERVER1, only then will it boot to OTC on SERVER2. I think that WDS integrates with my Active Directory domain and my Microsoft DHCP server always directs to the WDS server. So I'm wondering if there's a way to redirect a PXE boot from the pxelinux.0 file? Maybe I could let my clients boot to my WDS server and then the "default" file could point the client to another server? So like a proxy within a proxy? It's kind of a round-about solution but I'm out of ideas. Or maybe I'm missing something very basic ;) -- View this message in context: http://www.nabble.com/Running-RIS-and-Openthinclient-at-the-same-time--tp23064686p23245731.html Sent from the openthinclient.org users' mailing list mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ The Open Source Thin Client Solution http://openthinclient.org [email protected] https://lists.sourceforge.net/lists/listinfo/openthinclient-user
