Pathworks and Samba together

[Derek Garson]

Lots of good ideas, folks.

Generally fairly emetic (-: though considering how simple it would be if I could confine each product to one LAN.

> Please log a case if you want an official answer.

I didn't log a case but I did give feedback from the evaluation kit download. Maybe it will do some good.

>cheap-and-nasty NAT/PAT-capable IP router

I don't happen to have one lying around spare (not ethernet to ethernet anyway).

However for the record I have in the past successfully used SSH port forwarding to use Microsoft file sharing securely over the internet (forwarding *only* port 139). Possibly I could use a different destination port to fudge the port number.

Before moving on to the next para I should clarify that *all* desktops run Windows XP.

My untested thoughts on port 445 ... disable 445 usage in all clients (there is a reghack for this) but conversely disable NetBIOS over TCP on the test client.

NB: Because Pathworks seemingly does not support port 445 at all, disabling port 445 usage on clients won't violate too severely my requirement not to stuff up the existing production environment.

Then disable all the old NetBIOS over TCP support in Samba i.e. no 137, no 138, no 139.

Theoretically this should allow the two products to run in parallel on the *same* LAN.

Downside: Existing clients access shares on at least one other machine (a Windows 2000 Server box). Would have to verify no adverse consequences in forcing clients to use NetBIOS over TCP.

> In order for the server to be useful by most clients

For the record, it seems as if there is a reghack to get a client to use something instead of 137 and reghacks to get a client to use something instead of 445 (both datagram and session) but nothing that I could find for 138 and 139.

137 doesn't really need to be working anyway. Can use IP address or perhaps rely on DNS lookup.

>you will require port
redirection services on port 139, details of which are outlined in rfc1002.txt section 4.3.5

Cute. But how do you do this? Does Pathworks support it? Would be nice if I could add a (test) share that just redirects from Pathworks to Samba.

[Derek Garson]

> For what more could one ask?

Map Network Drive \\hostname:port\share

(-:

>Is it possible for you to limit Pathworks to DECnet? This will require installing the PW32 client on the PCs needing to access Pathworks shares.

Good idea but unfortunately this exceeds my threshhold for amount of disruption to existing environment.

> Most Windows systems will try TCP port 445 first.

My reading on the net was that Windows systems that use both port 445 and port 139, try port 445 in parallel with port 139 (and drop the connection on port 139 if both connect). But I didn't attempt to verify that experimentally.

Fortunately no domain logons in use here.

>Both Samba and A/S are hungry of resources (memory and CPU). Running both on the same CPU may be very heavy.

Good point. It was only my intention to run one or two test clients connecting to Samba so I may be OK (and I have plenty of free memory).

Regarding performance generally, I would happily give up 10% in file sharing throughput to get 100% reliability.

But then I myself would not be bearing the loss in throughput and I myself would be getting the full benefit of less harrassment by users. (-:

[Steven Schweda]

> >cheap-and-nasty NAT/PAT-capable IP router

> I don't happen to have one lying around
> spare (not ethernet to ethernet anyway).

Around here, someone is usually selling one
(typically with a four-port switch and an
802.11g antenna) for less than $50. (Last
week, at one place: $23 after $30 rebate,
$40 after $20 rebate, or just-plain $40,
depending on the model.) On your side of the
planet, cheap, PC-oriented junk could be more
dear.

Just think of all the time you could waste
if only you had more c&n hardware.

[Paul Nunez · Accepted solution]

Thanks to Derek's persistence, I gave this some additional thought and now have both Advanced Server and Samba running on the same Alpha system running OVMS 8.2.

The keys were:

1. You cannot affect which UDP nor TCP ports Advanced Server uses. It will allocate UDP ports 137 and 138, and TCP port 139 on all interfaces. Thus, you have to force Samba to avoid using these ports by:

a. Changing the definition of the SMBD service to use TCP port 445 instead of TCP port 139.

b. Do not start the NMBD process (to avoid allocating udp ports 137 and 138).

2. Prevent the Samba server from using the same interface that Advanced Server is using. There seems to be a few ways to do this:

a. Define the SMBD service using the /ADDRESS qualifier to specify which IP address the SMBD service will respond to.

b. Use the smb.conf global parameters:

bind interfaces only = yes
interfaces =

Note that initially I had both Advanced Server and Samba using a single interface/ip address on the Alpha. But when I tried to force the Windows client to use the Advanced Server and not Samba, I couldn't. The client would attempt the operation on tcp port 445 first and, despite specifying the Advanced Server's name in the request, the Samba server was responding. For example, the Advanced Server computername is dtaxp3as; Samba's computername is configured as dtaxp3. But even when I tried:

net view \\dtaxp3as

I would get the list of shares offered by the Samba server.

But once I defined an alias interface (i.e, $ ifconfig we0 alias 10.1.1.1/18) and redefined the SMBD service to use that address only (and restarted TCP/IP), I can now do things like:

net view \\10.1.1.1

and get the list of shares from the Samba server or:

new view \\

and get the list of shares from the Advanced Server.

You could also give the alias address a name in the DNS name space and/or define a statis WINS entries (or use LMHOSTS entires) so clients could use a name to connect to the Samba server.

But since the Samba server is NOT running the NMBD process, you can't rely on broadcasted NetBIOS name queries to translate the Samba computername to an IP address.

Obviously, there are likely other "issues" with this set up that I've not yet discovered (just started testing this morning). But I was able to map a share to both servers from my Windows XP client.

Below is the command file I used to set up the SMBD service (this only needs to be run once to define the service). If you already have an SMBD service defined ($ UCX SHOW SERVICE SMBD), you'll have to delete it ($ ucx set noservice smbd) and recreate it anew:

$ set noon
$ tcpip disable service smbd
$ tcpip set service smbd -
/protocol=TCP -
/port=445 -
/flag=listen -
/address=10.1.1.1 -
/user=SAMBA$SMBD-
/process=SMBD -
/file=SAMBA_ROOT:[BIN]SMBD_STARTUP.COM -
/log=(FILE:SAMBA_ROOT:[VAR]SMBD_STARTUP.LOG,ALL) -
/limit=10
$ TCPIP SET CONFIG ENABLE NOSERVICE SMBD

Then you need to modify sys$startup:samba_startup.com and comment out the lines that start the NMBD process.

[Derek Garson]

Good one!

Unfortunately I just discovered that the Alpha eval kit is VMS V8.2 only and I am on V7.3-2. So there will be a detour while we plan and execute that upgrade. I won't be able to do the Samba eval this month.

>But when I tried to force the Windows client >to use the Advanced Server and not Samba, I >couldn't.

For the record, there is a registry hack for this. It wouldn't be ideal in my scenario to have to apply the hack to each and every PC (except the PCs doing the testing) during the evaluation period - with the usual dangers associated with reghacks.

In case anyone is interested, wgrep for "SmbDeviceEnabled".

But tricking it with an alias IP address is much safer and simpler.

>and, despite specifying the Advanced >Server's name in the request, the Samba >server was responding.

As I understand it, the called system name is suppressed from the SESSION REQUEST message and is instead always *SMBSERV padded with NULs to a length of 16.

This is just as well because in a more complex network environment the server really has no idea what name the client might have used for the server. (Specifying the called name might have made sense in the original LAN-only, Microsoft-style name resolution.)

More importantly, if the client passed the actual called name and the server really checked it then all sorts of glorious hacks that I have had to use over the years would not work.