src/include/rpcsvc, branch release/2.2.7_cvs

This commit was manufactured by cvs2svn to create tag

1998-07-24T04:57:32Z

'RELENG_2_2_7_RELEASE'. This commit was manufactured to restore the state of the 2.2.7-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

Bring in the 'make -DNOCLEAN world' fixes from -current. The problem

1997-09-10T07:18:46Z

is that obj/tmp/usr/include is built first with symlinks and then deleted and replaced with real files, causing all the dependencies to be triggered.

YAMFC. NFS fixes, make NFSv3 the default, some other fs fixes.

1997-05-14T08:19:35Z

Reviewed by: Hidetoshi Shimokawa

'make install' is not supposed to touch anything.

1996-08-30T22:36:45Z

missed these parts of Bruce's changes last time..

1996-08-30T21:57:39Z

Submitted by: bde (again :-)

Some bmake magic to clean up the install more.

1996-08-30T19:31:28Z

fix another missed -c typo of mine. clean the rpcgen implicit rule more Submitted by: bde

replace cmp -s || install with ${INSTALL} -C, and @for with .for

1996-08-29T19:59:48Z

There are a few small additions to the protocol to make it

1996-07-04T02:08:17Z

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.

Now that Peter has been nice enough to bail me out of my last little

1996-06-05T03:47:18Z

mishap, it's time to have the Makefile install ypxfrd.x and ypxfrd.h.

(I hope I'm doing this correctly.)

1996-06-05T02:42:33Z

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. :)