aboutsummaryrefslogtreecommitdiff
path: root/include/rpcsvc/ypxfrd.x
Commit message (Collapse)AuthorAgeFilesLines
* Remove $FreeBSD$: one-line xdr patternWarner Losh2023-08-161-1/+0
| | | | Remove /^\s*%\s*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* Increase YPMAXRECORD to 16M to be compatible with Linux.Konstantin Belousov2019-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=350957
* - Correct mispellings of the word necessaryGabor Kovesdan2013-04-171-1/+1
| | | | | | | Submitted by: Christoph Mallon <christoph.mallon@gmx.de> (via private mail) Notes: svn path=/head/; revision=249583
* Use __FBSDID vs. rcsid[].David E. O'Brien2003-05-041-4/+2
| | | | Notes: svn path=/head/; revision=114629
* Removed duplicate VCS ID tags, as per style(9).Ruslan Ermilov2001-08-131-2/+0
| | | | Notes: svn path=/head/; revision=81586
* $Id$ -> $FreeBSD$Peter Wemm1999-08-271-2/+3
| | | | Notes: svn path=/head/; revision=50473
* Removed redundant declarations. rpcgen generates `typedef enum foo;'Bruce Evans1998-01-161-5/+2
| | | | | | | from `enum foo;'. Notes: svn path=/head/; revision=32553
* Resolve conflicts.Bill Paul1997-05-281-2/+2
| | | | Notes: svn path=/head/; revision=26208
* Revert $FreeBSD$ to $Id$Peter Wemm1997-02-231-2/+2
| | | | Notes: svn path=/head/; revision=23037
* Make the long-awaited change from $Id$ to $FreeBSD$Jordan K. Hubbard1997-01-141-2/+2
| | | | | | | | | | | This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long. Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise. Notes: svn path=/head/; revision=21673
* There are a few small additions to the protocol to make itBill Paul1996-07-041-5/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=16957
* (I hope I'm doing this correctly.)Bill Paul1996-06-051-0/+117
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. :) Notes: svn path=/cvs2svn/branches/WPAUL/dist/; revision=16119