d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
aa8f9f90ff
freebsd-dev/include/rpcsvc/ypxfrd.x

170 lines
7.0 KiB
Plaintext
Raw Normal View History

(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +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 any co-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.
*/
/*
* This protocol definition file describes a file transfer
* system used to very quickly move NIS maps from one host to
* another. This is similar to what Sun does with their ypxfrd
* protocol, but it must be stressed that this protocol is _NOT_
* compatible with Sun's. There are a couple of reasons for this:
*
* 1) Sun's protocol is proprietary. The protocol definition is
* not freely available in any of the SunRPC source distributions,
* even though the NIS v2 protocol is.
*
* 2) The idea here is to transfer entire raw files rather than
* sending just the records. Sun uses ndbm for its NIS map files,
* while FreeBSD uses Berkeley DB. Both are hash databases, but the
* formats are incompatible, making it impossible for them to
* use each others' files. Even if FreeBSD adopted ndbm for its
* database format, FreeBSD/i386 is a little-endian OS and
* SunOS/SPARC is big-endian; ndbm is byte-order sensitive and
* not very smart about it, which means an attempt to read a
* database on a little-endian box that was created on a big-endian
* box (or vice-versa) can cause the ndbm code to eat itself.
* Luckily, Berkeley DB is able to deal with this situation in
* a more graceful manner.
*
* While the protocol is incompatible, the idea is the same: we just open
* up a TCP pipe to the client and transfer the raw map database
* from the master server to the slave. This is many times faster than
* the standard yppush/ypxfr transfer method since it saves us from
* having to recreate the map databases via the DB library each time.
* For example: creating a passwd database with 30,000 entries with yp_mkdb
* can take a couple of minutes, but to just copy the file takes only a few
* seconds.
*/
#ifndef RPC_HDR
Use __FBSDID vs. rcsid[].
2003-05-04 02:51:42 +00:00
%#include <sys/cdefs.h>
%__FBSDID("$FreeBSD$");
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
#endif
/* XXX cribbed from yp.x */
Increase YPMAXRECORD to 16M to be compatible with Linux. Since YP protocol definition uses the constant to declare variable-size opaque byte strings, the change should be binary compatible with existing installations which do not expose keys or values larger than 1024 bytes. All uses of local variables with YPMAXRECORD sizes were removed to avoid insane stack use. On the other hand, variables with static lifetime should be fine and only result in increased VA use. Glibc made same change, increasing the allowed length for keys and values in YP to 16M, in 2013. Reviewed by: markj Discussed with: ian Sponsored by: Mellanox Technologies MFC after: 3 weeks Differential revision: https://reviews.freebsd.org/D20900
2019-08-12 20:27:33 +00:00
const _YPMAXRECORD = 16777216;
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
const _YPMAXDOMAIN = 64;
const _YPMAXMAP = 64;
const _YPMAXPEER = 64;
- Correct mispellings of the word necessary Submitted by: Christoph Mallon <christoph.mallon@gmx.de> (via private mail)
2013-04-17 11:42:40 +00:00
/* Suggested default -- not necessarily the one used. */
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
const YPXFRBLOCK = 32767;
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
/*
* Possible return codes from the remote server.
*/
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
enum xfrstat {
XFR_REQUEST_OK = 1, /* Transfer request granted */
XFR_DENIED = 2, /* Transfer request denied */
XFR_NOFILE = 3, /* Requested map file doesn't exist */
XFR_ACCESS = 4, /* File exists, but I couldn't access it */
XFR_BADDB = 5, /* File is not a hash database */
XFR_READ_OK = 6, /* Block read successfully */
XFR_READ_ERR = 7, /* Read error during transfer */
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
XFR_DONE = 8, /* Transfer completed */
XFR_DB_ENDIAN_MISMATCH = 9, /* Database byte order mismatch */
XFR_DB_TYPE_MISMATCH = 10 /* Database type mismatch */
};
/*
* Database type specifications. The client can use this to ask
* the server for a particular type of database or just take whatever
* the server has to offer.
*/
enum xfr_db_type {
XFR_DB_ASCII = 1, /* Flat ASCII text */
XFR_DB_BSD_HASH = 2, /* Berkeley DB, hash method */
XFR_DB_BSD_BTREE = 3, /* Berkeley DB, btree method */
XFR_DB_BSD_RECNO = 4, /* Berkeley DB, recno method */
XFR_DB_BSD_MPOOL = 5, /* Berkeley DB, mpool method */
XFR_DB_BSD_NDBM = 6, /* Berkeley DB, hash, ndbm compat */
XFR_DB_GNU_GDBM = 7, /* GNU GDBM */
XFR_DB_DBM = 8, /* Old, deprecated dbm format */
XFR_DB_NDBM = 9, /* ndbm format (used by Sun's NISv2) */
XFR_DB_OPAQUE = 10, /* Mystery format -- just pass along */
XFR_DB_ANY = 11, /* I'll take any format you've got */
XFR_DB_UNKNOWN = 12 /* Unknown format */
};
/*
* Machine byte order specification. This allows the client to check
* that it's copying a map database from a machine of similar byte sex.
* This is necessary for handling database libraries that are fatally
* byte order sensitive.
*
* The XFR_ENDIAN_ANY type is for use with the Berkeley DB database
* formats; Berkeley DB is smart enough to make up for byte order
* differences, so byte sex isn't important.
*/
enum xfr_byte_order {
XFR_ENDIAN_BIG = 1, /* We want big endian */
XFR_ENDIAN_LITTLE = 2, /* We want little endian */
XFR_ENDIAN_ANY = 3 /* We'll take whatever you got */
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
};
typedef string xfrdomain<_YPMAXDOMAIN>;
typedef string xfrmap<_YPMAXMAP>;
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
typedef string xfrmap_filename<_YPMAXMAP>; /* actual name of map file */
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
/*
* Ask the remote ypxfrd for a map using this structure.
* Note: we supply both a map name and a map file name. These are not
* the same thing. In the case of ndbm, maps are stored in two files:
* map.bykey.pag and may.bykey.dir. We may also have to deal with
* file extensions (on the off chance that the remote server is supporting
* multiple DB formats). To handle this, we tell the remote server both
* what map we want and, in the case of ndbm, whether we want the .dir
* or the .pag part. This name should not be a fully qualified path:
* it's up to the remote server to decide which directories to look in.
*/
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
struct ypxfr_mapname {
xfrmap xfrmap;
xfrdomain xfrdomain;
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
xfrmap_filename xfrmap_filename;
xfr_db_type xfr_db_type;
xfr_byte_order xfr_byte_order;
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
};
/* Read response using this structure. */
union xfr switch (bool ok) {
case TRUE:
opaque xfrblock_buf<>;
case FALSE:
There are a few small additions to the protocol to make it easier to use in mixed environments: - Add three new members to the request structure: - a filename specification - a database type specification - a system byte prder specification These allow the client to ask the server for a particular type of database (Berkeley DB hash/btree/recno, GNU GDBM, dbm, ndbm, etc...) and get back a meaningful error if the server doesn't support it. The byte order spec is needed if the database type is byte order sensntive. You don't, for example, want to read an ndbm database from a big endian machine on a little endian machine (the ndbm code will explode). The filename spec lets the client handle things like ndbm which uses two seperate files per database (foo.dir and foo.pag). The client can ask for each half, one at a time. - Add a list of database types and byte order values. Each list has a wildcard 'ANY' entry which lets the client ask for whatever the server supports. (XFR_ENDIAN_ANY is useful with the Berkeley DB hash method for instance, since it isn't byte order sensitive.) - Add two newserver failure codes: XFR_DB_TYPE_MISMATCH and XFR_DB_ENDIAN_MISMATCH. The server uses these to tell the client that it doesn't support the requested type/byte order. These changes were made at the suggestion of Thorsten Kukuk, the current maintainer of the Linux ypserv distribution. This allows Linux and FreeBSD NIS servers to use the same ypxfrd protocol and avoid accidentally exchanging incompatible map files.
1996-07-04 02:08:17 +00:00
xfrstat xfrstat;
(I hope I'm doing this correctly.) Import a my own little ypxfrd protocol. Note that this protocol is _NOT_ the same as Sun's, which is proprietary. This basically impliments an RPC-based file transfer protocol which lets a slave server suck over a raw map database file from the master. This is many times faster than the normal method, which requires reading the records from ypserv via yp_all() and then creating a new database on the fly, particularly when you have many tens of thousands of records in a map (e.g. a huge passwd database). The protocol number I chose falls within the 'user-specified' range. Maybe we should register it with Sun so we can get an official vendor number for it. :)
1996-06-05 02:42:33 +00:00
};
program YPXFRD_FREEBSD_PROG {
version YPXFRD_FREEBSD_VERS {
union xfr
YPXFRD_GETMAP(ypxfr_mapname) = 1;
} = 1;
} = 600100069; /* 100069 + 60000000 -- 100069 is the Sun ypxfrd prog number */
Reference in New Issue Copy Permalink