2 .TH RPC.YPXFRD 8 "August 2001" "YP Server" "Reference Manual"
4 rpc.ypxfrd \- NIS map transfer server
6 .B /usr/sbin/rpc.ypxfrd
17 .B /usr/sbin/rpc.ypxfrd
23 is used for speed up the transfer of very large NIS maps from a NIS
24 master to the NIS slave server. If a NIS slave server receives a
25 message that there is a new map, it will start
27 for transfering the new map.
29 will read the contents of a map from the master server using the yp_all()
30 function. This process can take several minutes when there are very large
31 maps which have to be stored by the database library.
35 server speeds up the transfer process by allowing NIS slave servers to
36 simply copy the master server's map files rather than building their
39 uses an RPC-based file transfer protocol, so that there is no need
40 for building a new map.
43 could be started by inetd. But since it starts very slowly,
44 it should be started after
46 from /etc/init.d/ypxfrd.
50 Causes the server to run in debugging mode. In debug mode, the server
51 does not background itself and prints extra status messages to stderr
52 for each request that it revceives.
56 is using this directory instead of /var/yp
60 will bind itself to this port,
61 which makes it possible to have a router filter packets
62 to the NIS ports. This can restricted the access to the NIS server from
63 hosts on the Internet.
66 Prints the version number
69 uses the same functions for checking a host as
73 will check a request from an address with
76 If the host is allowed to connect to the server,
78 will uses the rules from
80 to check the requested map. If a mapname doesn't match a rule,
82 will look for the YP_SECURE key in the map. If it exists,
84 will only allow requests on a reserved port.
97 protocol is not compatible with that used by SunOS. This is unfortunate
98 but unavoidable: Sun's protocol is not freely available, and even if it
99 were it would probably not be useful since the SunOS NIS v2 implimentation
100 uses the original ndbm package for its map databases whereas the other
101 implimentation uses GNU DBM or Berkeley DB. These packages uses vastly
102 different file formats. Furthermore, ndbm and gdbm are byte-order sensitive
103 and not very smart about it, meaning that a gdbm or ndbm database created on
104 a big endian system can't be read on a little endian system. The FreeBSD
106 protocol checks, if both, master and slave, uses the same database packages
107 and, if necessary, the byte order of the system.
110 ypxfrd protocol and FreeBSD Implementation: Bill Paul <wpaul@ctr.columbia.edu>
112 Linux Implementation: Thorsten Kukuk <kukuk@suse.de>