仮想マシンを利用することについて
今回はUbuntu Serverを個別のマシンではなく、ゲームを動かすWindows機上に仮想マシンを用意して動作させます。
個別にマシンやVPSがあれば必須ではありませんが、ゲームをする同一PC上でサーバを運用するならメリットは大きいです。
リソースに問題がないならWindows版サーバを立ち上げてもいいんですが、ホードの際や人数が多かったりすると無駄にリソースが持っていかれてゲームにならないので仮想マシンでリソースを制限します。
これによりホードなどの高負荷の際のサーバパフォーマンスは下がりますが、ホストのゲームプレイについてはWindows版サーバを制限なしに立ち上げるよりはマシかなと。
通常プレイにおいては当環境ではサーバパフォーマンスも悪くなかったので全然運用できます。
ただし、ホードの際はCPU 99.9%張り付きになるのでゾンビが止まったりワープしたりしますが、そこに目を瞑れば全然いけます。
RWGのマップ生成の際はコアを制限していると激遅なので一時的にコア数とメモリを増やしたほうがいいと思います。
もし個別にUbuntu Serverマシンがあるのであればそちらを利用するほうが圧倒的にパフォーマンスは良いです。
また、今回用いるVMware Workstation Player でなくてもHyper-Vでも設定さえすれば動きます。
検証環境
ホストマシン
OS |
Windows 10 Pro x64 |
CPU |
Intel Core i5 4590 |
Memory |
24GB |
GPU |
NVIDIA GeForce GTX 1070 |
Virtual |
VMware Workstation Player |
ゲストマシン
OS |
Ubuntu Server 18.04 LTS 64bit |
CPU |
Intel Core i5 4590 1 core 割当 |
Memory |
4GB |
CPUによってはSteamCMDが動作しませんのでご注意ください。
こちらで確認したものだと、
Raspberry Pi 4のARMプロセッサでは動作しませんでした。
64bit OSではそもそも必要パッケージが入らないので完全にダメで、32bit OSでもパッケージはあれどSegmentation faultで全く動作しなかったのでおそらくARMは完全にダメだと思います。
仮想マシンの作成
今回はUbuntu Server 18.04 LTS 64bitを用いますが、Desktopでも構いません。
ただし、
Desktopはメモリ消費もCPU消費も激しいので
Serverを強く推奨します。
また、7dtd DedicatedはおそらくLinuxでも64bitオンリーなので64bitを選びましょう。
なお、公式Ubuntuから落とすとめちゃくちゃ遅いので
ミラーを使うのをオススメします。
とりあえず理研のUbuntu 18.04を貼っておきます。
Ubuntu 18.04.4 LTS (Bionic Beaver)
※2024/07/22現在かなり古いバージョンなので新しいの入れてください。
仮想マシンの設定
当環境ではこのように設定しています。
CPUもメモリも割当が大きければ大きいほどパフォーマンスに余裕が生まれますが、ゲームPCと同一PCで動かす場合はある程度制限したほうがいいでしょう。
なお、メモリはある程度ないと動かないのでおおよそ10GB以上は必要だと思われます。
現在身内サーバでUndead Legacyのサーバを動かしていますが、11GBくらいは消費してます。
また、メモリに余裕があるなら実メモリを使用するようにしてもいいと思います。
VMware Workstation Playerでは標準で実メモリだけでなくHDD/SSD内部のメモリファイルを使用するので転送速度が遅いとパフォーマンスが下がります。
実際のところそんなに影響はないですが、HDDの寿命が縮みやすいのでちょっと心配。
実メモリを使う場合は.vmxファイルに次の設定を追記/変更を行います。
MemTrimRate = "0"
mainMem.useNamedFile= "FALSE"
sched.mem.pshare.enable = "FALSE"
prefvmx.useRecommendedLockedMemSize = "TRUE"
MemAllowAutoScaleDown = "FALSE"
ディスクI/Oが減少しますが、
設定した量だけの物理メモリを消費するため、その余裕がない状態だとホストOSごとパフォーマンス低下する恐れがあります。
必ず余裕のある状態で実行するようにしましょう。
ネットワークの設定
ここで
重要なのがネットワークの設定です。
通常はNATになっているんですが、これだとサーバ用途としては使用できません。
ここでのNATはルータのNAT機能ではなく、ホストマシンがゲストマシンのIPアドレス変換を行うNATとなります。
そのため、ゲストマシンが始点の通信はできても、
外部が始点の通信はルータから見えないためただしくポートフォワードできません。
7dtdサーバはクライアント(外部)が始点となる通信があるのでこれでは運用ができません。
また、ネットワークスセグメントが異なるためホストマシンからの通信もできません。
ポートフォワードの簡単な仕組みについては
7Days To Die サーバの建て方#ポート開放と転送の必要性にて解説しています。
そこでネットワークの設定を
ブリッジにします。
ブリッジにするとホストマシンにあるNIC(ネットワークインタフェース)と直結し、DHCPのIP割当もルータあるいは専用のDHCPサーバから割り当てされるため、
ルータからすると一つの独立したマシンがあるように見えます。(IPv6なら設定次第で外部からも見える)
これにより
ポートフォワードが可能となるため、外部が始点の通信でもゲストマシンに届くようになります。
前置きはこれぐらいにして、設定は単純にブリッジを選択します。
物理ネットワーク接続の状態を複製は特にネットワーク接続の切り替えがないなら不要です。
合っても特に問題はないかなと思いますが。
あとはアダプタ設定にてブリッジするNICを選択します。
複数ある場合はインターネット接続に使用しているNICを選択しましょう。
SSHのインストール
特に必要はありませんが、コマンドのコピペやModを導入する際にあると結構便利です。
また、SFTPはSSHプロトコルを利用するのでファイルのやりとりもこれがあれば簡単にできます。
ただし、サーバの制御ができてしまう上に今回はセキュリティ面の設定を一切行わないため、外部への公開はしないほうが良いでしょう。
ローカルエリアからのみのアクセスを前提とするためご注意ください。
もしセキュリティ面の設定(公開鍵認証方式)も行う場合はRaspberry Pi 4の記事になりますが、同様の設定でできます。
Raspberry Pi 4をサーバ仕様にセットアップする#SSHを公開鍵認証方式に変更する
SSHのインストール自体は簡単で、パッケージからインストールすればすぐに使えます。
$ sudo apt install openssh-server
$ sudo systemctl enable ssh
$ sudo systemctl restart ssh
あとはCygwinなどのSSHから
ユーザ名@ipで接続できます。
$ ssh user@192.168.1.163
IPアドレスのチェックは「ip addr show」でできます。
以下の出力例はサーバ設定ごにょごにょしたやつなので異なると思いますが、おそらくeth0かなにかの項目があると思います。
そこにあるinetの値がipv4のローカルIPアドレスとなります。
なお、ipv6の環境はまた異なるので別途検索してください。(ipv6の環境がない)
$ ip addr show
...
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9a:07:6d:8d:b9:7c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.163/24 brd 192.168.1.255 scope global br0
...
SFTPも同様に22番ポートで接続するとファイルへのアクセスも可能です。
当環境ではWinSCPからSFTPでアクセスしています。
依存パッケージのインストール
i386(32bit)アーキテクチャを追加し、32bitのgccライブラリをインストールします。
なお、Ubuntu 19.10では32bit OS及びパッケージを廃止しているため、いつこれらの提供が廃止されるかわかりません。
といいつつ一部のパッケージのサポートを継続しているようなのでほんとにどうなることやら。
もしかするとタイミングによっては廃止されている可能性もあるのでご注意ください。
その場合はold-releaseなどから引っ張る必要があるかもしれません。
とりあえず執筆当時の2020/03/18では問題なくインストールできました。
$ sudo dpkg --add-architecture i386
$ sudo apt update
$ sudo apt install lib32gcc-s1
2024/07/25現在、Ubuntu 24.02で確認するとlib32gcc1が無くなっており、lib32gcc-s1へとリネームされているようでした。
後者をインストールすればうまく動作しました。
SteamCMDのインストール
お次に今回の肝である
SteamCMDをインストールします。
UbuntuではパッケージとしてSteamCMDが配布されていますが、パスが通ってるところにインストールされるわけじゃないので個別にダウンロードして展開するほうがわかりやすいと思います。
確認してないけど、パッケージ版も32bitだから64bit OSだとそもそもないかも知れない。
$ mkdir ~/steamcmd && cd ~/steamcmd
$ wget http://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
$ tar zxvf steamcmd_linux.tar.gz
SteamCMDのログインと7dtdサーバのインストール
インストールできたらSteamCMDを起動します。
$ ./steamcmd.sh
起動できたら
anonymouseでログインします。
なお、個別IDでログインするように説明しているところもありますが、正直めんどいだけなのでanonymousでOK。
Steam> login anonymous
ログインできたら7dtdサーバをダウンロードします。
force_install_dirはインストール場所を強制的に変更するコマンドなので特に必要ではありません。
変更しない場合はユーザディレクトリ直下にできるSteam/steamapps内部にインストールされるはずです。
なお、app_updateは結構時間かかります。
Steam> force_install_dir ./7dtdserver
Steam> app_update 294420
Steam> quit
また、7dtdサーバの更新も同様にすることでできます。
ベータが必要な場合は「app_update 294420 -beta a16.4」みたいな感じでいけるはず。
基本はSteamのプロパティにあるベータと同じ値なのでそちらを参照してください。
インストール完了したらインストール先に移動し、startserver.shを実行します。
$ cd 7dtdserver
$ ./startserver.sh
起動はできませんが、serverconfig.xmlが生成されるかと思います。
serverconfig.xmlの編集
startserver.shを実行するとserverconfig.xmlが生成されるのでそれをベースに編集します。
各項目にはコメントが振られているのでプロパティ名とコメントを見つつ設定します。
$ nano serverconfig.xml
...とは言ったものの、ぶっちゃけCUIでやってられないのでホストPC側にて
Savannah Manager付属のConfigEditorで生成したものをSFTP経由でサーバ側へ移動させました。
サーバの起動
単純に
サーバを起動する場合はstartserver.shにconfigfileオプションをつけるとできます。
$ ./startserver.sh -configfile=serverconfig.xml
ただし、サーバ動作中は何もUbuntuサーバへのコマンド操作ができなくなるのでscreenで動作させるといい感じ。
なぜかshudownコマンドでシャットダウンしても切れない事があったので、その場合は^C(Ctrl + C)で落とすほかなさそう。
screenでサーバの起動
一つはscreenで、仮想端末を立ち上げてそこで実行します。
これにより
バックグラウンドで動作させることができるため、別の操作が可能です。
なお、screenはデフォルトで入っていないのでパッケージインストール(apt install screen)しておきましょう。
$ screen -S 7dtd
$ ./startserver.sh -configfile=serverconfig.xml
別の操作をする場合は「[Ctrl + A] + D」で現在の仮想端末からデアタッチ(抜ける)することができます。
再度アタッチする場合は-rオプションで。
$ screen -r 7dtd
Telnetでサーバへ接続
Ubuntu Server上でtelnetコマンドによりTelnet接続します。
$ telnet 192.168.1.163 8081
接続できるとパスワードを問われるので適当に入力すると7dtdサーバの操作ができると思います。
サービスでサーバの起動
一応サービスも置いておきますが、こちらはシャットダウンコマンドを送っても永遠に再起動を繰り返すのでちょっと使い勝手が悪い。
stopするとぶちギリになるしなんとか改善できんもんか。
本当に24時間付けるのでない限りscreenで動かすほうが賢明かも。
$ sudo nano /etc/systemd/system/7dtd.service
[Unit]
Description=7dtd dedicated server
After=syslog.target network-online.target
[Service]
Type=forking
WorkingDirectory=/home/ubuntu/steamcmd/7daystodie
ExecStart=/home/ubuntu/steamcmd/7daystodie/startserver.sh -configfile=/home/ubuntu/steamcmd/7daystodie/serverconfig.ded.xml
ExecStop=/usr/bin/pkill 7DaysToDieServe
User=ubuntu
Group=ubuntu
KillMode=none
Restart=no
[Install]
WantedBy=multi-user.target
IPアドレスによる接続
Savannah ManagerはLinuxに対応しておりませんが、Windows側からIPアドレスを直打ちすることでどのサーバへも接続することができます。
この機能を利用することでゲストマシンの7dtdサーバであってもホストマシンから制御が可能となります。
まず、Savannah Managerを起動し、適当に初期設定画面を流します。
するとでかい画面が開くので、ローカルサーバーモードをオフにし、その下にあるIP・ポート・パスワードを適当に入力します。
画像は使い回しなのでIPが違いますが、今回は「192.168.1.163」となります。
適当に入力できたらあとは「Telnetで接続」をクリックします。
すると自動でパスワード入力を済ませた状態で接続できます。
あとは
Savannah Manager 2のマニュアルと全く同じ操作でサーバの制御が可能です。
ただし、マニュアルには時期的に掲載していないかもしれませんが、
Backup Editorの使用はできません。
はじめに
こちらからはサーバ拡張作業になります。
必ず必要な手順ではないため省いても問題ありませんが、通常のサーバでは物足りない部分や不具合が修正されているので筆者は導入をおすすめします。
例えば、Server Fixesではウェブブラウザからマップを見ることができ、探索していなくてもプレイヤーが通ったところ(すなわち生成されたところ)であれば確認することができます。
また、その他のModなどもほぼ同様の手順で導入できますので一つのMod導入の参考例になるかと思います。
インストール作業
公式より
server_fixes.tar.gzをダウンロードし、適当な場所に展開します。
$ mkdir ~/serverfixes && cd ~/serverfixes
$ wget http://illy.bz/fi/7dtd/server_fixes.tar.gz
$ tar zxvf server_fixes.tar.gz
$ mv -r Mods ~/steamcmd/7dtdserver
これでインストール完了です。
要するに、
server_fixes.tar.gzに入っているModsディレクトリを7dtdサーバ直下に入れてあげればOK。
ただし、このリンクは最新版を落とすものなので、a16.4などの旧バージョンに当てる場合は公式サイトの更新履歴より対応するバージョンを探す必要があります。
公式の下部に「
7 Days to Die vs Mod version compatibility」という項目があるのでこれを見つつ探してください。
ブラウザでマップを開く
マップは
インストールの際にModsフォルダ内の
Allocs_WebAndMapRenderingを導入した場合のみ利用できます。
まず、serverconfig.xmlのTelnetPortのポート番号を控えておきましょう。
次に、控えておいたポート番号+1でウェブブラウザにてアクセスします。
例えば、TelnetPortが8081なら、「http://127.0.0.1:8082」となります。
するとマップが表示されるはずです。
なお、初期設定ではSteamアカウントでログインしていないと利用できないため、必要な場合は
マップの設定を御覧ください。
マップの権限の変更
マップの設定ファイルは7dtdサーバのセーブデータと同じく以下の場所に保管されています。
「
~/.local/share/7DaysToDie/Saves/webpermissions.xml」
.localは隠しファイルなのでWinSCPなどでも隠しファイルを表示するように設定しないと表示されません。
また、lsコマンドでは-aオプションを付けると隠しファイルが表示されます。
$ ls -la
webpermissions.xmlではserverconfig.xmlと同じく、XMLが採用されているため同じように編集します。
デフォルトでは全てコメントアウトされているため、個別に設定が必要ならコメントを外してpermissionを変更しましょう。
permissionは2000だとSteamログインなしで使用することができ、1000だとログインが必要になります。
それ以外の値は未確認ですが、tokenの権限あるいはゲーム内の権限(AdminやWhitelistの数値)と関連があると思われます。
permissions
web.map |
マップ表示に関する権限 |
webapi.getlog |
サーバコンソールのログの表示に関する権限 |
webapi.executeconsolecommand |
プロパティ名から推測するとコンソールコマンドを実行する権限 |
webapi.getstats |
|
webapi.getplayersonline |
オンラインのプレイヤーを取得する権限 |
webapi.getplayerslocation |
プレイヤーの位置を取得する権限 |
webapi.viewallplayers |
|
webapi.getlandclaims |
LandClaimを取得する権限 |
webapi.viewallclaims |
|
webapi.getplayerinventory |
プレイヤーのインベントリを取得する権限 |
webapi.gethostilelocation |
ゾンビの位置を取得する権限 |
webapi.getanimalslocation |
動物の位置を取得する権限 |
コマンドの.(ドット)以前を見るとwebとwebapiがありますが、webはウェブブラウザ上で表示されるもので、webapiの場合はウェブブラウザ上のマップでも反映されますが、それ以前にウェブAPIとして機能しているため外部アプリケーションやプログラム制御でデータだけの取得が可能です。
二重になるので詳細は
こちらにて。