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
with the following contents:
(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.