libeay32.dll installed with 2015.8.0 gives an error: "not designed to run on Windows or has error"

[DennisHarper]

Not sure exactly why this is occuring, however when I install the Win32OpenSSL-1_0_1j.exe, and copy the installed binaries into C:\Python27, then it works.

I tried to open the dll with DUMPBIN, to see if the HEADERs could give me any indication as to what was going on ( 32bit vs 64bit... I am running 32bit ), I got this error message: LINK : warning LNK4094: 'libeay32.dll' is an MS-DOS executable;

I can only assume that the file that you are including in the install is corrupted or wrong.

[twangboy]

@DennisHarper What version of windows are you running?

[DennisHarper]

@twangboy

OS Name: Microsoft Windows Web Server 2008 R2
OS Version: 6.1.7601 Service Pack 1 Build 7601
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
System Type: x64-based PC

[twangboy]

@DennisHarper Just to be clear, this is 32bit Windows 2008 R2?

[twangboy]

@DennisHarper When are you getting the error? On minion start? When you run a command? Which command?

[DennisHarper]

The OS is 64bit, however I am running 32bit python. This error occurs either when I start the minion, or even when I run a 'salt-call test.ping'.

[twangboy]

@DennisHarper The libeay32.dll and ssleay32.dll bundled in the 32bit install are compiled for 32bit windows. You'll need to install the 64bit version of Salt. Is there a reason you need to run 32bit salt?

[DennisHarper]

What I did:

1. Had a previous version installed.
2. Downloaded the tarball from: https://pypi.python.org/packages/source/s/salt/salt-2015.8.0.tar.gz
   3 Ran pip install salt-2015.8.0.tar.gz
3. Noticed that the minion did start.

My requirements are currently to have salt work with the 32bit version of Python. I am not sure what else I can say about that.... those are the the requirements.

[DennisHarper]

Just to be clear, the installer is making an assumption about the machine's architecture based on the version of salt that is being installed, is that correct?

[twangboy]

@DennisHarper I've never tried getting 32bit salt running on 64bit windows. But these are the packages that will need to be 64 bit:

• PSUtil
• PyCrypto
• PyWin32
• PyZMQ

Then you'll have to get the two SSL .dlls.

All these files can be found at:
https://repo.saltstack.com/windows/dependencies/

In the mean time, I will talk to the powers that be about the need to support 32bit salt on 64 bit windows.

Let me know if you're able to get this working.

[twangboy]

@DennisHarper Another thing you might consider is using our 64bit installer which installs a portable python that won't interfere with an existing installation of python. It puts python and all it's dependencies in the C:\salt\bin directory. Then you can use your local 32bit python for whatever else you're doing.

[twangboy]

https://repo.saltstack.com/windows/Salt-Minion-2015.8.0-3-AMD64-Setup.exe

[DennisHarper]

@twangboy:
Thanks for the recommendations... Unfortunately, the frozen install will not work for my requirements . However, I think that I might have figured out the root problem, just need to confirm one more thing.... stay tuned

[DennisHarper]

So the root problem of this whole thing seems to be that binary is not compiled correctly. I have not been able to pin down exactly why, but it seems that the executable type is not compatable with 64 bit systems.

It seems that the fix should be very straight forward... put a verions of the binaries are a format that are compatable with 64 bit systems.

I will continue to see why that assembly is not working on 64 bit systems, but this might be one of those windows problems you just kind of frustration box, and ultimately give up trying to figure out why.

[DennisHarper]

So, I found a place where they are compiled correctly: https://indy.fulgan.com/SSL/

This site is recomended by openssl.org: https://www.openssl.org/community/binaries.html

I tested the openssl-1.0.2d-i386-win32.zip download, and it worked perfectly.

[DennisHarper]

So, the root problem is simple... the binary that you guys are using is a 16bit binary, which does not work with 64bit systems.

To see for your self, there is a nice powershell script which will tell you the binary type, located here:
https://gallery.technet.microsoft.com/scriptcenter/Identify-16-bit-32-bit-and-522eae75

Furthermore, the assemblies that you all included have no verison information, therefore there is no way to determine which version of the OpenSSL protocol is being used. This obviously can be a major security concern, not only for salt, but any other python app that is being run, given you put this binary in the base python directory.

Lastly, I would recommend a less invasive approach to compiled 3rd party binaries. First, I would not put them in the base python27 folder. By doing this, any other python application that uses OpenSSL will use your supplied version. Perhaps, placing them in the c:\salt directory, then when salt comes up, appending to the window's PATH within the salt session. This would allow people to make the decision to run your supplied binaries, or any other version.... all they have to do is to have their version is in the path before salt starts up, and the os will search their path before salt's.

[twangboy]

@DennisHarper The two dll files we use are pulled from the site you mentioned above. (https://indy.fulgan.com/SSL/)
Maybe there's something with the way setup.py is pulling them down.

[DennisHarper]

Which version did you guys use? I will look at that one this weekend.

[DennisHarper]

I downloaded directly the version that you have here: https://repo.saltstack.com/windows/dependencies/32/
and it is 32bit.

However, when I just take out the class DownloadWindowsDlls in setup.py, it points to that location, but windows thinks it is 16bit... more to come

[DennisHarper]

So, there are an extra 3 kb when requests is used to download the libeay32.dll as compared to downloading it with chrome or urllib2. I have not been able to figure out why, however I am going to submit a pull request to use urllib2 to download this file instead of requests.

[twangboy]

@DennisHarper @s0undt3ch There's also an issue with setup.py that tries to detect the version of ssl binaries that need to be downloaded. It detects the version of python installed, not the architecture of the OS. So, in your case, you need the 64 bit binaries but because you're running 32bit python, you're getting the 32bit version.
The exact code it's using is platform_bits, _ = platform.architecture(). Instead it needs to use platform.machine.
I'm also seeing the problem with the OpenSSL dlls actually downloading when I run python setup.py install. It gets hung up on downloading each dll.
This is working off the head of 2015.5.

[DennisHarper]

@twangboy: I actually need the 32bit versions. The version installed should match the version of the Python being run. So, you guys are doing the correct thing there. It seems as if the problem is stemming from setup.py (class DownloadWindowsDlls), is not downloading the files correctly, and basically corrupting them. if you do not try to download them in 'chunks' it works just fine. I am looking at perhaps the file.write method possibly encoding the file in such a way that the os is getting confused.

[twangboy]

#27422