Suggestion for change in the vfs_ops structure?

[Andrew Bartlett]

On Wed, 2002-11-13 at 17:28, Kris Van Hees wrote:
> On Wed, Nov 13, 2002 at 05:16:38PM +1100, Andrew Bartlett wrote:
> > Well, I think making the MSDFS resolving code pluggable would be a good
> > thing.
> 
> Agreed.
> 
> > > > MSDFS works by the server attempting saying 'not here' to a file open. 
> > > > The client then asks there server for 'where is is then', and the server
> > > > gives a new UNC path.
> > > 
> > > You are right that I may not understand how MSDFS works.  Would the redirect
> > > request need to be replied to with a deeper path within the share that the
> > > client was already accessing?  E.g. if the client tries to access the following
> > > path:
> > > 
> > > 	\\afs-server\dist\OS\bin- at sys
> > > 
> > > would a valid redirect value be
> > > 
> > > 	\\afs-server\dist\OS\bin-i386_win2k
> > > 
> > > as far as MSDFS is concerned?  More explicitly, must the redirect reply point
> > > to a share or can it be to a specific file or directory within a share (even
> > > the same share as where the original request was sent for)?
> > 
> > I really should check with the people who actually wrote this, but I
> > think that is valid - as long as the @sys represents a folder.
> 
> That is a possible show-stopper since @sys can be used both in directory names
> and in actual file names.
> 
> > > > It is not 'resolved' on each access, and as such subsequent accesses do
> > > > not take any performance penalty.
> > > 
> > > The main question becomes in this case whether in MSDFS the Windows client is
> > > going to cache the result from the redirection or not.  E.g. if I first try to
> > > access \\afs-server\dist\OS\bin- at sys, and then a few minutes later I decide to
> > > go back to that location, will MS Windows automatically contact the redirected
> > > version or will it once again try to resolve it in the parent share, and have
> > > the Samba server send a 'not here' response and then query for the actual
> > > (redirected) location?
> > 
> > My understanding is that such redirects are cached.
> 
> A possible show-stopper for using MSDFS directly, as I mention below...
> 
> > > Its semantics could be described as a dynamic symbolic link, yes.  Its target
> > > is dependent on the client machine's architecture.  The reason why the Samba
> > > server has to deal with this is that a Samba server running on an AFS client
> > > machine would otherwise pass the pathname down to the underlying filesystem
> > > (AFS) where the @sys token would be translated using the architecture sysname
> > > for the Samba server machine, and not for the Windows client machine.
> > 
> > As long as it is presented to Samba as a broken symbolic link, I think
> > this would not be too hard to implement.
> 
> Well, that is not the case, since for the underlying filesystem it is usually a
> very valid name.  The fact is just that they would resolve to different targets.
> The Samba server (let's assume it is a Solaris box) would natively resolve it
> to something that includes its sysname (sun4x_58 for example) whereas for the
> Windows client it would need to resolve to something like i386_win2k.  And in
> most cases, both would exist as targets, so it would not appear as a broken
> symbolic link.

Well, it really depends on what you are trying to do - provide AFS to
clients over samba, or provide a service to clients over Samba.  If you
really want full AFS semantics, why not use the native AFS client?

If you want to provide a service, with @sys as an extra feature, then I
think that MSDFS provides a way to do this.

If you really want AFS semantics and are willing to put in the legwork,
then I would suggest you write a VFS module that actually implements AFS
directly, ie not via the kernel.

AFS ACLs and the like are so different to Unix that bypassing that layer
really does start to make sense, and you don't need nearly as many hacks
to get the right individual semantics.

However, you can do your translation stuff with just a standard VFS
module - the main challenge would be memory management.  In the way that
the audit module just passes along parameters, your module could pass on
modified (and separately allocated) parameters to the default functions.

Or take a different approach:  Tell the kernel what your arch is.  Why
can't the kernel do the correct translation for you?

> > > The finer detail is that if at any point the sysname for the client architecture
> > > would change (which is another thing I am working on since it is needed), the
> > > target of any further pathnames that contain a @sys token must resolve using the
> > > new sysname value.  That is why I ask about possible MSDFS redirection caching
> > > above, since that could violate these real time sysname change semantics.
> > 
> > I'm not quite sure what you mean here - the client's arch value isn't
> > going to change for the life of an SMB session nor the life of the
> > client installation for that matter :-)
> 
> Well, although specific sysname values are assigned for specific architectures
> (CPU - OS specific), some AFS environments tend to assign arbitrary sysnames
> to allow for a finer grained differentiation of systems.  E.g. using different
> sysnames for NT 4 SP 2 and NT 4 SP 3.  It is not uncommon to initially use the
> default sysname to get your system started using networked resources, and to
> then set the actual sysname you want for overall operation of the client
> system.
> 
> It is a bit of a pain, and fortunately not often used, but the semantics in AFS
> allow for it, so I have to support it :(

Well, I think you will have trouble getting that information to Samba -
that's my point.  Samba can only really tell the difference between
major client versions.  You could use the name in the session setup, but
I'm not sure that changes between service packs.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20021113/f5c9409f/attachment.bin