bootp/dhcp conflicts?

[Luigi]

hey all. I'm setting up a bunch of (preferably diskless) x-terminal thin clients for my department at a university... but it looks like i need to set up a dhcp server to hand the clients all their boot information.

Unfortunately, our dhcp server is campus-wide, and I have no control over it. i understand that setting up my own dhcp server would conflict with the campus IT "master", so that's no good.

is there any way to set up a passive boot server? so the client is given the address of the server, and the server only responds to specific requests? or can I put all of the network information onto a boot rom?

heck, and while i'm at it, what's the difference between dhcp and bootp?

:confused: :confused: :confused:

[Magueta]

I don't know what the difference is between DHCP and BOOTP but I think I can recommend something that might work. You can put your department on a different subnet so that you isolate the DHCP server from the rest of the university, then you can use a router to give your department access to the rest of the university. Note: I've never done this but it should work in theory. What you're doing is creating a network that can't be seen by the other computers on the university network and vice versa. You can also use either a switch, router, or bridge to disallow broadcast traffic across the bridge so a local dhcp server would probably not conflict with the university's server.
Yet another option is to just use the university DHCP server to hand out the addresses for your thin clients.

Joe

[Luigi]

1) all my systems are on their own subnet, but it isn't a private one. switching to a 192.168 or whatever subnet is actually against campus IT rules...(not that that bothers me, particularly ;) )

2) BUT the systems are wired into wall jacks, and i don't have access to any "bottleneck" point where i could set up a router/dhcp.

3) i don't have any control over the campus dhcp server, they could care less about what one regional IT manager wants! :(

4) in fact, my IPs are statically assigned anyways, so i don't even USE the campus dhcp server.


so we're back where we started. i want to assign my xterms their static ips without interfering with the campus dhcp server. heck, even a floppy disk boot is fine...

[Magueta]

I can't do anything about the first two, but the third and fourth I think are ok. As far as the DHCP server, you don't have to have access to it, in fact you don't have to do anything but enable dhcp on the thin clients and they'll ask for an address when they get turned on.
As for number 4, I've had a little experience with thin clients and I believe that they allow you to specify static IP addresses so with those two options you're still ok.

Joe

[Luigi]

ahhhhh! so have the clients follow this procedure:


boot - get ip from DHCP - access boot image from server -> change IP to assigned IP

?

hmmmmmmmmmmmmmmm
sounds intriguing.. how to secure the nfs share? i'll have to think about this. thanks!

[Magueta]

Be careful with setting static IP addresses on a DHCP network because some day on a reboot you'll get a message saying that some other machine already has that address. I didn't know that you needed static IP addresses.
If you're using DNS then perhaps you can just use the hostnames for mounting and let DHCP take care of the configuration settings. If you use the hostnames the IPs can change all they want, everything will always get mounted properly, and go to the right place regardless of the configuration info. Of course that's only if you can use hostnames to mount nfs shares. However, I'm pretty sure you can.
Write back and let us know what you find out.

Joe

[Luigi]

yeah, you can use hostnames for NFS.. no problem.

and my IPs and the IPs assigned by the DHCP server are separate... no one will ever get assigned one of MY addresses :) .

problem with your suggestion though... hostnames are bound to specific IPs. if the client gets DHCP/bootp on bootup, they'll have a random ip, with a random hostname associated with it. it isn't until they've gotten into the NFS share and have reconfigured their network info that they will have their "proper" hostnames... but that's already after they've been authenticated to NFS.

since my hostnames are *.chem.foo.edu, and the dhcp server hands out *.dhcp.foo.edu hostnames, i suppose i can just limit my nfs to *.*.foo.edu ... at least that conforms to departmental regulations, even if it isn't all that secure.

cool!

[Magueta]

What I'm saying is that the hostnames might not be bound to specific IPs. At least I'm pretty sure there's some way around it. I worked at a place where the administrator had everyone printing through some windows 95 clients because the printers weren't network printers. The PCs used DHCP to get their configuration information every morning when they booted up and it all worked great. There were 6 printers that were printed to that way and they all worked. I don't know how it worked but it did. I know that if you were using /etc/ hosts you'd be screwed but maybe there's some way to do it with DNS.

