AWVS在Linux上部署时，常见的依赖问题有哪些？

在企业网络安全检测中，Acunetix Web Vulnerability Scanner（AWVS）常被选作漏洞评估的核心工具。把它搬到 linux 环境里运行，往往要跨过一层“依赖迷宫”。即便官方文档列出了基本的库文件，实际装配时仍会碰到版本冲突、缺失组件以及系统发行版差异引发的连锁报错。

最常出现的依赖缺口

AWVS 的二进制包依赖图谱相当庞大，核心库几乎涵盖了图形、音频、网络安全三个维度。缺失任何一个关键库，启动脚本便会在 ldd 检查阶段直接报错，导致服务卡死。

• libgtk-3-0：提供 GUI 渲染，缺失会导致 Gtk-Message: Failed to load module。
• libnss3：SSL/TLS 握手的底层实现，版本低于 3.35 时会触发 SSL_ERROR_RX_RECORD_TOO_LONG。
• libasound2：音频子系统，尽管 AWVS 本身不播放声音，但内部日志组件会尝试调用。
• libxss1 与 libxdamage1：X11 扩展库，缺失会让 headless 环境报 Cannot open display。
• libxcb1 与 libxcb1-dev：XCB 协议层，版本不匹配经常导致 symbol lookup error。
• libx11-xcb-dev：编译时必须的头文件，若系统只装了运行时库，源码层面的插件会编译失败。

在基于 Debian 系列的发行版（如 Ubuntu）上，apt-get 能一次性拉齐大多数依赖；而在 RHEL 系列（CentOS、Rocky）里，yum 或 dnf 则需要手动映射对应的 glibc 与 libstdc++ 包。尤其是旧版 CentOS 7，其默认提供的 libnss3 仍停留在 3.28，直接导致 AWVS 启动时出现 “unsupported TLS version”。

排查与解决的实战技巧

面对报错信息，最直接的办法是用 ldd /opt/awvs/scanner/awvs 检查每个动态链接是否可解析。若出现 “not found”，立刻搜索对应的 apt 或 yum 包名；如果显示 “version `XYZ' not found”，则需要在官方源或第三方仓库里挑选更高版本的库，或者通过 apt-get install -t bionic libnss3 指定目标发行版。

• 利用 dpkg -S 或 rpm -qf 确认文件归属。
• 在 headless 环境下，部署 xvfb-run 包裹启动脚本，模拟 X server，解决 Cannot open display。
• 对冲突的 libxcb，可通过 apt-get install libxcb1=1.13-1ubuntu2 强制降级到兼容版本。

如果仍旧卡在依赖链的深处，考虑使用官方提供的 Docker 镜像。容器内部已经预装了兼容的库版本，只需映射本地网络与存储，即可绕开宿主机的包管理噩梦。对那些必须在裸机上运行的场景，建议在部署前先跑一遍 apt-get update && apt-get install -y $(cat /opt/awvs/requirements.txt)，把所有潜在的依赖一次性写进清单。