SAMBA V3 and beyond.
John E. Malmberg
wb8tyw at qsl.net
Thu Feb 17 14:57:37 GMT 2005
BERAMICE, Frantz wrote:
> 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
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
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
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.
wb8tyw at qsl.net
Personal Opinion Only
Please address all SAMBA-VMS related replies to this forum for public
More information about the samba-vms