一个运行在 aws 上的 TrinityCore 实例

Submitted by Dot on Tue, 10/04/2016 - 20:55

00 前言

  • TrinityCore 是什么?黑话,一个网络游戏框架;白话,一个魔兽世界服务器端
  • 本文只介绍怎样将编译好的 TrinityCore 移植到 ec2 上运行,至于编译,请参见 CentOS 7.2上编译TrinityCore
  • 服务器基于 TrinityCore 6.x master,面向魔兽世界当前版本 6.x.x 7.x.x,不定期更新
  • 由于大灾变之后几个资料片区域无 creature 和 object,加之 6.x master 稳定性差及诸多bug,本服务器娱乐性不强,可做学习交流观光旅游用途。将来如果有资源,会开放一个稳定的 3.3.5 版本供大家娱乐
  • 服务器地址 w.dotcra.com,可前往 http://w.dotcra.com 注册账号
  • TrinityCore is free, aws is free, we are free.
  • 这个服务器会存在多久?aws free tier 到期日是2017年9月10日,至少在那之前,服务器会一直存在

01 一些基础设施

  • 新建角色 110 级
  • 新建角色拥有足够的金币和背包
  • 所有种族和职业初始地均为 GM 岛,岛上有各职业神器和传奇装备商人、骑术训练师、暴风城和奥格瑞玛传送门
  • 荣誉击杀可能导致服务器崩溃,请大家和谐相处!
  • 更多设置一同被整合在两个文件中,modtc.sh (已并入 tcinit.sh )和 custom_tc_db.sql

02 怎么登录

  1. 编辑 WTF/Config.wtf,SET portal "w.dotcra.com"
  2. 前往 http://w.dotcra.com 下载登录器并注册账号,将 tc_bundle.txt 和 Wow_Patched.exe 解压至 wow 根目录,运行 Wow_Patched.exe 登录即可

03 怎样将编译好的 TrinityCore 移植到 ec2 上?

3.1 结论

  1. 假设你已在 CentOS 上编译好了 TrinityCore,工具均为 64 位版本
  2. 拷贝整个 TrinityCore Server 目录至 ec2
  3. 将 CentOS 上编译好的 boost文件(/lib64/libboost_*,一定是编译 TrinityCore 时用到的版本)拷贝至 ec2 相同目录下,所有者可能需要修改,权限 755:
    cd /lib64
    sudo chmod 755 libboost_*
  4. 拷贝 CentOS上的 /lib64/libcrypto.so.1.0.2j(文件名取决于你的openssl版本,这里仅供参考)至 ec2 相同目录下,所有者可能需要修改,在 ec2 上执行如下命令:
    cd /lib64
    sudo chmod 755 libcrypto.so.1.0.2j
    sudo ln -sf libcrypto.so.1.0.2j libcrypto.so.10
  5. 拷贝 CentOS 上的 /lib64/libstdc++.so.6.0.22(文件名取决于你的libstdc++版本,这里仅供参考)至 ec2 相同目录下,所有者可能需要修改,在 ec2 上执行如下命令:
    cd /lib64
    sudo chmod 755 libstdc++.so.6.0.22
    sudo ln -sf libstdc++.so.6.0.22 libstdc++.so.6
  6. 尝试运行 bnetserver,如果提示某文件 No such file or directory,则表明编译时使用的相应软件比 ec2 上较新,解决方法同前3步
  7. 至此, bnetserver 和 worldserver 应该可以运行了

3.2 过程

首先,你得在一台环境近似的主机上编译好 TrinityCore,我的 ec2 是 RedHat 7.2,所以我选择在 CentOS 7.2 上编译,工具均为64位版本。
由于 ec2 上并没有编译相同版本的 boost , openssl , libstdc++ , mysql 等,所以会提示找不到相应的动态库。 ldd 可以显示完整的依赖,但我们没必要全部拷贝。下面我们一步一步来,看看哪些是必须的。
先把编译好的 bnetserver 复制到 ec2 上运行,看看是什么情况,一个一个解决。

