doug@tci.bell-atl.com (Doug Mildram) (11/15/89)
To the 3 who replied, thanks for the tips on yellow pages.
No one liked it. They use simple copy techniques for nitely distribution
of /etc/passwd , (/etc/hosts, whatever...). Just make sure folks don't
change their passwords on machines whose /etc/passwd's get rewritten nitely.
YP does seem overly complex. Anyone care to defend it?
--
Doug Mildram Technology Concepts Inc.
40 Tall Pine Dr. uucp: {anywhere}!uunet!tci!doug, doug@tci.bell-atl.com
Sudbury MA 01776 (508) 443-7311 x273 tom@osf.osf.org (Tom Jordahl) (11/16/89)
In article <431@tci.bell-atl.com> doug@tci.bell-atl.com (Doug Mildram) writes: >To the 3 who replied, thanks for the tips on yellow pages. >No one liked it. They use simple copy techniques for nitely distribution >of /etc/passwd , (/etc/hosts, whatever...). Just make sure folks don't >change their passwords on machines whose /etc/passwd's get rewritten nitely. > >YP does seem overly complex. Anyone care to defend it? Well, YP is really nice *when it works*. It gives you the ability to maintain a central database at a central machine, without having a central point of failure for all your (1-500) workstations. The problem with using a "simple" copy technique to maintain a distributed database are numerous. What if joe-schmo's workstation is turned off or down when the copy scripts run? He has to wait till the next run. If you run the distribution often, there's overhead involved and passwd et al doesn't change *that* often. You can keep track of who you have sucessfully sent the new files too, but at this point it starts becomming less "simple". Yellow pages also allows the individual workstation "owner" to maintain local information in their /etc files, guest accounts, personal host addresses, etc. (no pun intended) This is in addition to the global info. This info can also override the global information, allowing a user to have a local home directory on his (diskfull) station, but having the same environment on all the other machines. On a large network, you can have several servers, any of which can serve any client. The databases are guaranteed to be updated, although there is some delay. It is also possible for the master to push the database out, or the clients to pull the database in whenever the user finds the update too slow. The updates only happen if the databases are modified since the last update, so unneccesary trafic is avoided. On the down side: If YP is being grumpy, your clients can get hung in a bad way looking for a server they insist is still around. Propagation of the databases in some implimentations is not reliable. (This is *not* true for Suns, in both 3.5 and 4.0 I have seen it work flawlessly.) Also on the down side, its a pain. You can have a separate source directory on the master host, which everyone may not know where to find. Having text files of the /etc information was designed to be convient, and it is. YP puts the info into dbm format, and you must use ypcat and the like to get at the info. Bottom line: When it works, it works well. When it doesn't work, you have a big mess. >Doug Mildram Technology Concepts Inc. Tom Jordahl Internet: tom@osf.org Open Software Foundation UUCP: ..!uunet!osf!tom "A silly quote is only worth what you put into it." -- me