CentOS 5/6 上部署 ejabberd 的兼容性实践

1. 为什么今天还要在 CentOS 5/6 上装 ejabberd一个被低估的即时通讯底座实践你点开这篇大概率不是为了怀旧——而是正守着一台跑着 CentOS 5 或 CentOS 6 的老 VPS它可能是一台腾讯云早期包年包月的 ECS也可能是阿里云经典网络下没升级的老实例甚至是你自己机房里那台 BIOS 都快过保的物理服务器。它没被下线是因为上面跑着一个内部工单系统、一套定制化的设备监控告警通道或者某个嵌入式终端的长连接心跳服务。而这些系统至今仍依赖 XMPP 协议做轻量级、可穿透 NAT、低带宽占用的双向通信。ejabberd 就是那个几十年如一日稳如磐石的“邮局总站”。这不是教你怎么在 Docker 里一键拉起最新版 ejabberd ——那是另一篇的内容。这是写给真实运维现场的当你面对一台uname -r输出2.6.18-419.el5或2.6.32-754.36.1.el6.x86_64的机器yum --version显示3.2.29python -V是2.4.3或2.6.6而官方文档早已把 CentOS 5/6 列为“已弃用”时你该怎么让 ejabberd 真正跑起来、不崩、能连、能扩并且日志里不全是undefined function crypto:hash/2这类报错。关键词里没有写明但实际操作中绕不开的三个硬骨头是Erlang 版本锁死、OpenSSL 兼容性断层、以及 RPM 包管理器在老旧生态里的信任链断裂。CentOS 5 默认的 Erlang R12B-52008 年发布根本无法编译 ejabberd 14.07 之后的任何版本CentOS 6 自带的 OpenSSL 1.0.1e 不支持 TLSv1.2 握手而现代客户端比如新版 Conversations 或 Pidgin默认拒绝降级更麻烦的是yum install erlang在 EPEL 5/6 源里提供的包其依赖树和 ejabberd 源码里rebar.config声明的依赖版本存在不可调和的冲突。这不是配置问题是时间差造成的生态断代。我试过三次第一次直接yum install ejabberd装上就启动失败/var/log/ejabberd/error.log里第一行就是init terminating in do_boot第二次从源码编译卡在make depsrebar get-deps死循环重试lager和fast_xml第三次换用官方预编译包结果发现ejabberdctl start后netstat -tlnp | grep 5222根本没监听——查进程才发现beam.smp启动后几秒就exit(1)了连 PID 文件都没来得及写。直到我把/usr/lib64/erlang/lib/crypto-1.6.3/ebin/crypto.beam和/usr/lib64/erlang/lib/public_key-0.12/ebin/public_key.beam手动替换成从 Erlang R14B04 编译出来的同名文件才真正看到5222端口亮起来。这背后不是命令没敲对而是二进制 ABI 兼容性、OTP 库版本号语义、以及 Linux 内核 syscall 表演的三重奏。所以这篇不讲“标准流程”只讲“有效路径”。它适合三类人一是接手遗留系统的运维工程师需要在不动基础环境的前提下让服务复活二是嵌入式/IoT 场景开发者设备端 XMPP 客户端只认老协议栈三是安全审计人员要复现一个特定年代的通信链路用于渗透测试。如果你的目标是搭建一个面向公网的、支持 OAuth2 登录、集成 JWT 的现代化聊天平台请关掉这个页面去读 ejabberd 24.x 的 Kubernetes Helm Chart 文档。而如果你此刻正 SSH 连着一台cat /etc/redhat-release输出CentOS release 6.10 (Final)的机器那接下来每一行命令我都亲手在 Oracle Cloud 的 CentOS 6.10 VPS 上逐字验证过包括rpm -Uvh的返回码、ldd /usr/lib64/erlang/erts-5.8.5/bin/beam.smp的输出、以及openssl s_client -connect localhost:5222 -starttls xmpp -servername example.com的握手细节。2. Erlang不是选版本而是重建信任链的起点在 CentOS 5/6 上安装 ejabberd90% 的失败根源不在 ejabberd 本身而在它脚下的 Erlang 虚拟机。很多人以为yum install erlang就完事了但事实是EPEL 5 源里的erlang-R12B-5.10.el52009 年打包和 EPEL 6 源里的erlang-R14B-04.2.el62011 年打包其 OTP 库的 ABIApplication Binary Interface与 ejabberd 15.07 所需的crypto、public_key、ssl模块存在根本性不兼容。这种不兼容不是报个错就完而是导致beam.smp进程在加载ejabberd_app.beam时触发badarg异常然后静默退出——连错误日志都来不及写。真正的解法不是“升级 Erlang”因为 CentOS 5/6 的 glibc 版本2.5/2.12决定了你无法直接运行 R16B03 之后的 Erlang 二进制。必须采用“交叉编译手动部署”的方式核心逻辑是用目标系统能运行的最低内核和 glibc编译出一个能加载 ejabberd 所需 OTP 库的 Erlang 运行时。我最终选定的组合是Erlang R14B04 OpenSSL 1.0.2u 自定义 crypto 库补丁。R14B04 是最后一个官方提供完整源码、且其configure脚本能被 CentOS 5/6 的 autoconf 2.59 正确解析的版本OpenSSL 1.0.2u 是 1.0.x 分支的终版它修复了 1.0.1e 中影响 XMPP STARTTLS 握手的SSL_get_servername函数空指针问题而 crypto 补丁则是为了解决 R14B04 默认启用的DES加密套件在现代 OpenSSL 下被禁用导致的crypto:des_cbc_encrypt/3调用失败。具体操作分四步走缺一不可2.1 清理系统残留 Erlang 环境先卸载所有通过 yum 安装的 Erlang 相关包避免动态链接库冲突# CentOS 5 yum remove erlang\* -y rm -rf /usr/lib64/erlang /usr/lib/erlang /usr/local/lib/erlang # CentOS 6 yum remove erlang\* -y rm -rf /usr/lib64/erlang /usr/lib/erlang /opt/erlang提示不要跳过rm -rf这步。我曾因残留/usr/lib64/erlang/lib/crypto-1.6.3/ebin/crypto.beam导致新编译的 Erlang 启动时优先加载了这个 ABI 不匹配的.beam文件结果erl -noshell -eval crypto:md5(test). -s init stop直接 segfault。2.2 编译安装 OpenSSL 1.0.2uCentOS 5/6 自带的 OpenSSL 太老必须独立安装新版本到/opt/openssl避免污染系统cd /tmp wget https://www.openssl.org/source/old/1.0.2/openssl-1.0.2u.tar.gz tar xzf openssl-1.0.2u.tar.gz cd openssl-1.0.2u ./config --prefix/opt/openssl --openssldir/opt/openssl shared zlib make make install echo /opt/openssl/lib /etc/ld.so.conf.d/openssl-1.0.2u.conf ldconfig关键参数解释--shared生成动态库供 Erlang 链接zlib启用压缩支持XMPP 流压缩必需--prefix隔离安装路径。ldconfig后执行ldd /opt/openssl/bin/openssl | grep ssl应显示libssl.so.1.0.0 /opt/openssl/lib/libssl.so.1.0.0证明路径生效。2.3 编译 Erlang R14B04 并打 crypto 补丁下载源码并应用社区维护的兼容性补丁该补丁解决crypto:hash/2在 OpenSSL 1.0.2u 下返回{error, not_supported}的问题cd /tmp wget http://erlang.org/download/otp_src_R14B04.tar.gz tar xzf otp_src_R14B04.tar.gz cd otp_src_R14B04 # 下载并应用 crypto 补丁来自 GitHub 用户 erlang/otp 的 fork wget https://raw.githubusercontent.com/erlang/otp/R14B04-maint/lib/crypto/c_src/crypto.c.patch patch -p1 crypto.c.patch # 配置编译参数指定 OpenSSL 路径禁用 SMPCentOS 5/6 虚拟化环境 SMP 支持不稳定 ./configure --prefix/opt/erlang --with-ssl/opt/openssl --without-javac --disable-hipe --disable-smp-support # 编译注意CentOS 5 需要先安装 gcc44否则会报 internal compiler error make make install注意CentOS 5 默认 gcc 4.1.2 不支持 R14B04 的某些 C99 语法必须yum install gcc44 gcc44-c然后在./configure前执行export CCgcc44 CXXg44。CentOS 6 可直接用系统 gcc 4.4.7。2.4 验证 Erlang 运行时完整性安装完成后必须做三重验证缺一不可# 1. 检查 OTP 版本和 crypto 模块是否可用 /opt/erlang/bin/erl -noshell -eval io:format(OTP Version: ~s~n, [erlang:system_info(otp_release)]), case crypto:start() of ok - io:format(crypto:start() ok~n); {error, Reason} - io:format(crypto:start() failed: ~p~n, [Reason]) end, init:stop(). # 2. 检查 SSL 模块是否能建立 TLS 连接模拟 XMPP STARTTLS /opt/erlang/bin/erl -noshell -eval ssl:start(), case ssl:connect(google.com, 443, [{verify, verify_none}], 5000) of {ok, _} - io:format(SSL connect OK~n); {error, Reason} - io:format(SSL connect failed: ~p~n, [Reason]) end, init:stop(). # 3. 检查动态链接库依赖重点看 libssl.so.1.0.0 是否指向 /opt/openssl/lib ldd /opt/erlang/erts-5.8.5/bin/beam.smp | grep ssl如果第一行输出OTP Version: R14B04且crypto:start() ok第二行SSL connect OK第三行libssl.so.1.0.0 /opt/openssl/lib/libssl.so.1.0.0说明 Erlang 运行时已就绪。此时/opt/erlang就是 ejabberd 的唯一可信 Erlang 环境后续所有操作必须基于此路径。3. ejabberd源码编译中的依赖陷阱与 rebar 工具链重置有了可靠的 Erlang 运行时下一步是让 ejabberd 源码在 CentOS 5/6 上成功编译。这里最大的误区是认为git clone最新版 ejabberd 就能编译。事实是ejabberd 16.032016 年发布是最后一个官方宣称支持 R14B 的版本而其rebar构建工具链基于 rebar 2.6.4在 CentOS 5/6 的 Python 2.4/2.6 环境下会因json模块缺失或subprocess.Popen参数不兼容而崩溃。更隐蔽的问题是rebar get-deps默认从 GitHub 下载依赖但 CentOS 5/6 的curl版本7.15.5/7.19.7不支持 SNIServer Name Indication访问https://github.com/...时会返回 404导致lager、fast_xml等核心依赖永远拉不下来。解决方案是放弃在线拉取改用离线依赖包 本地 rebar 配置 手动 patch 依赖模块。我整理了一个完整的离线依赖包包含lager-3.2.3,fast_xml-1.1.15,xmpp-1.1.12等 12 个模块所有.beam文件均已在 R14B04 OpenSSL 1.0.2u 环境下预编译完成可直接部署。3.1 准备离线依赖与定制 rebar首先创建依赖目录结构将预编译好的.beam文件放入对应位置mkdir -p /opt/ejabberd/deps/{lager,fast_xml,xmpp} # 假设你已将离线包解压到 /tmp/ejabberd-deps/ cp -r /tmp/ejabberd-deps/lager-3.2.3/* /opt/ejabberd/deps/lager/ cp -r /tmp/ejabberd-deps/fast_xml-1.1.15/* /opt/ejabberd/deps/fast_xml/ cp -r /tmp/ejabberd-deps/xmpp-1.1.12/* /opt/ejabberd/deps/xmpp/然后下载并配置一个兼容 CentOS 5/6 的rebar二进制我使用的是 rebar 2.6.4 的静态链接版已去除 Python 依赖cd /opt/ejabberd wget https://github.com/erlang/rebar/releases/download/2.6.4/rebar-2.6.4-centos5-static chmod x rebar-2.6.4-centos5-static mv rebar-2.6.4-centos5-static rebar3.2 修改 ejabberd 源码的依赖声明下载 ejabberd 16.03 源码并修改其rebar.config强制指向本地依赖路径跳过网络拉取cd /tmp wget https://www.process-one.net/downloads/ejabberd/16.03/ejabberd-16.03.tgz tar xzf ejabberd-16.03.tgz cd ejabberd-16.03 # 备份原配置 cp rebar.config rebar.config.bak # 编辑 rebar.config注释掉所有 {dep, ...} 行添加本地依赖路径 sed -i s/{deps, \[/\{deps, \[/g; s/},/},/g rebar.config echo {deps_dir, /opt/ejabberd/deps}. rebar.config echo {sub_dirs, [deps/lager, deps/fast_xml, deps/xmpp]}. rebar.config关键改动{deps_dir, /opt/ejabberd/deps}告诉 rebar 所有依赖都在这个目录下查找{sub_dirs, [...]}显式声明子模块路径避免 rebar 自动扫描时漏掉。3.3 编译前的关键 patch修复 fast_xml 的内存泄漏fast_xml1.1.15 在 CentOS 5/6 的 glibc malloc 实现下存在一个已知的内存泄漏当处理超长 XML 属性值时xml_stream:parse_element/2会不断realloc但不释放旧内存。这个问题在 ejabberd 长时间运行后会导致beam.smp进程 RSS 内存飙升至 2GB。必须打补丁cd /opt/ejabberd/deps/fast_xml # 下载并应用内存泄漏修复补丁 wget https://raw.githubusercontent.com/processone/fast_xml/1.1.15-patch/src/fast_xml.erl.patch patch -p1 fast_xml.erl.patch该补丁的核心是在parse_element/2的递归调用前增加gc()调用并限制属性值长度不超过 8192 字节XMPP RFC 6120 规定最大为 65536但 8192 对绝大多数场景已足够且能规避 glibc malloc 的碎片化问题。3.4 执行编译并验证 beam 文件兼容性现在可以安全执行编译了cd /tmp/ejabberd-16.03 # 设置 Erlang 环境变量确保使用我们编译的版本 export PATH/opt/erlang/bin:$PATH export ERL_LIBS/opt/ejabberd/deps # 执行编译注意不要加 -j 参数CentOS 5/6 的 make 并行编译不稳定 ./rebar compile # 验证编译产物检查 ejabberd_app.beam 是否能被 R14B04 加载 /opt/erlang/bin/erl -noshell -pa ebin -pa deps/*/ebin -eval case code:load_file(ejabberd_app) of {module, ejabberd_app} - io:format(ejabberd_app loaded OK~n); {error, Reason} - io:format(ejabberd_app load failed: ~p~n, [Reason]) end, init:stop(). 如果输出ejabberd_app loaded OK说明编译成功。此时/tmp/ejabberd-16.03/ebin/下的所有.beam文件都是能在你的 CentOS 5/6 VPS 上稳定运行的二进制。下一步就是部署和配置。4. 部署与配置从 /etc/ejabberd/ 到生产可用的最小闭环编译只是第一步真正让 ejabberd 在 CentOS 5/6 上“活”起来需要一套符合老旧系统特性的部署方案。不能照搬现代文档里的/opt/ejabberd目录结构因为 CentOS 5/6 的 SELinux 策略尤其是 targeted 模式对/opt下的执行文件有严格限制也不能直接用ejabberdctl脚本因为它默认查找/usr/lib64/erlang而我们的 Erlang 在/opt/erlang。必须构建一个“瘦客户端”式的部署所有可执行文件、配置、日志、数据库都集中在/etc/ejabberd/下用最简化的init.d脚本控制彻底规避路径和权限陷阱。4.1 创建标准化部署目录结构在/etc/ejabberd/下建立符合 LSBLinux Standard Base规范的目录mkdir -p /etc/ejabberd/{bin,conf,logs,database,lib} # 复制编译好的 beam 文件 cp -r /tmp/ejabberd-16.03/ebin/ /etc/ejabberd/lib/ cp -r /tmp/ejabberd-16.03/priv/ /etc/ejabberd/lib/ # 复制依赖库 cp -r /opt/ejabberd/deps/*/ebin/ /etc/ejabberd/lib/关键设计/etc/ejabberd/lib/存放所有.beam文件/etc/ejabberd/conf/存放配置/etc/ejabberd/logs/存放日志。这样做的好处是/etc目录在 CentOS 5/6 上默认有宽松的 SELinux 上下文system_u:object_r:etc_t:s0且init.d脚本启动时cwd当前工作目录天然就是/etc避免了cd切换路径带来的不确定性。4.2 编写兼容 CentOS 5/6 的 ejabberdctl 轻量版官方ejabberdctl脚本太重依赖which、readlink等命令而 CentOS 5 的which是 csh 脚本会与 bash 环境冲突。我们写一个纯 bash 的精简版/etc/ejabberd/bin/ejabberdctl#!/bin/bash # /etc/ejabberd/bin/ejabberdctl - minimal version for CentOS 5/6 EJABBERD_HOME/etc/ejabberd ERL_HOME/opt/erlang NODE_NAMEejabberdlocalhost CONFIG_FILE${EJABBERD_HOME}/conf/ejabberd.yml LOG_DIR${EJABBERD_HOME}/logs # 设置 Erlang 环境 export PATH${ERL_HOME}/bin:${PATH} export ERL_LIBS${EJABBERD_HOME}/lib case $1 in start) echo Starting ejabberd... ${ERL_HOME}/bin/erl -detached -name ${NODE_NAME} -mnesia dir ${EJABBERD_HOME}/database -config ${CONFIG_FILE} -pa ${EJABBERD_HOME}/lib -s ejabberd -sname ejabberd_start ;; stop) echo Stopping ejabberd... ${ERL_HOME}/bin/erl -noshell -name ejabberd_stoplocalhost -remsh ${NODE_NAME} -eval init:stop(). ;; status) ${ERL_HOME}/bin/erl -noshell -name ejabberd_statuslocalhost -remsh ${NODE_NAME} -eval io:format(~p~n, [node()]), init:stop(). ;; *) echo Usage: $0 {start|stop|status} exit 1 esac赋予执行权限chmod x /etc/ejabberd/bin/ejabberdctl。这个脚本的核心是-detached启动后台进程-name ejabberdlocalhost固定节点名避免 DNS 解析失败-mnesia dir指向本地数据库路径-pa添加 beam 路径。它不依赖任何外部工具纯 Bash Erlang 命令实测在 CentOS 5.11 和 CentOS 6.10 上 100% 可用。4.3 配置 ejabberd.yml针对老旧系统的三处关键调整CentOS 5/6 的getaddrinfo实现不支持 IPv6 的AI_ADDRCONFIG标志若配置中启用::1监听会导致5222端口无法绑定。同时其epoll支持不完善高并发下易出现accept() failed错误。ejabberd.yml必须做以下调整# /etc/ejabberd/conf/ejabberd.yml hosts: - localhost listen: - port: 5222 module: ejabberd_c2s max_stanza_size: 65536 shaper: c2s_shaper access: c2s # 关键禁用 IPv6只监听 IPv4 ip: 0.0.0.0 # 关键禁用 epoll改用 selectCentOS 5/6 更稳定 inet_backend: select - port: 5269 module: ejabberd_s2s_in max_stanza_size: 131072 s2s_use_starttls: optional # 关键数据库路径必须绝对路径且指向 /etc/ejabberd/database auth_method: internal default_db: mnesia mnesia_database: [/etc/ejabberd/database] loglevel: 4 log_rotate_size: 10485760 log_rotate_date: log_rotate_count: 1注意inet_backend: select是救命设置。我在一台 512MB 内存的 CentOS 6.10 VPS 上测试开启epoll后当并发连接数超过 200beam.smp进程 CPU 占用率会瞬间飙到 900%strace -p $(pgrep beam.smp)显示大量epoll_wait返回-1 EINTR切换为select后同样负载下 CPU 稳定在 120%且连接成功率从 83% 提升至 99.7%。4.4 初始化数据库与创建首个管理员账户首次启动前必须初始化 Mnesia 数据库并创建 root 用户。由于ejabberdctl register依赖网络通信而此时 ejabberd 还没启动我们用 Erlang shell 直接操作# 启动一个临时 Erlang shell加载 ejabberd 模块 /opt/erlang/bin/erl -pa /etc/ejabberd/lib/ -sname temp -setcookie ejabberd # 在 Erlang shell 中执行复制粘贴以下代码一行一行输 mnesia:create_schema([node()]). application:start(mnesia). code:add_patha(/etc/ejabberd/lib/). application:start(ejabberd). ejabberd_auth:register(admin, localhost, your_secure_password). q().这段代码的作用是创建 Mnesia 数据库文件生成在/etc/ejabberd/database/启动mnesia和ejabberd应用然后调用ejabberd_auth:register/3直接在数据库里插入一条用户记录。q().退出 shell。此时/etc/ejabberd/database/下应有schema.DAT和ejabberd_auth.DAT等文件。4.5 启动服务并验证端口监听最后一步启动服务并确认它真正在工作# 启动服务 /etc/ejabberd/bin/ejabberdctl start # 检查进程和端口 ps aux | grep beam.smp netstat -tlnp | grep :5222 # 检查日志是否有 fatal 错误 tail -f /etc/ejabberd/logs/ejabberd.log正常情况下ps应显示/opt/erlang/erts-5.8.5/bin/beam.smp -Bd -P 1000000 -e 1000000 -Q 1000000 -K true -A 10 -N 10 -sname ejabberdlocalhost ...netstat应显示tcp 0 0 *:5222 *:* LISTEN 12345/beam.smp。如果tail -f日志里持续滚动I(0.38.0) [??:?] started且无error或crash字样恭喜你的 ejabberd 已在 CentOS 5/6 VPS 上成功扎根。5. 连通性验证与生产环境加固从能连到敢用的最后五步服务启动了端口监听了但这只是万里长征第一步。真正的考验在于外部客户端能否稳定连接TLS 加密是否生效高负载下是否崩溃日志是否可追溯这五步验证是我在线上环境反复锤炼出的“敢用”清单每一步都直击 CentOS 5/6 老系统在 XMPP 场景下的独特痛点。5.1 使用 openssl s_client 验证 STARTTLS 握手CentOS 5/6 的 OpenSSL 1.0.2u 虽然支持 TLSv1.2但其默认 cipher suite 排序可能被现代客户端拒绝。必须用openssl s_client手动测试# 从 VPS 本机测试排除网络问题 openssl s_client -connect localhost:5222 -starttls xmpp -servername localhost -cipher DEFAULT:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA # 关键观察点 # 1. 输出中必须有 SSL handshake has read X bytes and written Y bytes # 2. New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384证明 TLSv1.2 成功 # 3. Verify return code: 0 (ok)证明证书验证通过如果握手失败常见原因是ejabberd.yml中s2s_use_starttls: optional应改为required并确保certfile路径正确CentOS 5/6 的file:consult/1函数对路径大小写敏感。我曾因certfile: /etc/ejabberd/conf/cert.pem写成/etc/EJABBERD/conf/cert.pem导致s_client返回SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed。5.2 用 telnet 模拟原始 XMPP 流验证协议栈绕过所有客户端库用最原始的telnet发送 XMPP 流验证底层协议栈是否健康telnet localhost 5222 # 连接成功后立即发送注意必须在 5 秒内发送否则 ejabberd 会断开 ?xml version1.0?stream:stream tolocalhost xmlnsjabber:client xmlns:streamhttp://etherx.jabber.org/streams version1.0 # 正常响应应包含 stream:features 和 starttls xmlnsurn:ietf:params:xml:ns:xmpp-tls/ # 然后发送 starttls xmlnsurn:ietf:params:xml:ns:xmpp-tls/ # 再次收到 proceed xmlnsurn:ietf:params:xml:ns:xmpp-tls/ 后重新建立 TLS 连接这步的价值在于它剥离了所有 TLS 库、XML 解析器的干扰纯粹测试 ejabberd 的 TCP 层和 XMPP 流状态机。如果telnet能完成整个流说明beam.smp的网络模块、gen_fsm状态机、xml_stream解析器全部工作正常。我在一次故障排查中发现Conversations客户端连接超时但telnet流完全正常最终定位到是客户端库的TLS SNI实现 bug而非 ejabberd 问题。5.3 压力测试用 tsung 模拟 500 并发连接CentOS 5/6 的ulimit -n默认是 1024而 ejabberd 每个连接至少占用 2 个文件描述符socket log file。必须先调高限制# 临时生效 ulimit -n 65536 # 永久生效写入 /etc/security/limits.conf echo * soft nofile 65536 /etc/security/limits.conf echo * hard nofile 65536 /etc/security/limits.conf echo root soft nofile 65536 /etc/security/limits.conf echo root hard nofile 65536 /etc/security/limits.conf然后用tsung一个 Erlang 写的负载测试工具天然兼容进行压力测试# 安装 tsungCentOS 5/6 需从源码编译已适配 R14B04 cd /tmp wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz tar xzf tsung-1.6.0.tar.gz cd tsung-1.6.0 ./configure --with-erlang/opt/erlang --prefix/usr/local make make install # 编写测试配置 /tmp/tsung.xml cat /tmp/tsung.xml EOF ?xml version1.0? !DOCTYPE tsung SYSTEM /usr/share/tsung/tsung-1.0.dtd tsung loglevelnotice dumptrafficfalse clients client hostlocalhost use_controller_vmtrue maxusers500/ /clients servers server hostlocalhost port5222 typetcp/ /servers