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