libsmbclient: Browsing and a URI spec?

Welsh, Armand armand.welsh at sscims.com
Thu Jan 4 20:30:07 GMT 2001


-> -----Original Message-----
-> From: Kevin Colby [mailto:kevinc at grainsystems.com]
-> Sent: Thursday, January 04, 2001 12:08 PM
->
-> I think everyone may be approaching this backward.  For Samba, your
-> workgroup is your domain.  I know that has been said before, but the
-> issue here may not be that you need an additional way of specifying
-> an "authentication domain".  That functionality is handled 
-> by what has
-> previously been referred to as the "workgroup" parameter.
-> 
-> The issue here seems to me to be that the client may not 
-> want to _browse_
-> that workgroup/domain (the authenticated and/or joined 
-> "workgroup"), but
-> rather use a different default browsing workgroup.  Perhaps 
-> approaching
-> the matter that way makes more sense.  You could then have clients
-> default to browsing the smaller, trusting domain, but authenticate to
-> the master domain--the same one Samba (as a server) joined and is
-> mentioned in smb.conf.  This could be accomplished by using 
-> the existing
-> configuration and adding a "browse = <default workgroup 
-> clients browse>"
-> parameter, or something like that.
-> 
-> Does this make sense?

Yes. Perfectly.  I agree 100%.  That is what I am trying to say... but I
think I must have misread something, because I thought the threed got side
tracked to a samba issue, where someone was suggesting that samba be updated
to allow participation in multiple domains, because of a trust issue...  If
we are talking only about libsmbclient, as the subject suggests, then I
agree 100% with your comment.

I would definately be in favor of a variable to handle default browsing
workgroup.  BUT not within the smb.conf, because I think the libsmbclient
should remain seperate from the samba client/server program.  

The potential of a libsmbclient goes far beyond the functionality of samba's
current implementation, because it deals with interacting with user
interfaces; proving a high level of interaction in a potentially simple
interface.  Samba, on the other hand, is a service that deals with exporting
unix resources to the SMB world, and additionally, smbclient allows for the
samba system to interact at a very low level with other SMB systems, from a
client perspective.  Samba has no need for a browse workgroup, at it's
current design level.

libsmbclient is also far simpler than samba, because it doesn't have to deal
with domain registration.  libsmbclient, because of it's versatility, and
simplicity, should probably interact with domains in the same way that win9x
clients do.  By not joining domains, because it's overkill.  libsmbclient,
is just that, an smbclient, and as such, doesn't host shares, therefore does
not need to join any domains.  It only needs domains for authentication, to
access non-anonymous server resources.

So with that said, I don't think libsmbclient should be weighted down with
the burden of having to handle the special case of domain trusts.  When
accessing a Microsoft box, the previously discussed design will work.  When
accessing samba servers, it should be up to the samba server to handle the
authentication.  If the samba server is not mature enough to handle trusts,
then samba is what needs to be addressed, not libsmbclient.

Just as is the case with windows clients accessing the samba server.

Agreed?




More information about the samba-technical mailing list