Import rpc.ypxfrd.
This server impliments an RPC-based file transfer protocol that allows
an NIS slave server to copy a raw map database file from an NIS master.
The goal here is to speed up the transfer of very large maps. If you
have, for example, an NIS password database with 30,000 records in it,
it can take around 8 to 10 minutes to regenerate it (four hash databases
are created). As it stands now, ypxfr(8) transfers a map by sucking all
the records from ypserv(8) on the master using yp_all() and writing them
to a new database using the db(3) library. This adds up to another 8 to 10
minutes, per slave. With as the number of slaves increases, this latency
becomes prohibitive.
With rpc.ypxfrd, all the slave has to do is copy the already-built
hash database file from the master and move it into place. Even with a
multi-megabyte file, this reduces the master to slave transfer time
to well under a minute. (This is using TCP.)
Access restrictions are applied using the same mechanism as in ypserv:
you can control access using /var/yp/securenets, and the server will
not transmit the master.passwd.* maps unless the transfer request originates
on a reserved port.
Note: this server is based on my hastily contrived protocol and is _NOT_
compatible with Sun's protocol of the same name. It can't be compatible
for a couple of reasons. For one thing, Sun's protocol has not been published
anywhere that I know of. It is not included in any of the SunRPC source
distributions that I've been able to find. Second, Sun's NIS v2 code
uses old style ndbm maps while FreeBSD uses Berkeley DB. The file formats
are incompatible, so being able to transfer maps between FreeBSD and SunOS
hosts wouldn't do any good anyway. (You could always port the FreeBSD NIS
code to SunOS if you really wanted to do it. :)
(There's also the little fact that SunOS/SPARC is big-endian and FreeBSD/i386
is little-endian. Berkeley DB can handle byte ordering differences; ndbm
probably can't.)
1996-06-05 04:36:55 +00:00
|
|
|
.\" Copyright (c) 1995, 1996
|
|
|
|
|
.\" Bill Paul <wpaul@ctr.columbia.edu>. All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
.\" must display the following acknowledgement:
|
|
|
|
|
.\" This product includes software developed by Bill Paul.
|
|
|
|
|
.\" 4. Neither the name of the author nor the names of contributors
|
|
|
|
|
.\" may be used to endorse or promote products derived from this software
|
|
|
|
|
.\" without specific prior written permission.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
|
.\"
|
1997-01-14 07:20:47 +00:00
|
|
|
.\" $FreeBSD$
|
Import rpc.ypxfrd.
This server impliments an RPC-based file transfer protocol that allows
an NIS slave server to copy a raw map database file from an NIS master.
The goal here is to speed up the transfer of very large maps. If you
have, for example, an NIS password database with 30,000 records in it,
it can take around 8 to 10 minutes to regenerate it (four hash databases
are created). As it stands now, ypxfr(8) transfers a map by sucking all
the records from ypserv(8) on the master using yp_all() and writing them
to a new database using the db(3) library. This adds up to another 8 to 10
minutes, per slave. With as the number of slaves increases, this latency
becomes prohibitive.
With rpc.ypxfrd, all the slave has to do is copy the already-built
hash database file from the master and move it into place. Even with a
multi-megabyte file, this reduces the master to slave transfer time
to well under a minute. (This is using TCP.)
Access restrictions are applied using the same mechanism as in ypserv:
you can control access using /var/yp/securenets, and the server will
not transmit the master.passwd.* maps unless the transfer request originates
on a reserved port.
Note: this server is based on my hastily contrived protocol and is _NOT_
compatible with Sun's protocol of the same name. It can't be compatible
for a couple of reasons. For one thing, Sun's protocol has not been published
anywhere that I know of. It is not included in any of the SunRPC source
distributions that I've been able to find. Second, Sun's NIS v2 code
uses old style ndbm maps while FreeBSD uses Berkeley DB. The file formats
are incompatible, so being able to transfer maps between FreeBSD and SunOS
hosts wouldn't do any good anyway. (You could always port the FreeBSD NIS
code to SunOS if you really wanted to do it. :)
(There's also the little fact that SunOS/SPARC is big-endian and FreeBSD/i386
is little-endian. Berkeley DB can handle byte ordering differences; ndbm
probably can't.)
1996-06-05 04:36:55 +00:00
|
|
|
.\"
|
|
|
|
|
.Dd June 2, 1996
|
|
|
|
|
.Dt RPC.YPXFRD 8
|
|
|
|
|
.Os
|
|
|
|
|
.Sh NAME
|
|
|
|
|
.Nm rpc.ypxfrd
|
|
|
|
|
.Nd "NIS map transfer server"
|
|
|
|
|
.Sh SYNOPSIS
|
|
|
|
|
.Nm rpc.ypxfrd
|
|
|
|
|
.Op Fl p Ar path
|
|
|
|
|
.Sh DESCRIPTION
|
|
|
|
|
The
|
|
|
|
|
.Nm rpc.ypxfrd
|
|
|
|
|
daemon is used to speed up the distribtion of very large NIS maps
|
|
|
|
|
from NIS master to NIS slave servers. The normal method for transfering
|
|
|
|
|
maps involves several steps:
|
|
|
|
|
.Bl -bullet -offset indent
|
|
|
|
|
.It
|
|
|
|
|
The master server calls
|
|
|
|
|
.Xr yppush 8
|
|
|
|
|
to inform the slave servers to start a transfer.
|
|
|
|
|
.It
|
|
|
|
|
The slave servers invoke
|
|
|
|
|
.Xr ypxfr 8 ,
|
|
|
|
|
which reads the entire contents of a map from the master server
|
|
|
|
|
using the yp_all() function.
|
|
|
|
|
.It
|
|
|
|
|
The
|
|
|
|
|
.Xr ypxfr 8
|
|
|
|
|
program then creates a new map database file by using the
|
|
|
|
|
.Xr db 3
|
|
|
|
|
library hash method to store the data that it receives from the server.
|
|
|
|
|
.It
|
|
|
|
|
When all the data has been retrieved,
|
|
|
|
|
.Xr ypxfr 8
|
|
|
|
|
moves the new file into place and sends
|
|
|
|
|
.Xr ypserv 8
|
|
|
|
|
on the local machine a YPPROC_CLEAR to tell it to refresh its
|
|
|
|
|
database handles.
|
|
|
|
|
.El
|
|
|
|
|
.Pp
|
|
|
|
|
This process can take several minutes when there are very large
|
|
|
|
|
maps involved. For example: a passwd database with several tens of
|
|
|
|
|
thousands of entries can consume several megabytes of disk space,
|
|
|
|
|
and it can take the
|
|
|
|
|
.Xr db 3
|
|
|
|
|
library package a long time to sort and store all the records
|
|
|
|
|
in a hash database. Consider also that there are two sets of map
|
|
|
|
|
files:
|
|
|
|
|
.Pa master.passwd.by{name,uid}
|
|
|
|
|
and
|
|
|
|
|
.Pa passwd.by{name,uid} .
|
|
|
|
|
.Pp
|
|
|
|
|
The
|
|
|
|
|
.Nm 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. Simply put,
|
|
|
|
|
.Nm rpc.ypxfrd
|
|
|
|
|
impliments an RPC-based file transfer protocol. Transfering even
|
|
|
|
|
a multi-megabyte file in this fashion takes only a few seconds compared
|
|
|
|
|
to the several minutes it would take even a reasonably fast slave server
|
|
|
|
|
to build a new map from scratch.
|
|
|
|
|
.Pp
|
|
|
|
|
The
|
|
|
|
|
.Nm rpc.ypxfrd
|
|
|
|
|
server uses the same access restriction mechanism as
|
|
|
|
|
.Xr ypserv 8 .
|
|
|
|
|
This means that slave servers will only be permitted to transfer
|
|
|
|
|
files if the rules in the
|
|
|
|
|
.Xr securenets 5
|
|
|
|
|
database permit it. Furthermore, only slave servers using reserved
|
|
|
|
|
ports will be allowed to transfer the
|
|
|
|
|
.Pa master.passwd
|
|
|
|
|
maps.
|
|
|
|
|
.Sh OPTIONS
|
|
|
|
|
The following options and flags are supported by
|
|
|
|
|
.Nm rpc.ypxfrd :
|
|
|
|
|
.Bl -tag -width flag
|
|
|
|
|
.It Fl p Ar path
|
|
|
|
|
This option can be used to override the default path to
|
|
|
|
|
the location of the NIS
|
|
|
|
|
map databases. The compiled-in default path is
|
|
|
|
|
.Pa /var/yp .
|
|
|
|
|
.El
|
|
|
|
|
.Sh FILES
|
|
|
|
|
.Bl -tag -width Pa -compact
|
|
|
|
|
.It Pa /var/yp/[domainname]/[maps]
|
|
|
|
|
The NIS maps for a particular NIS domain.
|
|
|
|
|
.El
|
|
|
|
|
.Sh SEE ALSO
|
1997-01-20 00:03:00 +00:00
|
|
|
.Xr yp 4 ,
|
Import rpc.ypxfrd.
This server impliments an RPC-based file transfer protocol that allows
an NIS slave server to copy a raw map database file from an NIS master.
The goal here is to speed up the transfer of very large maps. If you
have, for example, an NIS password database with 30,000 records in it,
it can take around 8 to 10 minutes to regenerate it (four hash databases
are created). As it stands now, ypxfr(8) transfers a map by sucking all
the records from ypserv(8) on the master using yp_all() and writing them
to a new database using the db(3) library. This adds up to another 8 to 10
minutes, per slave. With as the number of slaves increases, this latency
becomes prohibitive.
With rpc.ypxfrd, all the slave has to do is copy the already-built
hash database file from the master and move it into place. Even with a
multi-megabyte file, this reduces the master to slave transfer time
to well under a minute. (This is using TCP.)
Access restrictions are applied using the same mechanism as in ypserv:
you can control access using /var/yp/securenets, and the server will
not transmit the master.passwd.* maps unless the transfer request originates
on a reserved port.
Note: this server is based on my hastily contrived protocol and is _NOT_
compatible with Sun's protocol of the same name. It can't be compatible
for a couple of reasons. For one thing, Sun's protocol has not been published
anywhere that I know of. It is not included in any of the SunRPC source
distributions that I've been able to find. Second, Sun's NIS v2 code
uses old style ndbm maps while FreeBSD uses Berkeley DB. The file formats
are incompatible, so being able to transfer maps between FreeBSD and SunOS
hosts wouldn't do any good anyway. (You could always port the FreeBSD NIS
code to SunOS if you really wanted to do it. :)
(There's also the little fact that SunOS/SPARC is big-endian and FreeBSD/i386
is little-endian. Berkeley DB can handle byte ordering differences; ndbm
probably can't.)
1996-06-05 04:36:55 +00:00
|
|
|
.Xr yppush 8 ,
|
1997-01-20 00:03:00 +00:00
|
|
|
.Xr ypserv 8 ,
|
|
|
|
|
.Xr ypxfr 8
|
Import rpc.ypxfrd.
This server impliments an RPC-based file transfer protocol that allows
an NIS slave server to copy a raw map database file from an NIS master.
The goal here is to speed up the transfer of very large maps. If you
have, for example, an NIS password database with 30,000 records in it,
it can take around 8 to 10 minutes to regenerate it (four hash databases
are created). As it stands now, ypxfr(8) transfers a map by sucking all
the records from ypserv(8) on the master using yp_all() and writing them
to a new database using the db(3) library. This adds up to another 8 to 10
minutes, per slave. With as the number of slaves increases, this latency
becomes prohibitive.
With rpc.ypxfrd, all the slave has to do is copy the already-built
hash database file from the master and move it into place. Even with a
multi-megabyte file, this reduces the master to slave transfer time
to well under a minute. (This is using TCP.)
Access restrictions are applied using the same mechanism as in ypserv:
you can control access using /var/yp/securenets, and the server will
not transmit the master.passwd.* maps unless the transfer request originates
on a reserved port.
Note: this server is based on my hastily contrived protocol and is _NOT_
compatible with Sun's protocol of the same name. It can't be compatible
for a couple of reasons. For one thing, Sun's protocol has not been published
anywhere that I know of. It is not included in any of the SunRPC source
distributions that I've been able to find. Second, Sun's NIS v2 code
uses old style ndbm maps while FreeBSD uses Berkeley DB. The file formats
are incompatible, so being able to transfer maps between FreeBSD and SunOS
hosts wouldn't do any good anyway. (You could always port the FreeBSD NIS
code to SunOS if you really wanted to do it. :)
(There's also the little fact that SunOS/SPARC is big-endian and FreeBSD/i386
is little-endian. Berkeley DB can handle byte ordering differences; ndbm
probably can't.)
1996-06-05 04:36:55 +00:00
|
|
|
.Sh BUGS
|
|
|
|
|
The FreeBSD
|
|
|
|
|
.Nm 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 FreeBSD
|
|
|
|
|
implimentation uses Berkeley DB. These two packages use vastly different
|
|
|
|
|
file formats. Furthermore, ndbm is byte-order sensitive and not very
|
|
|
|
|
smart about it, meaning that am ndbm database created on a big endian
|
|
|
|
|
system can't be read on a little endian system.
|
|
|
|
|
.Sh AUTHOR
|
|
|
|
|
Bill Paul <wpaul@ctr.columbia.edu>
|
