From: Bhaskar S. M. <bh...@ca...> - 2002-08-28 13:50:15
|
> We tried it with the Vendor Id but we did not get the results that we were > expecting, I am not sure if it is something we are doing wrong or else. The > User class has more flexibility and that is why we wanted to use it. Being lazy, I decided this was too much work. > > For one, I know they like to zero-pad their strings. > This is interesting - I posted a question regarding this also - because > Actually we are facing a problem associated with the ROOT PATH, it is > supposed to be /opt/ltsp/i386. Because of the padding the ltsp server is > being passed the /opt/ltsp/i386000. a temp solution was to rename the path > accordingly. Long ago I decided fighting Windows servers is not a learning experience :) and however silly that might be, it does reduce the solution space. > > just use a different DHCP server on a Linux machine and running on a > different port number. > Does a DHCP client care which port the DHCP server is listening on, I > thought it does a broadcast. Does not this mean that whichever server picks > the request first servers the ip from its pool? The reason I ask is that we > are currently running a small private network (1 win2k DHCP SRVR, 1 TC i386, > 1 LTSP SRVR i386) but are aim is to use a M/F as an LTSP server but since we > need to add the ltsp parms to the clients we wanted to do it in the least > harmful way to our PROD DHCP srvrs and least customization. My working interpretation is that the broadcasts are specific to port numbers just like connections. The client however does care in the sense that you have to compile the etherboot image yourself after changing the port number in the header file. The compile is easy, but the disclaimer is that I didn't actually boot a client with that yet. I've only tested on PCMCIA clients where you simply edit the linuxrc. Someday someone (probably you :) will post The Right Way to do it, but with this you're not going to interfere with any of your production machines. -- bhaskar |