问题一,提示类似:
./bnetserver: error while loading shared libraries: libboost_system.so.1.60.0: cannot open shared object file: No such file or directory
此时我们将 CentOS 上编译好的 boost 文件(/lib64/libboost_*,一定是编译 TrinityCore 时用到的版本)拷贝至 ec2 相同目录下,所有者可能需要修改,权限 755 即可。
问题一解决了。
再次运行 ./bnetserver。

问题二,提示类似:
./bnetserver: /lib64/libcrypto.so.10: version `OPENSSL_1.0.2' not found (required by ./bnetserver)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./bnetserver)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./bnetserver)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./bnetserver)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./bnetserver)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libboost_system.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libboost_system.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /lib64/libboost_filesystem.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /lib64/libboost_filesystem.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libboost_filesystem.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libboost_filesystem.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libboost_thread.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libboost_thread.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /lib64/libboost_program_options.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libboost_program_options.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libboost_program_options.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /lib64/libboost_iostreams.so.1.60.0)
./bnetserver: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libboost_iostreams.so.1.60.0)
这次报错有点多,挺吓人,其实就是两个文件的版本问题。
/lib64/libcrypto.so.10
先看看 CentOS 上的 /lib64/libcrypto.so.10,
[[email protected] ~]$ ll /lib64/libcrypto.so.10 
lrwxrwxrwx. 1 root root 19 Sep 26 19:25 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.2j
再看看 ec2 上的,
[[email protected] ~]$ ll /lib64/libcrypto.so.10 
lrwxrwxrwx. 1 root root 19 Sep 29 15:40 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
把 CentOS 上的 /lib64/libcrypto.so.1.0.2j 拷贝到ec2同目录下(所有者可能需要修改,权限755即可),然后在 ec2 上将 /lib64/libcrypto.so.10 指向新文件libcrypto.so.1.0.2j
cd /lib64
chmod 755 libcrypto.so.1.0.2j
ln -sf libcrypto.so.1.0.2j libcrypto.so.10
/lib64/libstdc++.so.6
先看看 CentOS 上的 /lib64/libstdc++.so.6,
[[email protected] ~]$ ll /lib64/libstdc++.so.6
lrwxrwxrwx. 1 root root 19 Sep 16 20:09 /lib64/libstdc++.so.6 -> libstdc++.so.6.0.22
再看看 ec2 上的,
[[email protected] ~]$ ll /lib64/libstdc++.so.6
lrwxrwxrwx. 1 root root 19 Sep  4 09:19 /lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
把 CentOS 上的 /lib64/libstdc++.so.6.0.22 拷贝到 ec2 同目录下(所有者可能需要修改,权限 755 即可),然后在 ec2 上将 /lib64/libstdc++.so.6 指向新文件libstdc++.so.6.0.22
cd /lib64
chmod 755 libstdc++.so.6.0.22
ln -sf libstdc++.so.6.0.22 libstdc++.so.6

至此,./bnetserver 已经可以正常运行了。

以上是一种方案,这种方案问题在于,你需要在 CentOS 上编译新版的 boost 和 gcc,这是个很耗时的过程。
另一种方案是在 Fedora 上编译,因为软件较新,你可以直接编译 TrinityCore 。但随之而来的问题是,你必须解决 Fedora 和 ec2(Redhat 7.2) 上 glibc 的版本差异,否则服务器同样无法运行,在 ec2 上编译一个新版的 glibc 应该不会太久,或许是个办法,但我还没有尝试过。12月1日更新:今天尝试了下,编译新版 glibc 需要新版 binutils,当两个都编译好以后,还是会由于 mariaDB 版本不符而无法运行(在 Fedora 上编译时 mariaDB 是10.1.19,而 CentOS 上最新是 5.5.50)。而编译 10.1.19 需要 cmake,这个倒是可以 yum,但配置 mariaDB 的过程同样不会顺利。考虑到 Fedora 上相应软件一更新, ec2 上也要相应修改,最终放弃在 Fedora 上编译。

 

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.