[Samba] smbclient for SCO OpenServer 5.0.7

[Nico Kadel-Garcia]

On Wed, Sep 12, 2018 at 4:44 PM Kevin R. Bulgrien via samba
<samba at lists.samba.org> wrote:
>
> Looking back in the samba mailing list archives, I see not soancient requests
> for samba on ancient SCO OpenServer systems.
>
> Recently faced with a situation where a Windows Server upgrade to 2012 R2 and
> broke an smbclient upload from a SCO OpenServer 5.0.7 system.  Directory
> listings and file deletions did not fail, but all upload attempts produced
> empty files on the Windows server (this due, undoubtedly to default
> disablement of the SMB1 protocol in Windows Server 2012 R2).
>
> The last version of samba issued for that platform by SCO for 5.0.8 was
> 3.0.20a - far older than samba 3.6.0 where SMB2 was implemented.

Is there any way you can simply use NFS, even if it is from a shared
staging server that a Windows server also writes to? OpenServer is old
enough and was unmaintained for long enough before the demise of the
company that anything at the kernel and filesystem level, such as
smbclient, can be difficulty to upgrade. In fact this was what I said
in 2007, the last time I encountered very similar problems with SCO
OpenServer 5.0.7. I dropped an intermediate Linux staging server in
place that could serve the same filesystem via both NFS and CIFS.

> The port largely involved resolving type mismatches related to inconsistent
> use of uint32 and uint32_t in different parts of the source tree.  In some
> cases, the problem was as simple as prototypes not matching the actual
> type declarations.
>
> An edit one line of the configure script to disable a fatal error relating to
> a "required" syslog function dependency (as no way to disable the dependency
> was found to worked on this platform - though there may be some question as
> to whether the correct way to do so was found).
>
> It also seemed necessary to supply various gcc -D arguments as ./configure did
> not appropriately detect some capabilities of the platform and resulted in
> various `make` fatal errors.  My autotool knowledge is very sparse and it is
> openly acknowledged that there is a much better way to have resolved these
> issues.

My knowledge of those tools is... fairly deep, and after having to rip
out the hand-built and "patch bad code by tuning the compiler"
optimized version of gcc, my efforts 10 years ago got  much further. I
think I eventually got CIFS working.

> Resolving link failures was a bit more involved.  An S_ISSOCK() macro was not
> supplied by system /usr/include files, but this was able to be worked around
> with a minor edit.
>
> There was also an issue that /usr/include files did not document provided
> strtoll or strtoull functions though it both showed up in a strings search of
> libc and libstdc++ shared objects in /usr/lib.  For purposes of compiling
> only smbclient, though, it appeared that maybe only strtoull was required.
> lib/replace/replace.c did not suffice with respect to providing workarounds.
> I resorted to importing strtoull from gnulib to resolve the issue.
>
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> It should be noted, that I made no attempt to resolve build issues not related
> to those encountered when running `make bin/smbclient` in the source3 tree.
>
> I am certainly willing to attempt to share patches and the procedure followed
> if there are suggestions on a reasonable venue-maybe a VCS branch somewhere.
> I know that the official stance toward this platform is one of non-support,
> and, this is an incomplete port, but, in the interest of helping people
> that find themselves in a pinch, it doesn't seem worth letting salty
> attitudes dissuade sharing.  Thoughts?

The main one is "spend your time elsewhere", on code that is better
suited to an upgrade and not likely to remain an internal monkey
patch. That's partly why I wonder if you can switch the file access
protocol to NFS.