Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!news.uoregon.edu!vixen.cso.uiuc.edu!chi-news.cic.net!news.cais.net!van-bc!news.mindlink.net!sol.ctr.columbia.edu!sirius.ctr.columbia.edu!wpaul
From: wpaul@ctr.columbia.edu (Bill Paul)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: RPC errors
Date: 16 Jun 1996 17:20:47 GMT
Organization: Columbia University Center for Telecommunications Research
Lines: 202
Message-ID: <4q1fpf$dih@sol.ctr.columbia.edu>
References: <Pine.SUN.3.93.960615125010.15636C-100000@xs2.xs4all.nl>
NNTP-Posting-Host: sirius.ctr.columbia.edu
X-Newsreader: TIN [version 1.2 PL2]
Daring to challenge the will of the almighty Leviam00se, thomas@xs2.xs4all.nl
had the courage to say:
: Greetings,
: I have a problem with NIS -- no, i installed the DES package :-) I'm
: running a NIS server on a SUN Sparcstation 1+, and several clients on
: several machines (SUNs) and they all work fine - except my recently
: installed FreeBSD machine. NIS works about half the time there - roughly
: ever second 'finger <NIS-user>' gives me a 'no such user' message. Also
: roughly half the time i get an error-message:
: yp_next: clnt_call: RPC: Can't decode result
You could do me a great favor by trying a later 2.2 snapshot. There's
a June 12th one which may work better. I tried to make a few performace
improvements to the client side code and in the process I introduced
a bit of a bug which I don't think I fixed in time to make the SNAP
version that you have. (Though so far I've only had one confirmed case
of a problem caused by it.)
Basically, each ypclnt function (yp_next(), yp_first(), yp_match(), etc..)
was doing a _yp_dobind() and yp_unbind() each time it was called. This
meant that each function was doing a clnt_create() and clnt_destroy()
(along with a bit of internal NIS housrkeeping) even though it didn't
really need to. Considering that there are some programs that call
yp_next() many, many times in sucession (usually to read the passwd
database via getpwent()), the extra overhead can be murder.
So I changed things a bit to that each function would only bind a
given domain once no matter how many times it was called and only
rebind if an error was detected. (You can make several clnt_calls()
using just one instance of an RPC client handle.) Unfortunately, I
didn't realize (at first) that each binding preserves a UDP socket,
and that these sockets could get clobbered by the caller without the
ypclnt package realizing it. For example, if you have a program that
calls yp_next(), then does for(i = 0; i < 256; i++) { close(i); },
then calls yp_next() again, the second yp_next() would fail and be
forced to rebind because the caller has closed the socket it was
holding onto. Also, if the caller happened to open a new socket
or other descriptor using the same descriptor number as one of the
sockets references inside the ypclnt package, subsequent calls to
yp_next() would clobber the caller's socket and cause the program
to behave strangely.
Later I changed _yp_dobind() to check the authenticity of socket
descriptors and rebind (preserving the old descriptor) if it finds
that the descriptor has been toasted somehow. But the SNAP you have
doesn't have this change in it, which could explain the errors
your seeing.
: The errors and failures don't seem to have any relation, by the way, but
: this could be a flaw (*duck*) in FreeBSD's stderr handling, maybe ?
No, not even close.
: I also noticed an odd quirk in NFS (which i have running but haven't
: really used yet) -- I automount the home disk from the SUN, and every few
: times i type 'ls' in the 'home' directory, it nog only gives me a listing
: of all 111 users' homedirs, but also of their contents - like ls -R. This
: has never happened in any other mounted directory, nor when i piped ls to
: more for instance.
Sorry, I've never seen this myself.
: The SUN runs SunOS 4.1.3, the PC FreeBSD from the 2.2-960501-SNAP
: distribution, with only DES extra -- Does anyone know this problem, or a
: possible solution ?
I haven't seen this particular error message myself, but I still
suggest that you try a newer snapshot release.
: Or should i just forget about FreeBSD, and take Linux
: instead ?
#ifdef BOFH
Excuse me. Would you hold still for a moment? Thank you.
LART! LART! LART!
#else
This may sound like maketing FUD, but believe me when I say that
Linux's NIS support is no better than FreeBSD's. This is actually one
place where I feel that Linux's development strategy causes trouble.
(Bear in mind though that we're actually talking about Linux's userland
development, not the kernel.) NIS requires changes to several different
parts of the system: you need to modify several pieces of libc, you
have to add special support to certain system utilities (passwd, chpass,
chfn, etc...), you have to create several NIS-specific client utilities
(ypcat, ypwhich, yppoll, ypset, ypbind), and if you want server support
you also have to create a bunch of server programs (ypserv, rpc.yppasswdd,
rpc.ypxfrd) and other utlilties (yppush, ypxfr).
With Linux, libc is being developed by one group (or one person -- last
I checked, H.J. Lu was doing most of the work), the client utilities
are being developed by another group, the server utilities by a third
group (or person; Thorsten Kurkuk seems to be the one handling ypserv
now) and various other people may be working on the modified system
utilities like passwd and chfn. (If I remember correctly, both yppasswd
and yppasswdd are part of one package written by Olaf Kirch (actually,
he wrote the server and someone else provided a version of yppasswd
ported from NetBSD) which is maintained seperately from ypserv & co.)
And of course, NIS is itself dependent on the RPC library, which brings
us back to libc again but with a twist.
While division of labor can be a good thing, each of these packages
is maintained by seperate people in different parts of the world
who don't share a common development base. If you find a problem,
you have to figure out what part of the system is at fault: is it
RPC, is it libc, the utilities, one of the servers? Then you have to
figure out which distribution of the given component you have and
who maintains it. And then you need to make sure which version you
have.
To fix it, you have to first figure out where the latest version of
the problem component can be found and try to install and test it.
This in itself may not work since the guy who maintains the package
may be using a different Linux distribution than you, which could
lead to compile/link errors. Then once you get it compiled, you may
find that your problem is still there, or that the new version
introduces new problems that you never expected.
Furthermore, at least a few of the utilities are closely tied
to code inside libc. One example is ypbind: it generates binding
files which _yp_dobind() inside libc has to read. If for some
reason the ypbind maintainer decides to change the format (which
is not necessarily a bad thing if it's for a good reason like
improving performance), then libc has to be changed too. This
means that patches have to be submitted to the libc maintainer and
you have to wait for the next libc distribution to come out
before you can use the new ypbind. (Well, actually, if the
library code is smart it can contact ypbind directly to get the
binding information if reading the file fails. This assumes
that the format change can be detected.)
Lastly, you may find that the NIS support in the Linux distribution
that you bought doesn't work as well as you'd like, whereas your
neighbor bought a different Linux distribution and his NIS support
works just fine.
With FreeBSD, all of the NIS support is part of a single build
tree available from only one source. If one of the developers
changes one part of the system, the others will know about it
right away and can fix any potential conflicts that may arise.
Having all the userland code under one roof means that if I
change ypbind, I can also change libc to match it instead of
sending patches to the libc maintainer and sitting on my thumbs
until he makes a new release. All the different components
are kept in sync. All the latest code is available from one
central location (or a mirror of it); you don't have search
through a bunch of different FTP sites to find all the pieces.
And if you find a bug, you submit a problem report to just one
location. You have somewhat better communication between developers
since all people with commit access to the source repository are
on the same mailing lists and have accounts on the same machine.
(It happens that I've been doing a lot of the NIS-related work
with FreeBSD lately though there could be other people in the
future.) And you don't have a zillion different version numbers
to keep track of. (As an aside, this is one thing that always
amuses me about the Linux problem reports that I see in the
newsgroups: whenever someone posts about a problem, they
always have to include a littany of version numbers for the
various parts of their system. "I have libc version foo,
networking tools version bar, kernel version baz, YP clients
version blech and nfsd version blatz. The system was originally
FOOware version gronk but I've upgraded to gcc version wheeze
with ELF support blah and ld.so version squeak. Has anyone else
seen this problem?" You may have this sort of thing happen
during _development_ where the RCS version strings on certain
files will change and people will use them as references when
reporting bugs, but to have this spaghetti of version numbers
to deal with in a production system is just asking for trouble.)
If you really want to try Linux to compare its NIS support then
go ahead, but I don't expect you'll find it to be better than
FreeBSD's.
#endif
: (I need to use FreeBSD because linux doesn't have support for
: the Compaq machines we are obliged to use. But assides from this little
: problem (And the DES incompatibility) i'm quite pleased with FreeBSD)
I'm not sure what you mean by DES incompatibility. If you mean the
fact that FreeBSD ships with a crypt() function that generates MD5
hashes instead of the usual DES crypt(), this is not an incompatbility.
This is a necessity: Walnut Creek can't legally ship FreeBSD CD-ROMs
out of the country if they contain any DES code. Exporting crypto
code is crime in the U.S. Do work around this, FreeBSD uses MD5
hashes for its passwords by default and you can download a seperate
version of libcrypt that uses DES from an FTP site near you if
you want to add DES support.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"If you're ever in trouble, go to the CTR. Ask for Bill. He will help you."
=============================================================================