History log of /freebsd/usr.sbin/rpc.ypxfrd/ypxfrd_extern.h (Results 1 – 13 of 13)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.0.0
# b3e76948 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0
# 937d37fc 19-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r325842 through r325998.


# df57947f 18-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

spdx: initial adoption of licensing ID tags.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensou

spdx: initial adoption of licensing ID tags.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

Initially, only tag files that use BSD 4-Clause "Original" license.

RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133

show more ...


Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs
# ed4d1c46 06-Feb-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Apply the following mechanical transformations in preparation for
ansification and constification:

s{\s+__P\((\(.*?\))\)}{$1}g;
s{\(\s+}{\(}g;
s{\s+\)}{\)}g;
s{\s+,}{,}g;
s{(\s+)

Apply the following mechanical transformations in preparation for
ansification and constification:

s{\s+__P\((\(.*?\))\)}{$1}g;
s{\(\s+}{\(}g;
s{\s+\)}{\)}g;
s{\s+,}{,}g;
s{(\s+)(for|if|switch|while)\(}{$1$2 \(}g;
s{return ([^\(].*?);}{return ($1);}g;
s{([\w\)])([!=+/\*-]?=)([\w\(+-])}{$1 $2 $3}g;
s{\s+$}{\n};g

Also add $FreeBSD$ where needed.

MFC after: 1 week

show more ...


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs, release/4.3.0_cvs, release/4.3.0, release/4.2.0, release/4.1.1_cvs, release/4.1.0, release/3.5.0_cvs, release/4.0.0_cvs, release/3.4.0_cvs, release/3.3.0_cvs
# 97d92980 28-Aug-1999 Peter Wemm <peter@FreeBSD.org>

$Id$ -> $FreeBSD$


Revision tags: release/3.2.0, release/3.1.0, release/3.0.0, release/2.2.8, release/2.2.7, release/2.2.6, release/2.2.5_cvs, release/2.2.2_cvs, release/2.2.1_cvs, release/2.2.0, release/2.1.7_cvs
# 476602a9 22-Feb-1997 Peter Wemm <peter@FreeBSD.org>

Revert $FreeBSD$ to $Id$


Revision tags: release/2.1.6_cvs, release/2.1.6.1
# 1130b656 14-Jan-1997 Jordan K. Hubbard <jkh@FreeBSD.org>

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

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.

show more ...


Revision tags: release/2.1.5_cvs
# 16118c2b 05-Jun-1996 Bill Paul <wpaul@FreeBSD.org>

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 tr

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

show more ...


Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs
# ed4d1c46 06-Feb-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Apply the following mechanical transformations in preparation for
ansification and constification:

s{\s+__P\((\(.*?\))\)}{$1}g;
s{\(\s+}{\(}g;
s{\s+\)}{\)}g;
s{\s+,}{,}g;
s{(\s+)

Apply the following mechanical transformations in preparation for
ansification and constification:

s{\s+__P\((\(.*?\))\)}{$1}g;
s{\(\s+}{\(}g;
s{\s+\)}{\)}g;
s{\s+,}{,}g;
s{(\s+)(for|if|switch|while)\(}{$1$2 \(}g;
s{return ([^\(].*?);}{return ($1);}g;
s{([\w\)])([!=+/\*-]?=)([\w\(+-])}{$1 $2 $3}g;
s{\s+$}{\n};g

Also add $FreeBSD$ where needed.

MFC after: 1 week

show more ...


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs, release/4.3.0_cvs, release/4.3.0, release/4.2.0, release/4.1.1_cvs, release/4.1.0, release/3.5.0_cvs, release/4.0.0_cvs, release/3.4.0_cvs, release/3.3.0_cvs
# 97d92980 28-Aug-1999 Peter Wemm <peter@FreeBSD.org>

$Id$ -> $FreeBSD$


Revision tags: release/3.2.0, release/3.1.0, release/3.0.0, release/2.2.8, release/2.2.7, release/2.2.6, release/2.2.5_cvs, release/2.2.2_cvs, release/2.2.1_cvs, release/2.2.0, release/2.1.7_cvs
# 476602a9 22-Feb-1997 Peter Wemm <peter@FreeBSD.org>

Revert $FreeBSD$ to $Id$


Revision tags: release/2.1.6_cvs, release/2.1.6.1
# 1130b656 14-Jan-1997 Jordan K. Hubbard <jkh@FreeBSD.org>

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

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.

show more ...


Revision tags: release/2.1.5_cvs
# 16118c2b 05-Jun-1996 Bill Paul <wpaul@FreeBSD.org>

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 tr

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

show more ...