Return to BSD News archive
Xref: sserve comp.os.linux.development:22332 comp.os.386bsd.development:3011
Newsgroups: comp.os.linux.development,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!cs.utexas.edu!news.cs.utah.edu!news.provo.novell.com!park.uvsc.edu!news
From: Terry Lambert <terry@cs.weber.edu>
Subject: Re: SAMBA and NETWARE mounting
Organization: Utah Valley State College, Orem, Utah
Date: Tue, 10 Jan 1995 03:47:07 GMT
Message-ID: <D267uw.Grq@park.uvsc.edu>
X-Nntp-Posting-Host: hecate.artisoft.com
References: <3eo2j1$l5o@uqcspe.cs.uq.oz.au>
Sender: news@park.uvsc.edu (System Account)
Lines: 93
GHAH! USE CARRIAGE RETURNS AFTER *) CHARACTERS!!!!
erikp@cs.uq.oz.au (Erik Proper) wrote:
[ ... ]
] The workings ...
] When nfsd receives a mount request (or access request) (I'm not really familiar with the proper terminology, so please bear with me),
] it decides what 'language' it is in. If it starts with /samba/ it
] is a reference to a lanman service, if it starts with /netware/ it is
] a reference to a netware service, and otherwise it is a 'normal'
] access.
] If it is a normal access, then things should be done as usual. If
] it is an access to a lanman or netware fs things get more interesting.
] The nfsd must lookup the proper lanman/netware service in the
] babylon.exports file, and the required password in the password
] file. The nfsd should now translate the access from the remote host
] (or local host!!) to what it thinks to be an nfs volume to the
] lanman protocol or netware protocol and talk to the proper server.
] The result of this has to be translated back to nfs terminology and
] send back to the remote host.
What you probably wanted to say was that it is a local loopback NFS
mount on a different port number. Like AMD does already. You could
even modify the AMD code.
This is absolutely grim, and simply substitutes the location of the
code. It is much cleaner to put the code in the VFS layer instead
of cramming it through the VFS layer via NFS. Since the NFS and VFS
interfaces are for all intents identical, this really buys you little
beyond changing the way you link things.
The problem is that you've simply moved the actual work to another
location, and not really done any of it. There is still the problem
of turning this thing into an acceptable LANMAN or Netware client.
At last exposure to the NUC code (NetWare UNIX Client), which does
exactly what you want for NetWare, it was over 100,000 source lines,
if you include the IPX and other transport crap.
The last time I saw the NetWare for UNIX server, it was in the
neighborhood of 1.3x10^9 lines of code.
Oh yeah, I hacked on both of them for a little company called Novell.
The LanMan client part for Samba is a lot easier, although it doesn't
deal with the dealock issues (most of the code in NUC, now, is likely
related to dealing with concurrency and preemption -- you'd have to
ask the guy doing the work on it (hi Steve!)).
Can't have your machine hanging in it's request-response protocol
it's using to import the remote FS simply because the remote server
goes down.
There is a (mostly) working LANMAN FS for Linux already out there.
> Okay, question now is:
> 1) is this a good idea
> 2) who's got the time and desire to implement this?
It's a good idea, but implementation time is probably better spent
doing something else and licensing the code for $100,000 from Novell
(I suspect that it would take you longer than 1000 man-hours to
implement the code, since it took Novell at least that long, and
they have sourcecode for NetWare and NCP documentation that you
can't possibly (legally) have, and that assumes that you can get by
on $100/hour *minus* expenses.
The *only* possible alternative might be to license the remote boot
developement kit for OS/2 (the DOS one doesn't have to know how to
change a directory, but the OS/2 one does), and work it from there.
Getting the bootprom kit is cheap (or free), but tyou may have to
prove you are a card manufacturer...
That would get you hooked to a server, but it wouldn't let you
login (but you could download things from the login directory and
CD in unprotected subdirectories that don't require an authenticated
login, like the OS2 subdirectory).
To actually get a NetWare 4.0 login, you'd have to do what Microsoft
did, and hire 10 mathematicians for 6 months to deal with the RSA
key stuff -- and then you could start to code it.
Sorry to pee in the cheerios. 8-(.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.