Urban Widmark wrote:
>
> On Sat, 14 Jul 2001, Christopher R. Hertel wrote:
>
> > Does anyone know of an SMB server that does not support the *SMBSERVER
> > name but can run on a non-137 port? If such exists, then we might need
> > to extend the syntax to support it. If no such exist, then we do *not*
> > need to extend the syntax.
>
> Does the standard(s) allow making one?

The *SMBSERVER name is completely non-standard, but then so is accessing SMB
servers without a valid NetBIOS name. The RFCs specify the need for a
Called Name specifically to identify NetBIOS services.

So, what I'm suggesting, is that requiring the *SMBSERVER name is not
something the SMB URL spec should do. That doc describes the SMB URL and
its use, but should not be defining requirements for the SMB over NBT
protocol suite.

> My example isn't really about the server running on a non-standard port,
> it's about using ssh portforwarding in a way that makes it look like it
> runs on a non-standard port.
>
> Today I can do this:
> mount -t smbfs -o port=1234,ip=127.0.0.1 //cola/tmp /mnt/smb
> if I have a ssh tunnel from localhost:1234 going to some remote server
> named 'cola' (listening on port 139). cola has no meaning on the local
> network.

So the remote node (at 127.0.0.1??) is running SMB services on the normal
port, but you are redirecting the connection using SSH, and SSH is
redirecting via port 1234. Do I understand that correctly?

Two things. First, if the "remote" server is running NT4, W2K, or Samba
it will support the *SMBSERVER name, thus avoiding the problem.

Second, surely this is not something to be handled in the SMB URL. The
tunnel and redirection are external to the SMB protocol itself.

> The URL syntax could allow
> 1. mount -t smbfs -o port=1234,ip=127.0.0.1 smb://cola/tmp /mnt/smb
> 2. mount -t smbfs -o ip=127.0.0.1 smb://cola:1234/tmp /mnt/smb

Agreed.

> 3. mount -t smbfs smb://cola!127.0.0.1:1234/tmp /mnt/smb

This is what we are debating. I am not convinced that this should be
added to the URL syntax, but I'm not convinced otherwise either.

> 1 - no change from today
> 2 - use the normal URL way to specify port number
> 3 - extend it to include machine name

It's actually a service name with the suffix missing, not a machine name.
In your example, it may not match the machine name at all. If your
machine name is COLA, you might run this service under the name URBAN to
separate it from other services offered by the machine.

> If using URLs makes (1) still be the syntax used, that's not really a big
> problem. (2) is an improvement, and is what a user might expect from an
> URL.

Okay.

> I like (3) as it puts the netbios name and IP# (which I think belong
> together) in the same place. But if that is non-netbios like and mostly
> not useful to anyone, don't bother with it.

Well, I'd like to hear more input. The utility of this extension would be
that it would provide a way to manually reverse-map an IP address (or DNS
name) to a NetBIOS name so that the kludgy methods outlined in the
appendices need not be used. The things to keep in mind are:

- Using IP addresses (or DNS names) to access SMB over NBT services is an
  ugly kludgehackthing in the first place.

- This extension is only needed when the NetBIOS name spaces are disjoint
  (if you know the NetBIOS name, you should be able to use that unless
  the namespaces are disjoint, as in Urban's example).

- While it is ugly (really it is) I understand the utility of doing what
  Urban is proposing.

Hey! What about using the '?' delimitor (which I also disallow in the
current doc).

Hmmm... Maybe not. I can also imagine ways to use the '?' delimitor.

Imagine: smb://your.host.dot.com/sharename/command.exe?backorifice

Hmmm... On which machine would that run? I'd say the local machine, but
I suppose that's why I left the '?' operator undefined.

Comments, people?

More below...

> > > Can you have the same servername in different workgroups?
> > > workgroupA/serverX
> > > workgroupB/serverX
> >
> > Yes, that can happen. Quite easily.
> >
> > > The old "smb://" thread on samba-technical suggests you can't or
> > > shouldn't.
>
> [snip]
>
> > > If you could, you'd want to remember which of the serverX's you
> > > browsed to.
> >
> > Yes, but that's an application feature.
>
> But shouldn't the URL syntax be able to describe that?

It can't. Now that I look at it again, there is a basic underlying problem.

The two workgroups can contain servers with the same name *if* the server
names do not conflict. That is, once again, they are in disjoint name
spaces.

If we are talking about NetBIOS names, then both servers--regardless of
workgroup membership--would register the names SERVERX#20. If they are on
the same subnet or share the same NBNS then (assuming they are both M or H
nodes) they would have conflicting names. #20 names are unique names.

So, yes the above can happen, but only if the two do not wind up with a name
conflict.

If you are using IP addresses or the FQDN, then they must be unique across
the Internet.

I thought you were talking about maintaining workgroup context. Sorry.

> If smb://serverX/foo is not unique. Where do I end up if I select that
> "bookmark" in my pointy-clicky file browser? My machine belongs to
> workgroupC, which has no serverX.

I did not design the browsing system, so don't blame me. ;)

...but... smb://serverX must be unique within a NetBIOS namespace. The
only exception, as I've described elsewhere, is the case in which there is a
server named serverX and a workgroup also named serverX. This typically
means that the network is misconfigured, but it can happen so I provide some
ideas for a work-around in the draft doc.

Note that smb://serverX/foo *cannot* be a workgroup reference since the
share name (foo) is specified, thus no conflict at all.

> Or if I by default get serverX from workgroupA, how do I describe that
> the server I want to reach is serverX from workgroupB? I want to take
> that URL and store it in my bookmarks, copy it, send it in internal
> emails telling people where to get the latest copy of some document, ...

Thus the argument in favor of using IP addresses (DNS names) to identify
services.

You can pass around URLs using NetBIOS names if they are within the same
namespace. They fail instantly outside that NetBIOS scope, as you suggest.
This is why the IP address/DNS name kludge was created--and one reason that
Microsoft moved away from using NetBIOS at all.

Note that, while servers are members of workgoups (or NT Domains), the
heirarchy is just an organizational convention. A client from workgroupB
can connect to a server from WorkgroupA just by specifying the server
name. Access rights, and such, come into play but naming wise the namespace
is open and flat.

> In my world a URL should have one distinct meaning, independent of
> application. I don't need this at all, but it seemed like a flaw in the
> format. Perhaps it's because I don't understand all the clever netbios
> parts ...

Well, I personally do think that RFC1001/1002 were clever docs. They
specify a virtual LAN system with its own address space. The limits of that
address space (what I have been calling namespace but which is, more
properly, called scope) is very limited. (Note that scope exists even
without a Scope ID string. Scope means "the set of machines across which a
given NetBIOS name has a given meaning".)

The goal was to create a virtual "NetBIOS LAN" on top of IP so that legacy
applications could continue to run. These applications used the NetBIOS API
on DOS and Windows boxes. See http://www.ubiqx.org/cifs/NetBIOS.html

Point is, a NetBIOS name is only valid within the set of machines that share
a given scope. For M and H nodes, the scope is the union of the broadcast
domain and the NBNS (WINS) server database. For P nodes it's just the NBNS
and for B nodes its just broadcast space.

Think of it this way: At my office the URL string "http://duplo" might
bring up one web page, but over in the Chemistry department it might
bring up a very different web page. In this case, it's because the name
'ruby' is not fully qualified. These are DNS names, and my local resolver
is making some assumptions.

NetBIOS names are non-heirarchical, so in an IP world they are never fully
qualified.

Does that make sense?

Chris -)-----

--
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crhubiqx.mn.org
----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]