-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libeay32.dll installed with 2015.8.0 gives an error: "not designed to run on Windows or has error" #27373
Comments
@DennisHarper What version of windows are you running? |
OS Name: Microsoft Windows Web Server 2008 R2 |
@DennisHarper Just to be clear, this is 32bit Windows 2008 R2? |
@DennisHarper When are you getting the error? On minion start? When you run a command? Which command? |
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'. |
@DennisHarper The |
What I did:
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. |
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? |
@DennisHarper I've never tried getting 32bit salt running on 64bit windows. But these are the packages that will need to be 64 bit:
Then you'll have to get the two SSL .dlls. All these files can be found at: 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. |
@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 |
@twangboy: |
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. |
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. |
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: 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. |
@DennisHarper The two dll files we use are pulled from the site you mentioned above. (https://indy.fulgan.com/SSL/) |
Which version did you guys use? I will look at that one this weekend. |
I downloaded directly the version that you have here: https://repo.saltstack.com/windows/dependencies/32/ 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 |
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. |
@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. |
@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. |
Setup::DownloadWindowsDlls is downloading and writing the file as a text not a binary file. When creating the file handle to write the binary after being download from salt's dependency repo, the file handle was being created with just the 'write' attribute, however it also needs the 'binary' attribute. Change-Id: I037136b1b5975e53452b49b3d6b4a30a43dd55c6
Setup::DownloadWindowsDlls is downloading and writing the file as a text not a binary file. When creating the file handle to write the binary after being download from salt's dependency repo, the file handle was being created with just the 'write' attribute, however it also needs the 'binary' attribute. Change-Id: I2f67d27ee847cd7808a78cd5ec0b2151d6a0c0e7
Setup::DownloadWindowsDlls is downloading and writing the file as a text not a binary file. When creating the file handle to write the binary after being download from salt's dependency repo, the file handle was being created with just the 'write' attribute, however it also needs the 'binary' attribute. Change-Id: I2f67d27ee847cd7808a78cd5ec0b2151d6a0c0e7
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.
The text was updated successfully, but these errors were encountered: