Remove $FreeBSD$: one-line xdr pattern

Remove /^\s*%\s*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

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

- Correct mispellings of the word necessary

Submitted by: Christoph Mallon <christoph.mallon@gmx.de> (via private mail)

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Create the altix project branch. The altix project will add support
for the SGI Altix 350 to FreeBSD/ia64. The hardware used for porting
is a two-module system, consisting of a base compute module and a
CPU expansion module. SGI's NUMAFlex architecture can be an excellent
platform to test CPU affinity and NUMA-aware features in FreeBSD.

- Import the HEAD csup code which is the basis for the cvsmode work.

Use __FBSDID vs. rcsid[].

Removed duplicate VCS ID tags, as per style(9).

$Id$ -> $FreeBSD$

Removed redundant declarations. rpcgen generates `typedef enum foo;'
from `enum foo;'.

Resolve conflicts.

Hold onto your hats folks, here it comes: the first stage of the
Secure RPC import I've been threatening.

This step adds some necessary protocol definition files and headers to
rpcsvc, including the ones needed for NIS+.

Reviewed by: Mark Murray

Revert $FreeBSD$ to $Id$

Make the long-awaited change from $Id$ to $FreeBSD$

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.

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.

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