SAMBA V3 and beyond.

[John E. Malmberg]

BERAMICE, Frantz wrote:
> Hello,
> 
> Do you know if samba v3 for VMS is in the pipe ?

I know of some people looking at it.  I am personally more interested in 
looking at SAMBA V4.

Work on SAMBA V2 for UNIX except for security bug fix releases 
essentially stopped well over a year ago, and probably over 2 years ago.

With SAMBA V2.2.12, the SAMBA team has announced that it is the last of 
the "Emergency" patches to the V2 stream, which makes it the proper 
landing spot for systems that are currently unable to move to V3 or beyond.

The only real difference would be a few more LANMAN subprotocols would 
be supported.

Most of the new features that are available in SAMBA V3 are based on 
features that are conditionally compiled out of the SAMBA V2 port. 
There are not many differences in structure, so in theory, you could 
just take the current OpenVMS specific code and merge it with the SAMBA 
V3 code base, and it would likely work about the same as what SAMBA V2 
does now.

Work on SAMBA V3 for UNIX is now winding down, and plans are for it to 
be effectively frozen as soon as SAMBA V4 is viable.

Essentially starting work on a production quality and full featured V3 
port for OpenVMS needed to have started over two years ago in order for 
it to have any functionality better than what you have now with V2.

The main purpose of doing a V3 port attempt is to identify the 
UNIX/LINUX APIs that are not currently present on OpenVMS and need to 
be, and to look at changing the way the current OpenVMS specific hacks 
are done to be done the way that is defined in the existing architecture 
for LINUX/UNIX extensions.  This work is also required for V4, but would 
likely be significantly longer before they could be tested on V4.

If you do not need a production quality server in a hurry, and need to 
learn how it all fits together, starting with V3 as a learning 
experience is the way to go.

And there is no reason that the same things can not be done with the V2 
port to activate most of the same functionality, which would directly 
carry over to V3 and V4.

The issue right now is that the main SAMBA team is not interested in 
patches to SAMBA V2 at all and has mainly only been interested in 
emergency security patches for at least the last year, and there may 
only be a year or so left that they will be able to be convinced to 
accept changes to V3 that would make the UNIX code work better on OpenVMS.

SAMBA V4 is a new design that has not yet been fully finalized, so it 
may be possible to find ways to make it fit better with an operating 
system that does not fork(), and there are more of them interested in 
using SAMBA than just OpenVMS.

One of the issue on how to proceed is how to coordinate the efforts of 
all the volunteers and potential commercially supported programmers into
one effort.

I have not even been able to convince Jean-Yves to move to 2.2.12 as
the final landing point for the V2 stream, and I have not had time to
merge his changes into the 2.2.12 kit that I have previously posted
a link to.

It appears so far that SAMBA V4 may require at the minimum GNV and some 
flavor of Perl in order to build it.

-John
wb8tyw at qsl.net
Personal Opinion Only

-- 
Please address all SAMBA-VMS related replies to this forum for public 
discussion.