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.
Related
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.
I am trying to write my own script to create partitions. (Even though this can be done in anaconda, I want my custom script) The script creates lvm based partitions using lvm2py module. lvm2py requires liblvm2app library. which I installed in my squashfs.
When my script runs at installation, it is failing saying "LVM Library not found". This is error reported by lvm2py when find_library("lvm2app") fails.
Even though liblvm2app.so is present in /usr/lib64/ and all the other libraries dependant on liblvm2app.so are showing resolved in ldd.
Also note that sample python script that does find_library("c") also fails. Looks like python is not able to detect any of the shared libraries.
I also tried adding /usr/lib64 to LD_LIBRARY_PATH, but no luck.
Python is compiled with libpython support.
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.
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.
I'm attempting to build Python 2.6.2 from source on my Linux system. It has ncurses installed on /usr/local/, and curses.h is on /usr/local/include/ncurses. So curses.h isn't found on the include path, and those packages fail in the Python build.
What's the right solution to this? Is Python supposed to include <ncurses/curses.h>? Should /usr/local/include/ncurses be in the include path? Should there be a link from the files in the ncurses directory to /usr/local/include?
Or is there some simpler solution?
With many Open Source packages, you can set:
export CPPFLAGS="-I/usr/local/include"
or even:
export CPPFLAGS="-I/usr/local/include/ncurses"
before running the configure script. I haven't compiled Python recently enough to be sure that works, but it probably does -- I have ncurses installed under /usr/gnu (because /usr/local/ is automounted and contains antiques) and I don't remember having to use anything special to get it to work.
Double-checked...
The configure script only includes <curses.h>. I had to use:
export CPPFLAGS="-I/usr/gnu/include -I/usr/gnu/include/ncurses"
export LDFLAGS="-L/usr/gnu/lib"
./configure
To get the Python (2.5) configure to accept curses. You'd replace 'gnu' with 'local' for your configuration.
I know this is a very old question, but the problem still occurred to me when compiling python 3.6.0 from source so I guess it's still relevant.
Recent versions of ncurses come in several flavors: normal, wide character support, threaded. In order to allow programmers to keep and use different flavors, besides naming the libraries differently (ncursesw.so, ncursest.so, etc), the ncurses configure script sets up the makefile to put the header files in subdirectories by default. This also allows to have different curses implementations alongside ncurses, as specified in the man page.
Some programs, however, still assume that curses.h, along all other ncurses headers, are placed in the top level include search paths, and won't look into subdirectories. In many linux distributions there is usually some sort of workaround for the problem in ncurses developement packages, but if you are compiling ncurses from source, there are two possible approaches to solve the issue:
Using CPPFLAGS or equivalent, as the accepted answer suggests. It works, but you have to set the appropriate compilation flags every time.
Configuring ncurses with --enable-overwrite. This will install the ncurses header files in the top level include directory, according to your --prefix.
If you don't plan to install an alternate curses library, it's completely safe to put the ncurses headers in the top level include path, and it is the approach followed by Gentoo.