Joe

[Luigi]

sounds like your administrator used netbios... windows name addressing is not bound to ip... very convenient! (though it's caused me some headaches...) but i don't think i can get samba down to a size small enough to fit on a NIC ROM chip... *lol*

i think just filtering by the larger domain is what I'll have to do. sounds great though, thanks for your help!

[Magueta]

I think you're right about netbios.

I'm glad you fixed your problem.

Good luck

Joe

[cowanrl]

The difference between dhcp and bootp is basically what type of information is provided to the client.

With dhcp, the client is usually assigned an IP address, netmask, default gateway, dns servers, usually a domain name and possibly a host name. Those are the most common client configuration items but there are lots more. The client gets this info directly from dhcp server and uses it.

I've had experience with bootp in two different ways. At my last job, we used bootp as such:

The host booted up without an IP address. It contacted the bootp server via a broadcast. The bootp server assigned the client an IP address, the name of a boot file server(in our case it was running tftp) and the name of a configuration file.
The host used the IP address to contact the tftp server and download the configuration file. Within that configuration file was all the info needed to configure the host, including a permanent IP address. The IP address that was initially received from the bootp server was just used for contacting the tftp server.
Since each host required a different configuration file, the bootp server was set up to match an IP address to a MAC address. That way when the host was brought up, it always received the same configuration file from the tftp server.

The nice thing about this is that you can set up your bootp server to only give out IP addresses to MAC addresses it knows about. Even if you had other machines on your network using dhcp from a different server, they would never receive an IP address from your server if the MAC address wasn't part of the configruation.

As you can imagine, this was not the easiest thing to set up. We used the ISC dhcpd server and I used Webmin to configure it remotely. We used the tftp server that came on the Red Hat 7.2 CDs. But once it was all set up, it worked great. The hosts did not need a hard drive.
The same physical dhcp server also functioned as a normal dhcp server. We had some Windows and Red Hat clients on the network that used DHCP. They would receive their IP configuration info from the same server that was performing the bootp duties.

Another way I've seen bootp used is with diskless Unix Xterms like you are talking about. These workstations just had 16MB of RAM and the 16bit Motorola processor that was used in Macintoshes(I can't remember the number of it now) In this case, the diskless workstations were configured with a static IP address and the IP address of a bootp server. They contacted the bootp server and it provided all the information they needed to run. Things like fonts to use, the font server, where to run the application from.
In this situation I was just on the support end. If a diskless workstation went bad, I just replaced it, entered in the IP address info and bootp server and that was it. I did no configuration of the bootp server itself.

In my experience bootp is a lot harder to set up. But, there's a lot to be said for diskless workstations. I never had a hard drive crash in one. It's a lot easier to have a secure network with them also.
But, if your network goes down, your users twiddle their thumbs until you get it back up again.

[Luigi]

ha!!! fantastic!!

one question though - if those macs didn't have hard drives, where did they store their ip and server information? that's EXACTLY what i'm looking for.... i don't have enough clients to really merit a bootp server.

[cowanrl]

They weren't Macintoshes. They just used the same Motorola chip that was used in some of the older Macs.
The machines really didn't have much horsepower but they did the job.

The IP address and address of the bootp server were stored in NVRAM. That info was retained if the machine was powered down or rebooted.
But each time it was rebooted, it had to download all of the other configuration info from the bootp server. But they still came up faster than the NT 4 workstations they were eventually replaced with.
But, the NT4 workstations(P3 600s with 256MB of RAM at the time) ran the software much much faster.

[Magueta]

That is really great. Lots of info there. Makes me want to setup a bootp server for somebody. :-)

Luigi, I believe what Cowanrl is saying is that all the information was stored on another server, and that all the instructions and steps on how to get that info was downloaded and then executed by the thin client from the bootp server. While the client is up the information is in ram, once it's turned off it loses it all as you might have guessed, then it goes through the whole process again the next morning. The permanent IP address gets mapped to the correct client based on the mac address. At least that's how I understand it.

Joe

[Luigi]

well, i'm outta town for a week or so, but i'll post back here when i get back.. i'm definitely setting this up with a bootp server... i don't have any stations that have nvram, so that's my only route.

thanks for all your help!