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? -- Kevin R. Bulgrien
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.
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)?
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.
> > 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'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 !To provide some closure for this thread, a github fork of the samba project now exists that can be used to reproduce building smbclient on the SCO OpenServer 5.0.7 platform: https://github.com/kbulgrien/smbclient-3.6.26-sco3.2v5.0.7 I think this may be better than making a patch (for various reasons). The fork has smbclient in its name so it is more clear it is not meant for compiling anything other than smbclient even though it is a fork of the whole project. The fork is set to default to the v3-6-stable branch, and my changes were committed there. A document was added to describe the project, clearly detail my changes as licensed under the same one the samba project uses - and documents license compatibility of third-party sources I drew from. It also describes the build system configuration and details how to reproduce the build: https://github.com/kbulgrien/smbclient-3.6.26-sco3.2v5.0.7/blob/v3-6-stable/README.sco3.2v5.0.7 Cheers... -- Kevin R. Bulgrien