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.
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. :)
not based on gpl'ed code, just prototype and usage. I'm not 100% certain
they behave the same while the system is in trouble (eg: malloc() failing)
but in those circumstances all bets would be off anyway.
These routines work like sprintf() and vsprintf(), except that instead of
using a fixed buffer, they allocate memory and return it to the user
and it's the user's responsibility to free() it. They have allocate as
much memory as they need (and can get), so the size of strings it can deal
with is limited only by the amount of memory it can malloc() on your
behalf.
There are a few gpl'ed programs starting to use this interface, and it's
becoming more common with the scares about security risks with sprintf().
I dont like the look of the code that the various programs (including
cvs, gdb, libg++, etc) provide if configure can't find it on the system.
It should be possible to modify the stdio core code to provide this
interface more efficiently, I was more worried about having something
that worked and was secure. :-) (I noticed that there was once intended
to be a smprintf() routine when our stdio was written for 4.4BSD, but it
looks pretty stillborn, and it's intended interface is not clear). Since
Linux and gnu libc have this interface, it seemed silly to bring yet
another one onto the scene.
If _ANSI_SOURCE or _POSIX_SOURCE is defined, then <ctype.h> had to
be included before <stddef.h> or <stdlib.h> to get rune_t declared.
Now rune_t is declared perfectly bogusly in all cases when <ctype.h>
is included.
This change breaks similar (but more convoluted) convolutions in the
stddef.h in gcc distributions. Ports of gcc should avoid using the
gcc headers.
getnetgrent.c:
- Catch one bogon that snuck by: in _listmatch(), check for '\0'
rather than '\n'; strings returned from yp_match() are terminated
with a nul, not a newline.
getpwent.c:
- Rip out all of the +inclusion/-exclusion stuff from before and
replace it with something a little less grotty. The main problem
with the old mechanism was that it wasted many cycles processing
NIS entries even after it already knew they were to be exlcuded
(or not included, depending on your pointof view). The highlights
of these changes include:
o Uses an in-memory hash database table to keep track of all the
-@netgroup, -user, and -@group exclusions.
o Tries harder to duplicate the behavior normally obtained when using
NIS inclusions/exclusions on a flat /etc/passwd file (meaning things
come out in much the same order).
o Uses seperate methods for handling getpwent() and getpwnam()/getpwuid()
operations instead of trying to do everything with one general
function, which didn't work as well as I thought it would.
o Uses both getnetgrent() and innetgr() to try to save time where
possible.
o Use only one special token in the local password database
(_PW_KEYYPBYNUM) instead of seperate tokens to mark + and -
entries (and stop using the counter tokens too). If this new
token doesn't exist, the code will make due with the standard
_PW_KEYBYNUM token in order to support older databases that
won't have the new token in them.
All this is an attempt to make this stuff work better in environments
with large NIS passwd databases.
and real life. YPPUSHPROC_XFRRESP is supposed to return void and take
an argument of type yppushresp_xfr, not the other way around as yp.x seems
to imply. (I spent two hours today staring intensely at my prototype ypxfr
code and scratching my head before I finally figured this out.)
taking an argument of type ypresp_key. This is incorrect: it should be
ypresp_nokey. (yp_first() is supposed to return the first key in a
given map; the server doesn't need any client-specified key to handle
such a request.)
No, not really. There are just a couple of long-standing bogosities here
that I feel compelled to fix. :)
There are two small changes here:
1) yp.x actually contains _three_ protocol definitions: YPPROG (standard
NIS client/server procedures), YPPUSH_XFRRESPPROG (callback handler
for the YPPROC_XFR service, aka ypxfr/yppush) and YPBINDPROG (for ypbind,
ypset & friends). The problem is that when you run yp.x through rpcgen(1),
it generates client and server stubs with hooks for all three services.
This makes it impossible to actually use the rpcgen-erated code in a
program that only deals with _one_ of these services (ypserv, ypbind,
etc...) without manually removing the unneeded stubs (either by hand
editing or by committing unspeakable horrors with sed). This defeats
the whole purpose of using rpcgen and is generally annoying.
What I've done is to insert a few #ifndefs and #endifs to allow a
programmer to selectively blot out those functions that aren't needed
for a particular program. For instance, if you do 'rpcgen -DYPSERV_ONLY',
you'll get only the necessary client/server stubs to implement the
standard yp client and server functions. If you do 'rpcgen -DYPBIND_ONLY',
you get only what you need for ypbind. If you don't #define anything,
you get the whole mess, just like before, so existing programs won't
notice the difference. (Note that the -D flag is not supported by our
existing crufty version of rpcgen, but I intend to update it soon.)
2) The definition for the ypresp_key_val structure is actually incorrect
with respect to reality: the key and val members are specified in the
wrong order. It should be val/key rather than key/val. For whatever
the reason, Sun's actual NIS implementation contradicts the protocol
definition in this case. Again, accounting for this bogosity here is
cleaner and easier than mangling the output from rpcgen.
Note: this was done by selective patching from diffs by hand, in order
to not conflict with the 4.4BSD base code. Beta9 was done the same way.
Obtained from: Paul Vixie <paul@vix.com>
specified in the top level Makefiles.
Previously I missed dozens of Makefiles that skip the install after
using `cmp -s' to decide that the install isn't necessary.
- Don't do mkdir/chown/chmod
- Do `cmp -s' before attempting to install a header
This should fix the obnoxious problem of yp programs wanting to
rebuild every time.
include/signal.h:
There was massive namespace pollution from including <sys/types.h>.
POSIX functions were declared even when _ANSI_SOURCE is defined.
sys.sys/signal.h:
NSIG was declared even if _ANSI_SOURCE or _POSIX_SOURCE is defined.
sig_atomic_t wasn't declared if _POSIX_SOURCE is defined.
Declare a typedef for signal handling functions and use it to
unobfuscate declarations and to avoid half-baked function types
that cause unwanted compiler warnings at certain warning levels.
Fix confusing comment about SA_RESTART.
sys/i386/include/signal.h:
This has to be included to get the declaration of sig_atomic_t even
when _ANSI_SOURCE is defined, so be more careful about polluting
the ANSI namespace.
Uniformize idempotency ifdefs.
The version 2 support has been tested (client+server) against FreeBSD-2.0,
IRIX 5.3 and FreeBSD-current (using a loopback mount). The version 2 support
is stable AFAIK.
The version 3 support has been tested with a loopback mount and minimally
against an IRIX 5.3 server. It needs more testing and may have problems.
I have patched amd to support the new variable length filehandles although
it will still only use version 2 of the protocol.
Before booting a kernel with these changes, nfs clients will need to at least
build and install /usr/sbin/mount_nfs. Servers will need to build and
install /usr/sbin/mountd.
NFS diskless support is untested.
Obtained from: Rick Macklem <rick@snowhite.cis.uoguelph.ca>
on dlclose. Also correctly call constructors and destructors for libraries
linked with /usr/lib/c++rt0.o.
Change interpretation of dlopen manpage to call _init() rather than init()
for dlopened objects.
Change c++rt0.o to avoid using atexit to call destructors, allowing dlclose to
call destructors when an object is unloaded.
Change interface between crt0 and ld.so to allow crt0 to call a function on
exit to call destructors for shared libraries explicitly.
These changes are backwards compatible. Old binaries will work with the new
ld.so and new binaries will work with the old ld.so. A version number has
been introduced in the crt0-ld.so interface to allow for future changes.
Reviewed by: GAWollman, Craig Struble <cstruble@singularity.bevc.blacksburg.va.us>
