messy way, so as to not disrupt other yp programs: just add casts to
convert the incompatible enums, as the numerical values are the same
(either by accident, design, or the phase of the moon at that time).
MFC after: 1 week
Just like bin/ and sbin/, I think setting WARNS to the highest value
possible will make it more attractive for people to fix warnings.
- The WARNS variable is set in the Makefile in the directory of the
application itself, making it more likely that it will be removed out
of curiosity to see what happens.
- New applications will most likely build with WARNS=6 out of the box,
because the author would more likely fix the warnings during
development than lower WARNS.
Unfortunately almost all apps in libexec require a lowered value of
WARNS.
is asking for trouble (sequential database enumerations can get caught
in an infinite loop). The yp_mkdb(8) utility avoids putting such records
into a database, but ypxfr does not. Today I got bit by a NULL entry in
one of the amd maps on my network, which is served by a SunOS master.
The map was transfered successfully to my FreeBSD slave, but attempting
to dump it with ypcat(1) caused ypserv(8) to transmit the same record
over and over again, making the map appear to be infinitely large. I
finally noticed the problem while testing a new version of amd under
development at the Columbia CS department, which began gobbling up insane
amounts of memory while trying to swallow the map.
To deal with this problem, I'm modifying ypxfr to watch for records
with zero-length keys and turn them into something less destructive
before writing them to the database.
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.
matches what's in ypserv/yp_extern.h (which I changed when I added the
async DNS stuff). The conflict broke the build of rpc.yppasswdd.
Pointed out by: bde
and YP_SECURE flags so that it can properly add them to newly created
maps when needed. This applies only when using the 'standard' method
for map transfers. When using rpc.ypxfrd, the whole map is copied
verbatim, along with any special entries that may be encoded in it.
Also made -Wall a little quieter for ypxfrd_getmap.c.
or rpc.ypxfrd processes on remote systems that aren't bound to reserved
ports. The servers already do reserved port checks on the clients.
Obtained from: scrutinizing the OpenBSD ypxfr sources. (Note that this
applies to the ypserv check only; OpenBSD doesn't have an rpc.ypxfrd.)
