Return to BSD News archive
Xref: sserve comp.os.linux.development:22276 comp.os.386bsd.development:3008
Path: sserve!newshost.anu.edu.au!munnari.oz.au!yarrina.connect.com.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!uqcspe.cs.uq.oz.au!cs.uq.oz.au!erikp
From: erikp@cs.uq.oz.au (Erik Proper)
Newsgroups: comp.os.linux.development,comp.os.386bsd.development
Subject: SAMBA and NETWARE mounting
Date: 8 Jan 1995 07:00:49 GMT
Organization: Computer Science Dept, University of Queensland
Lines: 99
Message-ID: <3eo2j1$l5o@uqcspe.cs.uq.oz.au>
Reply-To: erikp@cs.uq.oz.au
NNTP-Posting-Host: lacewing.cs.uq.oz.au
Hi All,
this is an idea on how it could be made possible to have an easy way to mount lanmanager (samba) filesystems or netware filesystems. It is an idea which was initially mentioned to me by Paul Jones from the University of Nijmegen. At least ... this is based on what I think he meant. Neither of us have the time to implement something like this.
The idea is not to implement yet another fs (samba-fs or netware-fs), but to use nfsd as a babylonic fish (as in the Hitch Hiker's Guide to the Gallaxy .... internet ;-) ). I'm not sure to what extend the mountd is involved as well. One considerable advantage of using nfsd as a babylonic fish is that (to my knowledge) nfsd is similar accross different OSs, so the solution would work for different OSs (Linux, BSD386, ...) as well.
Down to business .....
Let us first focus on the administrative side of the babylonic fish ...
In the exports file we allow for a new class of entries (within the 'old' syntax).
An example:
# A normal entry:
/home beer(rw)
/usr beer(rw), liquor(ro)
# Samba file systems:
/samba/dos localhost(rw), pc-1(rw), beer(rw)
/samba/work localhost(rw), liquor(ro)
# Netware file systems:
/netware/vol-1 localhost(rw), liquor(ro)
/netware/vol-2 localhost(rw)
If mountd only uses this info to decide whether a given exported fs is mountable by a remote host (or localhost!!), then mountd probably does not need to be modified.
For nfsd a new config file is needed. Upon mounting a lanman filesystem or a netware file system, a password needs to be supplied. These passwords could be stored in a centralised file that is only
readable by the root. However, certainly lanman fs-s are usually pc
based, and the passwords may change frequently. Therefore it is a good
idea to have these passwords distributed over users owned files that
are maintained by a user (usually the owner of the PC sharing the
lanman fs to the net).
Therefore I propose the following architecture of files:
The file babylon.exports (for lanman and netware) contains the
following entries (for the example export file):
# Service on Unix, Lanman/netware service name, Password file
/samba/dos \\ERIKP-PC\DOS-SHARE \home\erikp\.passwd
/samba/work \\PAULJ-PC\WORK \home\erikp\.passwd
/netware/vol-1 \\BIG\VOL-1 \etc\nw.pass
/netware/vol-2 \\BIG\VOL-2 \etc\nw.pass
The password files have the format:
# Lanman/netware service name, Password
\\ERIKP-PC\DOS-SHARE GEHEIMPJE
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.
In brief:
remote-host/local-host <---> nfsd on local host <---> lanman server
Note that if the machine running the nfsd wants to mount a lanman
or netware fs it has to mount it through it's own nfsd....
Caching of the password ... It is probably wise to keep a short list
of passwords and lanman/netware services in memory to prevent to
frequent lookup accesses (is that really needed?) When playing around with wfw I've noticed that if a user changes a password on a shared fs, the machines that have mounted the fs loose that fs (with some delay). If the nfsd is confronted with a lost connextion to a lanman server due to a password change, it should simply lookup the proper service name and password again. (The user may have updated her/his password file in the mean time).
The key issue is of course efficiency. To get one unit of information
from a lanman/netware server to a host mounting such a file system, this unit of information needs to be transported over the net two times. Once in nfs format and once in the lanman/netware format. From
this stance it is much more efficient to implement lanman/netware
fs-s directly into the kernels of Linux and BSD386. However, from an
implementation point of view, the babylonic fish idea might just be
easier to implement. And ....
1) isn't a lanman server itself the slow factor?
2) if fast access is needed on a unix host X, then X should run
a babylonic nfsd itself! This means the nfs part is travelling
through the loopback device only.
Okay, question now is:
1) is this a good idea
2) who's got the time and desire to implement this?
CHeers,
Erik