rpc.ypxfrd
is used for speed up the transfer of very large NIS maps from a NIS
master to the NIS slave server. If a NIS slave server receives a
message that there is a new map, it will start
ypxfr
for transfering the new map.
ypxfr
will read the contents of a map from the master server using the yp_all()
function. This process can take several minutes when there are very large
maps which have to be stored by the database library.
The
rpc.ypxfrd
server speeds up the transfer process by allowing NIS slave servers to
simply copy the master server's map files rather than building their
own from scratch.
rpc.ypxfrd
uses an RPC-based file transfer protocol, so that there is no need
for building a new map.
rpc.ypxfrd
could be started by inetd. But since it starts very slowly,
it should be started after
ypserv
from /etc/init.d/ypxfrd.
OPTIONS
--debug
Causes the server to run in debugging mode. In debug mode, the server
does not background itself and prints extra status messages to stderr
for each request that it revceives.
-d directory
rpc.ypxfrd
is using this directory instead of /var/yp
-p port
rpc.ypxfrd
will bind itself to this port,
which makes it possible to have a router filter packets
to the NIS ports. This can restricted the access to the NIS server from
hosts on the Internet.
--version
Prints the version number
SECURITY
rpc.ypxfrd
uses the same functions for checking a host as
ypserv.
At first,
rpc.ypxfrd
will check a request from an address with
/var/yp/securenets
or the tcp wrapper.
If the host is allowed to connect to the server,
rpc.ypxfrd
will uses the rules from
/etc/ypserv.conf
to check the requested map. If a mapname doesn't match a rule,
rpc.ypxfrd
will look for the YP_SECURE key in the map. If it exists,
rpc.ypxfrd
will only allow requests on a reserved port.
The FreeBSD
ypxfrd
protocol is not compatible with that used by SunOS. This is unfortunate
but unavoidable: Sun's protocol is not freely available, and even if it
were it would probably not be useful since the SunOS NIS v2 implimentation
uses the original ndbm package for its map databases whereas the other
implimentation uses GNU DBM or Berkeley DB. These packages uses vastly
different file formats. Furthermore, ndbm and gdbm are byte-order sensitive
and not very smart about it, meaning that a gdbm or ndbm database created on
a big endian system can't be read on a little endian system. The FreeBSD
ypxfrd
protocol checks, if both, master and slave, uses the same database packages
and, if necessary, the byte order of the system.
