From: Boris Z. (boris@conley.com)
Date: 06/30/98-12:47:55 PM Z
Message-ID: <01BDA414.8A5FB070.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: NFS Server, VERY MUCH why the protocol/STANDARDS limits the server flexiblity Date: Tue, 30 Jun 1998 10:47:55 -0700 On Monday, June 29, 1998 3:59 PM, Bryan Feir [SMTP:bryan@sgl.crestech.ca] wrote: > > When you do a domain login to a NT server the server returns a file > > name > > (login script) which is in $netlogon share. In my case it was > > login script = %u ie user name. > > The $netlogon share when mount case a programme to be excuted eg > > make-user-batchfile %u > > > > What I am saying is, that the login script is return and is part of > > the authenticaion protocol > > All right, I'll grant you that one. > > > We must assume the client is not running NIS/NIS+, (NIS is insecure). > > And right here is the main point of disagreement. > > > NIS/NIS+ does not run between companies, and joe smith on the > > internet. > > The server must do all the work and inform the client. > > > > Brent's java NFS client cannot talk to NIS. NFS needs to stand > > on it's own two feet like SMB/CIFS. > > Why? Why must NFS have all the extra baggage and mess of something > like SMB? True, NFS could use some extensions, as some of what is in > SMB is useful, but a lot of that can be done by a separate protocol. One simple reason: in heterogeneous environment there are many different 'separate protocols' and services addressing the same need. When I implement a File System Redirector I do not wish to know what 'separate protocol' is used on the server side. Defining our own protocol items in such places is a reasonable architectural isolation. > > > > We may define NFS authentication type for example, for each > > share we should be able to define the authentication types > > accepted, > > the server tells the client which types it accepts and preferances. > > NFS already _does_ define authentication types. AUTH_DES and AUTH_KERB > are listed in the NFS3 protocol document (RFC 1813), and the Generic > Security Services (GSS) spec exists as well (RFC 2203). This is something > that's set up at the RPC level, and shouldn't be part of NFS directly. > > > > And Hummingbird NFS allows for \\server\$home, which looks up the home > > > directory through passwd.byname. > > > > This needs to happen on the server not on the client, the client needs > > to > > be simple ( so lower total cost of ownership ). If it is formalised on > > the server, then what you can acheive will not dependant on the client > > implementation eg Sun PC-NFS most things and Hummingbird NFS lots more. > > Considering the current complexity of the clients in dealing with > cache coherency, trying to keep the clients simple isn't necessarily a > valid goal. I agree they shouldn't be forced to be more complex. > Does NT Nfs server use AUTH_DES and AUTH_KERB authentication when impersonates users on NT cluster? We should not think how simple or complex should be a client, but rather how independent should be client and server implementations. Clients should not know too much about what authentication mechanism is used on the server. The goal of this work is to create a protocol that accommodates diversity, needs of different OSs - otherwise we'll end up with SMB. > > Put the features in Hummingbird client you talk about on the NFS server > > so instead all clients have these features in the same way. > > > > For example dir nfs://server/ gives a list of shares > > eg home my home account ie nfs://server/home eq > > /export/home...../datkins > > landata ie nfs://server/landata eq /export/disk5/pcapps > > groups ie nfs://server/ eq virutal directory map > > or points to /export/groups where it contains symbolic > > links > > to all the group directories accross many drives. > > > > I belive that a NFS server should be just like and other programme > > on a unix server or what ever. Like using apache web server to look > > though a system. > > To which I ask: why can't much of this be done within the current > protocol? As I said before, there's nothing that forces the mount > daemon to always export the share using the same name it's using > internally. The mount daemon knows the UID of the requesting user > just as well as the NFS daemon does, it could return a different > mount point depending on who does the request to handle your /home/ > case. Just means you'd have to forbid access to the mount daemon > for AUTH_NONE requests, which is reasonable anyway. > > The most complex part I could see here is handling the case of > listing all the shares. You'd need a generic '/' path which returns > a faked filesystem containing the share names as directories. This > sounds suspiciously like a job for the public file handle from WebNFS. > (RFC 2054, 2055, 2224). > > True, there aren't many current implementations that allow such > things, but they're certainly not forbidden by the protocol. > > Bryan Feir
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:52 AM Z CST