My last note described various problems getting PC-NFS (3.0.x)
to print or even find and use the YP servers after switching from
Sun 386i's (SunOS 4.0.1) to SPARCstations (SunOS 4.1.1). I received
many responses, summarized below. The immediate problems are solved.
Problems: Slow to non-existant acknowledgment of YP servers by PC and
thus bad network access. Inability to print due to lack of permission
to drive "U:"
What I did was:
Make sure pcnfsd was running (of course).
Answered all questions completely on the PC-NFS configure;
including the "advanced" questions, not trusting the PC
to figure anything out on its own.
Made sure "/var/spool/pcnfs" is exported. PC-NFS doesn't
use lpd; it writes directly to subdirectories via network
disk "u:" a.k.a. "/var/spool/pcnfs".
This isn't entirely satisfactory; I'd like the PC's to be
able to sniff out new info better (so I don't have to go
around and type at 20 keyboards) but is as far as I've gotten.
Some of the suggestions would probably completely solve the
problem but, given the amount of heat directed at yours truely,
I just went ahead and used the first thing that worked and will
work out the rest on evenings when no-one is using the PC's.
Many Many Thanks-
Dave Fetrow
Biostatistics, University of Washington
P.S. I sent Email to anyone who asked for the info already BUT
it sometimes bounced. Hopefully, this won't have that problem.
================================================================
Received: by philica.ica.philips.nl;
id AA19241; Wed, 1 May 91 16:30:40 +0200
Date: Wed, 1 May 91 16:30:40 +0200
From: geertj@ica.philips.nl (Geert Jan de Groot)
Message-Id: <9105011430.AA19241@philica.ica.philips.nl>
To: fetrow@biostat.washington.edu
Subject: Re: PCNFS
Status: R
Hi,
I might be able to help you out here. It takes some efforts to get PCNFS up.
First off, remember that PC's are very simple-minded about network issues.
During startup, some heuristic measures are taken that shouldn't be,
but nevertheless are. Your best bet is to run
etherfind -host <PC> -o -broadcast
and see who's talking to who.
PCNFS tries to ypbind, default route and rpc.pcnfsd from the same host
it got its reverse ARP answer from. Therefore, look with etherfind to
see what the PC is trying to do.
Here, we made a distiction between the fileservers, that have rarpd, ypserv,
pcnfsd, routed etc running and the rest, which doesn't have any of these
services up. So, the PC 'picks' a machine ritch of services.
Your delay probably stems from re-tries in the hope to find a 'better'
server. Non-loaded workstations usually have the advantage over
loaded fileservers and this doesn't succeed. Therefore our fileserver
distiction.
> Another symptom is the inability to print (it is not getting permission
> to use drive "u:") although /etc/hosts.lpd lists the PCs.
/etc/hosts.lpd has NOTHING to do with the PC's ability to print.
(although the lpq program I posted some weeks ago does need it).
The PC tries to mount /usr/spool/pcnfs. This directory is dictated
in the rpc.pcnfsd binary (or the command line of rpc.pcnfsd, but there's
a bug in command line handling if I remember correct).
You need to add that directory in /etc/exports and run exportfs -a after that.
A PC tries to print by:
1. trying to mount the spool directory during startup.
2. making a temporary file in /usr/spool/pcnfs/<PC>.
3. When it is time to spool the file, the spooling is done via a rpc.pcnfs
RPC call.
This must all succeed in order to print.
===========
From: ramsey@majorleague.npirs.purdue.edu
Status: R
>> We recently switched from Sun 386i's to Sun 4's for the YP servers
>> in our domain. We are running 4.1.1 on the 4's.
>>
>> Although the Suns are quite happy with the change my PC's have
>> gotten very cranky. They run PC-NFS 3.0.0 and 3.0.1. It can take
>> 20 minutes to get past "YPSET" on the PC.
What *we* had to do to get everything working when *we* changed from a
386i to a sparc was to (1) turn off all the pc's except 1, (2) using
nfsconf, answer every direct connect network question explicitly,
including the advanced questions, without letting pcnfs use *any*
defaults or *any* information derived by itself from the net or from
yp maps. (3) reboot the pc and try to authenticate. Eventually we got
everything working. When we went to pcnfs 3.5 we had to manually
change the nfs/network.bat file (but thats a different story). Hope
this helps...
-Ed
=============
When I upgraded to 4.1.1 from 3.5 my PCs were very cranky as well.
I forget the symptoms but the key thing was to modify the pcnfsd code
that runs on the SUNs. Thinking about it more maybe only logins failed...
But I have attached my code at the end here. The trick was to find all
routines that were supposed to be returning an 'int' and actually make
them return it. It seems the old compilers would return a 0 even if
you didn't explicitly do it, the new one doesn't. It affected the
passwd verification scheme??? I think I changed some routines to be
void.... All I know is that everything works now....
--G
--
Guntram Wolski gwolsk@sei.com
Silicon Engineering, Inc. 408-438-5331 x112
...!{mips,ames,ucscc}!seidc!gwolsk
===========
....Waiting for permission to post....
===========
Date: Wed, 1 May 91 12:44:14 MDT
From: asc!jerry@beaver.cs.washington.edu (Jerry Stachowski)
Message-Id: <9105011844.AA10975@agcsun>
To: fetrow@u.washington.edu
Subject: PC-NFS & SunOS 4.XX
Status: R
I ran into an authentication errors when I switched from PC-NFS 2 to PC-NFS
3. You might check that net ypset and net pcnfsd are set up in your
\nfs\network.bat file.
Take Care,
Jerry Stachowski
agcsun!jerry@boulder.COLORADO.edu
============
From: yamada-sun!eric@nosun.West.Sun.COM (Eric Hanchrow)
...suggested upgrading to 3.5. The upgrade appears to be very reasonablly
priced although my problem probably have not gone away.
============
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:13 CDT