YPXFR(8) | MidnightBSD System Manager's Manual | YPXFR(8) |
ypxfr
— transfer
NIS database from remote server to local host
/usr/libexec/ypxfr |
[-f ] [-c ]
[-d target domain]
[-h source host]
[-s source domain]
[-p path]
[-C taskid program-number ipaddr
port] mapname |
The ypxfr
utility copies an NIS database
(or map) from one NIS server to another using NIS
services. In FreeBSD, ypxfr
is generally invoked by
ypserv(8) when it
receives a map transfer request from
yppush(8). The
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
yppasswd(1)).
When run, 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
transferred, 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
ypserv(8) process to
clear any possible references it may still have to the stale map.
Note that all files created by ypxfr
are
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
cron(8) 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.byname and
passwd.byuid) should be updated perhaps once every
hour. Using cron(8) to
automatically update the NIS maps is not strictly mandatory since all
updates should be propagated by
yppush(8) 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.
When ypxfr
is invoked without a
controlling terminal, e.g. from inside
ypserv(8), it logs all
its output using the
syslog(3) facility.
The FreeBSD version of
ypxfr
has support for a special map transfer
protocol which works in conjunction with the FreeBSD
rpc.ypxfrd(8) 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
rpc.ypxfrd(8) 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
ypserv(8) 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
ypxfr
:
-f
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.-c
ypxfr
manually on a machine that is not yet
running ypserv(8).
Without this flag, failure to contact the local NIS server will cause
ypxfr
to abort the transfer.-d
target domain-h
source hostypxfr
only copies maps from
the NIS master server.-s
source domain-p
path-p
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,
ypserv(8), passes this
flag to ypxfr
if it too has been told to use an
alternate path.-C
taskid program-number ipaddr portypxfr
is invoked
by ypserv(8) in
response to a map transfer request initiated by
yppush(8). In this
instance, ypxfr
needs to 'callback' to the
yppush(8) process and
interact with it, so
yppush(8) 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
yppush(8) process on
the master server.Bill Paul <wpaul@ctr.columbia.edu>
February 5, 1995 | midnightbsd-3.1 |