Discussion:
SAMBA / CIFS for OpenVMS
(too old to reply)
h***@gmx.de
2017-02-22 13:08:04 UTC
Permalink
Raw Message
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?

VSI seems to refuse to get in contact with me.

Kind reagrds
Matthias
Simon Clubley
2017-02-22 13:15:54 UTC
Permalink
Raw Message
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
I don't know the answer to your question, but what VSI contact address
did you use and how long have you been waiting for a reply ?

(I've had answers from anywhere within a couple of hours to a couple
of days, so if it's longer than that, are there any spam filtering
issues with your email address ?)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
h***@gmx.de
2017-02-22 14:18:27 UTC
Permalink
Raw Message
That's the address of Sue Skonetski and ***@vmssoftware.com

With Sue I had an initial contact last at 20th of January

Kind regards
Matthias
Simon Clubley
2017-02-22 18:35:53 UTC
Permalink
Raw Message
Talk to Clair at ***@vmssoftware.com as this is getting into the
area that he's going to be able to give you the answer to or
otherwise be able to point you to someone who can.

More important however, is if someone at VSI isn't reading queries
or if those queries are getting lost in the system then that's
something Clair needs to know about so he can get something done
about it.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
c***@gmail.com
2017-02-22 21:46:05 UTC
Permalink
Raw Message
Post by Simon Clubley
area that he's going to be able to give you the answer to or
otherwise be able to point you to someone who can.
More important however, is if someone at VSI isn't reading queries
or if those queries are getting lost in the system then that's
something Clair needs to know about so he can get something done
about it.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Let me see if I can help.
c***@gmail.com
2017-02-23 00:51:13 UTC
Permalink
Raw Message
Post by c***@gmail.com
Post by Simon Clubley
area that he's going to be able to give you the answer to or
otherwise be able to point you to someone who can.
More important however, is if someone at VSI isn't reading queries
or if those queries are getting lost in the system then that's
something Clair needs to know about so he can get something done
about it.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Let me see if I can help.
Obviously I cannot answer for HP. There is nothing new from VSI. We are getting requests for a newer Samba but it a big project and not on our radar at this time.
Stephen Hoffman
2017-02-23 01:16:08 UTC
Permalink
Raw Message
Post by c***@gmail.com
There is nothing new from VSI. We are getting requests for a newer
Samba but it a big project and not on our radar at this time.
FWIW... And you've probably already thought of this, but... Might
want to ask those folks whether they specifically want Samba, or if
they're looking for SMB2 or SMB3 client or server services, NTLM
(hopefully not), Active Directory Domain Controller support, etc.

This because various SMB servers are available, including Samba.

This SMB server might even work on OpenVMS, potentially subject to more
current support for Java on OpenVMS:

https://www.alfresco.com/news/press-releases/alfresco-makes-leading-java-implementation-jlan-shared-file-drive-interface


Some of the other available commercial and open-source SMB servers include:

https://www.tuxera.com/products/tuxera-smb/
http://www.freenas.org
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-02-26 03:59:37 UTC
Permalink
Raw Message
Post by Stephen Hoffman
This SMB server might even work on OpenVMS, potentially subject to more
https://www.alfresco.com/news/press-releases/alfresco-makes-leading-java-implementation-jlan-shared-file-drive-interface
It runs on Java 5 so no problem with Java version.

I have tried to get it to work, but with no luck.

The configuration is a bit complex and I don't have the SMB knowledge to
understand it.

Arne

PS: Also some functionality (announcement??) requires a JNI module. But
I suspect most VMS people could live without that.
h***@gmx.de
2017-02-23 11:13:25 UTC
Permalink
Raw Message
Post by c***@gmail.com
Post by c***@gmail.com
Post by Simon Clubley
area that he's going to be able to give you the answer to or
otherwise be able to point you to someone who can.
More important however, is if someone at VSI isn't reading queries
or if those queries are getting lost in the system then that's
something Clair needs to know about so he can get something done
about it.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Let me see if I can help.
Obviously I cannot answer for HP. There is nothing new from VSI. We are getting requests for a newer Samba but it a big project and not on our radar at this time.
As far as I got it from http://www.vmssoftware.com/news/VMS_Software_Roadmap.pdf

with Open VMS 8.4-1H1 a new Samba Version is included? Isnn't it ?

Kind reagrds
Matthias
BillPedersen
2017-02-23 11:30:06 UTC
Permalink
Raw Message
Post by h***@gmx.de
Post by c***@gmail.com
Post by c***@gmail.com
Post by Simon Clubley
area that he's going to be able to give you the answer to or
otherwise be able to point you to someone who can.
More important however, is if someone at VSI isn't reading queries
or if those queries are getting lost in the system then that's
something Clair needs to know about so he can get something done
about it.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Let me see if I can help.
Obviously I cannot answer for HP. There is nothing new from VSI. We are getting requests for a newer Samba but it a big project and not on our radar at this time.
As far as I got it from http://www.vmssoftware.com/news/VMS_Software_Roadmap.pdf
with Open VMS 8.4-1H1 a new Samba Version is included? Isnn't it ?
Kind reagrds
Matthias
No.

There MAY have been some clean up, and possibly some security fixes but other than that no. No changes. Still based on 3.0.28a.

Bill.
p***@gmail.com
2017-02-22 15:29:34 UTC
Permalink
Raw Message
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
Kind reagrds
Matthias
did you put in the 2015 patch? I'm looking to have at a minimum a SMB 2.0 capable version and reached out to HPE to see if they had any updates as to the last email about it a year ago... saying they would keep me updated as to the status :-)
Rich Jordan
2017-02-22 21:49:13 UTC
Permalink
Raw Message
Post by p***@gmail.com
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
Kind reagrds
Matthias
did you put in the 2015 patch? I'm looking to have at a minimum a SMB 2.0 capable version and reached out to HPE to see if they had any updates as to the last email about it a year ago... saying they would keep me updated as to the status :-)
2015 patch? I found no mention of that on the HPE site (and many of the links on the Samba page are still broken pointing to hp.com addresses instead of hpe...). Entitled patch? Only available with a support call?

Thanks for any info.
Stephen Hoffman
2017-02-23 00:37:31 UTC
Permalink
Raw Message
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64)
available which is not part of the new VSI OS package?
If your question was around the availability of patches for the cited
CIFS version past ECO1, then yes, there are some patch sets available.

But I'm not aware of any HPE ports of more recent versions of Samba,
and I'd be very surprised to see any additional work (from HPE) to
update this area, if that was your question.

There were not-packaged-as-an-ECO out-of-band patch sets made available
via an HP FTP site. The basis for the patches was the same version
as was used for Samba CIFS V1.2 ECO1; it's all based on 3.0.28a. IIRC,
patch set three (PS3, PS03, PS003, the nomenclature seemed to vary) was
the newest when I last looked (a while ago), though the HPE web page
only mentions patch set 2 (and doesn't provide a download link).

Some background:

http://h41379.www4.hpe.com/network/cifs_download.html

For some few added details on accessing the patch server:

http://de.openvms.org/TUD2011/CIFS-Tips_und_Tricks.pdf

Not sure if the FTP server mentioned in that presentation is still
active or has been re-hosted over into the HPE domain (yet?). Some
rummaging might turn up a username and password for the CIFS patch
sets, or contact the HPE support folks directly and ask for the
credentials.

There are also some known issues with Samba releases as far back as
3.0.28a, too:
http://www.cvedetails.com/vulnerability-list.php?vendor_id=102
--
Pure Personal Opinion | HoffmanLabs LLC
Rich Jordan
2017-02-23 22:58:41 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64)
available which is not part of the new VSI OS package?
If your question was around the availability of patches for the cited
CIFS version past ECO1, then yes, there are some patch sets available.
But I'm not aware of any HPE ports of more recent versions of Samba,
and I'd be very surprised to see any additional work (from HPE) to
update this area, if that was your question.
There were not-packaged-as-an-ECO out-of-band patch sets made available
via an HP FTP site. The basis for the patches was the same version
as was used for Samba CIFS V1.2 ECO1; it's all based on 3.0.28a. IIRC,
patch set three (PS3, PS03, PS003, the nomenclature seemed to vary) was
the newest when I last looked (a while ago), though the HPE web page
only mentions patch set 2 (and doesn't provide a download link).
http://h41379.www4.hpe.com/network/cifs_download.html
http://de.openvms.org/TUD2011/CIFS-Tips_und_Tricks.pdf
Not sure if the FTP server mentioned in that presentation is still
active or has been re-hosted over into the HPE domain (yet?). Some
rummaging might turn up a username and password for the CIFS patch
sets, or contact the HPE support folks directly and ask for the
credentials.
There are also some known issues with Samba releases as far back as
http://www.cvedetails.com/vulnerability-list.php?vendor_id=102
--
Pure Personal Opinion | HoffmanLabs LLC
Hoff,
thanks for the info. I posted a query to HP from the Samba page (not holding breath for response but worth a shot). I'll probably open a support call. It has been long enough since I dealt with Samba that I forgot about the PS00# patches. The customer system has what was available and current in 2014 but I didn't think to check for a PS update on it. If there is a 2015 patch then if anyone has at least the release notes for it (or any newer) I'd really appreciate seeing them. In the meantime, I'll dig into our archives from the last time we worked on it and see what I can squeeze out of HP(e).

The issue they have is crashes of a couple of Windows 10 PCs that seem to occur when they are using drives mapped on the VMS Samba server. The problem has survived PC replacement and windows reinstalls (and driver updates, etc). There are reports of issues working with other platform Samba servers (newer of course) that are worked around by disabling server-side SMB3/4 (Windows 10 apparently tries to force use of a newer version). Not sure yet if there is anything that can be done on the client instead.
Stephen Hoffman
2017-02-24 00:13:43 UTC
Permalink
Raw Message
Post by Rich Jordan
The issue they have is crashes of a couple of Windows 10 PCs that
seem to occur when they are using drives mapped on the VMS Samba
server. The problem has survived PC replacement and windows reinstalls
(and driver updates, etc). There are reports of issues working with
other platform Samba servers (newer of course) that are worked around
by disabling server-side SMB3/4 (Windows 10 apparently tries to force
use of a newer version). Not sure yet if there is anything that can be
done on the client instead.
I'd escalate that directly to HPE support, as — without a trace of the
traffic, and BTW there are a whole pile RCEs in all but the most recent
tcpdump versions — there's a decent possibility of some organizational
finger-pointing between HPE and Microsoft and Samba. Windows should
not crash, but what the Samba CIFS port is doing could conceivably be
broken. And the Samba folks will undoubtedly require an upgrade from
the problematic and known-insecure and fossil version in use. That's
not the sort of discussion I'd expect the HPE CIFS web page email
contact to be able to field...
--
Pure Personal Opinion | HoffmanLabs LLC
Rich Jordan
2017-02-24 21:51:30 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Rich Jordan
The issue they have is crashes of a couple of Windows 10 PCs that
seem to occur when they are using drives mapped on the VMS Samba
server. The problem has survived PC replacement and windows reinstalls
(and driver updates, etc). There are reports of issues working with
other platform Samba servers (newer of course) that are worked around
by disabling server-side SMB3/4 (Windows 10 apparently tries to force
use of a newer version). Not sure yet if there is anything that can be
done on the client instead.
I'd escalate that directly to HPE support, as — without a trace of the
traffic, and BTW there are a whole pile RCEs in all but the most recent
tcpdump versions — there's a decent possibility of some organizational
finger-pointing between HPE and Microsoft and Samba. Windows should
not crash, but what the Samba CIFS port is doing could conceivably be
broken. And the Samba folks will undoubtedly require an upgrade from
the problematic and known-insecure and fossil version in use. That's
not the sort of discussion I'd expect the HPE CIFS web page email
contact to be able to field...
--
Pure Personal Opinion | HoffmanLabs LLC
Hoff
I don't expect the CIFS email contact to field that; I just asked them to let us know if there were any updates or patches beyond the PS 2 on the download page, and if so what was needed to get same (service call, etc), or _at least_ the release notes. I don't expect them to deal with an actual service issue. It would be interesting to confirm that an OpenVMS Samba server is in fact the latest Windows 10 exploit.

Lately I don't much expect a response if they can't even fix the links on the page, but hope springs eternal. The page says the request is going to the "OpenVMS Webmaster". I have to wonder if HP has anyone/anygroup in that position.
BillPedersen
2017-02-23 02:11:55 UTC
Permalink
Raw Message
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
Kind reagrds
Matthias
I might as well jump in here. Back in the Fall of 2013 I started a project to port a newer version of Samba to OpenVMS. I had cycles available then. This was based upon a port of Samba 4.3 initially. I have since move up to a newer version. The build environment changed from being a BASH shell script environment to one using WAF, a build environment using Python scripts.

Well, along the way I found I had to improve the Python infrastructure to support the build which created some distraction and then I was distracted by getting a new, very demanding job. So things were on hold from the Summer of 2014 to the Spring of 2015 when I was laid off from that job.

So I restarted the project, revisited and improved the Python infrastructure (specifically subprocess.py) and the found I needed to create a work around in Perl for similar reasons. That was done more expeditiously. I continued working on it. Part of the reason to improve these tools is that I use the philosophy that if you can create a build environment that requires minimal if any changes to the build environment used on Linux then you are ahead of the game and can then move to newer versions of the project more readily. This is in contrast to what DEC/Compaq/HP/HPE have done where they basically hacked the port to fit VMS and then for the most part did not implement new versions unless absolutely forced to do so.

Actually got it to the point of where I could in fact connect to a VMS based server process, get a directory listing, display contents of a file. Issues arose with the support for Samba's TDB (trivial data base). There had been an implementation previously which I started to work on extending.

I took a new job last June. This was not as demanding but I needed to show my commitment to my new employer. So I slowed my efforts. I would estimate that I am probably 30% through the effort.

Unfortunately, I had a personal tragedy in my life last September and have not even had my servers running since then. I am slowly getting back to the point where I can restart this project. The big issue will be finding time and energy. I also have to keep my employer happy and keep some time for myself.

I have made some proposals to create a version of a Samba client based upon a later version of the V3.xx code but nothing has come of that. It would at least then give me some leverage in getting more work done on the 4.x version of Samba.

If there were some way to leverage interest to support this effort then there could probably be more progress. But at present it is entirely dependent on my finding time out of my own schedule and life to make progress.

Bill.
David Froble
2017-02-23 03:54:12 UTC
Permalink
Raw Message
Post by BillPedersen
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64) available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
Kind reagrds
Matthias
I might as well jump in here. Back in the Fall of 2013 I started a project to port a newer version of Samba to OpenVMS. I had cycles available then. This was based upon a port of Samba 4.3 initially. I have since move up to a newer version. The build environment changed from being a BASH shell script environment to one using WAF, a build environment using Python scripts.
Well, along the way I found I had to improve the Python infrastructure to support the build which created some distraction and then I was distracted by getting a new, very demanding job. So things were on hold from the Summer of 2014 to the Spring of 2015 when I was laid off from that job.
So I restarted the project, revisited and improved the Python infrastructure (specifically subprocess.py) and the found I needed to create a work around in Perl for similar reasons. That was done more expeditiously. I continued working on it. Part of the reason to improve these tools is that I use the philosophy that if you can create a build environment that requires minimal if any changes to the build environment used on Linux then you are ahead of the game and can then move to newer versions of the project more readily.. This is in contrast to what DEC/Compaq/HP/HPE have done where they basically hacked the port to fit VMS and then for the most part did not implement new versions unless absolutely forced to do so.
Actually got it to the point of where I could in fact connect to a VMS based server process, get a directory listing, display contents of a file. Issues arose with the support for Samba's TDB (trivial data base). There had been an implementation previously which I started to work on extending.
I took a new job last June. This was not as demanding but I needed to show my commitment to my new employer. So I slowed my efforts. I would estimate that I am probably 30% through the effort.
Unfortunately, I had a personal tragedy in my life last September and have not even had my servers running since then. I am slowly getting back to the point where I can restart this project. The big issue will be finding time and energy. I also have to keep my employer happy and keep some time for myself.
I have made some proposals to create a version of a Samba client based upon a later version of the V3.xx code but nothing has come of that. It would at least then give me some leverage in getting more work done on the 4.x version of Samba.
If there were some way to leverage interest to support this effort then there could probably be more progress. But at present it is entirely dependent on my finding time out of my own schedule and life to make progress.
Bill.
I'm wondering what is so great about Samba? I also wonder why anyone would want
to store weendoze files on a VMS system? Possibly there are reasons, I've yet
to become aware of them.

I got a real cheap weendoze system, a couple of disks mirrored, and store all my
weendoze stuff there. Works for me. Might not for others.

Sounds to me like a square peg and round hole problem ....
Jan-Erik Soderholm
2017-02-23 07:12:38 UTC
Permalink
Raw Message
Post by David Froble
Post by BillPedersen
Post by h***@gmx.de
Is there any new version after Version 1.2 ECO1 for OpenVMS (I64)
available which is not part of the new VSI OS package?
VSI seems to refuse to get in contact with me.
Kind reagrds Matthias
I might as well jump in here. Back in the Fall of 2013 I started a
project to port a newer version of Samba to OpenVMS. I had cycles
available then. This was based upon a port of Samba 4.3 initially. I
have since move up to a newer version. The build environment changed
from being a BASH shell script environment to one using WAF, a build
environment using Python scripts.
Well, along the way I found I had to improve the Python infrastructure to
support the build which created some distraction and then I was
distracted by getting a new, very demanding job. So things were on hold
from the Summer of 2014 to the Spring of 2015 when I was laid off from
that job.
So I restarted the project, revisited and improved the Python
infrastructure (specifically subprocess.py) and the found I needed to
create a work around in Perl for similar reasons. That was done more
expeditiously. I continued working on it. Part of the reason to improve
these tools is that I use the philosophy that if you can create a build
environment that requires minimal if any changes to the build environment
used on Linux then you are ahead of the game and can then move to newer
versions of the project more readily.. This is in contrast to what
DEC/Compaq/HP/HPE have done where they basically hacked the port to fit
VMS and then for the most part did not implement new versions unless
absolutely forced to do so.
Actually got it to the point of where I could in fact connect to a VMS
based server process, get a directory listing, display contents of a
file. Issues arose with the support for Samba's TDB (trivial data
base). There had been an implementation previously which I started to
work on extending.
I took a new job last June. This was not as demanding but I needed to
show my commitment to my new employer. So I slowed my efforts. I would
estimate that I am probably 30% through the effort.
Unfortunately, I had a personal tragedy in my life last September and
have not even had my servers running since then. I am slowly getting
back to the point where I can restart this project. The big issue will
be finding time and energy. I also have to keep my employer happy and
keep some time for myself.
I have made some proposals to create a version of a Samba client based
upon a later version of the V3.xx code but nothing has come of that. It
would at least then give me some leverage in getting more work done on
the 4.x version of Samba.
If there were some way to leverage interest to support this effort then
there could probably be more progress. But at present it is entirely
dependent on my finding time out of my own schedule and life to make
progress.
Bill.
I'm wondering what is so great about Samba?
It is all about integration of environments.
Post by David Froble
I also wonder why anyone would
want to store weendoze files on a VMS system? Possibly there are reasons,
I've yet to become aware of them.
Not simply "storing" something. That can obviously easily be done
on a Windows based server. Or a ready-built NAS of different sizes.
Post by David Froble
I got a real cheap weendoze system, a couple of disks mirrored, and store
all my weendoze stuff there. Works for me. Might not for others.
Sounds to me like a square peg and round hole problem ....
I have always seen Pathworks, Samb or whatever as a means to get better
integration between environments. Getting "seam-less" access for Windows
based end-users to data created on VMS.

Now, for the last 15+ years, web based solutions has solved that better.

I see very little "use" of the kind of file based integration that
Pathworks or Samba gives today. We let our VMS rutines put files in
some directory that is servered through the web server.
gérard Calliet
2017-02-23 16:01:24 UTC
Permalink
Raw Message
Hello,

I had a question about cms. They wanted to re-use some very old software
which was in a cms library.

They had an apparent version issue:

$ cms set lib my_dsk:[my_cms]
%cms-e-noref, error referencing my_dsk:[my_cms]
-cms-w-manconlib, my_dsk:[my_cms] is a version prior to cms v3.5-04 and
cannot be used with the current version of CMS. Please see release notes
for conversion...

So they attempted a conversion:
$ cms convert lib my_dsk:[my_cms] my_dsk:[my_cms3]
%cms-e-convnotnec, library my_dsk:[my_cms] is already in the current format

Any idea?

Thanks,

Gérard Calliet

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2017-02-23 17:26:14 UTC
Permalink
Raw Message
Post by gérard Calliet
Hello,
I had a question about cms. They wanted to re-use some very old
software which was in a cms library.
$ cms set lib my_dsk:[my_cms]
%cms-e-noref, error referencing my_dsk:[my_cms]
-cms-w-manconlib, my_dsk:[my_cms] is a version prior to cms v3.5-04 and
cannot be used with the current version of CMS. Please see release
notes for conversion...
$ cms convert lib my_dsk:[my_cms] my_dsk:[my_cms3]
%cms-e-convnotnec, library my_dsk:[my_cms] is already in the current format
Any idea?
As we have all recently been told, OpenVMS is a "real operating
system", which presumably means it's for real people who really like to
find the real documentation and really read it. Because that isn't
the conversion command. Well, that is a conversion command. But
that's not the right conversion command. That's the conversion
command to convert from some even-more-fossil version of CMS to a
less-fossil version of CMS, and not the version conversion that you
need for this case. Why the convert version conversion command
doesn't do the proper thing here (too), I will never understand. The
release notes used to have some text on this, and here's a summary of
the CMS and DTM conversion sequence, from the old FAQ...
Post by gérard Calliet
  13.8  How do I convert to new CMS or DTM libraries?
                   A change was made to the format of the CMS database
                   for CMS libraries starting with V3.5-03-to ensure
                   that earlier versions of CMS are unable to access the
                   database once the "conversion" to V3.5-05 and later is
                   made, you must issue the following two commands when
                   upgrading from V3.5-03 and prior. (The only differences
                   between CMS version V3.5-03 and CMS version V3.5-05
                   involve changes to ensure that no earlier version of
                   CMS can access the "converted" database, and corrupt
                   it.)
                   To perform the "conversion", issue the following
                   $ RENAME disk:[directory]00CMS.* 01CMS.*
                   $ COPY NLA0: disk:[directory]00CMS.CMS
                   The new file 00CMS.CMS must have the same security
                   settings as the 01CMS.CMS file, and is created solely
                   to ensure continued compatibility with tools that
                   expect to find a 00CMS.CMS file (eg: various versions
                   of the Language-Sensitive text editor LSEDIT).
                   If you choose to install and use the longer variant
                   names support that is available with CMS V4.1 or later,
                   you cannot mix earlier CMS versions within a cluster.
                   If you attempt to mix older and newer versions, you
                   will typically see the following BADLIB and BADTYPSTR
                   error sequence when accessing the CMS library from the
                   %CMS-F-BADLIB, there is something wrong with your library
                   -CMS-F-BADTYPSTR, header block type is 145; it should be 17
                   Please see the CMS V4.1 release notes for additional
                   details on this.
                   To perform the equivalent "conversion" for DEC Test
                   Manager (DTM) V3.5 and prior versions to V3.6 and later
                   versions, issue the following DCL commands for each DTM
                   $ RENAME disk:[directory]00DTM.* 01DTM.*
                   $ COPY NLA0: disk:[directory]00DTM.DTM
                   Like CMS, this change is intended to prevent older
                   versions of DTM from accessing newer libraries, and
                   corrupting the contents. Like CMS, once the libraries
                   are renamed, they cannot and should not be renamed
                   back to the older names; like CMS, the changes are not
                   downward-compatible.
                   To convert version 1 (ancient) DTM and CMS libraries
                   forward, please see the DTM CONVERT and the CMS CONVERT
                   commands.
--
Pure Personal Opinion | HoffmanLabs LLC
gérard Calliet
2017-02-23 23:31:14 UTC
Permalink
Raw Message
Post by gérard Calliet
Hello,
I had a question about cms. They wanted to re-use some very old
software which was in a cms library.
$ cms set lib my_dsk:[my_cms]
%cms-e-noref, error referencing my_dsk:[my_cms]
-cms-w-manconlib, my_dsk:[my_cms] is a version prior to cms v3.5-04
and cannot be used with the current version of CMS. Please see release
notes for conversion...
$ cms convert lib my_dsk:[my_cms] my_dsk:[my_cms3]
%cms-e-convnotnec, library my_dsk:[my_cms] is already in the current format
Any idea?
As we have all recently been told, OpenVMS is a "real operating system",
which presumably means it's for real people who really like to find the
real documentation and really read it. Because that isn't the
conversion command. Well, that is a conversion command. But that's
not the right conversion command. That's the conversion command to
convert from some even-more-fossil version of CMS to a less-fossil
version of CMS, and not the version conversion that you need for this
case. Why the convert version conversion command doesn't do the proper
thing here (too), I will never understand. The release notes used to
have some text on this, and here's a summary of the CMS and DTM
conversion sequence, from the old FAQ...
Post by gérard Calliet
13.8 How do I convert to new CMS or DTM libraries?
A change was made to the format of the CMS database
for CMS libraries starting with V3.5-03-to ensure
that earlier versions of CMS are unable to access the
database once the "conversion" to V3.5-05 and later is
made, you must issue the following two commands when
upgrading from V3.5-03 and prior. (The only
differences
between CMS version V3.5-03 and CMS version V3.5-05
involve changes to ensure that no earlier version of
CMS can access the "converted" database, and corrupt
it.)
To perform the "conversion", issue the following
$ RENAME disk:[directory]00CMS.* 01CMS.*
$ COPY NLA0: disk:[directory]00CMS.CMS
The new file 00CMS.CMS must have the same security
settings as the 01CMS.CMS file, and is created solely
to ensure continued compatibility with tools that
expect to find a 00CMS.CMS file (eg: various versions
of the Language-Sensitive text editor LSEDIT).
If you choose to install and use the longer variant
names support that is available with CMS V4.1 or
later,
you cannot mix earlier CMS versions within a cluster.
If you attempt to mix older and newer versions, you
will typically see the following BADLIB and BADTYPSTR
error sequence when accessing the CMS library from the
%CMS-F-BADLIB, there is something wrong with your
library
-CMS-F-BADTYPSTR, header block type is 145; it
should be 17
Please see the CMS V4.1 release notes for additional
details on this.
To perform the equivalent "conversion" for DEC Test
Manager (DTM) V3.5 and prior versions to V3.6 and
later
versions, issue the following DCL commands for each
DTM
$ RENAME disk:[directory]00DTM.* 01DTM.*
$ COPY NLA0: disk:[directory]00DTM.DTM
Like CMS, this change is intended to prevent older
versions of DTM from accessing newer libraries, and
corrupting the contents. Like CMS, once the libraries
are renamed, they cannot and should not be renamed
back to the older names; like CMS, the changes are not
downward-compatible.
To convert version 1 (ancient) DTM and CMS libraries
forward, please see the DTM CONVERT and the CMS
CONVERT
commands.
Many thanks. A lot of apologies from a "misérable" newbie.
Next time I'll buy the encyclopedia before asking the great men.

Gérard Calliet

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2017-02-24 00:59:14 UTC
Permalink
Raw Message
Post by gérard Calliet
Many thanks. A lot of apologies from a "misérable" newbie.
Next time I'll buy the encyclopedia before asking the great men.
Um, no. That's not the message I'd intended. I

I'd prefer that the developers of the product(s) involved preferably
don't choose implementations this badly designed. Because if any of
us want to deal with similar solutions, there are usually a plethora of
much cheaper options available, too. That's all ignoring hidden costs,
such as the support costs involved. This design is not your mess,
that convert command should have worked, or analogous. Reading the
docs should have been entirely unnecessary here.

There is also a good case here for having a real database underneath
and not developers rolling their own solutions, as is the case here and
in many other spots within OpenVMS and layered products — but databases
are also options that have become far easier and far more available in
the past decade or two, long after this particular CMS mess was
implemented.

Bad designs are bad designs. Yes, sometimes design mistakes and
omissions and bugs happen. But sometimes the designs are just bad.
We aren't in the same environment now, and expectations — such as
available staffing and staff experience or training, and simply having
the time to find and read the documentation — differ greatly from those
that OpenVMS and layered products classically assumed and still
operates in.

More than a few of the "read the release notes" references in products
are indications of problems that the developers or designers have
decided to not deal with themselves, and to shift the problems to
others. That shift and those release notes are certainly sometimes
warranted, but that shift in general — particularly a shift that is as
apparently unnecessary as this one — is something becoming increasingly
difficult to sustain for a premium product. Nothing has prevented any
subsequent CMS release from including a change in the convert code, too.

TL;DR: The CMS designers let you down.
--
Pure Personal Opinion | HoffmanLabs LLC
gérard Calliet
2017-02-24 10:02:01 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by gérard Calliet
Many thanks. A lot of apologies from a "misérable" newbie.
Next time I'll buy the encyclopedia before asking the great men.
Um, no. That's not the message I'd intended. I
I'd prefer that the developers of the product(s) involved preferably
don't choose implementations this badly designed. Because if any of us
want to deal with similar solutions, there are usually a plethora of
much cheaper options available, too. That's all ignoring hidden costs,
such as the support costs involved. This design is not your mess, that
convert command should have worked, or analogous. Reading the docs
should have been entirely unnecessary here.
There is also a good case here for having a real database underneath and
not developers rolling their own solutions, as is the case here and in
many other spots within OpenVMS and layered products — but databases are
also options that have become far easier and far more available in the
past decade or two, long after this particular CMS mess was implemented.
Bad designs are bad designs. Yes, sometimes design mistakes and
omissions and bugs happen. But sometimes the designs are just bad.
We aren't in the same environment now, and expectations — such as
available staffing and staff experience or training, and simply having
the time to find and read the documentation — differ greatly from those
that OpenVMS and layered products classically assumed and still operates
in.
More than a few of the "read the release notes" references in products
are indications of problems that the developers or designers have
decided to not deal with themselves, and to shift the problems to
others. That shift and those release notes are certainly sometimes
warranted, but that shift in general — particularly a shift that is as
apparently unnecessary as this one — is something becoming increasingly
difficult to sustain for a premium product. Nothing has prevented any
subsequent CMS release from including a change in the convert code, too.
TL;DR: The CMS designers let you down.
It works, thanks.

I understand what you are saying. But in some cases it is very difficult
to choose a new product.

Here, there was a complete development, integration, reference, delivery
environment for a number of critical software (urban transportation).
The management of the sources, compiled objects and library, versioning
is part of the strong validation process.

The major part of that was developed between 80s and 90s. There were
strong teams with a good understanding of the VMS culture. They created
the whole environment using thousands of logical names, and CMS embedded
in a lot of DCL procedures.

It would be a huge work to re-create a complete environment with the
same qualities, and there should be a lot of re-validation to do, to use
another tool than CMS. And the set of living applications on VMS is more
and more reduced. So no possible investment.

The case of yesterday was a sort of archived application in the set of
applications.

I detailed the story to explain there are cases where you have to keep
maintaining layered products, even if there are better solutions.
My opinion is that in these cases it is only if we can prove in such
environments that VMS stability is a good economic choice, and we can
improve willingness for investment that we’ll be able to choose new
tools, and make evolutions on the platforms.

We need evaluations – not all is good in VMS products -, and we need
very long time backward knowledge and compatibility, to be able to do
smooth transitions

Gérard Calliet

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2017-02-23 16:04:08 UTC
Permalink
Raw Message
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there are
reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in
a fashion. SMB is very common, widely available, and a really handy
way to store and access files on a remote server. I'd certainly like
to be able to use the macOS clients to access OpenVMS native files via
SMB or suchlike, as part of accessing data and doing development across
the platforms. So would at least some of the folks using Windows and
Linux, both of which have extensive SMB support built in.

Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.

Further along into the future, SMB is a good potential foundation for
file access within clustering; whether to be added to and eventually
replace MSCP/SCS and traditional remote file access, or for use in some
newer and more loosely-coupled designs, or both.
Post by David Froble
I got a real cheap weendoze system, a couple of disks mirrored, and
store all my weendoze stuff there. Works for me. Might not for others.
Ayup. But then this same path extends further out, into where OpenVMS
generally fits, and to how OpenVMS integrates. OpenVMS is and will be
a completely awful choice as an SMB server for many reasons not the
least of which is price, and neither VSI nor HPE presently offer an SMB
client. But OpenVMS does have to play as a client and a server in
what are increasingly SMB-based networks.
Post by David Froble
Sounds to me like a square peg and round hole problem ....
Outside of its use and its applicability within the installed base,
that also unfortunately sums up rather more about OpenVMS itself than
I'd prefer. The port is the first big new deliverable from VSI, but
that port is also a very small part of the entire effort involved with
maintaining something as large as an operating system product. VSI
will be making more of these trade-offs than most folks can imagine,
and there's no way that SMB and other services will become available
anytime soon, nor SMB replacing MSCP/SCS, not short of a combined
effort from VSI and a third-party, a buy-out, the arrival of a couple
of truckloads of cash in Bolton, or other such. And as you quite
correctly note, there are already other and cheaper choices; FreeNAS,
Linux and other options all all set a pretty good floor, there.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-02-23 19:07:49 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there
are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in a
fashion. SMB is very common, widely available, and a really handy way
to store and access files on a remote server. I'd certainly like to be
able to use the macOS clients to access OpenVMS native files via SMB or
suchlike, as part of accessing data and doing development across the
platforms. So would at least some of the folks using Windows and Linux,
both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of bricks, might I
mention FTP?
Bill Gunshannon
2017-02-23 19:29:08 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there
are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in
a fashion. SMB is very common, widely available, and a really handy
way to store and access files on a remote server. I'd certainly like
to be able to use the macOS clients to access OpenVMS native files via
SMB or suchlike, as part of accessing data and doing development
across the platforms. So would at least some of the folks using
Windows and Linux, both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of bricks,
might I mention FTP?
FTP is for copying files. SAMBA is for accessing them as if they were
local. Big difference.

bill
David Froble
2017-02-23 22:15:00 UTC
Permalink
Raw Message
Post by Bill Gunshannon
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there
are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in
a fashion. SMB is very common, widely available, and a really handy
way to store and access files on a remote server. I'd certainly like
to be able to use the macOS clients to access OpenVMS native files via
SMB or suchlike, as part of accessing data and doing development
across the platforms. So would at least some of the folks using
Windows and Linux, both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of bricks,
might I mention FTP?
FTP is for copying files. SAMBA is for accessing them as if they were
local. Big difference.
bill
Once I copy them to the "local" system, they become "local" ....
Arne Vajhøj
2017-02-24 02:55:18 UTC
Permalink
Raw Message
Post by David Froble
Post by Bill Gunshannon
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there
are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in
a fashion. SMB is very common, widely available, and a really handy
way to store and access files on a remote server. I'd certainly like
to be able to use the macOS clients to access OpenVMS native files via
SMB or suchlike, as part of accessing data and doing development
across the platforms. So would at least some of the folks using
Windows and Linux, both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of bricks,
might I mention FTP?
FTP is for copying files. SAMBA is for accessing them as if they were
local. Big difference.
Once I copy them to the "local" system, they become "local" ....
Yes. But that is just a slightly more complicated process.

For occasionally usage that is fine.

For frequent usage it becomes a hassle.

There is a reason why mount of remote disks has been added
to most operating systems.

Arne
p***@gmail.com
2017-02-23 19:42:47 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there
are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in a
fashion. SMB is very common, widely available, and a really handy way
to store and access files on a remote server. I'd certainly like to be
able to use the macOS clients to access OpenVMS native files via SMB or
suchlike, as part of accessing data and doing development across the
platforms. So would at least some of the folks using Windows and Linux,
both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of bricks, might I
mention FTP?
FTP isn't allowed on the network and sftp is not... well VMS friendly. with SAMBA being a little more security conscious even being at SMB1.
Stephen Hoffman
2017-02-23 19:47:21 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there are
reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL in
a fashion. SMB is very common, widely available, and a really handy
way to store and access files on a remote server. I'd certainly like
to be able to use the macOS clients to access OpenVMS native files via
SMB or suchlike, as part of accessing data and doing development across
the platforms. So would at least some of the folks using Windows and
Linux, both of which have extensive SMB support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of
bricks, might I mention FTP?
Out of curiosity, why mention FTP in the context of Samba, SMB and file
shares? I might infer some unfamiliarity with file shares as commonly
used on Windows, macOS, Linux, OpenVMS or elsewhere? Pragmatically,
all this stuff is moving around where the remote-access client and/or
the server is implemented within the system and network stacks, and
potentially also how many and which specific commands and tools the
user has to issue to access remote files. It's all remote access,
after all. SMB, NFS and DEC DFS implement the client in the file
system stack, as does DECnet FAL. FTP has this implemented in a
separate utility. But if I don't want to change the various commands
and tools to add support for remote access, then an implementation akin
to a file share — or something akin to DECnet FAL — is pretty handy.
Not that both DECnet FAL and FTP don't have serious problems in their
current implementations, and not that I wouldn't mind a FAL-like client
for IP. But if there's to be a FAL-like client for IP in OpenVMS, I'd
prefer to see sftp and not FTP and for various reasons, and I'd prefer
including a way to implement other clients for additional connections;
clients such as for SMB and NFS.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-02-23 22:21:15 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
I'm wondering what is so great about Samba? I also wonder why
anyone would want to store weendoze files on a VMS system? Possibly
there are reasons, I've yet to become aware of them.
It's a file services protocol available on far more than Microsoft
Windows, akin to MSCP/SCS, NFS, DEC DFS, or suchlike, or DECnet FAL
in a fashion. SMB is very common, widely available, and a really
handy way to store and access files on a remote server. I'd
certainly like to be able to use the macOS clients to access OpenVMS
native files via SMB or suchlike, as part of accessing data and doing
development across the platforms. So would at least some of the
folks using Windows and Linux, both of which have extensive SMB
support built in.
Remote-mounted file shares are really handy, though shares are not an
approach that OpenVMS folks — outside of clusters, and the sometimes
problematic and entirely unintegrated NFS client and server support —
are just accustomed to doing.
At the risk of having you come down on me like a ton, or two, of
bricks, might I mention FTP?
Out of curiosity, why mention FTP in the context of Samba, SMB and file
shares? I might infer some unfamiliarity with file shares as commonly
used on Windows, macOS, Linux, OpenVMS or elsewhere? Pragmatically,
all this stuff is moving around where the remote-access client and/or
the server is implemented within the system and network stacks, and
potentially also how many and which specific commands and tools the user
has to issue to access remote files. It's all remote access, after
all. SMB, NFS and DEC DFS implement the client in the file system
stack, as does DECnet FAL. FTP has this implemented in a separate
utility. But if I don't want to change the various commands and tools
to add support for remote access, then an implementation akin to a file
share — or something akin to DECnet FAL — is pretty handy. Not that
both DECnet FAL and FTP don't have serious problems in their current
implementations, and not that I wouldn't mind a FAL-like client for
IP. But if there's to be a FAL-like client for IP in OpenVMS, I'd
prefer to see sftp and not FTP and for various reasons, and I'd prefer
including a way to implement other clients for additional connections;
clients such as for SMB and NFS.
You'll get no argument from me on the usefulness of FAL.

Now, I'm not typical, as all I do is R&D, but, I tend to store files on the
system(s) on which I'll be using them. So, if I do need a file from another
platform, copying it is the usual choice. No, I don't serve files from
dissimilar systems.

In the event that a production task needs such files, as appropriate, I set up
services and clients, such that a client can ask for some service to be
performed. This can include the client sending and receiving data, including files.
Stephen Hoffman
2017-02-24 00:06:16 UTC
Permalink
Raw Message
Post by David Froble
Now, I'm not typical, as all I do is R&D, but, I tend to store files on
the system(s) on which I'll be using them. So, if I do need a file
from another platform, copying it is the usual choice. No, I don't
serve files from dissimilar systems.
That certainly works at a small scale and clearly works for your
preferred style of project work and suchlike, but sharing files — SMB
or MSCP/SCS in a cluster — is handy when you want to have common files
across multiple systems. Either a single master (read only) copy, or
your (shared, read-write) working copy. Really handy for porting from
VAX to Alpha to Itanium to..., and handy for work across multiple
OpenVMS versions, or for various other permutations.

I've used shares for distributed software builds —
https://github.com/distcc/distcc or otherwise — where the local files
are exported as a share and all the build engines mount and churn away
on the code, too. Particularly outside of the OpenVMS environment, I
use a DVCS such as git or mercurial for distributed source code control
and access, and — other than for builds — probably not a share.

Shares are also handy for having big pools of storage available across
multiple computers; for NAS. MSCP/SCS services aren't available
outside of OpenVMS servers — and OpenVMS itself has no access to
MSCP/SCS outside a host-local or cluster configuration — with NAS
devices and other servers running SMB and NFS being far more prevalent
in the market.

There are also products which implement remote backups using file
shares; distributed archiving to a de-dup capable NAS device, etc.

But shares certainly don't solve all problems, any more than FTP or
sftp or a DVCS or anything else in this business would.
Post by David Froble
In the event that a production task needs such files, as appropriate, I
set up services and clients, such that a client can ask for some
service to be performed. This can include the client sending and
receiving data, including files.
That's where having a kitting and distribution procedure would be
handy. Whether based on RSS, or manual push or pull/poll, or
otherwise. See https://sparkle-project.org or https://brew.sh among
many examples, and with slightly different purposes. Linux has
multiple choices here of course, and as is usual. OpenVMS completely
and entirely lacks that whole concept, however. Which means we all
tend to end up reimplementing this stuff, usually bespoke. Sometimes
PCSI based, sometimes VMSINSTAL, sometimes using other mechanisms.
Sometimes by manual processing and FTP transfers. With gaps in
various of the app-specific OpenVMS implementations I've encountered;
omissions such as kit and binary digital signing. But that's also not
where I'd typically look to use a share, either. Or FTP.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-02-23 19:08:50 UTC
Permalink
Raw Message
Post by David Froble
I'm wondering what is so great about Samba?
I don't think anyone really likes Samba, but they need the
functionality it provides.

And it is definitely one of the more feature rich and widely
used products.

But I don't find it easy to configure.
Post by David Froble
I also wonder why anyone
would want to store weendoze files on a VMS system? Possibly there are
reasons, I've yet to become aware of them.
I got a real cheap weendoze system, a couple of disks mirrored, and
store all my weendoze stuff there. Works for me. Might not for others.
Mapping a drive from from a Windows PC to a VMS dircetory is simply
a very convenient way of moving files between the two systems.

Just like NFS mounting a disk is convenient for *nix
interoperability.

FTP is always a possibility but the mounted drive is more
convenient.

Arne
h***@gmx.de
2017-02-23 10:14:28 UTC
Permalink
Raw Message
I would like to update for one reason: I got a security advice from our "Intrusion prevention and Inventory service" to update to at least 3.5.10

The problem is the swat service (which I disabled!).
I told them it's a hoax. But they insist to update Cifs.

Here is the output of the service:

============= diagnosis =============
Two vulnerabilities exists in Samba:


1) The Samba Web Administration Tool (SWAT) allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests.


2) Input passed to the "user" field of the "Change password" page of SWAT is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

Affected Versions:-

Samba 3.0.x through 3.5.9.



Note:- The remote detection relies only on banner version and does not check for SWAT enabled/disabled. The SWAT feature is tested in authenticated detection, assuming that the swat binary is located in the /usr/sbin directory and has root privileges.

============= solution =============

Workaround

Ensure SWAT is turned off and configure Samba using an alternative method to edit the smb.conf file.


The vendor has released updates to resolve this issue. Update to Samba 3.5.10 to resolve the issue. Refer to Samba Release Notes 3.5.10 to obtain additional details.


Patch:

Following are links for downloading patches to fix the vulnerabilities:

Samba 3.5.10 (Samba 3.5.10)
Stephen Hoffman
2017-02-23 16:07:48 UTC
Permalink
Raw Message
Post by h***@gmx.de
I would like to update for one reason: I got a security advice from our
"Intrusion prevention and Inventory service" to update to at least
3.5.10
The problem is the swat service (which I disabled!).
I told them it's a hoax. But they insist to update Cifs.
You're left to remove it, or to firewall access to the servers, or —
unlikely — to convince HPE or VSI or somebody else to port an update or
an alternative for you, or to wade in and port it yourself.

Old versions of Samba have various (other) security vulnerabilities
too, and as I've previously linked.
--
Pure Personal Opinion | HoffmanLabs LLC
Snowshoe
2017-02-23 21:04:36 UTC
Permalink
Raw Message
Does anyone have any quick cookbook answers to installing a simple SAMBA
installation on VMS? All I want to do is to share files from a
directory (and subdirectories) on VMS to a PC and I can't even get that
to work. I'm sure I have some knob mistuned when trying to turn off all
that stuff I don't want, printers, multiple users, SWAT etc. but still...
Stephen Hoffman
2017-02-23 21:33:42 UTC
Permalink
Raw Message
Post by Snowshoe
Does anyone have any quick cookbook answers to installing a simple
SAMBA installation on VMS? All I want to do is to share files from a
directory (and subdirectories) on VMS to a PC and I can't even get that
to work. I'm sure I have some knob mistuned when trying to turn off all
that stuff I don't want, printers, multiple users, SWAT etc. but still...
My (few) posted notes on the CIFS Samba port are offline. My
experience with various of the CIFS Samba ports has been less than
entirely satisfactory. It mostly works, if everything is as exactly as
intended and expected. If not, then things do tend to tip over, and
errors can sometimes be interesting to troubleshoot. Some versions of
the Samba port have tools that tipped over with stackdumps if
privileges were missing, and the privilege requirements weren't listed
in the docs. The testparm tool tipped over if SYSLCK was missing was
one case I encountered, for instance.

It's sometimes necessary to have to rummage around to get the port to
work. But I largely gave up on the CIFS ports to OpenVMS back in 2009
and 2010, though there might be some fixes in the password-protected
download area.

Also look for a remote file system for your (presumably) Microsoft
Windows system that accesses OpenVMS via FTP or maybe WebDAV (via
Apache), if a file share is your general goal and not specifically an
SMB-based share. Maybe also look at FileZilla or CyberDuck or
suchlike.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2017-02-26 12:56:19 UTC
Permalink
Raw Message
<snip>
Post by Stephen Hoffman
My (few) posted notes on the CIFS Samba port are offline. My
experience with various of the CIFS Samba ports has been less than
entirely satisfactory. It mostly works, if everything is as exactly as
intended and expected. If not, then things do tend to tip over, and
errors can sometimes be interesting to troubleshoot. Some versions of
the Samba port have tools that tipped over with stackdumps if
privileges were missing, and the privilege requirements weren't listed
in the docs. The testparm tool tipped over if SYSLCK was missing was
one case I encountered, for instance.
It's sometimes necessary to have to rummage around to get the port to
work. But I largely gave up on the CIFS ports to OpenVMS back in 2009
and 2010, though there might be some fixes in the password-protected
download area.
Also look for a remote file system for your (presumably) Microsoft
Windows system that accesses OpenVMS via FTP or maybe WebDAV (via
Apache), if a file share is your general goal and not specifically an
SMB-based share. Maybe also look at FileZilla or CyberDuck or
suchlike.
--
Pure Personal Opinion | HoffmanLabs LLC
We use SAMBA and pretty well restrict our use of it for simplistic file transfer from windows clients to VMS

The users are not overly technology savvy so simplistic drag n drop type of operations is all that's needed. FTP based scripts are also used

WASD has a lot of support for WebDAV and I'd like to look further into it's use

SAMBA for us does from time to time present issues for which root causes often go wanting and you often feel like your taking increased risks as you experiments with more complex functions of SAMBA

In the past I was informed our workplace tried NFS but found SAMBA more reliable.
I've heard WebDAV is a notch up again in terms of windows to VMS interoperability over SAMBA (although this might be one of those religious debate topics) so I am keen to give it a go sometime
Stephen Hoffman
2017-02-27 16:37:58 UTC
Permalink
Raw Message
Post by IanD
FTP based scripts are also used
That'll fail an audit, unless it's FTPS or stunnel'd or otherwise VPN'd.
Post by IanD
In the past I was informed our workplace tried NFS but found SAMBA more reliable.
NFS on OpenVMS hasn't been the most robust implementation, though
recent versions do work and do have adequate NFSv3 support.
Post by IanD
I've heard WebDAV is a notch up again in terms of windows to VMS
interoperability over SAMBA (although this might be one of those
religious debate topics) so I am keen to give it a go sometime
WebDAV via HTTPS would be a step up from FTP, certainly. Much like the
choice of LPR/LPD or telnet printing in antiquity, use whatever works,
meets local requirements (clearly not particularly considering
security, in this case), use what works, what's available, and what's
affordable.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-02-27 17:44:54 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by IanD
FTP based scripts are also used
That'll fail an audit, unless it's FTPS or stunnel'd or otherwise VPN'd.
Post by IanD
In the past I was informed our workplace tried NFS but found SAMBA more reliable.
NFS on OpenVMS hasn't been the most robust implementation, though recent
versions do work and do have adequate NFSv3 support.
You keep saying this. I used NFS in production at the University when
I had VAXen and it always worked just fine.

bill

Stephen Hoffman
2017-02-24 00:11:03 UTC
Permalink
Raw Message
Post by David Froble
Now, I'm not typical, as all I do is R&D, but, I tend to store files on
the system(s) on which I'll be using them. So, if I do need a file
from another platform, copying it is the usual choice. No, I don't
serve files from dissimilar systems.
That certainly works at a small scale and clearly works for your
preferred style of project work and suchlike, but sharing files SMB
or MSCP/SCS in a cluster is handy when you want to have common files
across multiple systems. Either a single master (read only) copy, or
your (shared, read-write) working copy. Really handy for porting from
VAX to Alpha to Itanium to..., and handy for work across multiple
OpenVMS versions, or for various other permutations.

I've used shares for distributed software builds
https://github.com/distcc/distcc or otherwise where the local files
are exported as a share and all the build engines mount and churn away
on the code, too. Particularly outside of the OpenVMS environment, I
use a DVCS such as git or mercurial for distributed source code control
and access, and other than for builds probably not a share.

Shares are also handy for having big pools of storage available across
multiple computers; for NAS. MSCP/SCS services aren't available
outside of OpenVMS servers and OpenVMS itself has no access to
MSCP/SCS outside a host-local or cluster configuration with NAS
devices and other servers running SMB and NFS being far more prevalent
in the market.

There are also products which implement remote backups using file
shares; distributed archiving to a de-dup capable NAS device, etc.

But shares certainly don't solve all problems, any more than FTP or
sftp or a DVCS or anything else in this business would.
Post by David Froble
In the event that a production task needs such files, as appropriate, I
set up services and clients, such that a client can ask for some
service to be performed. This can include the client sending and
receiving data, including files.
That's where having a kitting and distribution procedure would be
handy. Whether based on RSS, or manual push or pull/poll, or
otherwise. See https://sparkle-project.org or https://brew.sh among
many examples, and with slightly different purposes. Linux has
multiple choices here of course, and as is usual. OpenVMS completely
and entirely lacks that whole concept, however. Which means we all
tend to end up reimplementing this stuff, usually bespoke. Sometimes
PCSI based, sometimes VMSINSTAL, sometimes using other mechanisms.
Sometimes by manual processing and FTP transfers. With gaps in
various of the app-specific OpenVMS implementations I've encountered;
omissions such as kit and binary digital signing. But that's also not
where I'd typically look to use a share, either. Or FTP.



--
Pure Personal Opinion | HoffmanLabs LLC




------------------------------------
Original headers:

Xref: b4gate.uuhec.net comp.os.vms:22195
From: Stephen Hoffman <***@hoffmanlabs.invalid>
Content-Transfer-Encoding: 8bit
Lines: 58
User-Agent: Unison/2.2
References: <48a248db-c1cd-4d28-b630-***@googlegroups.com> <o8lm9j$ivs$***@dont-email.me> <o8n126$jtm$***@dont-email.me> <o8nbqk$uhj$***@dont-email.me> <o8ne4n$80c$***@dont-email.me> <o8nn5b$9o4$***@dont-email.me>
Mime-Version: 1.0
Organization: HoffmanLabs LLC
Newsgroups: comp.os.vms
Date: Thu, 23 Feb 2017 19:06:16 -0500
Path: b4gate.uuhec.net!newsfeed.xs3.de!io.xs3.de!nntp-feed.chiark.greenend.org.uk!ewrotcd!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
Message-ID: <o8nta6$vf5$***@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Cancel-Lock: sha1:9KYc3xjddY9lpb4IqjDByhyKZvk=
Injection-Info: mx02.eternal-september.org; posting-host="daa9c538d5ae399c7b3bce3fe42aa1a8";
Subject: Re:SAMBA / CIFS for OpenVMS


-- Pyffle HQ -=- London, England -=- http://pyffle.com
Loading...