williams@vrdxhq.verdix.com (Tim Williams) (05/22/89)
Has anyone out there had any experience with the use of PC NFS which allows DOS based PCs to use a SUN as a file server. Good and bad experiences would be appreciated. Also, is there a document or book on NFS. I am mainly looking for the technical details on how it works and the format of its headers and such. Thanks Tim Williams
roy@phri.UUCP (Roy Smith) (05/23/89)
williams@vrdxhq.verdix.com (Tim Williams) writes: > Has anyone out there had any experience with the use of PC NFS which allows > DOS based PCs to use a SUN as a file server. We have been using PC-NFS for a year or more and are reasonably happy with it. We use the 3Com-503 card that Sun sells. I suspect you can get other (possibly better) cards from other sources for less money, but we figured we'd avoid hassles getting everything from one vendor. I'm not really a network guru, so I can't comment on the fine points, but it does seem to work. We mount disks from our Sun-3/180 file servers running SunOS-3.5.2 and Vax-11/750 running MtXinu 4.3BSD/NFS, mostly so people can store their 1.5 Mbyte digitized images on the Sun's big disks (the PC exists mostly to drive a raster scan device). The funkiest thing we've done so far is a direct PC-Macintosh ftp transfer using the ftp client that comes with PC-NFS on the PC and the NCSA ftp server. We had to start up the ftp server by hand on the Mac, but it worked fine after that. Setup was, to my mind, kind of complicated. I should qualify that by saying that I know next to nothing about DOS so whereas I was totally baffled by what needed to put in which startup file may be completely second nature to somebody who really knows their way around a DOS system. There is a rather nice menu-driven config program to gather information like IP addresses and host names. PC-NFS knows how to talk to YP servers (but, I don't think it can talk to nameservers, or at least the version we have doesn't seem to be able to). It knows about arp and rarp, subnets, and configurable broadcast addresses. With the help of a pcnfsd running on some server on your network (they supply pcnfsd source) you can to print to printers under control of the Berkeley lpr spooling mechanism. They supply a telnet(vt100) and ftp client too. About the only thing missing to make a PC a full-fledged network machine is SMTP, but I think that may be an option. It's not entirely clear what good an SMTP server does on a PC, but it might be nice to be able to send mail, and maybe read it using some sort of POP client. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
stan@cory.Berkeley.EDU (See-Mong Tan) (05/24/89)
In article <17676@vrdxhq.verdix.com> williams@vrdxhq.verdix.com (Tim Williams) writes: [deleted] >Also, is there a document or book on NFS. I am mainly looking for >the technical details on how it works and the format of its headers and such. The reference I found really useful was the Sun publication "Networking on the Sun Workstation," published and probably available from them. Unless I'm wrong, they give you that manual if you buy a couple of workstations from them. The book (it's thick enough) gives a lot of technical details of NFS, and the attendant mount protocol also. If you're looking for technical, I suggest you start here. >Tim Williams ------- stan@lbl-csam.arpa stan@csam.lbl.gov
geoff@hinode.east.sun.com (Geoff Arnold) (05/26/89)
In an article which got dropped on the way to my system but which Carl Smith forwarded to me, Alastair Milne (milne@ICS.UCI.EDU) writes: }>Has anyone out there had any experience with the use of PC NFS which allows }>DOS based PCs to use a SUN as a file server. Good and bad experiences }>would be appreciated. } } I didn't think there was any other way to use it! My understanding of } PC-NFS is that it requires a UNIX-based host to be on the same net, } providing all server capacities (not just file) for all the PC's on the } net, as none of the PC's can be a server. } While it is true that the vast majority of NFS servers are UNIX-based, let's give credit to the brave souls who have written servers for VMS. VM, MVS and many other OS's - including DOS. PC-NFS (and any other NFS client worthy of the name) will interoperate with all of these, and has done so at Connectathons each year since '86. } I have only 2 complaints about PC-NFS so far: } - can't get broadcasts to the PC's from either server or other PC's. } would be very useful for downtime alerts. What protocol would you suggest we talk? We don't really want to fill up memory with TCP-based TSR's. One suggestion (if you're good at DOS applications) would be to designate a particular file on an NFS drive as a bulletin board, and write a little TSR that periodically stat'd the file and if it had changed displayed the contents in a pop-up window. If someone writes one and puts it on the net, we'd all be able to use it. } - neighbouring PC's are still completely invisible to each other. } There is no way, for instance, for the XT with its 10MB hard disc to } share hard discs with one or more of the Tandy's, which each have 70MB } hard discs. Check out the announcements in earlier comp.protocols.nfs postings concerning SOS, a DOS NFS server written by See-Mong Tan at LBL. You can FTP it from lbl-csam.arpa in /pub/sos.tar.Z. Geoff Arnold, Internet: garnold@sun.com Manager, PC-NFS Engineering UUCP: ....!sun!garnold PCDS Group, Sun Microsystems Inc. "A disclaimer? Sure, at that price you can have half a dozen of 'em."
milne@ics.uci.edu (Alastair Milne) (06/04/89)
geoff@hinode.UUCP (Geoff Arnold) writes >..., milne@ICS.UCI.EDU writes: > >} I have only 2 complaints about PC-NFS so far: >} - can't get broadcasts to the PC's from either server or other PC's. >} would be very useful for downtime alerts. > >What protocol would you suggest we talk? We don't really want to fill up >memory with TCP-based TSR's. I don't know nearly enough about NFS to be able to talk about its protocols, but I do know that PC-NFS incorporates a serial number checker which causes each PC to check its own PC-NFS S/N against that of every other PC on the net; and if any 2 or more PC's are found to have the same number, the screens of both or all of them are erased and a message from Sun displayed on them. If this happens 3 times, all copies with the same S/N are disabled. The immediate reaction is that if Sun can do this much to guard against piracy (a reasonable measure, I think, though it can cause some incidental problems in installation), a similar service for broadcasts should not be impossible, presumably derived from the anti-piracy system. I more than agree with you about TSR's (TCP-based or any other kind): with an "operating system" such as DOS, which provides *no* runtime management of code, allowing stray bits of it to remain in memory -- unsupervised, unswappable, immovable -- seems to me likely to invite totally unexpected runtime problems, especially as few of them are likely to be as robust as one could wish. As I recall, even the best known resident servicers (such as PC Sidekick) can cause odd and devious problems when new applications or TSR's are added. Not quite as risky as throwing unknown chemicals together to see what happens, but not wholly dissimilar, either. I would certainly sooner tackle a problem in almost any other way. >One suggestion (if you're good at DOS >applications) would be to designate a particular file on an NFS drive >as a bulletin board, and write a little TSR that periodically >stat'd the file and if it had changed displayed the contents in >a pop-up window. I'm semi-moderate with DOS applications, though I've never tried a resident servicer (note paragraph above). I have seen a little discussion of installing a servicer for the clock interrupt, though never a full implementation. I'm not at all sure, though, that an interrupt handler is allowed to make BIOS calls, much less run a child program. (BTW, the only "stat" I know of was a CP/M program. Can't immediately think of a DOS equivalent.) Would anybody care to explore this? >If someone writes one and puts it on the net, we'd all be able to use it. Frankly, I'd sooner have a solution integrated into PC-NFS. But this might at least be better than nothing. >... SOS, a DOS NFS server written by See-Mong Tan at LBL. >You can FTP it from lbl-csam.arpa in /pub/sos.tar.Z. A great tip, thanks! I have ftp'd it already. I tried running it, just for fun, on one of the Tandy's, but it just reported 4 things it couldn't do, and gave up. I suspect it needs PC-NFS disabled first. I need a closer look at the man sections. (If it's for DOS, why is it so UNIX oriented?)
stan@cory.Berkeley.EDU (See-Mong Tan) (06/05/89)
In article <16545@paris.ics.uci.edu% Alastair Milne <milne@ics.uci.edu% writes:
%
%%... SOS, a DOS NFS server written by See-Mong Tan at LBL.
%%You can FTP it from lbl-csam.arpa in /pub/sos.tar.Z.
%
% A great tip, thanks! I have ftp'd it already. I tried running it, just
% for fun, on one of the Tandy's, but it just reported 4 things it couldn't
% do, and gave up. I suspect it needs PC-NFS disabled first. I need a
% closer look at the man sections. (If it's for DOS, why is it so UNIX
% oriented?)
The server program works with PC-NFS's socket libraries, courtesy of
Geoff Arnold. There are some things you must set up first, like a file
with a list of exported filesystems, etc., and I don't think you want
to *disable* PC-NFS.
Why is it so Unix oriented? I can think of a few reasons:
1. I'd never worked with a PC before. So when I did the docs, the
best choice was troff for me, since...
2. It's Berkeley here, I grew up on BSD Unix. :-).
---
stan@lbl-csam.arpa
stan@csam.lbl.govandrew@dgbt.uucp (Andrew Patrick ) (07/01/89)
In article <3781@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: ... >About the only thing missing to make a >PC a full-fledged network machine is SMTP, but I think that may be an >option. It's not entirely clear what good an SMTP server does on a PC, but >it might be nice to be able to send mail, and maybe read it using some sort >of POP client. Sun sells a product called PC-NFS Lifeline that runs on top of PC-NFS and provides for mail service at the PC. Lifeline runs in either SMTP or POP mode -- I have only fooled with the POP mode. The mailer that runs on the PC is OK, with a nice menu system for novices, but there are a few annoying bugs. Basically, Lifeline gives you adequate mail capabilities on your PC-NFS clients. -- Andrew Patrick, Ph.D. Communications Research Centre (613) 990-4675 Department of Communications, Ottawa, Canada UUCP, INTERNET: andrew@dgbt.crc.dnd.ca PATH: utzoo!bnr-vpa!bnr-rsc!dgbt!andrew BITNET: andrew@doccrc (if all else fails)
dsill@ark1.nswc.navy.mil (Dave Sill) (07/12/89)
In article <1121@dgbt.uucp> andrew@dgbt.uucp (Andrew Patrick ) writes: In article <3781@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: ... >About the only thing missing to make a >PC a full-fledged network machine is SMTP, but I think that may be an >option. It's not entirely clear what good an SMTP server does on a PC, but >it might be nice to be able to send mail, and maybe read it using some sort >of POP client. Sun sells a product called PC-NFS Lifeline that runs on top of PC-NFS and provides for mail service at the PC. Lifeline runs in either SMTP or POP mode -- I have only fooled with the POP mode. The mailer that runs on the PC is OK, with a nice menu system for novices, but there are a few annoying bugs. Basically, Lifeline gives you adequate mail capabilities on your PC-NFS clients. Have you asked Sun when those bugs will be fixed? We looked at Lifeline a while ago, but dropped it when Sun told us they had no future planned for it. -Dave Sill dsill@relay.nswc.navy.mil
andrew@dgbt.uucp (Andrew Patrick ) (07/25/89)
In article <8@ark1.nswc.navy.mil> dsill@ark1.nswc.navy.mil (Dave Sill) writes: >In article <1121@dgbt.uucp> I wrote: > Sun sells a product called PC-NFS Lifeline that runs on top of PC-NFS > and provides for mail service at the PC. Lifeline runs in either SMTP > or POP mode -- I have only fooled with the POP mode. The mailer that > runs on the PC is OK, with a nice menu system for novices, but there > are a few annoying bugs. Basically, Lifeline gives you adequate mail > capabilities on your PC-NFS clients. > >Have you asked Sun when those bugs will be fixed? We looked at >Lifeline a while ago, but dropped it when Sun told us they had no >future planned for it. The bugs in Lifeline are getting me down. We have it running on 6 PCs and it continues to crash the machines for no apparent reason. Further, about 50% of the time mail is not sent correctly and is placed in the "queue" for later delivery. Are there alternatives to Lifeline Mail that will run on top of PC-NFS (or something similar)? Something that uses the POP protocol would be nice. -- Andrew Patrick, Ph.D. Communications Research Centre (613) 990-4675 Department of Communications, Ottawa, Canada UUCP, INTERNET: andrew@dgbt.crc.dnd.ca PATH: utzoo!bnr-vpa!bnr-rsc!dgbt!andrew BITNET: andrew@doccrc (if all else fails)
nol2321@dsacg2.dsac.dla.mil (Jim Dunn) (06/04/91)
In regards to the various questions concerning PCNFS(tm) and the Clarkson
Packet Drivers, I have written the following document. Note that I am not
associated with either Sun Microsystems or Clarkson University, therefore
this document is provided as is, no warranty is expressed or implied.
You have several alternatives as to the configuration of your
pc when it comes to the Ethernet LAN. Some are:
a) PCNFS(tm) drivers only.
b) PCNFS(tm) drivers mixed with Clarkson Drivers. (after NFSRUN)
- - - - - -
c) PCNFS(tm) drivers mixed with Clarkson Drivers. (before NFSRUN)
d) Clarkson Drivers Only.
Note:
The "A" and "B" setups are seemingly identical, as are the "C" and
"D" setups. Notice the line drawn between the two sets of setups.
The "A" setup allows you to run all programs compiled with the
PCNFS(tm) Toolkit using the NFS TCP/IP packet protocol. Also, you
have "mounted drive" capabilities.
The "B" and "C" setup uses the Clarkson drivers to replace some of
the Sun drivers, allowing you to use the network before and after
you run the PRT.EXE or NFSRUN.EXE programs.
The "B" setup is an "emulated A" setup, allowing all of the same
functions as the "A" setup. (however, I have noticed that some
programs will lock up the pc if you forget to run PKTMODE)
The "C" setup is a "half way into the A" setup, allowing you to
run all the Clarkson Packet Driver Protocol programs such as KA9Q,
NCSA Telnet, CUT/CP-REV-D, etc. The downside is that in this half
way state, you cannot run PCNFS(tm) Toolkit programs or access the
PCNFS(tm) Mounted Drive.
The "D" setup is the simplest, using only the Clarkson Packet
drivers to allow the same access as the "C" setup.
Recommendation:
If you need PCNFS(tm) Mounted Drive or toolkit apps, use the "A"
setup, else, use the "D" setup.
Appendix of configuration files: (for a 3C503 card)
---"A" config.sys---
device=c:\nfs\pcnfs.sys /f20
device=c:\nfs\sockdrv.sys
device=c:\drivers\vecie6.sys /i5
device=c:\nfs\nfsvec.sys
lastdrive=v
---eof config.sys---
---"A" autoexec.bat---
set tz=EST5EDT
set path=c:\nfs
set NFSDRIVE=c
prt -T25 *
nfsrun
---eof autoexec.bat---
---"B" config.sys---
device=c:\nfs\pcnfs.sys /f20
device=c:\nfs\sockdrv.sys
device=c:\LAN\pktd.sys
lastdrive=v
---eof config.sys---
---"B" autoexec.bat---
set tz=EST5EDT
set path=c:\nfs
set NFSDRIVE=c
C:\LAN\3c503.com 0x7e 5 0x300
prt -T25 *
nfsrun
---eof autoexec.bat---
---"C" config.sys---
device=c:\nfs\pcnfs.sys /f20
device=c:\nfs\sockdrv.sys
device=c:\LAN\pktd.sys
lastdrive=v
---eof config.sys---
---"C" autoexec.bat---
set tz=EST5EDT
set path=c:\nfs
set NFSDRIVE=c
C:\LAN\3c503.com 0x7e 5 0x300
---eof autoexec.bat---
---"C" nfs.bat--- NOTE: nfs.bat is executed whenever
prt -T25 * you want to change your setup
nfsrun to "B". A reboot is required
---eof nfs.bat--- to get back to setup "C".
---"D" config.sys---
---eof config.sys---
---"D" autoexec.bat---
set tz=EST5EDT
C:\LAN\3c503.com 0x7e 5 0x300
---eof autoexec.bat---
Dumb Answer:
There may be some who will ask, "Why bother with setup B or C anyway?"
Well, you may wish to have multiple copies of your autoexec.bat and
config.sys that, when renamed, would allow you to reboot under a
different configuration "umbrella," thus you are more flexible...geoff@shark-bb.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (06/05/91)
A few comments on Jim's posting. (1) The product is actually PC-NFS(R), not PCNFS(tm). >sigh< (2) For PC-NFS 3.5 you should add the "/s" switch to the PCNFS.SYS line throughout. Sorry about that. (3) Jim asks (rhetorically) why anyone would want to bother with running PC-NFS over packet drivers. There are a couple of reasons he didn't mention. First, and obviously, the packet driver may be the only usable driver for your board. For example, we don't ship a driver for the NE1000, and the NDIS driver for this adapter is (as far as I can determine) badly broken. The packet driver works very nicely. The second reason is if you plan to switch between PC-NFS and some other software which uses the packet driver (e.g. SOSS): it certainly helps your configuration if you can use the same driver in each case. (If you have to switch i/o addresses, for example, you only have one configuration line syntax to worry about. In the case of the 3C503, the PC-NFS driver requires that shared memory be disabled, while the packet driver uses shared memory, so you have an extra incentive to use a common driver!) Finally, if you have the time and the inclination it may be worthwhile trying all of the driver options (native PC-NFS, packet driver, NDIS) to see which is smallest/fastest. You should not assume that our native driver is automatically going to be the best (particularly for those boards for which we use vector drivers from 3Com). Different drivers perform differently on different hardware: for example, if you have a system with a fast CPU but relatively slow DMA, using a driver that employs shared memory or programmed i/o will probably be a win. Since drivers rarely advertise the way they do i/o, you'll have to experiment. -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- ------------------------------------------------------------------------------ -- Sun Microsystems PC Distributed Systems ... -- -- ... soon to be a part of SunTech (stay tuned for details) --