Per.Winberg@dc.luth.se (Per Winberg) (04/03/91)
Hello
We are trying to run PC-NFS (ver 3.01) and Novell (Ver 2.11 and 3.10)
but we can't make them coexist. Can somebody help us with this small problem.
What we want to do is to access drives on Novellservers, and on the SUN-Unix
at the same time, without reconf. and reboot our MSDOS-workstations. It's so
annoying.
Our LAN-configuration
From the workstation-view, we are connected to a MultiPortRepeater, and from
the MPR to SUN-server (PC-NFS), and our Novell-servers.
We are using 3COM503 and 3COM523 ethernetcards.
Where can we get the right drivers ?
How shall we set up the workstations for this ?
Do we have to use econfig ?
Do we have to go through a bridge/router ? (Packetdrivers ver 1.8)
Could we use PKTD.SYS in PDNFS.ZIP, the last lines in the docs, says something
about "If...then we could coexist with Novell.".
WHAT SHALL WE DO ????????
----------------------------------------------------------------------------
Per Winber, Computer centre, University of Lulea, S-951 87 Lulea, Sweden
Tel: +46 920 91 778 (direct) +46 920 91 000 (operator). Fax: +46 920 972 88
Domain: per@dc.luth.se Path: {uunet,mcsun,sunic}!dc.luth.se!perjrd@cc.usu.edu (04/05/91)
In article <1664@hagbard.dc.luth.se>, Per.Winberg@dc.luth.se (Per Winberg) writes: > Hello > > We are trying to run PC-NFS (ver 3.01) and Novell (Ver 2.11 and 3.10) > but we can't make them coexist. Can somebody help us with this small problem. > What we want to do is to access drives on Novellservers, and on the SUN-Unix > at the same time, without reconf. and reboot our MSDOS-workstations. It's so > annoying. > > Our LAN-configuration > > From the workstation-view, we are connected to a MultiPortRepeater, and from > the MPR to SUN-server (PC-NFS), and our Novell-servers. > We are using 3COM503 and 3COM523 ethernetcards. > > Where can we get the right drivers ? > > How shall we set up the workstations for this ? > > Do we have to use econfig ? > > Do we have to go through a bridge/router ? (Packetdrivers ver 1.8) > > Could we use PKTD.SYS in PDNFS.ZIP, the last lines in the docs, says something > about "If...then we could coexist with Novell.". > > WHAT SHALL WE DO ???????? > > ---------------------------------------------------------------------------- > Per Winber, Computer centre, University of Lulea, S-951 87 Lulea, Sweden > Tel: +46 920 91 778 (direct) +46 920 91 000 (operator). Fax: +46 920 972 88 > > Domain: per@dc.luth.se Path: {uunet,mcsun,sunic}!dc.luth.se!per One thing you can do is an anonymous ftp to my VMS VAX, netlab.usu.edu 129.123.1.11, and look in the [.pcnfs] directory for comments on the situation and a spiffed up pktd.*. What I found was that I could make PC-NFS and Novell coexist at the Packet Driver level, but they would not at the DOS redirector level. The incompatibility was assigned to SUN's corner because the similar redirector of AT&T StarGROUP did work fine with NetWare. My PC-NFS version is 3.0. Since then SUN has issued a new version of PC-NFS, which I am told addresses these and other issues. So you might want to talk with SUN about the new version. Joe D.
oowwoo@mixcom.COM (Tom J. Vandenberg) (04/08/91)
This may be a stupid question, but are you running the 386 3.1 PCNFS NLM? Tom Vandenberg, CNE oowwoo@mixcom.com
Anders.Nilsson@dc.luth.se (Anders Nilsson) (04/09/91)
In article <492@mixcom.COM> oowwoo@mixcom.COM (Tom J. Vandenberg) writes: >This may be a stupid question, but are you running the 386 3.1 PCNFS NLM? > >Tom Vandenberg, CNE >oowwoo@mixcom.com WHAT ??? If there is a 386 3.1 PCNFS NLM, I really want to know all about it. (I thought that the NFS NLM only works when a UNIX, or whatever, wants to NFS-mount a Novel NetWare drive) Answer quickly, please. ----- Anders ----
keith@ca.excelan.com (Keith Brown) (04/12/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <1664@hagbard.dc.luth.se> <1991Apr4.201455.47278@cc.usu.edu> <492@mixcom.COM> <1675@hagbard.dc.luth.se> Date: Wed, 10 Apr 1991 18:16:25 GMT In article <1675@hagbard.dc.luth.se> Anders.Nilsson@dc.luth.se (Anders Nilsson) writes: >In article <492@mixcom.COM> oowwoo@mixcom.COM (Tom J. Vandenberg) writes: > >If there is a 386 3.1 PCNFS NLM, I really want to know all about it. No, there is not a 386 3.1 PCNFS NLM. >(I thought that the NFS NLM only works when a UNIX, or whatever, wants to >NFS-mount a Novel NetWare drive) The product is really designed to support UNIX NFS clients but, as you might expect, can provide generic NFS file service to just about anything capable of being an NFS client. The main issue with using NetWare NFS v1.1 being used in conjunction with PCNFS is authentication. Unlike NetWare/IPX/NCP, NFS relies on user authentication being done at the client for security. Using UNIX as an example, a user must login and quote a password to gain access to the machine, after which the OS identifies the user using two 16 bit numbers, a User ID (UID) and a group ID (GID). It is these two numbers that are passed across the network in NFS client requests so that the NFS server can identify the requestor. You can "trust" the UID and GID because the requestor had to quote a username and password to obtain those numbers. Alas, this reasoning breaks down when you introduce NFS clients that have no user authentication mechanism, such as DOS PCs and Macs. The potential is there for anyone to simply walk up to a DOS PC, set up whatever UID and GID they wanted and start making NFS requests of a server (assuming the mount point was not protected). In order to provide a veneer of security most PCNFS implementations don't allow you to do this. They insist that you "authenticate" yourself against a little daemon program running in the networks "secure" environment, usually called PCNFSD. Authentication amounts to the PCNFS user haveing to quote a username and password to PCNFSD which, if they are correct, will result in PCNFSD dishing out the corresponding UID and GID to the PCNFS implementation which will then proceed to use it in NFS requests. So, whats the issue with NetWare NFS? Well, the issue is that we currently don't implement a PCNFSD.NLM as part of the product. The good news is that we don't really have to! First off, we have this other method by which DOS systems gain access to NetWare servers. Some of you may have used it :-). Second off, for the hardened PCNFShead who wouldn't be seen dead with a NetWare shell or non-TCP/IP protocol stack on his/her DOS system it isn't an issue either. There only needs to be one PCNFSD on the network against which you authenticate yourself, after which you can use the UID and GID you have been authenticated as in requests to any servers, including NetWare NFS servers. If you're such a PCNFS lover in the first place, you'll already have a PCNFSD running somewhere, won't you? It's not all roses and violins however. There is at least one PCNFS implementation I know of that insists on authenticating itself against a PCNFSD that must be running on the same server as you plan to be mounting. We're still scratching our heads on this one. Perhaps if we ignore it for long enough, it will go away! Before anyone follows up on my scribblings on security, *yes* I do know about secure RPC and *yes* I do know about Kerberos, so don't bother. They are outside of the scope of this posting. Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM