Sometimes it responds like a charm, but sometimes I got the error "No data received". I searched around but nothing worked. The posts which are suggesting the use of "gdb" to debug the apache for possible errors, well, I do not have the chance to test it with gdb, because in the server I'm working on, there's not any development softwares or libraries (except python), and I cannot install them. And the other half of the posts suggest the solutions which are compatible with webservers working with PHP - I don't know whether it makes any difference to the problem or not.
My httpd configuration is like this:
Apache/2.2.11 (Unix) DAV/2
mod_ssl/2.2.11 OpenSSL/0.9.8b
mod_jk/1.2.15
PHP/5.1.6
mod_wsgi/2.1-BRANCH
Python/2.4.3 configured
I use Django, and hence mod_wsgi. Is there any other way for debugging this issue rather than using gdb?
Note that, in the previous versions of my application, I didn't get any error like this, never. For the newer versions, I didn't change the technology, just upgraded Django to 1.3, started using ZSI 2.1 on CentOS5.
Thanks in advance.
As Graham-Dumpleton commented above, it seems to be a well known issue in mod_wsgi, namely with the expat library version compatibility.
The reason for the failure (as well as the steps to solve it) are described here
tl;dr solution (from the link above):
Note that this only applies to Python versions prior to Python 2.5.
From Python 2.5 onwards, the copy of the "expat" library bundled in
with Python is name space prefixed, thereby avoid name clashes with an
"expat" library which has previously been loaded.
Related
Sorry for answering my own question, but I've seen this crop up in multiple forums, so I wanted to post this in hope it helps someone else.
The basic problem occurs when trying to run Ansible against older Python interpreters -- particularly Python 2.6 on RedHat 5 -- and getting error messages about 'libselinux bindings not available' or similar errors.
While this could happen for any Python-based application, I see it most commonly on Ansible. Ansible presumes the selinux module is available and will always attempt to import it at runtime.
The libselinux-python bindings are not a simple python module. The module must be cross-compiled against both the target version of Python and the target version of libselinux. The nice folks maintaining the RedHat 5 EPEL repositories did not generate a Python 2.6/libselinux 1.33 module.
The 'existing' libselinux-python module from the standard repos will not work, because it is specific to the supplied Python 2.4 interpreter. If you copied the module from a different Python 2.6 install -- say, a RedHat 6 system -- that won't work either, because it's built against the wrong version of libselinux. While you can amuse yourself with the various errors created by different combinations, Ansible won't bother to distinguish between them; it will just state that the bindings are unavailable.
The solution is to create a 'stub' selinux python module to pacify Ansible. Create a file
/usr/lib64/python2.6/site-packages/selinux/__init__.py
with the following contents:
def is_selinux_enabled():
return False
def is_selinux_mls_enabled():
return False
(This is Python code, so mind the indents.) This effectively disables Ansible from working with selinux. Also, tasks running against these systems should not include any selinux attributes, such as setype or seuser. (Honestly, I haven't tested it fully.) But basic modules like lineinfile or command now work properly.
This does not required disabling selinux; it only prevents Ansible from manipulating selinux attributes. If necessary, you can always use the one of the command modules to script around it.
I would have liked to post this as a comment to the #crankyeldergod's answer (as his response lead me to figure out my fix to this issues) but I don't have enough posts to comment yet.
I also kept receiving the "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!" error despite having the libselinux-python packages installed. I went into /usr/lib64 and checked the python directories I found there until I located the one with selinux files present. I made note of that version of python and declared it explicitly in my inventory file, ie - ansible_python_interpreter=/usr/bin/python3.6 in my case and that resolved the issue.
I would like the most advanced version of Python that still works on Windows XP. I need both Python 2 and Python 3.
What versions of Python will work on Windows XP?
I found that Python 2.7.9 and Python 3.4.4 are the newest versions of Python that work in Windows XP. I found this out through trial and error.
I've found a desperate guy (Daniel Pistelli) who didn't give up at the windows error dialog:
https://ntcore.com/?p=458
I like how he approaches the topic:
If we try to start any new application on XP, we’ll get an error
message informing us that it is not a valid Win32 application. This
happens because of some fields in the Optional Header of the Portable
Executable.
[...]
Fortunately, it’s enough to adjust the fields in the executable we want to start (python.exe), there’s no need to adjust the DLLs as well. If we try run the application now, we’ll get an error message due to a missing API in kernel32. So let’s turn our attention to the imports.
And then he goes on for another 5-6 screens. To sum it up, apparently you'll have to:
Modify the python.exe header,
Run a tiny Python script to remap some DLL calls,
Recalculate some binary hashes,
Create a fake kernel32.dll with certain calls forwarded,
Modify python37.dll to point to this fake thing,
and then you're all set. To be honest I couldn't quite follow (let alone verify!) some of the steps but it looks legit and there are links with Daniel's half-baked solutions for the harder parts, also a lot of Python sources explained. I will definitely give this thing a try.
In fact, here are the final scripts from his GitHub page:
https://github.com/dpistelli/xptmrt
Moral of the story: you can be crazy, but you'll never be dismantle-all-dlls-and-exes-and-open-hexeditors-and-disassemble-hashing-algorithms-and-mock-it-all-together-so-it-works-under-xp-crazy!
Someone had built Python 3.4.10, which is slightly newer than the officially prescribed Python3 v3.4.3/3.4.4 for Windows XP. Since it comes from the third-party (not the official Python website), use at your own risk,
-->Download<--
i tried 3.3.3 but i came up with an error message use 3.4.3/2.7.9 they are the only versions that work now sadly
There are several custom builds of Python >3.44 suitable for Windows XP. A poster at reddit has provided Python 3.55 here:
https://www.reddit.com/r/Python/comments/3tgi0t/python_35_x86_on_windows_xp/
Here is an XP compatible build of 3.6.15 source code only:
https://alex-free.github.io/winxp_python3.6.15/
At the MSFN forums someone has provided an XP compatible build of 3.8.1350 here:
https://msfn.org/board/topic/183741-python-3813-for-windows-xp-sp3/
Official website says about 3.4.10: https://www.python.org/downloads/release/python-3410/
Any of them, python is very platform independent. Some features might not work, but that would best be found in the documentation.
Installing python 3.4 from python.org is a breeze - it downloads a .msi file and next thing I know, I have python installed on my C drive. However, I want to install python 3.3 since I want to use PyScripter and from what I understand, PyScripter does not work with python 3.4.
I went to this page: https://www.python.org/downloads/release/python-336/ and I only have an option to download a "tarball". From what I understand of the readme files, I need to build python from here, which I have never done (and it does not seem that straightforward)..
There is msi installer for python 3.3.5 though: https://www.python.org/downloads/release/python-335/
Python.org states that 3.3.6 is only a security update to 3.3.5 - so if possible it would be nice to install 3.3.6
How can I most easily install 3.3.6? If there is no easy way is there really any concern with 3.3.5?
When 3.4.0 was released, the normal maintainance of 3.3.x ceased. This is standard policy. However, source only security fixes will be made until 5 years after 3.3.0 (also standard policy). The 'security' fixes are aimed at servers running on Python, and accepting input from random people on the net. People running such servers generally compile their own binaries, and usually run on linux, etc, rather than windows. You should be fine for your purposes with the last Windows installer.
PS. comment 25 on this forum claims to have PyScriptor running on 3.4.
If you read the page you linked, as Pierre mentioned it states
This is a security-fix source-only release
As far as I can tell that means that the only changes are to python source files. Meaning there will be no benefit to having an actual installer since the only changes are in .py (probably) files.
It also states:
The list of fixed security related issues can be found in the NEWS file.
If you're too lazy to click that link, here's the relevant portion:
Core and Builtins
-----------------
- Issue #22518: Fixed integer overflow issues in "backslashreplace",
"xmlcharrefreplace", and "surrogatepass" error handlers.
- Issue #22520: Fix overflow checking when generating the repr of a unicode
object.
- Issue #22519: Fix overflow checking in PyBytes_Repr.
- Issue #22518: Fix integer overflow issues in latin-1 encoding.
Library
-------
- Issue #22517: When a io.BufferedRWPair object is deallocated, clear its
weakrefs.
- Issue #22419: Limit the length of incoming HTTP request in wsgiref server to
65536 bytes and send a 414 error code for higher lengths. Patch contributed
by Devin Cook.
- Lax cookie parsing in http.cookies could be a security issue when combined
with non-standard cookie handling in some Web browsers. Reported by
Sergey Bobrov.
- Issue #21766: Prevent a security hole in CGIHTTPServer by URL unquoting paths
before checking for a CGI script at that path.
- Fix arbitrary memory access in JSONDecoder.raw_decode with a negative second
parameter. Bug reported by Guido Vranken.
- Issue #20633: Replace relative import by absolute import.
- Issue #21082: In os.makedirs, do not set the process-wide umask. Note this
changes behavior of makedirs when exist_ok=True.
- Issue #20875: Prevent possible gzip "'read' is not defined" NameError.
Patch by Claudiu Popa.
- Issue #11599: When an external command (e.g. compiler) fails, distutils now
prints out the whole command line (instead of just the command name) if the
environment variable DISTUTILS_DEBUG is set.
- Issue #4931: distutils should not produce unhelpful "error: None" messages
anymore. distutils.util.grok_environment_error is kept but doc-deprecated.
- Issue #20283: RE pattern methods now accept the string keyword parameters
as documented. The pattern and source keyword parameters are left as
deprecated aliases.
- Issue #21323: Fix http.server to again handle scripts in CGI subdirectories,
broken by the fix for security issue #19435. Patch by Zach Byrne.
Tests
-----
- Issue #17752: Fix distutils tests when run from the installed location.
- Issue #20946: Correct alignment assumptions of some ctypes tests.
- Issue #20939: Fix test_geturl failure in test_urllibnet due to
new redirect of http://www.python.org/ to https://www.python.org.
You'll have to decide for yourself - do you care about those issues? If so, you should be able to just extract the tarball and copy over the python source - probably just merge the lib directories. If you're really conscientious you'd run a diff on the appropriate directories to identify the files and their actual changes.
I (thankfully) never ran into this before, and (sadly) just did.
My app now imports 2 packages, which each import the requests library. The two authors have pegged the version of requests to different versions. One wants 2.1.0 , the other wants 2.3.0.
Automated tests appear to pass on both. My app appears to function perfectly on both.
My app won't start, however, because of the requirements. From what I can understand on my development environment, it's because of the version number being pegged in a requirements.txt file. [ In dev we have PasteDeploy + Waitress, an exception is raised in PasteDeploy; in production we have uwsgi ]
The only ways I can think of handling this, is to:
fork the projects
change the system to not use zipped eggs, and run a patch.
both are going to be a hassle to maintain, and add a lot of complexity to the build/deploy process.
does anyone have other suggestions?
You have a couple of options these are the only ones I can think of:
fork (sorry but this may be the easiest/ quickest),
wait for a new version for the older package, or
change it to not use zipped eggs (I don't really understand this though).
[EDIT] could you potentially trick one into thinking that it is using its version. I don't know the specifics, but from my understanding you could use a virtual machine.
There could be others that I don't know (it actually probable) but that is all I could think of hopefully you find a solution though!
Currently I have Python 3.1.1 installed on my system, same version on my server with WSGI 3.0 running on Apache 2.2.
I want to keep using Python 3.1, but I'm finding that lots of libraries/frameworks don't support it yet, namely Django, Pylons, MySQLdb, etc.
I also checked an account I have on a friend's server, and it is running Python 2.3.4...
I want to write a sort of blog/forum type application that I can expand into a CMS, and eventually write related desktop applications for, as sort of a long-term pet project.
I'd like to use the newest version of Python possible for best security and highest consistency with the desktop-applications-to-be, while still maintaining a good level of portability, and supporting most of the frameworks and libraries I will use.
But I'm lost on which one I should pick. It seems like 2.4 would have the greatest amount of portability but it's sort of old, and I don't want to wind up using a bunch of post-2.4 features that won't compile, and having to re-write with messier code to compensate for it. 2.6 would be better, but it seems like lots of libraries are still porting over to that, and 3.1 would be the best since it eliminates a lot of cruft from the language.
One thing I'd like to highlight is that it'd be nice to know what I will be missing if I choose an older version of Python. For example, if I were to need my application to run on my old Python 2.3.4 account on my friend's server, what libraries/features would I be lacking that exist in newer versions? What problems would I surely run into that would make me wish I was using Python 2.6 or 3.1? Which of these features would be available via __future__ imports?
So, what would be the best direction to go? Should I just use 2.6 and deal with any issues? Should I go for 2.4 to maximize my ability to possibly distribute it to shared hosting environments? Or should I just jump into 3.1 and have a slightly-crippled application until libraries like MySQLdb catch up?
For now, Python 3 is not widely deployed in production. Depends on what you use Python for. If it's just for one off scripts, it will be ok either way, if the idea is to use third party modules, C modules and or deploy painlessly, then settle for any of the 2.4+ versions. Many projects strive to keep 2.3 compativility, but you shouldn't have any problems to use 2.4-2.6, as the changes in the language are minor. If you can, use 2.6, as it's the closest to Python 3, as it has some features backported to it.
The problem with Python 3 is a Catch 22:
most useful third party modules are still not ported to 3, as developers are waiting for wide usage,
people can't migrate because modules they rely on haven't migrated yet, keeping the sage low.
You should not have any problems using any of the 2.4-2.6, give 3, some time.
Use Python 2.6
Begin with Python 2.5 if you're not sure.
Have a look at Google App Engine (based on Django). It's using Python 2.5 and it's free.
However, you will not be able to call scipy (for example) or any libraries with "C" inside.
You will have the greatest amount of portability with Python2.5. Moreover, python3k is not really used in the industry.
"2.6 would be better, but it seems like lots of libraries are still porting over to that"
What? What libraries -- that you need -- are "still porting over to that"?
"3.1 would be the best" "but I'm finding that lots of libraries/frameworks don't support"
Correct. You've stated that twice in the question. That's very clear.
"Should I just use 2.6 and deal with any issues"
What issues? Do you have any specific concerns?
It seems to work really, really well. What are your specific concerns?
For intranet web apps I had to install python 2.5 (due to combination of wiki, bug tracker, and httpd WSGI compatibility).
For custom web apps I standardized on python 3.2.
Thus I have both installed simultaneously. I write for 3.2 and bring specific libraries up to spec as needed. However large packages which I don't want to modify use their own 2.5.
Compatibility between 3.2 and 3rd party packages is still an issue at this time, and so is the lack of proper python recipes.
In summary: Install two versions.