维护多套Python版本的Linux服务器最让人头疼的不是虚拟环境切来切去而是系统级依赖在各版本之间打架。这段时间我就被libselinux这个包折腾了一下午机器上同时跑着CentOS自带的Python 2.7、源码编译的Python 3.8还有用pyenv装的Python 3.12结果在Python 3.12里只要import selinux直接给你一个ModuleNotFoundError。而RPM层面rpm -qa | grep selinux清清楚楚地列着libselinux-python包是装了可Python 3.12就是找不到这个模块。这事的本质就是同名RPM包的排他机制和多Python版本ABI不兼容叠加在一起产生的包存在但环境不可用的尴尬局面。这篇文章就把我这次排查和解决的全过程拆开讲清楚适合正在维护多版本Python环境、或者在旧系统上装新Python后遇到selinux相关报错的运维和开发者参考。1. 问题全景RPM同名包冲突与多Python版本纠缠1.1 一个典型的包存在导入失败场景先还原一下现场。我的测试服务器是CentOS 7系列系统默认Python版本是2.7.5因为要跑一些老脚本这个版本不能动。后来项目需要我用源码方式编译安装了Python 3.8.10再后来又用pyenv装了Python 3.12.1做新项目的隔离环境。其实pyenv管理的Python还算规矩pyenv install出来的解释器会有独立的site-packages目录不太容易和系统环境串台。问题是Python 3.8和后续的3.12在某些依赖上需要用到SELinux的Python绑定——准确说是selinux这个Python模块它是libselinux官方提供的C扩展绑定用于在Python层面执行SELinux相关的查询和策略操作。当时我在Python 3.8里执行python3 -c import selinux一切正常。但切到Python 3.12pyenv环境再跑同样的命令直接报ModuleNotFoundError: No module named selinux然后我去查系统RPM包rpm -qa | grep -E selinux|python.*selinux输出里有libselinux-python-2.5-15.el7.x86_64也有libselinux-python3-2.5-14.el7.x86_64。看到这里你可能会问既然libselinux-python3都装了Python 3.12怎么会找不到问题就在这儿这个RPM包里面的python3指的是系统自带的Python 3.6而不是我后来装的Python 3.8/3.12。RPM包管理器安装Python模块时会按照编译时的路径写死比如/usr/lib/python3.6/site-packages/。它根本不知道、也管不到你用源码方式装到/usr/local/python3.8或者pyenv隔离环境里的Python。1.2 libselinux是什么为什么会绑定Python聊解决方案之前得先把libselinux这个包的身份搞清楚。libselinux是SELinuxSecurity-Enhanced Linux用户态的核心库提供了一组C函数接口用来做安全上下文查询、策略加载、文件标签管理等操作。几乎所有主流Linux发行版都默认启用SELinux或者至少编译了它的基础库所以libselinux.so.1这个动态库是系统底层的常驻人口。但光有C库还不够上层应用如果用Python写就需要一个从Python到C语言的桥接层。于是libselinux项目自己维护了一套Python绑定也就是selinux这个模块。它本质上是一个.so扩展文件比如selinux/_selinux.cpython-38-x86_64-linux-gnu.so由Cython或CPython C API编译生成负责把Python的调用翻译成libselinux.so.1提供的C函数调用。这里就有一个关键点Python的C扩展模块是绑定特定Python主版本号的。Python 2和Python 3的ABI完全不一样即使在Python 3系列内部CPython 3.8和3.12的C API也有差异虽然大部分情况下兼容但不同小版本编译出的.so文件不能想当然地互相替代。理论上3.8编出来的扩展在3.12里大概率可以加载除非用了一些deprecated API但你不可能指望Python 2时代编译的selinux.so被Python 3.12加载那是绝对不可能的。1.3 为什么RPM层面的同名不等于Python层面的可用RPM包管理器有一个铁律同一个包名同一时间系统里只能存在一个版本。libselinux-python这个包给Python 2用libselinux-python3给Python 3用它们在RPM仓库里是两个不同的包名一个带python一个带python3所以理论上可以共存。但继续往下挖就会发现问题libselinux-python3-2.5-14.el7.x86_64这个RPM包在CentOS 7上编译时依赖的是/usr/bin/python3也就是系统自带的Python 3.6解释器。RPM安装的时候它会把文件放到Python 3.6的默认site-packages路径/usr/lib/python3.6/site-packages/selinux/你后来用源码编译的Python 3.8默认prefix是/usr/local对应的site-packages是/usr/local/lib/python3.8/site-packages/Python 3.12如果是pyenv管理的路径更是完全隔离~/.pyenv/versions/3.12.1/lib/python3.12/site-packages/这三个路径在Python解释器看来是三个完全不同的世界。RPM只保证它自己知道的那个解释器能找到模块至于你自己装的其他Python版本它一概不管。这就是包存在但环境不可用的根本原因包管理器维护的是系统全局的文件系统路径而Python解释器维护的是它自己的sys.path搜索路径两者在多自编译Python版本共存的场景下产生了严重脱节。2. 冲突根源拆解RPM的Excel式排他规则2.1 RPM包管理器的基本游戏规则要把这个问题讲透还是得回到RPM本身的工作原理。RPMRed Hat Package Manager本质是一个文件清单脚本元信息的打包格式。安装一个RPM包时管理器会检查几个东西依赖关系这个包依赖哪些包系统里是否满足版本要求。文件冲突要安装的文件是否已经被其他包占用。同名包版本冲突是否已经安装了相同名称的其他版本。这里第三点是让很多人踩坑的地方。假设你已经安装了libselinux-python-2.5-15.el7再去执行yum install libselinux-python-2.5-16.el7如果两个包的名称相同但版本不同yum会默认做升级而不是共存。如果想要同时保留两个版本必须显式指定--install或者用yum install配合--setoptobsoletes0之类的参数而且即便强制安装了RPM数据库中的文件清单也会混乱以后卸载、升级都容易出问题。在libselinux的场景里libselinux-python和libselinux-python3虽然名称不完全相同但它们都包含了一个关键路径下的文件比如/usr/lib/python2.7/site-packages/selinux/ /usr/lib/python3.6/site-packages/selinux/包名不同路径不同所以RPM层面并不冲突。真正冲突的地方在于不同Python版本的site-packages路径天然隔离导致看起来都有、实际各管各。很多人错误地以为装了libselinux-python3所有Python 3都能用实际上只有编译该包时头文件指向的那个解释器能用。2.2 看清RPM包与Python模块的映射关系为了让你更直观地理解我做了一张对照表列出同名类似物但实际差异巨大的关键信息项libselinux-pythonlibselinux-python3源码/自编译Python目标解释器Python 2.7Python 3.6系统自带Python 3.8 / 3.12自定义安装路径/usr/lib/python2.7/site-packages/usr/lib/python3.6/site-packages/usr/local/lib/python3.8/site-packages或 pyenv路径模块文件selinux/_selinux.soPython 2 ABIselinux/_selinux.cpython-36m-x86_64-linux-gnu.so需要为3.8/3.12独立编译RPM识别方式能识别系统和yum能识别系统yum环境RPM完全不识别Python能否导入只有Python 2能只有系统Python 3.6能只有自己编译的Python 3.8/3.12能从这个表可以看出来同一堆代码libselinux的Python绑定因为目标解释器不同在文件系统里就产生了好几个互不相通的副本。RPM管得了系统路径下的那几份管不了你个人编译安装的Python解释器。2.3 常见错误想法rpm -qa里有包Python就能用很多人在排查时觉得不可思议我明明rpm -qa | grep python能看到一大堆包为什么Python 3.12还是import失败原因就一句话RPM数据库是系统级的Python的包搜索路径是解释器级的。你在RPM数据库里查到某个包只代表这个包向文件系统里释放了一些文件并不代表所有Python解释器都会自动加载它们。Python解释器启动后会按顺序搜索sys.path这个列表里包含当前脚本所在目录PYTHONPATH环境变量指定的目录解释器编译时的prefix对应的标准库和site-packages目录.pth文件里追加的路径它不会去/usr/lib/python2.7/site-packages里找Python 3能用的模块除非你手动把那个路径塞进sys.path。而且就算塞进去了Python 2 ABI编译的.so文件在Python 3里加载时大概率直接ImportError: dynamic module does not define module export function或者更隐晦的undefined symbol错误。所以正确的心智模型是RPM只是文件分发工具Python模块的可用性完全取决于解释器能不能搜到正确ABI的扩展文件。3. 多Python版本兼容的方案设计与选型3.1 先盘一下几条路线解决这个问题的思路有很多但质量参差不齐。我结合这几年的运维经验把主流方案分成四类先列个对比表方案原理优点缺点推荐度方案Apip安装selinux从PyPI安装纯Python封装或绑定简单快速新版PyPI上的selinux包可能不维护或需要系统libselinux头文件分情况方案B从RPM包中提取.so文件解包RPM手动把selinux目录复制到目标Python的site-packages不需要编译ABI可能不匹配Python 2与3的文件基本不可互用低方案C源码编译selinux绑定下载libselinux源码用目标Python运行setup.py完全匹配目标解释器ABI干净可靠需要编译环境和依赖头文件高方案D软链接/改名把Python 3.6的.so硬指向Python 3.12零成本大概率崩溃或损坏site-packages极其不推荐极低3.2 为什么新版pip install selinux不一定靠谱首选可能有人会想PyPI上不是有selinux这个包吗pip install selinux不行吗我在Python 3.12环境里试过确实能装上但这个包和系统libselinux的版本匹配度是个大问题。PyPI上的selinux包本质是同一个上游项目SELinuxProject/selinux的Python绑定打包发布但它依赖系统的libselinux.so.1动态库如果动态库版本太老或者头文件缺失安装时编译就会失败。而且这个包的发布节奏不一定跟得上系统的安全补丁在CentOS 7这种老系统上系统自带的libselinux库版本可能很老2.5而PyPI上最新版selinux可能期望更高版本的库装完照样报undefined symbol。结论是如果你的系统libselinux库版本比较老还是优先考虑和系统同源的libselinux源码版本而不是追新的PyPI包。3.3 彻底搞懂为什么源码编译是唯一稳的路线真正稳妥的做法是让libselinux官方的Python绑定代码针对每一个需要兼容的解释器重新编译一次。这个过程本质上就是拿到与系统libselinux版本匹配的源码。在目标Python解释器环境下执行setup.py build和setup.py install。编译成功后site-packages里出现该解释器专属的selinux目录内含ABI匹配的.so文件。这样做的好处是ABI绝对匹配编译时用的就是目标解释器的头文件和链接参数不担心跨版本不兼容。版本可控可以指定和系统libselinux同版本的源码避免版本漂移。路径干净每个Python环境各有一份独立的site-packages副本互不干扰RPM也管不着完全符合多版本共存的需求。可复现相同流程可以随时为新的Python版本比如3.13重新编译一遍秒级扩展。3.4 各方案适用的场景边界不过这四类方案不是说一定要死磕源码编译。实践中我一般这样选如果只是临时跑一个脚本缺selinux就报错可以试着用pip install selinux能过就用不纠结性能。但要注意这个包装完后要确认能不能正常import并且执行基础调用最好跑一下selinux.selinux_getenforcemode()。如果系统是CentOS 7/RHEL 7这一类老发行版系统自带Python是2.7你新装的Python版本又比较新直接源码编译绑定是唯一靠谱的路径因为老系统的repo里没有匹配新解释器的RPM包。如果只是Python 3.6自带的系统环境那根本不用折腾确认yum install libselinux-python3已经装了就行。4. 实操全过程为Python 3.12编译libselinux绑定4.1 环境准备与依赖清点先说环境我这次操作的系统是CentOS 7.9内核版本3.10SELinux处于Enforcing模式。系统的libselinux库版本是2.5。要编译Python绑定需要准备以下几样东西# 安装编译工具链 yum install -y gcc make python3-devel # 安装libselinux开发头文件编译Python扩展时需要 yum install -y libselinux-devel # 确认目标Python解释器 pyenv versions # 输出中应有 3.12.1 # 查看当前系统SELinux库版本 rpm -qa | grep libselinux # libselinux-2.5-15.el7.x86_64有一点要特别注意编译Python扩展时python3-devel和libselinux-devel的版本必须与运行时一致。CentOS 7上默认的python3是3.6版本如果你pip install selinux或源码编译时误用了系统Python 3.6的python3-config编译出来的东西只会丢到3.6的site-packages里对3.12没有任何帮助。所以执行编译安装步骤时必须明确指定用哪个解释器。4.2 获取与系统匹配的libselinux源码这里有个技巧不要随便去GitHub上拉最新的master分支应该去找和系统libselinux版本对应的tag。比如系统是2.5那就可以去找2.5或相近的release tag。# 克隆官方仓库 git clone https://github.com/SELinuxProject/selinux.git cd selinux # 切换到对应版本分支 git checkout 2.5 # 进入libselinux子项目 cd libselinux在libselinux的源码目录里Python绑定相关的文件通常位于src/下的selinux.py、selinux_python.i或selinux/子目录不同版本结构略有差异。2.5版本的目录大概是src/selinux/、src/selinux.c和src/setup.py。如果不确定路径可以这样快速找到find . -name setup.py | grep -i python找到setup.py后看一下里面的配置。通常这个setup.py会调用distutils.core.setup把selinux.c编译成_selinux.so扩展并打包selinux这个顶层Python包里面包含__init__.py和编译出来的_selinux扩展。4.3 用目标Python解释器执行编译安装关键步骤来了。要确保是用Python 3.12去执行setup.py而不是系统默认的python3也就是3.6。给我的pyenv里的Python 3.12.1指定完整路径~/.pyenv/versions/3.12.1/bin/python setup.py build ~/.pyenv/versions/3.12.1/bin/python setup.py install如果编译过程中报错缺少头文件通常是因为libselinux-devel没装全或者没有把/usr/include/selinux路径暴露给编译器。这时可以通过环境变量指定export CFLAGS-I/usr/include export LDFLAGS-L/usr/lib64 -lselinux ~/.pyenv/versions/3.12.1/bin/python setup.py build编译成功后会看到类似信息running build running build_ext building _selinux extension gcc -pthread ...然后install。install后验证一下是否真的装到了Python 3.12的site-packages路径~/.pyenv/versions/3.12.1/bin/python -c import selinux; print(selinux.__file__)正常会输出~/.pyenv/versions/3.12.1/lib/python3.12/site-packages/selinux/__init__.py说明绑定已经进入3.12的环境并且_selinux.so是和3.12 ABI匹配的。4.4 多版本共存同一台机器的并行处理如果你也想让Python 3.8同时能用只需要把上面的~/.pyenv/versions/3.12.1/bin/python换成3.8的路径再执行一遍setup.py build和setup.py install。因为site-packages路径是按解释器隔离的两份编译结果各自存放在不同目录完全不会互相覆盖。不过要注意一个细节编译Python 3.8绑定之前最好清一下build临时目录。因为setup.py build会把中间产物缓存在源码目录的build/下如果上一次是用3.12编译的这次直接用3.8编译有些旧的对象文件可能会导致冲突或链接到错误的Python库。最稳妥的做法是rm -rf build ~/.pyenv/versions/3.8.10/bin/python setup.py build ~/.pyenv/versions/3.8.10/bin/python setup.py install4.5 验证selinux功能是否真的可用编译安装之后只验证import不报错还不够还得验证功能是否正常。我一般会跑一条最基础的SELinux API~/.pyenv/versions/3.12.1/bin/python -c import selinux print(SELinux enabled:, selinux.is_selinux_enabled()) print(Enforce mode:, selinux.selinux_getenforcemode()) 如果输出SELinux enabled: 1 Enforce mode: (0, 1)那就说明从Python绑定到C库的整个链路是通的。顺便说一句selinux_getenforcemode()返回的是一个元组第一个元素是状态码第二个是模式值0Permissive1Enforcing。5. 踩坑实录常见问题与排查技巧5.1 ModuleNotFoundErrorNo module named selinux这个报错出现频率最高。排查思路分三步确认目标解释器的site-packages里有没有selinux目录python3.12 -c import sys; print(\n.join(sys.path))然后在列出的路径中找selinux目录。如果找不到说明绑定压根没装进这个解释器环境按上面的源码编译步骤操作即可。确认是否被其他同名包扰乱如果你之前用过系统的libselinux-python3那个包会产生/usr/lib/python3.6/site-packages/selinux目录。部分自编译Python的sys.path可能包含了这个系统路径尤其是通过环境变量PYTHONPATH加进去的导致解释器尝试加载一个ABI不匹配的.so文件这时反而会报更隐蔽的ImportError。检查pyenv/虚拟环境的隔离性如果用pyenvpyenv which python3.12能看到路径如果用venv要保证激活的状态下执行安装。5.2 ImportErrorundefined symbol / dynamic module does not define module export function这个报错基本是ABI不匹配的典型症状。比如你在Python 3.12里强行加载Python 3.6编译的_selinux.cpython-36m-x86_64-linux-gnu.so就会报ImportError: /usr/lib/python3.6/site-packages/selinux/_selinux.cpython-36m-x86_64-linux-gnu.so: undefined symbol: PyUnicode_AsUTF8String或者SystemError: dynamic module does not define module export function (PyInit__selinux)遇到这个情况不要试图用改名、复制文件的方式蒙混过关。cpython-36m文件名里面那个36m就是ABI标识Python解释器启动时会校验它和当前版本是否匹配不匹配直接拒绝。唯一的出路是重新编译出cpython-312标识的.so文件。5.3 RPM安装时文件冲突/usr/lib/python2.7/site-packages/...有时候你想从RPM层面强制安装某个版本的libselinux-python结果yum报文件冲突比如file /usr/lib/python2.7/site-packages/selinux/__init__.py from install of libselinux-python-2.5-15.el7.x86_64 conflicts with file from package libselinux-python-2.5-14.el7.x86_64这就说明系统里已经存在同名的旧包占了路径。不要轻易用rpm --force强制覆盖那样会让RPM数据库的文件清单混乱以后卸载或升级时容易残留垃圾文件。应该先用rpm -e把旧版本卸干净再装新的。5.4 RPM不识别自装Python的路径/usr/local/python3.8找不到selinux安装完源码编译的selinux后运行的是/usr/local/python3.8/bin/python3.8但是检查RPM数据库却说没有selinux相关的包这完全不奇怪。因为源码编译安装做的事情RPM数据库根本不知道。不要试图用RPM去管理源码安装的环境那是两套完全独立的文件分发体系。5.5 升级Python后旧site-packages残留如果你把Python 3.8升级到3.9、3.10、3.11旧版本对应site-packages里的selinux绑定会继续存在但新解释器不会自动去找旧版本的路径。除非你把旧目录手动加入PYTHONPATH但这种做法很容易埋雷因为不同小版本之间的ABI兼容性虽然没有官方保证但也通常能用但不值得赌。正确做法是每升一个Python小版本就重新编译一次selinux绑定或者干脆在用新版本之前先清理掉旧版本的selinux模块避免误加载。6. 个人体会与避坑清单这次折腾下来我最深的感受是RPM包管理器和Python解释器本来就是两个相对独立的体系在多版本Python共存的机器上强行靠RPM解决一切Python依赖是行不通的。正确心态应该是系统级包libselinux本体库、编译器、头文件由RPM管Python特异性的扩展绑定selinux模块由Python解释器各自管两者分工明确互不越界。最后整理一份实用避坑清单都是我亲手踩过的编译selinux绑定时不要用python setup.py install这种省略解释器路径的写法很可能调用了系统的Python 3.6。每次换Python版本先rm -rf build再编译避免使用上一次编译的中间产物。不要凭喜好随意下载GitHub最新版libselinux源码优先选与系统libselinux库版本一致或接近的tag。selinux.__file__的路径必须和python -c import sys; print(sys.prefix)对应否则说明装错了环境。处理完selinux之后顺手检查一下其他系统级Python扩展比如systemd、dbus-python它们也可能面临同样的多版本兼容问题提前处理能省很多事。这套方法我已经在多个生产环境验证从Python 3.8到3.12都能顺利搞定。下次你再遇到同名RPM包冲突这一类问题不妨沉住气先弄清包管理器管的路径和解释器找的路径是不是同一个往往答案就清楚了一半。 
长河君 · 2026/10/7 10:49:18 · 阅读 1.2k libselinux与多Python版本冲突：从ModuleNotFoundError到源码编译
维护多套Python版本的Linux服务器最让人头疼的不是虚拟环境切来切去而是系统级依赖在各版本之间打架。这段时间我就被libselinux这个包折腾了一下午机器上同时跑着CentOS自带的Python 2.7、源码编译的Python 3.8还有用pyenv装的Python 3.12结果在Python 3.12里只要import selinux直接给你一个ModuleNotFoundError。而RPM层面rpm -qa | grep selinux清清楚楚地列着libselinux-python包是装了可Python 3.12就是找不到这个模块。这事的本质就是同名RPM包的排他机制和多Python版本ABI不兼容叠加在一起产生的包存在但环境不可用的尴尬局面。这篇文章就把我这次排查和解决的全过程拆开讲清楚适合正在维护多版本Python环境、或者在旧系统上装新Python后遇到selinux相关报错的运维和开发者参考。1. 问题全景RPM同名包冲突与多Python版本纠缠1.1 一个典型的包存在导入失败场景先还原一下现场。我的测试服务器是CentOS 7系列系统默认Python版本是2.7.5因为要跑一些老脚本这个版本不能动。后来项目需要我用源码方式编译安装了Python 3.8.10再后来又用pyenv装了Python 3.12.1做新项目的隔离环境。其实pyenv管理的Python还算规矩pyenv install出来的解释器会有独立的site-packages目录不太容易和系统环境串台。问题是Python 3.8和后续的3.12在某些依赖上需要用到SELinux的Python绑定——准确说是selinux这个Python模块它是libselinux官方提供的C扩展绑定用于在Python层面执行SELinux相关的查询和策略操作。当时我在Python 3.8里执行python3 -c import selinux一切正常。但切到Python 3.12pyenv环境再跑同样的命令直接报ModuleNotFoundError: No module named selinux然后我去查系统RPM包rpm -qa | grep -E selinux|python.*selinux输出里有libselinux-python-2.5-15.el7.x86_64也有libselinux-python3-2.5-14.el7.x86_64。看到这里你可能会问既然libselinux-python3都装了Python 3.12怎么会找不到问题就在这儿这个RPM包里面的python3指的是系统自带的Python 3.6而不是我后来装的Python 3.8/3.12。RPM包管理器安装Python模块时会按照编译时的路径写死比如/usr/lib/python3.6/site-packages/。它根本不知道、也管不到你用源码方式装到/usr/local/python3.8或者pyenv隔离环境里的Python。1.2 libselinux是什么为什么会绑定Python聊解决方案之前得先把libselinux这个包的身份搞清楚。libselinux是SELinuxSecurity-Enhanced Linux用户态的核心库提供了一组C函数接口用来做安全上下文查询、策略加载、文件标签管理等操作。几乎所有主流Linux发行版都默认启用SELinux或者至少编译了它的基础库所以libselinux.so.1这个动态库是系统底层的常驻人口。但光有C库还不够上层应用如果用Python写就需要一个从Python到C语言的桥接层。于是libselinux项目自己维护了一套Python绑定也就是selinux这个模块。它本质上是一个.so扩展文件比如selinux/_selinux.cpython-38-x86_64-linux-gnu.so由Cython或CPython C API编译生成负责把Python的调用翻译成libselinux.so.1提供的C函数调用。这里就有一个关键点Python的C扩展模块是绑定特定Python主版本号的。Python 2和Python 3的ABI完全不一样即使在Python 3系列内部CPython 3.8和3.12的C API也有差异虽然大部分情况下兼容但不同小版本编译出的.so文件不能想当然地互相替代。理论上3.8编出来的扩展在3.12里大概率可以加载除非用了一些deprecated API但你不可能指望Python 2时代编译的selinux.so被Python 3.12加载那是绝对不可能的。1.3 为什么RPM层面的同名不等于Python层面的可用RPM包管理器有一个铁律同一个包名同一时间系统里只能存在一个版本。libselinux-python这个包给Python 2用libselinux-python3给Python 3用它们在RPM仓库里是两个不同的包名一个带python一个带python3所以理论上可以共存。但继续往下挖就会发现问题libselinux-python3-2.5-14.el7.x86_64这个RPM包在CentOS 7上编译时依赖的是/usr/bin/python3也就是系统自带的Python 3.6解释器。RPM安装的时候它会把文件放到Python 3.6的默认site-packages路径/usr/lib/python3.6/site-packages/selinux/你后来用源码编译的Python 3.8默认prefix是/usr/local对应的site-packages是/usr/local/lib/python3.8/site-packages/Python 3.12如果是pyenv管理的路径更是完全隔离~/.pyenv/versions/3.12.1/lib/python3.12/site-packages/这三个路径在Python解释器看来是三个完全不同的世界。RPM只保证它自己知道的那个解释器能找到模块至于你自己装的其他Python版本它一概不管。这就是包存在但环境不可用的根本原因包管理器维护的是系统全局的文件系统路径而Python解释器维护的是它自己的sys.path搜索路径两者在多自编译Python版本共存的场景下产生了严重脱节。2. 冲突根源拆解RPM的Excel式排他规则2.1 RPM包管理器的基本游戏规则要把这个问题讲透还是得回到RPM本身的工作原理。RPMRed Hat Package Manager本质是一个文件清单脚本元信息的打包格式。安装一个RPM包时管理器会检查几个东西依赖关系这个包依赖哪些包系统里是否满足版本要求。文件冲突要安装的文件是否已经被其他包占用。同名包版本冲突是否已经安装了相同名称的其他版本。这里第三点是让很多人踩坑的地方。假设你已经安装了libselinux-python-2.5-15.el7再去执行yum install libselinux-python-2.5-16.el7如果两个包的名称相同但版本不同yum会默认做升级而不是共存。如果想要同时保留两个版本必须显式指定--install或者用yum install配合--setoptobsoletes0之类的参数而且即便强制安装了RPM数据库中的文件清单也会混乱以后卸载、升级都容易出问题。在libselinux的场景里libselinux-python和libselinux-python3虽然名称不完全相同但它们都包含了一个关键路径下的文件比如/usr/lib/python2.7/site-packages/selinux/ /usr/lib/python3.6/site-packages/selinux/包名不同路径不同所以RPM层面并不冲突。真正冲突的地方在于不同Python版本的site-packages路径天然隔离导致看起来都有、实际各管各。很多人错误地以为装了libselinux-python3所有Python 3都能用实际上只有编译该包时头文件指向的那个解释器能用。2.2 看清RPM包与Python模块的映射关系为了让你更直观地理解我做了一张对照表列出同名类似物但实际差异巨大的关键信息项libselinux-pythonlibselinux-python3源码/自编译Python目标解释器Python 2.7Python 3.6系统自带Python 3.8 / 3.12自定义安装路径/usr/lib/python2.7/site-packages/usr/lib/python3.6/site-packages/usr/local/lib/python3.8/site-packages或 pyenv路径模块文件selinux/_selinux.soPython 2 ABIselinux/_selinux.cpython-36m-x86_64-linux-gnu.so需要为3.8/3.12独立编译RPM识别方式能识别系统和yum能识别系统yum环境RPM完全不识别Python能否导入只有Python 2能只有系统Python 3.6能只有自己编译的Python 3.8/3.12能从这个表可以看出来同一堆代码libselinux的Python绑定因为目标解释器不同在文件系统里就产生了好几个互不相通的副本。RPM管得了系统路径下的那几份管不了你个人编译安装的Python解释器。2.3 常见错误想法rpm -qa里有包Python就能用很多人在排查时觉得不可思议我明明rpm -qa | grep python能看到一大堆包为什么Python 3.12还是import失败原因就一句话RPM数据库是系统级的Python的包搜索路径是解释器级的。你在RPM数据库里查到某个包只代表这个包向文件系统里释放了一些文件并不代表所有Python解释器都会自动加载它们。Python解释器启动后会按顺序搜索sys.path这个列表里包含当前脚本所在目录PYTHONPATH环境变量指定的目录解释器编译时的prefix对应的标准库和site-packages目录.pth文件里追加的路径它不会去/usr/lib/python2.7/site-packages里找Python 3能用的模块除非你手动把那个路径塞进sys.path。而且就算塞进去了Python 2 ABI编译的.so文件在Python 3里加载时大概率直接ImportError: dynamic module does not define module export function或者更隐晦的undefined symbol错误。所以正确的心智模型是RPM只是文件分发工具Python模块的可用性完全取决于解释器能不能搜到正确ABI的扩展文件。3. 多Python版本兼容的方案设计与选型3.1 先盘一下几条路线解决这个问题的思路有很多但质量参差不齐。我结合这几年的运维经验把主流方案分成四类先列个对比表方案原理优点缺点推荐度方案Apip安装selinux从PyPI安装纯Python封装或绑定简单快速新版PyPI上的selinux包可能不维护或需要系统libselinux头文件分情况方案B从RPM包中提取.so文件解包RPM手动把selinux目录复制到目标Python的site-packages不需要编译ABI可能不匹配Python 2与3的文件基本不可互用低方案C源码编译selinux绑定下载libselinux源码用目标Python运行setup.py完全匹配目标解释器ABI干净可靠需要编译环境和依赖头文件高方案D软链接/改名把Python 3.6的.so硬指向Python 3.12零成本大概率崩溃或损坏site-packages极其不推荐极低3.2 为什么新版pip install selinux不一定靠谱首选可能有人会想PyPI上不是有selinux这个包吗pip install selinux不行吗我在Python 3.12环境里试过确实能装上但这个包和系统libselinux的版本匹配度是个大问题。PyPI上的selinux包本质是同一个上游项目SELinuxProject/selinux的Python绑定打包发布但它依赖系统的libselinux.so.1动态库如果动态库版本太老或者头文件缺失安装时编译就会失败。而且这个包的发布节奏不一定跟得上系统的安全补丁在CentOS 7这种老系统上系统自带的libselinux库版本可能很老2.5而PyPI上最新版selinux可能期望更高版本的库装完照样报undefined symbol。结论是如果你的系统libselinux库版本比较老还是优先考虑和系统同源的libselinux源码版本而不是追新的PyPI包。3.3 彻底搞懂为什么源码编译是唯一稳的路线真正稳妥的做法是让libselinux官方的Python绑定代码针对每一个需要兼容的解释器重新编译一次。这个过程本质上就是拿到与系统libselinux版本匹配的源码。在目标Python解释器环境下执行setup.py build和setup.py install。编译成功后site-packages里出现该解释器专属的selinux目录内含ABI匹配的.so文件。这样做的好处是ABI绝对匹配编译时用的就是目标解释器的头文件和链接参数不担心跨版本不兼容。版本可控可以指定和系统libselinux同版本的源码避免版本漂移。路径干净每个Python环境各有一份独立的site-packages副本互不干扰RPM也管不着完全符合多版本共存的需求。可复现相同流程可以随时为新的Python版本比如3.13重新编译一遍秒级扩展。3.4 各方案适用的场景边界不过这四类方案不是说一定要死磕源码编译。实践中我一般这样选如果只是临时跑一个脚本缺selinux就报错可以试着用pip install selinux能过就用不纠结性能。但要注意这个包装完后要确认能不能正常import并且执行基础调用最好跑一下selinux.selinux_getenforcemode()。如果系统是CentOS 7/RHEL 7这一类老发行版系统自带Python是2.7你新装的Python版本又比较新直接源码编译绑定是唯一靠谱的路径因为老系统的repo里没有匹配新解释器的RPM包。如果只是Python 3.6自带的系统环境那根本不用折腾确认yum install libselinux-python3已经装了就行。4. 实操全过程为Python 3.12编译libselinux绑定4.1 环境准备与依赖清点先说环境我这次操作的系统是CentOS 7.9内核版本3.10SELinux处于Enforcing模式。系统的libselinux库版本是2.5。要编译Python绑定需要准备以下几样东西# 安装编译工具链 yum install -y gcc make python3-devel # 安装libselinux开发头文件编译Python扩展时需要 yum install -y libselinux-devel # 确认目标Python解释器 pyenv versions # 输出中应有 3.12.1 # 查看当前系统SELinux库版本 rpm -qa | grep libselinux # libselinux-2.5-15.el7.x86_64有一点要特别注意编译Python扩展时python3-devel和libselinux-devel的版本必须与运行时一致。CentOS 7上默认的python3是3.6版本如果你pip install selinux或源码编译时误用了系统Python 3.6的python3-config编译出来的东西只会丢到3.6的site-packages里对3.12没有任何帮助。所以执行编译安装步骤时必须明确指定用哪个解释器。4.2 获取与系统匹配的libselinux源码这里有个技巧不要随便去GitHub上拉最新的master分支应该去找和系统libselinux版本对应的tag。比如系统是2.5那就可以去找2.5或相近的release tag。# 克隆官方仓库 git clone https://github.com/SELinuxProject/selinux.git cd selinux # 切换到对应版本分支 git checkout 2.5 # 进入libselinux子项目 cd libselinux在libselinux的源码目录里Python绑定相关的文件通常位于src/下的selinux.py、selinux_python.i或selinux/子目录不同版本结构略有差异。2.5版本的目录大概是src/selinux/、src/selinux.c和src/setup.py。如果不确定路径可以这样快速找到find . -name setup.py | grep -i python找到setup.py后看一下里面的配置。通常这个setup.py会调用distutils.core.setup把selinux.c编译成_selinux.so扩展并打包selinux这个顶层Python包里面包含__init__.py和编译出来的_selinux扩展。4.3 用目标Python解释器执行编译安装关键步骤来了。要确保是用Python 3.12去执行setup.py而不是系统默认的python3也就是3.6。给我的pyenv里的Python 3.12.1指定完整路径~/.pyenv/versions/3.12.1/bin/python setup.py build ~/.pyenv/versions/3.12.1/bin/python setup.py install如果编译过程中报错缺少头文件通常是因为libselinux-devel没装全或者没有把/usr/include/selinux路径暴露给编译器。这时可以通过环境变量指定export CFLAGS-I/usr/include export LDFLAGS-L/usr/lib64 -lselinux ~/.pyenv/versions/3.12.1/bin/python setup.py build编译成功后会看到类似信息running build running build_ext building _selinux extension gcc -pthread ...然后install。install后验证一下是否真的装到了Python 3.12的site-packages路径~/.pyenv/versions/3.12.1/bin/python -c import selinux; print(selinux.__file__)正常会输出~/.pyenv/versions/3.12.1/lib/python3.12/site-packages/selinux/__init__.py说明绑定已经进入3.12的环境并且_selinux.so是和3.12 ABI匹配的。4.4 多版本共存同一台机器的并行处理如果你也想让Python 3.8同时能用只需要把上面的~/.pyenv/versions/3.12.1/bin/python换成3.8的路径再执行一遍setup.py build和setup.py install。因为site-packages路径是按解释器隔离的两份编译结果各自存放在不同目录完全不会互相覆盖。不过要注意一个细节编译Python 3.8绑定之前最好清一下build临时目录。因为setup.py build会把中间产物缓存在源码目录的build/下如果上一次是用3.12编译的这次直接用3.8编译有些旧的对象文件可能会导致冲突或链接到错误的Python库。最稳妥的做法是rm -rf build ~/.pyenv/versions/3.8.10/bin/python setup.py build ~/.pyenv/versions/3.8.10/bin/python setup.py install4.5 验证selinux功能是否真的可用编译安装之后只验证import不报错还不够还得验证功能是否正常。我一般会跑一条最基础的SELinux API~/.pyenv/versions/3.12.1/bin/python -c import selinux print(SELinux enabled:, selinux.is_selinux_enabled()) print(Enforce mode:, selinux.selinux_getenforcemode()) 如果输出SELinux enabled: 1 Enforce mode: (0, 1)那就说明从Python绑定到C库的整个链路是通的。顺便说一句selinux_getenforcemode()返回的是一个元组第一个元素是状态码第二个是模式值0Permissive1Enforcing。5. 踩坑实录常见问题与排查技巧5.1 ModuleNotFoundErrorNo module named selinux这个报错出现频率最高。排查思路分三步确认目标解释器的site-packages里有没有selinux目录python3.12 -c import sys; print(\n.join(sys.path))然后在列出的路径中找selinux目录。如果找不到说明绑定压根没装进这个解释器环境按上面的源码编译步骤操作即可。确认是否被其他同名包扰乱如果你之前用过系统的libselinux-python3那个包会产生/usr/lib/python3.6/site-packages/selinux目录。部分自编译Python的sys.path可能包含了这个系统路径尤其是通过环境变量PYTHONPATH加进去的导致解释器尝试加载一个ABI不匹配的.so文件这时反而会报更隐蔽的ImportError。检查pyenv/虚拟环境的隔离性如果用pyenvpyenv which python3.12能看到路径如果用venv要保证激活的状态下执行安装。5.2 ImportErrorundefined symbol / dynamic module does not define module export function这个报错基本是ABI不匹配的典型症状。比如你在Python 3.12里强行加载Python 3.6编译的_selinux.cpython-36m-x86_64-linux-gnu.so就会报ImportError: /usr/lib/python3.6/site-packages/selinux/_selinux.cpython-36m-x86_64-linux-gnu.so: undefined symbol: PyUnicode_AsUTF8String或者SystemError: dynamic module does not define module export function (PyInit__selinux)遇到这个情况不要试图用改名、复制文件的方式蒙混过关。cpython-36m文件名里面那个36m就是ABI标识Python解释器启动时会校验它和当前版本是否匹配不匹配直接拒绝。唯一的出路是重新编译出cpython-312标识的.so文件。5.3 RPM安装时文件冲突/usr/lib/python2.7/site-packages/...有时候你想从RPM层面强制安装某个版本的libselinux-python结果yum报文件冲突比如file /usr/lib/python2.7/site-packages/selinux/__init__.py from install of libselinux-python-2.5-15.el7.x86_64 conflicts with file from package libselinux-python-2.5-14.el7.x86_64这就说明系统里已经存在同名的旧包占了路径。不要轻易用rpm --force强制覆盖那样会让RPM数据库的文件清单混乱以后卸载或升级时容易残留垃圾文件。应该先用rpm -e把旧版本卸干净再装新的。5.4 RPM不识别自装Python的路径/usr/local/python3.8找不到selinux安装完源码编译的selinux后运行的是/usr/local/python3.8/bin/python3.8但是检查RPM数据库却说没有selinux相关的包这完全不奇怪。因为源码编译安装做的事情RPM数据库根本不知道。不要试图用RPM去管理源码安装的环境那是两套完全独立的文件分发体系。5.5 升级Python后旧site-packages残留如果你把Python 3.8升级到3.9、3.10、3.11旧版本对应site-packages里的selinux绑定会继续存在但新解释器不会自动去找旧版本的路径。除非你把旧目录手动加入PYTHONPATH但这种做法很容易埋雷因为不同小版本之间的ABI兼容性虽然没有官方保证但也通常能用但不值得赌。正确做法是每升一个Python小版本就重新编译一次selinux绑定或者干脆在用新版本之前先清理掉旧版本的selinux模块避免误加载。6. 个人体会与避坑清单这次折腾下来我最深的感受是RPM包管理器和Python解释器本来就是两个相对独立的体系在多版本Python共存的机器上强行靠RPM解决一切Python依赖是行不通的。正确心态应该是系统级包libselinux本体库、编译器、头文件由RPM管Python特异性的扩展绑定selinux模块由Python解释器各自管两者分工明确互不越界。最后整理一份实用避坑清单都是我亲手踩过的编译selinux绑定时不要用python setup.py install这种省略解释器路径的写法很可能调用了系统的Python 3.6。每次换Python版本先rm -rf build再编译避免使用上一次编译的中间产物。不要凭喜好随意下载GitHub最新版libselinux源码优先选与系统libselinux库版本一致或接近的tag。selinux.__file__的路径必须和python -c import sys; print(sys.prefix)对应否则说明装错了环境。处理完selinux之后顺手检查一下其他系统级Python扩展比如systemd、dbus-python它们也可能面临同样的多版本兼容问题提前处理能省很多事。这套方法我已经在多个生产环境验证从Python 3.8到3.12都能顺利搞定。下次你再遇到同名RPM包冲突这一类问题不妨沉住气先弄清包管理器管的路径和解释器找的路径是不是同一个往往答案就清楚了一半。