UNIX System Administration Handbook - Evi Nemeth [305]
The files in Table 18.1 are usually accessed through routines in the standard C library. For example, the /etc/passwd file is searched with the getpwuid, getpwnam, and getpwent routines. These routines take care of opening, reading, and parsing the passwd file so that user-level programs don’t have to do it themselves.
Since few programs access these configuration files directly, it is relatively easy to convert a system to use a network database. Once the library routines are patched, most client programs become automatically “upgraded.” Even software that you obtain from the public domain and from third-party vendors should work correctly with an updated library.
18.2 COPYING FILES AROUND
We use brute-force file copying to maintain the University of Colorado’s Engineering network. It is not an elegant solution, but it works on every kind of machine and is easy to set up and maintain. It’s also a reliable system because it minimizes the interdependencies among machines.
It’s often assumed in manuals and in UNIX culture that you will use a system such as NIS or NIS+ if one is available. But if your needs aren’t complex, you don’t need a complex solution. Sometimes the dumbest, most straightforward solution is best.
Our site consists of several connected but independent fiefdoms. Only a little bit of administrative data is shared everywhere. In our distribution scheme, each fiefdom has one or two servers that store master copies of its system files. This is the sort of environment in which file copying works well, since the task is simply to pump the data around, not to tailor it for particular machines or networks.
File copying systems can use either a “push” model or a “pull” model. With “push,” the master server periodically distributes the freshest files to each client, whether the client wants them or not. Files may be pushed explicitly whenever a change is made or may simply be distributed on a regular schedule (perhaps with some files being transferred more often than others).
The push model has the advantage of keeping the distribution system centralized on one machine. Files, lists of clients, update scripts, and timetables are all stored in one place, making the scheme easy to control. One disadvantage is that each client must allow the master to modify its system files, creating a security hazard.
In a pull system, each client is responsible for updating itself from the server. This is a less centralized way of distributing files, but it is also more adaptable and more secure. A pull system is especially attractive when data is shared across administrative boundaries because the master and client machines need not be run by the same political faction.
rdist: push files
The rdist command is the easiest way to distribute files from a central server. It has something of the flavor of make: you use a text editor to create a specification of the files to be distributed, and then you use rdist to bring reality into line with your specification. rdist copies files only when they are out of date, so you can write your specification as if all files were to be copied and let rdist optimize out unnecessary work.
rdist preserves the owner, group, mode, and modification time of files. When rdist updates an existing file, it first deletes the old version before installing the new. This feature makes rdist suitable for transferring executables that might be in use during the update.1
Unfortunately, rdist has some security issues. It runs on top of rsh- and relies on rsh style authentication to gain access to remote systems. Under this scheme, root access is permitted from any host listed in a target system’s /.rhosts file. This scheme was acceptable on the relatively open and isolated networks of the past, but it’s really too dangerous