HackMD
  • New!
    New!  “Bookmark” and save your note
    Find a note that's worth keeping or want reading it later? “Bookmark” it to your personal reading list.
    Got it
    • New!  “Bookmark” and save your note
      New!  “Bookmark” and save your note
      Find a note that's worth keeping or want reading it later? “Bookmark” it to your personal reading list.
      Got it
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
      • ODF (Beta)
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
    Menu Sharing Help
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML ODF (Beta)
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note    
    Published Linked with
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    --- tags: Tutorials --- # Server Hosting Tutorial This is a tutorial/brain dump of how to set up an SS14 server. This guide will cover everything you need, from private servers to play with your friends, to production servers for proper server hosts. There are two methods you can use. A "bare" server that just runs the game server directly, or `SS14.Watchdog`. We recommend the latter for more proper deployments and also if you want to be accessible via the launcher. If you have any questions, ping PJB on Discord. ## Recommended Specs for hosting !!! MAY VARY DURING DEVELOPMENT !!! 1-16 players: * 4 Core Cpu 2.6ghz or higher * 2GB Memory * 1GB Disk space 16-32 players: * 6 Core Cpu 2.8ghz or higher * 4GB Memory * 2GB Disk space 32-64 players: * 8 Core Cpu 2.8ghz or higher * 4GB Memory * 4GB Disk space 64-128 players: * 8 Core Cpu 3.2ghz or higher * 8GB Memory * 8GB Disk space ## "I want to set up a quick private server for my friends". 1. Install the [.NET 5 Runtime](https://dotnet.microsoft.com/download). 2. Download the latest version of the server from [our Jenkins instance](https://builds.spacestation14.io/jenkins/job/SS14%20Content/), for your operating system. 3. Extract that to a directory somewhere. 4. Run `Robust.Server.exe` (or `Robust.Server` via terminal on macOS/Linux) 5. Make sure you have TCP port 1212 **and** UDP port 1212 port forwarded. 6. Give your friends and yourself your IP address and have them paste it into the launcher. <small>Just kidding, you don't have any friends.</small> ## Install .NET Runtime. The server is not self contained (and neither are client builds) and needs a [.NET 5 Runtime](https://dotnet.microsoft.com/download) installed. For `SS14.Watchdog` you ALSO need the ASP .NET Core 5 Runtime. ## Running Bare Server The "simplest" configuration is to get a build of the server for your platform, unzip it, and launch the server program (`Robust.Server.exe`/`Robust.Server`). We host our official builds [on our Jenkins instance](https://builds.spacestation14.io/jenkins/job/SS14%20Content/) or you can export them yourself if you have a fork. This will not, of course, handle automatic restarts (in case of a crash) or updates. Note that when you run a server like this, the build information that the launcher needs (so it has a version of the client to download) points to our Jenkins instance. **We do not keep those builds around forever** so eventually people will no longer be able to connect to the server. Obviously this is not a problem if you want to set up a quick and dirty private server for your friends. Just make sure to download a new version of the server at least every week. ### Server configuration You can configure settings in the server by editing the config file, `server_config.toml`. The config file is TOML which is basically INI ~~except better specified, somewhat more powerful, easier to misuse, and more annoyingly opinionated (comments NEED their own line)~~. Settings have one key they fall under and then the name. So if I say `game.lobbyenabled` it goes under the `[game]` header like so: ```toml [game] lobbyenabled = true ``` Got that? Good. **Some sane defaults you might want to set for your server if you actually intend to host this properly:** ```toml [net] # Reducing tickrate to 30 is basically unnoticeable # but reduces server, client and network load dramatically. tickrate = 30 [game] # Changes the name of the server as it appears in the lobby and launcher. hostname = "Foo Station" # Enables the lobby instead of straight up throwing clients into a game. lobbyenabled = true [auth] # Enforces authentication so that ALL connecting clients must have a proper account. # Otherwise, guest logins are allowed. # Possible values here are: 0 (optional), 1 (required), 2 (disabled) mode = 1 ``` ### Admin Privileges By default, no admin privileges are set. Connections made from localhost are automatically full admin and bypass any authentication requirements. Of course, that's not very useful for real live servers hosted on a dedicated box, so you have a chicken and egg problem. You can use the `promotehost` (e.g. `promotehost PJB`) command on the server's console to temporarily give a connected client full HOST privileges. This will allow them to set up further admin privileges (and set their own permanently) with the in-game admin permissions panel. The privileges are lost when the server shuts down. Host privileges are dangerous to give and should only be given to people you can absolutely trust. They can, by design, be used as an RCE with the `scsi` command, allowing a complete takeover of the server. ### Build Configuration If you *do* want to set up a more permanent server, you will have to re-host the client downloads somewhere. Anywhere accessible via a plain URL is fine. You will want to edit the server config file (`server_config.toml`) to add the following to it: ```toml [build] # Download locations of the entire client build in a zip, as a HTTP (or HTTPS) URL. download_url = "" ``` ### ADVANCED Server Build Configuration This is for people running their own codebase and server. The launcher needs to download the client binary to be able to run the game. It gets information about this client binary from the game server via an info API. The information returned from this API is configured in two ways: `build.json` and `build.*` configuration variables. `build.json` is a file that gets put next to the server executable automatically by the build system. This is how the server knows what the build info is when just downloading a bare server zip. (note that this is NOT done by `package_release_build.py`, since it relies on build information from Jenkins. `gen_build_info.py` does it in a separate step) The second option is by specifying configuration variables (from command line or config file, both work): ```toml [build] # "Identifier" of your codebase. This is used by the launcher to manage installations. # Try to keep this unique between different codebases. # Nothing will break if you don't (or if there's a malicious actor), # but the launcher WILL be forced to redownload files more often than otherwise necessary. fork_id = "" # Version string of the current build running on the server. # This just prompts the launcher to redownload if it's different. version = "" # Version of the engine to download. # Engine versions are hosted by us and will probably stay up forever. engine_version = "" # Download locations of the entire client build in a zip, as a HTTP/HTTPS URL. download_url = "" # SHA256 hash of client zip files specified above. hash = "" ``` Note that `SS14.Watchdog` specifies *most* of for you if you have configured it with auto updates (depending on update provider). It notably cannot provide `engine_version` or `fork_id` version, so you're best off specifying the former in build.json (your build system should be non garbage for this) and the latter in a config file. ## `SS14.Watchdog` [`SS14.Watchdog`](https://github.com/space-wizards/SS14.Watchdog/) (codename Ian) is our server-hosting wrapper thing, similar to TGS for BYOND (but much simpler for the time being). It handles auto updates, monitoring, automatic restarts, and administration. We recommend you use this for proper deployments. To set it up, download the code (linked above), and publish it for your platform (`dotnet publish -c Release -r linux-x64 --no-self-contained`), since we currently don't provide any publishes ourselves. Note that you need to have the ASP.NET Core Runtime installed. Then copy `SS14.Watchdog/bin/Release/netcoreapp3.1/linux-x64/publish` to a directory on your server or something. You will want to edit `appsettings.yml` to add a server and configure some stuff. Example from our official servers (obviously tokens redacted): ```yml Logging: LogLevel: Default: "Information" Microsoft: "Warning" Microsoft.Hosting.Lifetime: "Information" SS14: "Debug" AllowedHosts: "*" # API URL that your watchdog is accessible from. # This HAS to be set so the game servers can communicate with the watchdog. # If you don't want the watchdog to be publically accessible, do `http://localhost:5000/` here. BaseUrl: https://builds.spacestation14.io/watchdog/ Servers: Instances: # ID of your server. wizards_den: # Name of the server Name: "Wizard's Den" ApiToken: "foobar" # API token to control this instance remotely like run updates, restart server. ApiPort: 1212 # API port OF THE GAME SERVER. This has to match the 1212 HTTP status API (described below). Otherwise the watchdog can't contact the game server for stuff. # Auto update configuration. This can be left out if you do not need auto updates. Example is for our official Jenkins instance. # See below for alternatives. UpdateType: "Jenkins" Updates: BaseUrl: "https://builds.spacestation14.io/jenkins" JobName: "SS14 Content" ``` ### Server Instance Folder The watchdog will automatically create a folder structure for each server instance. This is at `instances/<instanceId>` relative to the current working directory when executing the watchdog. Each instance folder has the following files and folders: * `binaries/`: Is used to store client binaries when using the "Local" update type, see below. * `bin/`: Contains the actual extracted server binaries. * `data/`: Stores server data like player preferences. * `config.toml`: Is the config file the server will load (the watchdog overrides the default location, `server_config.toml` next to the .exe, to avoid it getting deleted when the server resets). ### "Manual" Local Updates You can use the watchdog with local files, and have it automatically generate the necessary build information. This will also host the client binaries for you. To configure this, use the following update configuration in your `appsettings.yml`, in the entry for your server instance: ```yml UpdateType: "Local" Updates: Version: "foobar" # Version string to use. ``` The watchdog will automatically host client binaries. Where does it pull them from? The `binaries/` folder in your server instance folder! Note that for this to work, the watchdog HAS to be publically accessible via `BaseUrl` in the config file. You can edit the `Version:` specified in the config to tell the launcher that it should update the game next time you connect. You will have to manually move files around and extrac the server binaries. ### Auto Updates with Jenkins See the example config file above as an example of how to configure the watchdog to auto update with Jenkins. ### Custom Auto Updates Not supported, but it should be relatively trivial to edit the code for `SS14.Watchdog` to add support for whatever update mechanism you need. See `UpdateProvider.cs`. ## Port Forwarding The server obviously needs network ports to be forwarded so that people can connect. The game server uses two ports: * UDP `1212` is used for main game netcode. This is necessary for the *client* to be able to connect to the server. This can be configured with the `net.port` configuration variable. * TCP `1212` is a HTTP status API. This is also necessary for the *launcher* to be able to connect to the server. You do not need this to connect with a bare client. This can be configured with the `status.bind` configuration variable (which takes in a string like `*:1212` or `127.0.0.1:3000`). You can slap the HTTP status API behind a reverse proxy if you want. This is recommended for production servers since then you can do HTTPS (slap it behind nginx and turn on HTTPS). Note that if you do this you have to set the `status.connectaddress` config variable to specify the UDP address the main netcode should connect to. This has to look like this: `udp://server.spacestation14.io:1212` (for our server, obviously substitute with your params). ## SQL Setup SS14 uses an SQL database to store server data like player slots. By default, an **SQLite** database is automatically used which is sufficient for local testing and small servers. If you want the ability to share the database between multiple servers or such however, the server also supports connecting to **PostgreSQL**. ~~(If you have need for MySQL/MariaDB or others, tell us, should be easy enough to add.)~~ Nevermind that last line MariaDB is pathetic compared to postgres and it would require non trivial amounts of engineering effort of make work. I'm fine merging PRs that add it but I'm not taking the initiative myself. Relevant configuration properties, along with default values: ```toml # Server config file [database] # Database type to use. Can be "sqlite" or "postgres" currently. prefs_engine = "sqlite" # Path to store the database at when using SQLite. Note that is NOT a disk path. # This is relative to the server data directory, which is specified by --data-dir when starting the server from the command (or automatically set by SS14.Watchdog) prefs_sqlite_dbpath = "preferences.db" # PostgreSQL database configuration, should be self explanatory. prefs_pg_host = "localhost" prefs_pg_port = 5432 prefs_pg_database = "ss14_prefs" prefs_pg_username = "" prefs_pg_password = "" ``` The game server automatically does migrations when it starts up, you do not have to do them manually. ## Getting Your Server In The Launcher The server list the launcher pulls is hosted by us at `https://builds.spacestation14.io/hub/api/servers`. If you would like your server to get on this list, please contact us via Discord or such (adding your server is completely manual at the moment). ## Prometheus Metrics SS14 supports hosting a metrics server that [Prometheus](https://prometheus.io/) can scrape, with which you can then make fancy graphs in [Grafana](https://grafana.com/) or such. Ask on Discord if you actually want our Grafana configuration. To configure this, you can use the following config variables: ```toml [metrics] enabled = true # Address to bind the metrics server to host = "localhost" # Port to bind the metrics server to port = 44880 ``` You can then scrape this with the following Prometheus config (for example): ```yml global: scrape_interval: 1s evaluation_interval: 1s scrape_configs: - job_name: "wizards_den_us_west" static_configs: - targets: ["localhost:44880"] ``` ## Loki Logging SS14 also supports pushing structured log data to [Loki](https://grafana.com/oss/loki/). Because this is modern DevOps crap the website doesn't say what it actually does but when combined with Grafana you can go and look at and filter logs in a debatably more sane way than bare text files. No, you do not need Promtail set up for this to work. SS14 pushes directly to Loki. To configure this, you can use the following config variables: ```toml [loki] enabled = true # HTTP address of the Loki server. address = "http://localhost:3100" # Name of this server, gets included in all log messages. name = "wizards_den_us_west" # Parameters for HTTP Basic authentication, if you have Loki configured behind it. # If left out, no authentication will be attempted. # username = "" # password = "" ```

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.
    All
    • All
    • Team
    No template found.

    Create a template

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in via Google

    New to HackMD? Sign up

    Help

    Documents

    Tutorials
    YAML Metadata
    Slide Example
    Book Example

    Contacts

    Talk to us
    Report an issue
    Send us email

    Cheatsheet

    Example Syntax
    Header # Header
    • Unordered List
    - Unordered List
    1. Ordered List
    1. Ordered List
    • Todo List
    - [ ] Todo List
    Blockquote
    > Blockquote
    Bold font **Bold font**
    Italics font *Italics font*
    Strikethrough ~~Strikethrough~~
    19th 19^th^
    H2O H~2~O
    Inserted text ++Inserted text++
    Marked text ==Marked text==
    Link [link text](https:// "title")
    Image ![image alt](https:// "title")
    Code `Code`
    var i = 0;
    ```javascript
    var i = 0;
    ```
    :smile: :smile:
    Externals {%youtube youtube_id %}
    LaTeX $L^aT_eX$

    This is a alert area.

    :::info
    This is a alert area.
    :::

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully