[Info-vax] Pathworks or one of its descendants on x86

[already5chosen at yahoo.com]

On Thursday, February 22, 2018 at 5:50:04 AM UTC+2, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> > Stephen Hoffman via Info-vax
> > Sent: February 21, 2018 2:17 PM
> > To: info-vax at rbnsn.com
> > Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> > Subject: Re: [Info-vax] Pathworks or one of its descendants on x86
> > 
> > On 2018-02-20 12:37:47 +0000, Kerry Main said:
> > > For something like Samba, the native file system and TCPIP stack are
> > > critical components of the overall solution.
> > 
> > Um, can anybody name a modern general-purpose operating system
> > that
> > doesn't have both a file system and an IP network stack?  Even
> > embedded
> > operating systems all have both a file system and IP networking, though
> > some might allow subsetting.
> > 
> > > Lets not forget that an entirely new, more modern TCPIP stack and file
> > > system will also be part of the upcoming OpenVMS X86-64 equation, so
> > > comparing OpenVMS Samba X86-64 performance to the past is not
> > likely
> > > much of a comparison.
> > >
> > > New OpenVMS file system notes:
> > > <http://www.hp-
> > connect.se/SIG/New_File_System_VMS_Boot%20Camp_2016.pdf>
> > 
> > We'll see what the IP stack and file system performance will be when it
> > all arrives.   If I'm worried and in a hurry for better performance,
> > I'll toss an SSD underneath it all.  Yeah, that'd require VAFS for one
> > of those newfangled 30 TB SSDs due to the capacity limits inherent in
> > ODS-5.
> > 
> > > As someone else stated, PathWorks is NT4 technology, so hardly worth
> > > looking at for the future. That's the equivalent of looking at 386 or
> > > 486 PC technology for hardware deployment.
> > 
> > PATHWORKS Server was deprecated an aeon or three ago, and it's very
> > insecure.  It was replaced with Advanced Server.   Which is insecure.
> > The OpenVMS Samba port is the replacement for the Advanced Server
> > package, though the available Samba port for OpenVMS is an old port of
> > Samba and is itself also very insecure.
> > 
> > All three of these are SMB / SMB1 / SMB 1.0 / CIFS-era packages,
> > insecure, and none of these will pass a typical security audit, and
> > newer systems will have to be reconfigured and security downgraded to
> > allow connections into an SMB1 era server.
> > 
> > The Microsoft business manager for SMB (Ned Pyle) very strongly
> > recommends against the continued use of any SMB 1.0 / CIFS-era clients
> > or servers.
> > 
> > Current Samba is far more secure and SMB 3.1.1 (current) and with its
> > own Active Directory (AD) implementation now available, though Samba
> > switched from GPLv2 to GPLv3, and which usually which constrains its
> > incorporation into the base system of a closed-source operating system.
> >  There are alternative SMB stacks available from third-party providers.
> > 
> > The production release of OpenVMS for x86-64 isn't due out until ~2020,
> > based on the current VSI roadmap.    I expect we'll learn more about
> > this area and about the particular version(s) involved in any
> > open-source ports, and more about many other areas over the next year
> > or two.  This as VSI gets away from the base system and more cycles
> > with the layered products and open source packages, and gets some
> > time
> > to test the performance of the various changes to OpenVMS,
> > networking,
> > and the layered products.
> > 
> > As a potential workaround for a requirement for a file share that's
> > compatible with other operating system platforms, WebDAV might get
> > you
> > where you want, and Apache on OpenVMS does offer that capability.
> > NFS
> > is another option, as well.
> > 
> > Related:
> > https://en.wikipedia.org/wiki/Server_Message_Block
> > https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-
> > a9b235c58ed4
> > https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-
> > smb1/
> > 
> 
> All this discussion about file servers may be somewhat mute for any traditional OS platform as many med-large customers are now deploying appliance CIFS/NFS solutions.
> 
> 😊
> 
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

The point is not so much a file server as an ability to share files between VMS and Windows in the convenient and safe manner. Whether files themselves reside on VMS, Windows, "visible" Linux or "invisible" Linux (i.e. file server appliance) is of secondary importance. In ether case, VMS side needs to speak in modern variant SMB protocol and be able to authenticate vs one or another directory service. All that in the manner configurable and controlled by VMS admin, but maximally transparent to VMS user and to user's applications. From user perspective shared files should be as similar as possible to "native" VMS files.
And I don't agree that performance does not matter. It only does not matter to a degree. When talking to appliance, it's probably o.k. to do it 2-3 times slower than other clients, but not 20-30 times slower.