CentOS 8 中 targetcli 无法启动，提示“ModuleNotFoundError: No module named ‘rtslib_fb’”如何解决？

Question

在 CentOS 8 中执行 `targetcli` 时出现 `ModuleNotFoundError: No module named 'rtslib_fb'`，根本原因是：CentOS 8 默认仓库已移除 `targetcli` 及其核心依赖 `python3-rtslib-fb`（原 `rtslib` 的 Python 3 兼容分支）。该工具自 RHEL 8/CentOS 8 起被官方弃用，转而推荐使用 `targetcli-fb`（社区维护分支）或更现代的 `lnst`/`cockpit-storaged`。解决方法：先启用 EPEL 8 仓库（`dnf install epel-release`），再安装兼容包：`dnf install targetcli-fb python3-rtslib-fb python3-configshell-fb`。注意勿混用 `targetcli`（旧版，已失效）与 `targetcli-fb`（新入口命令，符号链接至 `/usr/bin/targetcli` 或需手动创建）。验证运行 `targetcli-fb` 即可。若仍报错，检查 Python 3.6+ 环境及 SELinux 是否拦截模块加载（临时设为 permissive 排查）。此问题属典型“生态迁移导致的依赖断裂”，非配置错误。

Answer 1

一、现象层：命令执行失败的直观表现

在 CentOS 8 系统中执行 targetcli 命令时，终端立即报错：

Traceback (most recent call last):
  File "/usr/bin/targetcli", line 23, in <module>
    from rtslib_fb import RTSLibError
ModuleNotFoundError: No module named 'rtslib_fb'

该错误非权限缺失、路径错误或语法误用所致，而是 Python 解释器在导入核心模块时彻底找不到符号——表明底层依赖链已断裂。此为典型“运行时模块缺失”现象，是问题暴露的第一层表象。

二、依赖层：包生态迁移引发的断链真相

• RHEL 8/CentOS 8 官方仓库自发布起即移除 targetcli（源码包名：python-rtslib）、python3-rtslib-fb 及 python3-configshell-fb；
• Red Hat 明确将 targetcli 标记为 Deprecated，不再维护其 RPM 构建与安全更新；
• 社区演进路径为：rtslib → rtslib-fb（feature-branch）→ rtslib_fb（Python 3 命名规范重构），而 CentOS 8 默认源未同步该演进分支；
• EPEL 8 成为唯一稳定提供 targetcli-fb 全套组件的可信第三方仓库。

三、架构层：从内核到用户态的iSCSI Target栈解耦

如下 Mermaid 流程图展示 CentOS 8 中 iSCSI Target 工具链的分层结构与依赖流向：

graph LR
A[Linux Kernel
iscsi_target_mod] --> B[ConfigFS Interface]
B --> C[rtslib_fb
Python 3 binding]
C --> D[targetcli-fb
CLI frontend]
D --> E[cockpit-storaged
Web UI alternative]
C -.-> F[lnst
Network storage testing]

可见 rtslib_fb 是承上（内核 target_core）启下（CLI/UI）的关键胶水层，其缺失直接导致整个用户态控制面瘫痪。

四、解决方案层：精准复原工具链的四步操作法

步骤	命令	说明
① 启用 EPEL 8	dnf install -y epel-release	确保 epel 仓库启用且 GPG 密钥可信
② 安装新工具链	dnf install -y targetcli-fb python3-rtslib-fb python3-configshell-fb	三者版本严格绑定，不可拆分安装
③ 验证入口命令	ls -l /usr/bin/targetcli*	确认 targetcli-fb 存在，且 targetcli 为软链或需手动创建
④ 运行验证	targetcli-fb	进入交互式 shell 后执行 ls 应显示 /backstores 等根节点

五、排障层：当标准方案失效时的深度诊断路径

1. Python 环境校验：运行 python3 -c "import sys; print(sys.version_info)" 确认 ≥3.6；
2. 模块路径检查：执行 python3 -c "import rtslib_fb; print(rtslib_fb.__file__)" 验证安装路径是否在 site-packages；
3. SELinux 干预排查：临时执行 setenforce 0，若此时 targetcli-fb 正常，则需审计 audit2why -a | grep targetcli 并生成策略模块；
4. 内核模块加载：确认 modprobe target_core_mod iscsi_target_mod 无报错，且 lsmod | grep target 输出非空。

六、演进层：超越 targetcli 的现代存储管理范式

需清醒认知：targetcli-fb 是向后兼容的过渡方案，而非长期演进方向。RHEL/CentOS 生态正加速转向：

• Cockpit + storaged：通过 Web 控制台统一管理 LVM/iSCSI/NVMe-oF，支持 RBAC 与审计日志；
• LNST（Linux Network Storage Testbed）：面向自动化测试场景，以 YAML 定义 Target/Initiator 拓扑并驱动内核行为；
• Podman + CSI Driver：在容器化环境中以插件方式暴露块设备服务，契合云原生存储编排趋势。

这标志着存储管理正从“命令行驱动的手动配置”迈向“声明式定义+策略驱动的自动运维”新阶段。