[Samba] smbclient for SCO OpenServer 5.0.7

[Gaiseric Vandal]

On 09/12/18 16:56, Jeremy Allison via samba wrote:
> On Wed, Sep 12, 2018 at 03:27:37PM -0500, Kevin R. Bulgrien via samba 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.
>>
>> In any event, over the past few days, an attempt has been made to tackle
>> resolution of this problem.  Here is notice that the non-trivial effort
>> succeeded at building smbclient 3.6.25 for SCO OpenServer 5.0.7.
>>
>> Though uninterested in discussing the use of SCO or OpenServer 5.0.7 and all
>> the swirling negativity regarding ancient systems or unfriendly vendors, but
>> feel it might be of some unfortunate interest to some in the community.  It
>> seems in the spirit of FOSS to pass the word along to others.
>>
>> Though the port/patch is likely less than optimal, a test today did result a
>> statically linked smbclient executable that successfully transfer files and
>> generally interacts with a Windows Server 2012 R2 from SCO OpenServer 5.0.7
>> without enable of the SMB1 protocol.  It was not necessary to uninstall the
>> native Samba package.
>>
>> $ uname -srvm
>> SCO_SV 3.2 5.0.7 i386
>> $ ./samba-3.6.25/source3/bin/smbclient --version
>> Version 3.6.25
>> $ gcc --version
>> 2.95.3
>>
>> 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.
>>
>> 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?
> I'm always interested in seeing Samba get built for old/exotic
> architechures and platforms - however 3.6.x is *way* out of
> support, so there's no chance this patch could get merged.
>
> If you want to make it useful for others, you could always log
> a bug (which you or we will mark as WONTFIX due to the age of
> the code) and then upload your patch file as an attachment.
>
> At lease then we have a record of your achievement that you
> can point people having similar issues at !
>
> Cheers,
>
> 	Jeremy.
>

Can you compile a newer version of gcc and gmake , then use that to 
build samba 3.6.x ?    Although wondering if it may be safer to build 
samba 4.x.      The various patches for the BADLOCK vulnerability a few 
years ago made it really clear that samba 3.x was no longer feasible.



Are regular users logging into the sco machine ?

If samba 3.6.x or 4.x refuses to compile, could you use sftp as an 
alternative (e.g. with filezilla server on the windows server)?