From owner-freebsd-hackers Wed Jun 25 06:47:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA22964 for hackers-outgoing; Wed, 25 Jun 1997 06:47:17 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA22959 for ; Wed, 25 Jun 1997 06:47:10 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id JAA04669; Wed, 25 Jun 1997 09:47:10 -0400 From: Bill Paul Message-Id: <199706251347.JAA04669@skynet.ctr.columbia.edu> Subject: Re: NIS To: chuckr@glue.umd.edu (Chuck Robey) Date: Wed, 25 Jun 1997 09:47:09 -0400 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Chuck Robey" at Jun 24, 97 11:42:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Chuck Robey had to walk into mine and say: > > I have been reading about NIS, trying to come to grips with it all, but I > haven't been able to com eup with an answer to one last stumbling block. > Maybe someone here knows what I don't ... > > I'm trying to figure out a flexible and reliable setup for a small ISP > that has maybe 5 machines. What I would ideally like is to have a main > server, have the database on that server duplicated on a second machine > just in case the first machine has to go down for maintenance (or some > catastrophe), and the rest of the machines be slaves. I'm particularly > interested in the passwd map. Ideally, it shouldn't be necessary to make all the machines into NIS servers, although you can do it that way. I have about 100 machines with 6 NIS servers, one of which is the master. (One of these is actually just to support one machine on a non-CTR subnet that's been relocated temporarily.) One of these is actually a FreeBSD system (the others are SunOS.) The ypbind program is supposed to take care of locating a server for you. It broadcasts to the local network looking for a server; any servers that hear the broadcast will reply, and ypbind will bind to the first server that answers. Normally, it's a good idea to arrange for NIS servers (masters or slaves) to bind to themselves. This may happen automatically anyway, since a ypserv running on the local host is likely to answer ypbind much faster than anyone else. To force the issue, you can start ypbind with the -ypsetme flag and use the ypset command to bind it to 'localhost.' As long as ypserv doesn't crash, the server should remain bound to itself indefinitely. If a machine is just a client and the server it's bound to crashes and burns, there will be a pause of about a minute before ypbind will broadcast again in search of another server. (Ypbind pings the server(s) it's bound to once every minute to make sure they're still alive. If not, it invalidates the binding and broadcasts again for a new one.) Note that ypbind can only bind to machines that can hear its broadcasts, which implies that there's at least one NIS server on each subnet where you have NIS clients. (You can force it to bind to any machine with ypset, but if it becomes unbound, ypbind won't be able to contact the server again without administrator intervention.) In FreeBSD-current, I added an option to let ypbind 'many-cast' instead of broadcast; this lets it bind across subnets, but you have to tell ypbind the IP addresses of all the available servers when you launch it; without broadcasting, there's no way it can learn of new servers on its own. > What I don't understand is how the passwd maps can get converted into the > passwd file and the mater.passwd file, so they could be duplilcated, both > on the main server and the secondary server. I think I understand how > yp_mkdb makes the nis maps, but I don't see how the source files for the > maps get updated. I know this isn't terribly important for files other > than passwd, but it's passwd that I'm interested in. I want to have the > master.passwd and passwd files on the server right up to date, and the > same files on the backup server fairly close, say, no more than several > hours out of date. I could just move the files occaisonally from the > server to a backup dir on the slave server, but I don't see how they ever > get built at all on the master. See /var/yp/Makefile and /usr/libexec/yppwupdate. When you use yppasswd, rpc.yppasswdd handles updates of both the text based template file and the NIS maps. Note that you can specify /etc/master.passwd as the template for the passwd maps instead of /var/yp/master.passwd; in this case, rpc.yppasswdd will also run pwd_mkdb to rebuild the local passwd database as well. It's usually safer to use a seperate template file though. The master.passwd maps are generated from /var/yp/master.passwd first, then /var/yp/passwd is created from /var/yp/master.passwd using an awk script. If you uncomment the 'UNSECURE=True' line in the Makefile, then the passwd maps will have the real crypted passwords in them; if not, only the master.passwd maps will have them, and only the superuser can access these maps. If you have only FreeBSD hosts, then you can leave the UNSECURE settine along (you don't want real passwds in the passwd maps), but for compatibility with other systems (e.g. SunOS, IRIX, HP-UX, AIX, and yes even Linux) you need to disable this feature. If you have large maps, you will probably want to run rpc.ypxfrd on the master server; it speeds up the transfer of very large maps significantly. (It is a shortcoming of the design of NIS v2 that slaves must transfer the entire map to pick up changes; there's no way to tell the slave exactly what changed, so it needs everything. In NIS+, the master server keeps a log of changes and the replicas can pull over only those updates that it needs and apply them to its own databases. The exception is when a brand new replica is added to an existing domain; here the replica must dump out the entire contents of the domain in order to synchronize itself with the master. Ideally, this should never happen more than once.) rpc.ypupdated is supposed to do similar nonsense, but it's only used to updated the publickey.byname map when using Secure RPC. NIS itself doesn't use Secure RPC (however I'm thinking of changing that.) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================