of the rpc.lockd fully compliant with the old file locking semantics.
Andrew will dig into the statd code next and then will attack the split
locking.
This also backs out a lot of the work I've done on making the code
more conformant with non-written style rules, but we'll revisit that
later.
Submitted by: "Andrew P. Lentvorski" <bsder@allcaps.org>
Fix the WARNS 1 warnings except unused variables.
Add prototype for log_netobj().
Don't compare signed/unsigned.
Cast u_int64_t to 'unsigned long long' and print using %llu.
Fix constness of string arrays.
Use a cast to avoid an unused parameter in a signal handler.
alarm(2) can't fail, so don't check for it.
ANSI'ify some functions.
src/sys/fs/fifofs/fifo_vnops.c) to serve locks better, my previous
workaround for lack of decent fifo system wasn't cutting it,
particularly the kernel would send a message down the fifo and
immediately close it, this would lead to delayed unlock requests
being seen by the lockd causing all sorts of badness.
Basically, don't reopen the fifo, just select(2) on it.
make the code not automatically dead but actually use the debug level
in order to determine if output is needed. Fix non-existant from_addr()
by #define'ing it to inet_ntoa().
Remove hardcoded -g from Makefile.
Reported by: "John W. De Boskey" <jwd@bsdwins.com>
Tested by: "John W. De Boskey" <jwd@bsdwins.com>
associated changes that had to happen to make this possible as well as
bugs fixed along the way.
Bring in required TLI library routines to support this.
Since we don't support TLI we've essentially copied what NetBSD
has done, adding a thin layer to emulate direct the TLI calls
into BSD socket calls.
This is mostly from Sun's tirpc release that was made in 1994,
however some fixes were backported from the 1999 release (supposedly
only made available after this porting effort was underway).
The submitter has agreed to continue on and bring us up to the
1999 release.
Several key features are introduced with this update:
Client calls are thread safe. (1999 code has server side thread
safe)
Updated, a more modern interface.
Many userland updates were done to bring the code up to par with
the recent RPC API.
There is an update to the pthreads library, a function
pthread_main_np() was added to emulate a function of Sun's threads
library.
While we're at it, bring in NetBSD's lockd, it's been far too
long of a wait.
New rpcbind(8) replaces portmap(8) (supporting communication over
an authenticated Unix-domain socket, and by default only allowing
set and unset requests over that channel). It's much more secure
than the old portmapper.
Umount(8), mountd(8), mount_nfs(8), nfsd(8) have also been upgraded
to support TI-RPC and to support IPV6.
Umount(8) is also fixed to unmount pathnames longer than 80 chars,
which are currently truncated by the Kernel statfs structure.
Submitted by: Martin Blapp <mb@imp.ch>
Manpage review: ru
Secure RPC implemented by: wpaul
track.
The Id line is normally at the bottom of the main comment block in the
man page, separated from the rest of the manpage by an empty comment,
like so;
.\" $Id$
.\"
If the immediately preceding comment is a @(#) format ID marker than the
the $Id$ will line up underneath it with no intervening blank lines.
Otherwise, an additional blank line is inserted.
Approved by: bde
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.
their path names in the synopsis line (especially since they
referenced the wrong path!). Corrected some other minor problems
with the rpc.lockd man page.
- Use rpcgen to generate the unmodified boilerplate code rather than
having it in the repository.
- Eliminate the conflicting function names by changing them to their
"natural" rpcgen generated names
stub lockd.
This implements just the protocol, but does not interact with the kernel.
It says "Yes!" to all requests. This is useful if you have people using
tools that do locking for no reason (eg: some PC NFS systems running some
Microsoft products) and will happily report they couldn't lock the file
and merrily proceed anyway. Running this will not change the reliability of
sharing files, it'll just keep it out of everybody's face.
