Меню Рубрики

Ark survival evolved сервер linux

Ark survival evolved сервер linux

This guide provides the steps to install an ARK: Survival Evolved dedicated server on x64 versions of Debian 8+, CentOS 7+, and Arch Linux. The method can be extended pretty much in-tact to other Linux distributions that use systemd [www.freedesktop.org] provided that the necessary libraries in Step 2 are installed accordingly.

The assumption is made that you are already familiar with Debian/CentOS/Arch and have the know-how to accomplish the operating system tasks in this guide. This is not a guide on how to use Linux in general or Debian/CentOS/Arch in particular.

Steps 1-7 will get the server up and running. Steps 8-14 are for server maintenance and extending functionality.

The 32-bit binaries for glibc [www.gnu.org] are required to run SteamCMD (Step 3), even when running a 64-bit version of Linux. To install these binaries execute the following commands:

Before you execute the above command in Arch, you need to first enable the multilib repository. You do this by uncommenting the following two lines in /etc/pacman.conf:

SteamCMD is the command-line version of Steam used to install servers of all sorts, both Valve and non-Valve products. In addition to ARK, examples of other games that use SteamCMD for its servers are Left 4 Dead 2 (Valve) and Arma 3 (Bohemia Interactive).

Install SteamCMD as a non-root user. To do this, execute the following command:

in one of the following directories (create as necessary):

The first option is if you want to use an already-existing user account denoted by . The second option is if you create a user named ‘steam’ used specifically for server-related purposes. In this case is ‘steam’ and the path is truncated accordingly. The rest of the guide will assume the server is installed under the user ‘steam’.

For security reasons, avoid installing SteamCMD in locations such as /usr, /usr/local, /opt, etc. By installing in /home, the read/write priveleges and authorized access are significantly restricted.

Execute the following command in the steamcmd directory created in Step 3:

Then, enter the following commands at the Steam> prompt:

If the download does not finish and instead times out and returns you to the Steam> prompt with an error message, then re-enter ‘app_update 376030 validate’ until installation is successful. You may have to do this several times.

It is also possible to initiate the download as a single command:

A final argument +quit can also be added to the preceeding command so as to avoid having to manually exit SteamCMD. However, my preference is to avoid doing so in the event that the update encounters errors and the app_update command needs to be re-executed. As is commonly done in Linux, the single-line command can also be aliased to save on typing and memorizing (don’t forget to adjust the execution path for steamcmd.sh).

As was the case for SteamCMD, for security reasons the server should also be installed in /home. The install path is /home/steam/servers/ark.

Add an entry to systemd [www.freedesktop.org] so the server can be started as a proper system service. To do this, create a file named ark-server.service in the following location:

with the following contents:

Replace with the text to appear in the browser listing. Also note that ExecStartPre and ExecStart are both just single lines. Steam may be causing line-wraps in your viewing of this guide so as to make it appear as if there are additional lines between ExecStartPre, ExecStart, and LimitNOFILE. The correct lining is:

Also notice that the service is registered under the User+Group ‘steam’. Change accordingly if needed.

The above code starts the server with The Island as the world map. To use The Center, change TheIsland -> TheCenter (no spaces in TheIsland or TheCenter) in the ExecStart line.

The ExecStartPre line is simply the single-line command in Step 4 for updating the server. Therefore, when the server is started it will automatically first check for updates before proceeding to initialize. This line can be removed if updates are handled manually and the service is used simply to start the server. Additional information on modifying system service files can be found here:

Note: Various other guides instruct to create scripts for launching the server and also instruct to modify certain system settings to increase the number of open files allowed in order to satisfy the requirements for ARK. Using the above systemd approach eliminates the need for using such scripts and modifications as everything is automatically taken care of when the server is run as a proper system service.

Start then immediately stop the server (after it completes its first initialization):

Starting the server once will generate the necessary default configuration files, which can then be modified to tweak the server’s settings.

The enable command is what registers ark-server.service as a service and allows the server to automatically start on boot. To disable automatic startup and the service in general, execute the following command:

Configure the server’s settings to your liking via the following two files*:

then start the server again:

Consult the following for a comprehensive list of configuration options:

* It is possible to add some (but not all) settings directly to the ExecStart command line in Step 5 instead of the above .ini files. A lot of people prefer to (incorrectly) use this method. The .ini configuration files approach is the preferred method, especially if only one game instance is being run. The command line arguments approach has two main uses: 1) to quickly change certain settings for testing and debugging purposes, and 2) to easily switch between multiple different game instances (different maps, mods, etc.), with the intention of still playing other instances. This allows one to maintain a single set of .ini files common to all instances. Moreover, it is possible to register multiple different system services as done in Step 5 with differing ExecStart lines in order to facilitate switching between different game instances. For example, instead of ark-server.service, one could create ark-server-island.service and ark-server-center.service, and each of these can have its own set of mods loaded via ExecStart, while sharing the same base .ini configurations.

Leaving the default-generated settings will allow connections to the server at this point. Also, once the server is started it is immediately visible and joinable (in

1 min) in the public server browser. It’s a good idea to set a join-server password until all configurations have been completed:

To see the server, go to View -> Servers in the main Steam client. Then, navigate to the Favorites tab -> click on Add a server -> enter the IP address of the server. If it is not visible, then there is likely a problem with port forwarding and/or the firewall. Adding it to favourites here will also list it under the Favorites filter in-game.

Note: After the server is started, it will take approximately 1 minute to initialize everything before it is visible and joinable.

The following command lets you check the status of the server:

After any future updates to ark-server.service, run the following command to ensure the changes are applied:

All game states are saved in:

You will see the following files in the above directory:

  • TheIsland.ark — Current game state
  • TheIsland_DATE_TIME.ark — Previous game state
  • #.arkprofile — Players that have joined the server
  • #.arktribe — Tribes on the server

You will likely see a lot of TheIsland_DATE_TIME.ark files. They can be safely deleted. It’s a good idea to keep a handful, though (the server only keeps the 20 most-recent saves).

To make a backup, simply copy the above files to a safe location. It’s good practice to just backup the entire directory at regular intervals (e.g., once or twice a day) and keep a 1-2 week’s worth of archives. Each game state is

The frequency that the server will create a saved state can be set in the server configuration files.

Whenever an update is released, simply ‘stop’ the server, execute Step 4, then ‘start’ the server. It is not necessary to ‘disable’/’enable’ the server, just ‘stop’/’start’.

Make sure to keep backups in case you need to roll-back.

There are many fantastic mods available on the Steam Workshop. While these mods can significantly enhance ARK, they can also be the downfall of your server if not selected and managed carefully.

In general, the two prime considerations that should be given when selecting mods are:

    They should be ‘clean’ and ‘stackable’. This means that they do not interfere with or alter any core game files, and that they can be used alongside other mods. Many mods specify in their Workshop descriptions that they satisfy these criteria. This first consideration will not necessarily be satisfied in the case of ‘total conversion’ or ‘overhaul’ mods.

  • Is the mod worth having at the cost of additional maintenance and time spent diagnosing possible future errors? Does your server really need 100 mods?
  • Before installing any mods, stop the server.

    To install mods, the first thing that should be done is to add the mod IDs to the server configuration file. To do this open:

    and under the [ServerSettings] block add/modify the ActiveMods line:

    Mods should be separated using a comma without white spaces following the comma, i.e., use #,# and not #, #.

    For example, two mods that I like to use are Structures Plus and Platforms Plus. They would appear in GameUserSettings.ini as:

    These IDs are obtained from the corresponding Workshop urls:

    When creating the ActiveMods list, the order may be important as some mods require that they be loaded before others. Load order is left-to-right. That means that the left-most mod, or the first in the list, will be loaded first by the server, while the right-most mod, or the last in the list, will be loaded last by the server. Workshop descriptions will typically indicate if load order is important for a particular mod. Otherwise, if order is important but not specified, then it will need to be determined by trial-and-error.

    The next step is to get the actual content onto the server. Navigate to the Workshop page of a particular mod, then use your Steam client to subscribe to the mod on the computer where you have the user-playable installation of ARK installed. The subscription should trigger the content download.

    Once the download is complete, start ARK on that computer and wait at the main menu screen until the mod is actually installed. Mod installation status is displayed in the bottom-right of the main menu screen.

    Then, exit ARK and navigate to the following location on the computer where the user-playable version of ARK is installed:

    Locate the folder and the .mod file corresponding to the ID value you noted down from the Workshop url. Copy those two items to your server:

    The server can now be started and the mods will be loaded.

    If a user attempts to login to the server and they do not have a mod in the list, then the mod will be automatically downloaded. Depending on the number and/or sizes of the mods, users might timeout and get disconnected from the server when attempting to join if downloading and installing takes too long. Several attempts to join the server might be necessary until everything is downloaded and installed.

    It is at this point that the issue of the number of mods on the server comes into play. The server does not update mods automatically. The process of copying mods over to the server manually must be done each time there is an update to a mod. This becomes problematic when considering a lot of mods.

    First of all, when a Workshop content update triggers in the Steam client, there is no information as to what exactly from the Workshop was updated. So there is the problem of tracking down which mod was updated.

    The second problem is that Workshop content updates are pushed automatically to clients (the Steam option to not automatically update game content does not apply to Workshop content). Therefore, it is possible that users are locked out of a server because of incompatibilities between their version of the mod and that which is installed on the server. Then, instead of a simple update and continuing to play the game, time is wasted trying to hunt down which mod needs to be updated.

    A third possible issue is if a game update breaks a mod’s compatibility with the game. Until patched by the mod authors, you could end up losing dinos and your base.

    Therefore, consider using only a handful of carefully-selected stable, and preferrably actively-maintained, mods (10 is a reasonable number, 20 is pushing it) that can be quickly looked up on the Workshop pages for modification dates in order to track down which mods need to be updated.

    The higher the number of mods used, the higher the probability of more frequent updates. You don’t want to be updating the server on a daily basis.

    The following are comprehensive tools for all things server-related (these are not mine, but rather just ones that I particularly like):

    It is recommended to get acquainted with and use these tools after the initial installation. While the tools can also install the server, it initially takes longer to figure out how the tools work than it is to just follow Steps 1-7. However, beyond the installation phase, these tools are indispensable.

    Think of the following analogy: you are on foot about to cross an intersection. Crossing by foot will likely get you across more quickly (Steps 1-7) than hailing a cab (the Tools). However, once you do cross, you are limited by how far you can go by walking compared to in-vehicle. People typically want to get a server up and running as quickly as possible. The details can come later =)