From: wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen)
Newsgroups: comp.sys.apollo
Subject: Re: 3COM PC NFS and Domain/OS
Date: 6 Jan 93 09:51:38 GMT
Organization: Eindhoven University of Technology, The Netherlands

In article <1993Jan05.215921.23513@edsi.plexus.COM> chuck@edsi.plexus.COM (Chuck Tomasi) writes:
=>I almost posted this about a month ago, but thought I would check the
=>FAQ list first... lucky for me I did and found some information.
Well that's what the FAQ is all about :-)
You've got some usefull stuff in there as well.

=>I'm running 3COM PC NFS on a test PC at our site and got pcnfsd.v2 off
=>the net, however the PC doesn't want to talk to our Apollo.  We're
=>running Domain/OS 10.3.5.4 on our workstation.  The sources 3COM sent
=>along with PC NFS didn't compile worth crap under Domain so I grabbed
=>the suggested pcnfsd.  After recently testing it I came to the same
=>conclusion as if it wasn't running at all.  I get a NFS103 error which
=>says that the remote host is not communicating.  Is there some way to
=>specify a port number to pcnfsd.v2?

Just to be obvious: You do have Apollo-NFS installed.
Otherwise the pcnfsd does do you any good. 
(eg. it makes, among others, the /etc/rpcinfo command available)

Note that most of the stuff is tested using PC-NFS by SUN. (at least my
remarks are.)

I'd have to look into the sources of the pcnfsd if there's switch
specifying a fixed port. Normaly it is all set up by the portmapper.

You just ask the port mapper for a free socket number, and go there and
wait for RPC calls. When somebody want to call you, he first goes to the
portmapper, and asks for your socket number.

To check if your routines are really available, use:
	rpcinfo -p <pcnfsd-host>                                

ebh{wjw}8: rpcinfo -p ebs
   program vers proto   port
    100000    2   tcp    111
    100000    2   udp    111
    100005    1   udp    856
    100003    2   udp   2049
    150001    1   udp    750
    150001    2   udp    750
    150001    1   tcp    753
    150001    2   tcp    753
[Now good OS-es would translate some of the numbers :-> ]
[But then they wouldn't have NFS :-) ]
but: 
  program 100000 is the portmapper himself, it is always on the fixed socket 111
          100005        mountd              on a variable port
          100003        nfsd		    should be on a variable port,
					    but SUN-HACKS made it default fixed. :-[
	  150001	pcnfsd		    on variable ports

Note that the pcnfsd has two versions of the RPC's registered. Version 1 and 2
It is up to the calling RPC to choose either one.

Next to that you can see that some services are both on udp and tcp.
Like on apollo where things can be tcp or dds.

Now if rpcinfo doesn't show anything, your problem lies with basic NFS/portmapper
problems. Otherwise it could be somewhere in the pcnfsd.
Which is shure a problem to compile, since there is an RPClib for 10.3.5, but
no includes which is dynamic. 
So I compiled the the actual SUN PC 4.0 code and statically linked to that lib.
I got some warnings, but I'm not deep enough into Apollo tricks to solve those.
[And it workes flawless for use, so I'm spending the time elsewhere]

=>I have successfully used 3comnfsd on our HP-UX machines, but as
=>mentioned before those sources don't compile at all on our Domain
=>machines.
If the user on Apollo are the same as those on Apollo, why not use the HP-UX deamon.
[same = same UID and GID]
Only one source of authorisation of PC-NFS is needed within an organisation, 
as long as all users have the same identity everywhere.

Enjoy, en feel free to ask,

	Willem Jan

Digital Information Systems Group, Room EH 10.35 
Eindhoven University of Technology   
P.O. 513                     		Tel: +31-40-473401,Fax: +31-40-448375
5600 MB Eindhoven            		The Netherlands
Newsgroups: comp.sys.apollo