From owner-freebsd-questions Thu Mar 16 16:10:10 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA04473 for questions-outgoing; Thu, 16 Mar 1995 16:10:10 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA04463 for ; Thu, 16 Mar 1995 16:10:08 -0800 Received: from starkhome.UUCP (root@localhost) by sbstark.cs.sunysb.edu (8.6.9/8.6.9) with UUCP id TAA03955 for questions@freebsd.org; Thu, 16 Mar 1995 19:10:08 -0500 Received: by starkhome.cs.sunysb.edu (8.6.11/1.34) id TAA18975; Thu, 16 Mar 1995 19:03:21 -0500 Date: Thu, 16 Mar 1995 19:03:21 -0500 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Message-Id: <199503170003.TAA18975@starkhome.cs.sunysb.edu> To: "Raoul Medina" Cc: questions@FreeBSD.org In-reply-to: "Raoul Medina"'s message of Thu, 16 Mar 1995 18:31:11 +0100 Subject: Using FreeBSD on a network of diskless PCs Sender: questions-owner@FreeBSD.org Precedence: bulk > 1) Is FreeBSD free of charge for any institution as it is for any particular ? > (particularly for public universities...) Yes. > 2) Is it possible to do a remote boot via ethernet ? Are there any security > problems using this method ? (Could someone boot using a floppy disk and > then become root, allowing him to connect to the entire network with these > privileges ? ) Yes it is possible. The "netboot" code that is distributed with the system works for this. You put the code in a ROM on the network card. You also need to set up a bootp server on the net to issue configuration information by tftp in response to clients that are trying to boot up. The kernel itself is loaded via NFS. We are currently setting up a lab in which all the clients initially boot diskless, then reload data to the local disk, if necessary. I have hacked the netboot loader to be a 2-stage boot. Stage 1 goes in the ROM and won't do anything but load the stage 2 boot off of the server. The stage 2 boot can be set up to do whatever you want. Right now we have the option of booting FreeBSD or doing a normal boot sequence, e.g. A:, C: to load MSDOS. Using this scheme, you can prohibit booting from floppy by having the second stage boot refuse to return to run the normal A:, C: sequence. I have set up the NFS root and the /etc/rc so that the NFS root is completely read-only, so that a single root can be shared between multiple clients. This eases maintenance. The scheme I devised is somewhat baroque, but it seems to work. I can tell you more if you are interested. If somebody does boot up a floppy, and thereby loads their own kernel, they can of course become root on that client. This does not have any particular security implications that I know of, as long as you have your NFS servers configured so that they don't give root access to remote roots, and as long as you don't have any bogus .rhosts or hosts.equiv files that give out root permissions. Actually, it is easier to hack NFS as a normal user than it is as root, because root is treated specially. So, somebody could become root on a client, but that shouldn't automatically permit them to be root on a remote server. However, you do have to keep in mind that if they are root on a client machine, not only can they write whatever they want on the local disk, but they can also use the network card to snoop the net, to discover passwords or whatever. This may also be a consideration for you. > 3) Can we configure the X86Config file in order to take into account the > heterogeneity of monitors and video cards ? Particularly, may we change > the X11 manager sources to tell him to search for the right configuration > of a PC in a file called (for instance) X86Config. ? Yes, a separate XF86Config file can be provided on the basis of hostname, I believe. It should be flexible enough for your purposes. > We should also consider that some of the video cards require different > XServer (S3, SVGA, etc...). May we change the "startx" sources in order > to select the X. as the XServer ? Usually the server is invoked as simply "X", which is a symbolic link to the appropriate server. You could arrange for the symbolic links to be different on different clients, or you could substitute a shell script which would apply a greater level of intelligence to determine which server to run. - Gene Stark