Pathworks and Samba together

[Derek Garson]

My Alpha has two ethernet controllers, EIA0 and EIB0. The two LANs in question have quite separate requirements and uses and I require Pathworks only to be accessible on EIA0.

This thread relates to my previous thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1016940

When I discovered that unexpectedly Pathworks was accessible on both LANs, I thought that if I could persuade Pathworks to do what I wanted then before I used packet filtering to disable Pathworks completely on the second LAN, I would try the evaluation kit for Samba on the second LAN.

This should provide a low-risk, low-disruption way of trialling Samba and of preparing for migration, while keeping Pathworks running in production on the LAN where it is supposed to be running.

I can't be the only person in the VMS-universe contemplating this.

Now considering that it would appear that Pathworks can't be confined to a single LAN, does anyone have any good ideas for how to trial Samba in parallel with running Pathworks?

We don't have a second Alpha. We have an old, spare VAX somewhere but I don't think HP is making the Samba eval kit available for VAX.

We can almost certainly find a spare PC, and we can probably install Linux on it and trial Samba there but that is obviously not as good a trial.

I suspect that Galaxy is not possible for our Alpha (2 CPU, DS20E) - but that might be overkill anyway.

[Derek Garson]

PS This obviously raises the related question of whether Samba can be confined to one LAN.

[John Gillings]

Hi Derek,

I don't think this will be possible because both pathworks and samba will want to be listening to the same ports. As you've said, Pathworks can't (easily) be limited to a single LAN, ergo, I don't think they'll co-exist.

Please log a case if you want an official answer.

[Steven Schweda]

If you're sufficiently desperate, and if one
server or the other could be persuaded to use
different ports, you might be able to get a
cheap-and-nasty NAT/PAT-capable IP router,
and interpose it between one LAN interface
and its network.

[Derek Garson]

Hi John,

"can't (easily)" ... I'm always interested in non-easy things. (-: Are you saying that there is some way to limit Pathworks to one subnet but it's not easy? Yes, I know that I "can" patch the Pathworks executable. (-: And, yes, I saw your article in DTJ about faking shareable images.

Surely I can't log a case for Samba already?

"how do I run the two products in parallel?" is more an "ideas / experiences" question than a "support" question.

For example, someone might have some information / experience regarding how to move one or other product to non-standard ports (but that would require matching instructions for my test PC).

Oh, and it occurs to me to wonder about port 445 support. As far as I can tell, Pathworks does not support port 445. But if Samba does then maybe there's an opening there.

[Steven Schweda]

> For example, someone might have some
> information / experience regarding how to
> move one or other product to non-standard
> ports

No experience, and only unreliable info,
but perhaps for Samba (nmbd):

-p

UDP port number is a positive integer value. This option changes the default UDP port number (normally 137) that nmbd
responds to name queries on. Don't use this option unless you are an expert, in which case you won't need help!

(They're _so_ funny.)

If you get desperate, look for NMB_PORT,
DGRAM_PORT, and SMB_PORT in SMB.H.

> (but that would require matching
> instructions for my test PC).

That's the problem which the NAT/PAT-capable
IP router solves. The PC uses port, say,
137, the NAT/PAT jive shifts it to the port
of your choice at the address of your choice,
and the message arrives there, instead of at
its apparent destination.

If I actually knew which ports were used for
what, I could be dangerous.

There seem to be some things in smb.conf,
too, like "bind interfaces only" and "socket
address".

Note that I have a spare Alpha, so I
shouldn't ever need to go through all this.

[Steven Schweda]

Oh, look. smbd has a "-p" option, too:

-p

port number is a positive integer value. The default value if this parameter is not specified is 139.

This number is the port number that will be used when making connections to the server from client software. The standard
(well-known) port number for the SMB over TCP is 139, hence the default. If you wish to run the server as an ordinary
user rather than as root, most systems will require you to use a port number greater than 1024 - ask your system
administrator for help if you are in this situation.

In order for the server to be useful by most clients, should you configure it on a port other than 139, you will require port
redirection services on port 139, details of which are outlined in rfc1002.txt section 4.3.5.

This parameter is not normally specified except in the above situation.


For what more could one ask?

[Antoniov.]

Hi Derek,
I'm trying SAMBA/CIFS V3.0 on IA64 and SAMBA 2.2.8 on Alpha.
I think you should know that:
a) Samba/CIFS V3.0 is not yet avaiable on Alpha architecture.
b) Samba V2.2.8 is not performing on VMS; I compared Advanced Server with Samba and the first one is better and better.
c) Both Samba and A/S are hungry of resources (memory and CPU). Running both on the same CPU may be very heavy.

If I was in your shoes, I wait for Samba/CIFS Version 3 on Alpha before trial it.
If you can't find another CPU, you could install Samba but switch using alternatively A/S or Samba, never both togheter.

Antonio Vigliotti
http://it.openvms.org

[Andy Bustamante]

Based on your question I'm assuming that you have Pathworks configured using TCPIP. 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. Use "ADMIN/CONFIG" and the transport tab to disable TCPIP and enable DECnet.

The media CD for Pathworks 32 is in the quarterly SPL.

Andy Bustamante

[Paul Nunez]

Hi,

Advanced Server uses UDP port 137 for NetBIOS Name services, UDP port 138 for NetBIOS Datagram services, and TCP port 139 for file/print services.

Samba uses the same ports, but can be configured to use TCP port 445 (in addition to or instead of 139). I created a TCP service listening on port 445 and my Windows client was able to connect to the Samba (Itanium) server. Just use the output from $ TCPIP SHOW SERVICE/FULL SMBD to create a similar service listening on port 445.

Most Windows systems will try TCP port 445 first.

But you still need to deal with ports 137 and 138 in order to have both co-exist on one machine. I'm not saying it's not possible, I just haven't found a way to do this. Windows 2000/XP/2003 will use DNS to resolve names and will fallback to use NetBIOS Name services (assuming NetBIOS over TCP/IP hasn't been disabled). Besides browser stuff and domain logon, I'm not sure what else relies on NetBIOS Datagrams (udp port 138). I suppose you could disable the browser to cut down on that traffic. Windows clients likely are using ldap rather than netbios datagrams to do domain logons...

You can also restrict which interfaces on which Samba operates.

As for using PATHWORKS32 V7.4 on the clients, you need to purchase a license to use PATHWORKS32 on Windows clients. I'm not referring to the license which allows clients (with or without PATHWORKS32) to map shares to PATHWORKS or Advanced Server servers (pwlmxxxca07.03). It's just your typical right-to-use license. More info at:

http://h71000.www7.hp.com/pathworks32/weblic.html

Just some more fodder to consider...

Regards,

Paul

[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.