CVS tag for lates samba 3.0 series

John E. Malmberg wb8tyw at qsl.net
Fri Apr 28 22:35:07 GMT 2006


Jeremy Allison wrote:
> On Tue, Apr 25, 2006 at 04:06:41PM +0530, Dhruva Krishnamurthy wrote:
> 
>>Hello,
>> I would like to see if there are any major changes in the latest
>>sources in CVS repository in 3.0 series with respect to
>>samba-3.0.23pre. We are planning to merge some of the code changes we
>>have made to port it on OpenVMS. We had started merging with 3.0.22
>>and I found significant changes between 3.0.22 .vs. samba-3.0.23pre.
>>Hence, I would like to know if there are big changes in latest 3.0 CVS
>> wrt samba-3.0.23pre1.
>> What CVS tag should I use to access the latest HEAD in 3.0 series?
> 
> There were major changes (100,000 lines of code change) between
> 3.0.22 and 3.0.23preXX. Currently the 3.0.23 and SVN code trees
> are in sync. I suggest you check out SAMBA_3_0 and base
> changes on that.

I have sent DK instructions on how to use rsync on Linux to maintain a 
local copy of SAMBA_3_0 and SAMBA 4 on an OpenVMS system.

> What areas of the code have you changed for OpenVMS ? How
> invasive are they ?

I can not comment about the specifics as I have mainly been looking at 
what it takes to get SAMBA V4 to build on OpenVMS.

But here is a summary of the issues that I have seen for V2/V3 of Samba, 
not in any specific order:

   1. No fork()

   2. Need to use special hand off socket from inetd equivalent which
      launches smbd because of no fork().

   3. SMBD when launched this way re-inits the TDB files out from
      under the other SMBD processes.

   4. Pid files should not be used on OpenVMS because of different
      process model.  This just interferes with debugging.

   5. fcntl() locking is not available at this time.

   6. fstat() or stat() does not report current file size unless fsync()
      is called to flush the output to disk.  Richard Sharp found out
      why that is important to the SMB protocol.

   7. Samba Panic handler needs to be disabled because it prevents the
      OpenVMS Panic handler from giving an accurate or even meaningful
      error report.
      This may affect other platforms in the same way.

   8. select() will only work on socket numbers, not file descriptors.

   9. stat() is high overhead call as it actually touches the disk.

   10. setegid()/setgid() not meaningful on OpenVMS.

   11. smbclient claims "Control-D" is keyboard EOF instead of looking
       it up in term_info API.  OpenVMS does not have the term_info API
       either, but that can be faked with a macro.  OpenVMS uses
       Control-Z for keyboard EOF.  So technically this is a UNIX bug,
       as the keyboard EOF may be set to a different character.

   12. Test for running with setuid bit set fail on OpenVMS.

   13. Behavior of open file access after setuid() call is different.

   14. OpenVMS text files are not usually byte streams, yet they are
       a common type of file that a Samba client expects to read or
       update.

For a few of these, there are methods of hiding the differences with out 
making changes to the source code.

Disabling the panic handler like #if HAVE_OS_PANIC_HANDLER requires a 
change in the source.  So will changing the "Control-D" text.

I have been distracted from working directly on Samba V4 because it 
required a newer port of GTK+ than what was currently available, and 
that required a bunch of other stuff.

On SAMBA V4, I have found a number of issues with Configure that I have 
already posted about.

The only one that I do not yet have a work around for is that Configure 
is specifically testing for an readdir() behavior that X/Open 
specifically says that programs should not expect, and even passing that 
  configure test is not proof that the readdir() always will work that 
way given sufficient directory sizes or file activity an update to 
Linux, or a different filesystem than was tested for the build.  OpenVMS 
can not pass that test, and can not easily implement emulation of the 
fall back.

-John
wb8tyw at qsl.net
Personal Opinion Only



More information about the samba-technical mailing list