transfer NIS database from remote server to local host
-d target domain]
-h source host]
-s source domain]
-C taskid program-number ipaddr
ypxfr utility copies an NIS database (or
map) from one NIS server to another using NIS
services. In FreeBSD,
generally invoked by
when it receives a map transfer request from
ypxfr utility is used primarily in environments
where several NIS servers are in use in a single domain. One server, the NIS
master, maintains the canonical copies of all NIS maps, and all the other
servers, the NIS slaves, copy new versions of the maps from the master
whenever any updates are made (i.e., when a user updates their password via
ypxfr creates a temporary
database file in /var/yp/[domainname], and fills it
with the contents of mapname as supplied by the
specified source host. When the entire map has been
ypxfr deletes the original copy of
mapname and moves the temporary copy into its place.
When the transfer is complete,
ypxfr will attempt to
send a 'clear current map' request to the local
process to clear any possible references it may still have to the stale
Note that all files created by
owner readable and writable only for security reasons. Since the NIS maps
and the directory in which they reside are normally owned by root, this
prevents non-privileged users from making unauthorized modifications.
In order to maintain consistency across all NIS servers,
ypxfr can be run periodically in a
job. Maps which change infrequently need only be updated once a day
(preferably late at night when system usage is lowest), whereas those that
are subject to frequent changes (such a
passwd.byuid) should be updated perhaps once every
to automatically update the NIS maps is not strictly mandatory since all
updates should be propagated by
when /var/yp/Makefile is run on the NIS master
server, however it is good practice on large networks where possible outages
could cause NIS servers to fall out of sync with each other.
The FreeBSD version of
ypxfr is invoked without a
controlling terminal, e.g. from inside
it logs all its output using the
support for a special map transfer protocol which works in conjunction with
server. This protocol allows it to transfer raw map database files from the
NIS master server and can be many times faster than the standard transfer
method, particularly for very large NIS maps. The
ypxfr utility will check to see if the
server is registered on the NIS master server and attempt to use it if it is
present. If it is not it will fall back to the standard transfer method,
copying the map contents from
and creating new maps instead.
Note that while the FreeBSD ypxfrd
protocol is conceptually similar to the SunOS ypxfrd protocol, the
FreeBSD protocol is not compatible with Sun's,
therefore it will not work with Sun's ypxfrd server.
FreeBSD slave systems can still transfer maps from
any non-FreeBSD NIS server,
however they will only be able to take advantage of the faster protocol if
the master server is also running FreeBSD.
The following options and flags are supported by
- Force a map transfer. Normally,
ypxfr will not
transfer a map if it determines that the NIS master's copy is not newer
than the existing copy already on the local host: the
-f flag forces a transfer regardless of which
server's version is more recent.
- Do not send a 'clear current map' request to the
process running on the local host. This flag is normally used when
ypxfr manually on a machine that is not
Without this flag, failure to contact the local NIS server will cause
ypxfr to abort the transfer.
- Specify a target domain other than the current NIS domain.
- Specify the name of the host from which to copy the NIS maps. This option
is used to ensure that
ypxfr only copies maps from
the NIS master server.
- Specify the domain from which to transfer a map, in the event that the
transfer is being done across two different NIS domains.
- Specify the top level directory containing the NIS maps. By default, this
path is /var/yp. The
flag allows you to specify an alternate path should you wish to store your
NIS maps in a different part of the file system. The NIS server,
passes this flag to
ypxfr if it too has been told
to use an alternate path.
taskid program-number ipaddr port
- These options are used only when
ypxfr is invoked
in response to a map transfer request initiated by
In this instance,
ypxfr needs to 'callback' to the
process and interact with it, so
passes to it an IP address ipaddr, port number
port, registered program number
program-number and a transaction ID
taskid that it can use to contact the waiting
process on the master server.
- The name of the map to transfer.
- The NIS maps for a particular NIS domain.