So I'm part of the way there. I moved OTC to a different server (Ubuntu 8.10) which I named "mercury".
I've configured DHCP option 66 to be my WDS server "leo" (no quotes) and option 67 to be "\Boot\x86\pxelinux.0" However, when I boot my client it only connects to LEO, my WDS server. I've configured option 66 to be "mercury" and option 67 to be "pxelinux.0" and the darn thing still connects to LEO. If I stop the OTC, TFTP and WDS services on LEO, only then will it boot to OTC on mercury. :( Tobias Abt wrote: > > Hi! > > DigiDT schrieb: >> On my network I have my Terminal Services users that use Openthinclient >> but I >> also have a lot of regular desktops as well as a couple racks of servers. > > Ok. Who doesn't? :-) > >> For my regular desktops and servers I want to be able to rebuild them >> with >> Windows Remote Installation Services (RIS or aka WDS if you run 2003 R2). > > No problem, the OTC server will only serve clients that are configured. > All other can do whatever they like to. > >> Now, at it's (black) heart, RIS is a TFTP boot server that downloads a >> small >> graphical front-end pretty much the same way that OTC does. In the past, >> I've successfully hacked RIS using the pxelinux.0 bootloader >> (pxelinux.cfg, >> default, etc) so that if I type one thing at the "Boot:" prompt it will >> load >> up a linux image (thinstation and codtech) and if you type in "ris" it >> will >> load up the RIS server. It's pretty nifty actually > > Ok, so in this configuration you set up your DHCP server to issue > next-server and file name options (or options 66 and 67 on Windows > DHCP). > >> I've poked around the innards of OTC and it still uses pxelinux.0 but it >> does something weird with the default file (template.txt). I've found >> that >> I can modify template.txt the same way I did with the "default" file (I >> assume that the template.txt becomes default at some point) and load up >> the > > No, we supply a MAC address specific config file which is way before > pxelinux falls back to "default" in its chain of config file names, > but actually, because the config file is individually and dynamically > created on the fly for each client, it would not matter whether we > supply it when the client (already running pxelinux.0) is asking > for one matching its MAC, all or parts of its IP address or "default". > > But we only supply boot information to configured clients. So we won't > interfere with your RIS clients. > >> RIS kernel (wdsnbp) but it didn't find the RIS server since the service >> was >> disabled. >> >> The problem that I'm running into with RIS is that the service on the >> back-end relies on a separate RIS TFTP service. So in order to use the >> RIS, >> I have to use its TFTP server. > > So what? > > Do you have to have both RIS service and OTC service on the same server? > > If yes, then you will have to tweak it to make it work because only one > TFTP server can occupy UDP port 69. From my point of view not the way > to go. Save yourself the hassle and use different servers. Virtual > machines are ok as OTC servers, too. So save yourself the trouble. :-) > > If those two services are intended to run on different servers anyway > then there is no need to tweak. No need at all! > > Just configure your DHCP server to supply your clients with options > next-server (pointing to your RIS server) and file name (the path > to the RIS server's pxelinux.0). > > Now configure just those clients that should boot OTC as thin clients > in OTCs manager, leave the other PXE clients in that section alone. > > And, if you ever want to boot a client from RIS that normally boots > from OTC, go to the manager section thin clients and edit the mac > address (I usually change the first byte to "ff" which is easy to > restore afterwards). Now it won't get supplied with a config by OTC > when booting. > > Those two systems do not collide. It was especially a design requirement > we wanted to have: minimum intrusion into existing environments and as > few changes to the customer environment as possible. > > The *only* time you would have to tweak should be when you have a really > dumb software distribution service that tries to supply *every* PXE > device without possible exception with its system. But you mentioned > that you did that before with pxelinux so I assume you are not a victim > of such a problem. :-)) > > Please also read this: > http://openthinclient.org/Boot%20procedure%20demystified?structure= > >> So, my question is this; can OTC use a separate TFTP server and still >> maintain it's functionality? > > Yes, see other mail. > > -- > Bye, > Tobias Abt > > levigo systems gmbh ----------- ein unternehmen der levigo gruppe > Max-Eyth-Strasse 30 Telefon: 07031 / 4161-10 > D-71088 Holzgerlingen Telefax: 07031 / 4161-11 > Geschäftsführer: Oliver Bausch http://systems.levigo.de/ > Registergericht: Stuttgart HRB 245 180 USt-ID: DE813226078 > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > The Open Source Thin Client Solution http://openthinclient.org > openthinclient-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openthinclient-user > > -- View this message in context: http://www.nabble.com/Running-RIS-and-Openthinclient-at-the-same-time--tp23064686p23164281.html Sent from the openthinclient.org users' mailing list mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ The Open Source Thin Client Solution http://openthinclient.org openthinclient-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openthinclient-user
