barryf@aix01.aix.rpi.edu (Barry B. Floyd) (05/01/91)
I have seen SOSS mentioned with respect to NFS. What does SOSS stand for (save our sorry ship?)? What does it do, if anything? Why is it related to NFS? If it is software or a standard of some sort, is there and FTP site with it or descriptions thereof (e.g. RFC xxxx) available? thanks in advance barry -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+
stan@cs.uiuc.edu (Seemong Tan) (05/02/91)
In article <n41g=ta@rpi.edu>, barryf@aix01.aix.rpi.edu (Barry B. Floyd) writes: |> I have seen SOSS mentioned with respect to NFS. What does SOSS stand for |> (save our sorry ship?)? What does it do, if anything? Why is it related |> to NFS? First, there was SOS, Stan's Own Server, which I wrote while at Lawrence Berkeley Laboratory. It is a NFS server for the IBM PC, so you can export the DOS box's drives as NFS filesystems. Geoff Arnold at Sun gave me lots of help on it. Now, Rich Braun of Kronos has written SOSS, Son of Stan's Server, which greatly improves reliability and speed over the original SOS. It also includes support for Novell products. Rich Braun is really quite a studly programmer for having taken SOS and made it into SOSS! |> If it is software or a standard of some sort, is there and FTP site with |> it or descriptions thereof (e.g. RFC xxxx) available? It's available via anonymous ftp from spdcc.com. And some other sites, but I can't recall where. |> | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | |> | Manager Information Systems - HR \\\ usere9w9@rpitsmts | |> +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+ stan
rbraun@spdcc.COM (Rich Braun) (05/03/91)
stan@cs.uiuc.edu (Seemong Tan) writes: >It's available via anonymous ftp from spdcc.com. And some other sites, >but I can't recall where. I now have the following distribution sites. I'm still curious as to how one gets it to people without direct ftp access; I believe Clarkson runs a mail archive server, but I've also gotten requests for it from Bitnet sites. If someone with lots of Internet software distribution experience can help me make this more widely available (and be able to respond to inquiries from far corners of the net), I'd like to correspond. Here's the anonymous-ftp list: System Directory Contact ------------ --------- ------- spdcc.com pub/sos rbraun (MA) sun.soe.clarkson.edu pub/ka9q nelson (NY) iuvax.cs.indiana.edu!sir-alan /u/pubdir/SOS mikes (IN) cs.ep.utexas.edu pub/sos pwesley (TX) garbo.uwasa.fi pc/comm hv (Finland) kirk.bu.oz.au pub/PC/soss bambi (Australia) nestroy.wu-wien.ac.at pub/src/PCtcp/soss mah (Austria) One person has agreed to make it available via mail-order diskette for about US$4. And I do run a walk-up service for companies like Interleaf. :-) With regard to my ~3-month estimate of creating a client-NFS version, that only applies to someone who has already written a TSR to intercept DOS file I/O operations, and knows basically how to hook something like SOSS into something already familiar. It would probably be much harder for the typical summer-grad, though you never know; summer grads are often very fast learners. And recalling my own college days, they can be highly motivated by the prospect of seeing their software in use daily by thousands of grateful people. -rich
nelson@sun.soe.clarkson.edu (Russ Nelson) (05/03/91)
In article <7461@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes:
I now have the following distribution sites. I'm still curious as to how
one gets it to people without direct ftp access; I believe Clarkson runs
a mail archive server, but I've also gotten requests for it from Bitnet
sites.
Send mail to archive-server@sun.soe.clarkson.edu with a body
containing the single word "help". That works for everybody, BITNET,
UUCP, whatever. We get requests from all sorts of strange sites, like
.su, .za, .hu, .tw, .my, .yu, and the usual gang: .be, .dk, .se, .no,
.de, .at, .au, and .nz. Not to mention .us and .ca, of course. :-)
Also, you can phone in to grape.ecs.clarkson.edu at (315)268-6667,
and download pub/msdos/tcpip/soss.zoo.
Or send me $10 and I'll slap it on a floppy for you. Be sure to say
what disk density you want.
Russell Nelson
11 Grant St.
Potsdam, NY 13676
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.nol2321@dsacg2.dsac.dla.mil (Jim Dunn) (05/03/91)
In article <n41g=ta@rpi.edu>, barryf@aix01.aix.rpi.edu (Barry B. Floyd) writes: > I have seen SOSS mentioned with respect to NFS. What does SOSS stand for > (save our sorry ship?)? What does it do, if anything? Why is it related > to NFS? > If it is software or a standard of some sort, is there and FTP site with > it or descriptions thereof (e.g. RFC xxxx) available? > > barry SOSS(1) NAME soss Son of Stan's Server SYNOPSIS soss [-rtv] DESCRIPTION SOSS is a file server conforming to SUN Microsystems' NFS protocol version 2. It will run on IBM-PC compatibles under Microsoft MS-DOS, using any Ethernet interface supported by Clarkson University's packet drivers. Performance and reliability have been significantly enhanced over the original SOS released in 1989. The file "export.us" must exist in the default directory on the server. The format is similar to Sun NFS's "/etc/exports" as defined in exports(5), except that directories on the server side are specified in MS-DOS format, ie. "<drive>:<path name>." SOSS will parse this file to learn which filesystems on the local machine it will accept mount requests for. Up to 50 individual clients may be specified for any exported directory. SOSS requires the system clock to be set correctly. The MS-DOS timezone environment variable should be set the way it is under Unix. (E.g., for Eastern Time, use SET TZ=EST5EDT or SET TZ=EDT4; daylight savings time isn't handled correctly by the Microsoft C library linked with this version.) Note that MS-DOS does not understand dates prior to January 1, 1980. If you have a Network Time Server established on your network, you should run PC/IP SETCLOCK prior to running SOSS. Before running SOSS, configure your Ethernet interface card and the packet driver software. Using CUSTOM, set correct parameters (IP address, name and time server addresses) in NETDEV.SYS, then add the line "DEVICE=NETDEV.SYS" to CONFIG.SYS, and reboot your system. Run the appropriate packet driver, specifying software interrupt vector 0x7e; here is an example: ni5210 -n 0x7e 5 0x300 0xd000 You can then run NetWare, if desired, and then invoke SOSS. There should be a capacity for at least fifteen files to be opened at a time. SOSS caches file handles for faster access during reads. File names in filesystems mounted with SOSS are limited to eight characters, with a three character extension. Attempts to create a file with a name not matching the above restrictions will result in an error message, NFSERR_NAMETOOLONG, unless the truncation option is specified. All file names are mapped to lowercase. The owner ID of any directory or file in a SOSS filesystem will appear to be that of the user accessing it. Files have three possible modes: regular files, which are global read, write and executable, read only, which are global read and executable, and subdirectories, which are global read, write and executable. Chmod(1) may not work as expected with SOSS files, and chown(1) will not work at all. An SOSS filesystem may be mounted by mount(1). On the client system's mount command line, a filesystem is specifed by the sequence "/drive/directory." On the server side, a root directory may be exported by using the form "c:\"; a subdirectory may be exported using the form "c:\foo". The rsize and wsize parameters must be specified less than or equal to 512 bytes. An example of a typical mount command issued on a client system: # mount -f NFS,intr,rsize=512,wsize=512 dosbox:/c /usr/sos If you modify the EXPORT.US file, you should remove the INODE.DMP file before restarting the server, and unmount/remount any exported filesystems on each client. In general, if you remove INODE.DMP, you should remount the filesystems from the client side, in order to get rid of any stale file handles. One product you may wish to use in conjunction with SOSS, if you are using it to export a hard drive physically connected to the SOSS server PC, is a disk cache which keeps data blocks in extended memory. This functionality was not added to SOS itself due to the low cost of high-quality commercial products like PCKWIK. PREREQUISITES The basic hardware and software requirements for SOSS are as follows: 1. The Clarkson University packet drivers, configured for your Ethernet board. (These are available via anonymous ftp on sun.soe.clarkson.edu plus other sites which carry SOSS.) 2. A 286- or 386-based PC. (It may work with an XT.) 3. A single Ethernet card which is supported by Clarkson; this includes most popular products. 4. Another system with NFS client support (DOS, Unix, VAX/VMS, VxWorks, or whatever) and TCP/IP. 5. Some free disk space (usually well under 0.5 megabytes) on the default disk drive, for maintaining the inode list. OPTIONS -r The -r option causes all exported filesystems to be read only. -t To suppress filename-too-long errors when a client system specifies a filename longer than the eight-point-three characters allowable under DOS, use the -t (silently truncate) option. -v The -v option causes SOSS to announce successful completion of each NFS request (verbose mode). SOSS normally announces only errors and mount requests. FILES These files should exist in the default directory from which the server was started: export.us list of exported filesystems and clients. If you specify a client list, be sure you are running a domain name server and that its IP address has been provided in NETDEV.SYS. inode.dmp index node information for crash recovery. novell.id UID mapping for Novell filesystems (not supported). netdev.sys device configuration file for PC/IP, set up for your system using custom.exe. (A device entry for this file must be placed in config.sys.) BUGS AND LIMITATIONS - Portmapper and mount daemons are incomplete. See below. - The portmapper operates on datagrams. TCP requests are not supported. - There is no support for large packets (> 512 bytes). - The server crashes as soon as about 7,500 inodes are created. - NFS_RENAME cannot rename directories, and cannot move files from one directory to another. - Inodes are not recycled as files are deleted. - A filename beginning with dot is unsupported, and the 'rm' command under AIX creates such files. - The server requires a dedicated PC and does not use extended memory. DEBUGGING A set of debugging macros is available to help you in debugging run-time problems or to provide useful diagnostics when modifying SOSS source code. This feature uses two environment variables: NFSDEBUG and DEBUGFILE. By default, debugging is disabled; you can selectively enable trace messages by setting NFSDEBUG to a list of flags as follows: *rpctrace - RPC-level messages mountd - mount requests nfserr - error conditions for certain requests nfsdebug - miscellaneous debugging information nfsdisp - main NFS dispatcher (like SOSS -v) nfslookup - file lookups nfsread - file reads nfswrite - file writes *nfstime - timing information *inode - inode information Asterisked items are not used in the released version. Debugging output goes to the console display unless DEBUGFILE is set to a file or device name. If you want all trace messages, set NFSDEBUG=all; if you want all but a few, you can use negated flags, as in "set NFSDEBUG=all;-nfsread;-nfswrite". REQUESTS "Port Mapper Requests" Only one call is supported: PMAPPROC_GETPORT. The port mapper knows of only the NFS and mount daemon ports. In version two of the NFS protocol, NFS port is bound to 2049. This is a bug in the NFS protocol which Sun Microsystem claims it will fix in the near future. "Mount Daemon Requests" Three calls are supported: MOUNTPROC_MOUNT, MOUNTPROC_UMOUNT, and MOUNTPROC_EXPORT. These reply to mount and unmount requests for specified filesystems. The MOUNTPROC_EXPORT function provides a list of exported file systems (in Unix-style syntax), but does not include the list of authorized clients for each. "NFS Server Requests" SOSS supports the whole range of valid requests for version two of the NFS protocol, except NFSPROC_READLINK, NFSPROC_LINK and NFSPROC_SYMLINK. MS-DOS does not support links. This is a list of requests: Procedure 0: NFSPROC_NULL /* for server response and timing */ Procedure 1: NFSPROC_GETATTR /* get file attributes */ Procedure 2: NFSPROC_SETATTR /* set file attributes */ Procedure 3: NFSPROC_ROOT /* obsolete em not supported */ Procedure 4: NFSPROC_LOOKUP /* lookup file in directory */ Procedure 5: NFSPROC_READLINK /* not supported */ Procedure 6: NFSPROC_READ /* read from file */ Procedure 7: NFSPROC_WRITECACHE /* obsolete em not supported */ Procedure 8: NFSPROC_WRITE /* write to file */ Procedure 9: NFSPROC_CREATE /* create file */ Procedure 10: NFSPROC_REMOVE /* remove file */ Procedure 11: NFSPROC_RENAME /* rename a file */ Procedure 12: NFSPROC_LINK /* not supported */ Procedure 13: NFSPROC_SYMLINK /* not supported */ Procedure 14: NFSPROC_MKDIR /* make directory */ Procedure 15: NFSPROC_RMDIR /* remove directory */ Procedure 16: NFSPROC_READDIR /* read directory */ Procedure 17: NFSPROC_STATFS /* status of filesystem */ COMMENTS Comments and bugs should be addressed to: rbraun@spdcc.com, stan@cs.uiuc.edu, or stan@lbl-csam.arpa AUTHORS See-Mong Tan, Harvard Holmes, Craig Eades, Rich Braun SEE ALSO d2x(1), x2d(1), nfs(4p), nfsd(8), mount(1), mount(8), umount(1), exports(5) "A Low-Cost Unix/DOS Network Solution for Software Engineering", Richard Braun (rbraun@spdcc.com), Kronos, Inc., April 1991. "Network File System Protocol Specification", RFC-1094, Bill Nowicki (nowicki@sun.com), Sun Microsystems Inc., March 1989. "Networking on the Sun Workstation", Sun Part No. 800-1324-03. "Packet Drivers Made Simple", Joe R. Doupnik (jrd@cc.usu.edu), Utah State University, January 1990. "PC/IP User's Guide", Jerome H. Saltzer and John L. Romkey, Massachusetts Institute of Technology Laboratory for Computer Science, March 1986. "User Documentation for the Packet Driver Collection", Russ Nelson, Clarkson University (nelson@clutx.clarkson.edu).