Foreword from Grim - Part 0

I hope you take the profanity in this document in stride and understand it as bad humor and/or a coping mechanism. You may find my writing style to be condescending, for which I will say that is not the intent of this document. Try to power through it, or point it out if gets especially bad. That being said, you will not find corporate-friendly speech here.

The collection of this information is the result of doing this as first a hobby and eventually a career for a few years, and I write it with the intent that it may be saved for posterity and be useful for the reader: if someone reading this to completion (potentially a couple of times) is able to replace me in the technical duties of the unit, the goal of this document is reached.

It might take a bit to get to the point sometimes, as with this foreword. Again, try to power through it.

So you want to be a Server Admin

Abandon all hope ye who enter here.

So, you want to be a Server Admin? Congratulations, and my condolences. Let’s get started.

Why is this public information (for unit members)?

I want claims of knowledge-hoarding, security by obscurity, and technocratic dictatorships to be baseless. Also, this write-up facilitates three things:

Onboarding new server admins.
Someone might actually be interested in this shit, God forbid, by having the info.
Anyone thinking this is easy can be referred to this document. If it ever is easy, it’s because previous admins put work into making it so.

A Note on Preliminary Info

Yes, you have to read these. Don’t skip or skim them. You will be tested on this crap before being given box access.

You might find trivial or otherwise previously-known information, particular in regards to Arma 3’s workings. The purpose of said information being contained is to avoid making any assumptions about previous knowledge, such that anyone following this document can be expected to have the same baseline.

If you find any section requiring prior knowledge without a section explaining it, please point it out so it can be added to the document. A particular example is CBA Settings: the first draft of this document was not intended to contain a section on CBA Settings, but it was pointed out that a good portion of Arma players do not even know of their existence. Given their importance, sections explaining what CBA Settings are and how to access and manage them were added.

Hardware - Part 1

Our server is a bare-metal Linux server, meaning, it is a physical server on a rack somewhere: not a virtual machine, not a game panel. It is as physical of a computer as the one you’re reading this on. The only difference is you access it over a network. Specs may vary over time. The server started being hosted on InterServer with a Ryzen 5900X, 64GiB of DDR4, 2TB of NVMe storage, and a 1Gbps network connection.

You may notice there’s no GPU in this configuration, that’s because servers aren’t typically meant to render things, unless they’re specialized to do so (or do other calculations a GPU is good at).

Technical Jargon - GB/s vs Gbps

There’s a difference.

Computers only understand 0’s and 1’s. A single 0 or 1 is referred to as a “bit”. This is inconvenient, so engineers long ago in the dark ages grouped eight bits together and called it a “byte”.

A byte is, thus, 8 bits. This is important.

GB/s (and KB/s, and MB/s, and TB/s, I can go on.) should be read as “Gigabytes per second”. Your SSDs, RAM, storage in general, is measured in bytes. You have an SSD with anywhere from 128 Gigabytes to 1 Terabyte (or more) in your computer.

Gbps (etc.) should be read as “Gigabits per second”. This is what network speed is measured in. This means 1Gbps is actually only 125MB/s (because one byte is eight bits). Your ISP sells your network speed with this measurement.

Why is this the way it is? Who the fuck knows. ISPs get to sell bigger numbers is a big reason.

The other is measuring data throughput (throughput = the rate at which something “moves”) doesn’t make sense in packets, when you can only ever signify a single on or off state at a time. This is where computers only understanding 0’s and 1’s comes back into play: the same goes for your Ethernet cable (the blue/black/white cable that connects your computer to your router) or Wi-Fi, you can only transfer one bit at a time (because electricity is either on or off, we don’t talk about analog values here), so it makes sense to measure speed in how many bits can be transferred per second.

Don’t get me started on GiB vs GB. Fuck Microsoft. Back to important shit.

Software - Part 2

That bare-metal Linux server previously mentioned started out running Ubuntu 24.04. If you’re now thinking, “wait, isn’t it running Linux?”, then you might have some hope still. Linux is free open-source software (FOSS). Yes, Linux is complicated. More importantly for us, it’s also faster and more stable for running servers. It needs virtually zero maintenance once setup. And it’s free. And it has the capability to run very useful software that Windows can’t, like Docker.

Linux

Like Windows, Linux is an operating system. Differing from Windows, Linux has many flavors to choose from, called distributions, which determine how you, the user, interact with the operating system. Changes can range anywhere from the GUI (Graphic User Interface) used to open programs and access files, to the inner workings of the system determing how and when software is executed.

A note on distributions

Linux is downloaded, installed, served, distributed, in different distributions. There are many Linux distributions. Which is better? Whichever one you feel comfortable with. Distributions may be based on other distributions, like mods, essentially. In the common sense, Linux is typically understood to be used with a terminal, whereas Windows and MacOS uses GUIs. This is only correct by circumstance, given Linux’s common use cases (like running servers!). There are GUI-based Linux distributions. The Steam Deck and Steam Machine run on Valve’s custom SteamOS Linux distribution.

Why we use a terminal as the default

Linux was originally built to be used as the operating system for running, and interacting with, servers.

Simply put, you need to exchange less data with the server if you’re only transferring text. When you’re dealing with high latency and a lot of network bullshit (read up on the TCP protocol’s workings and think about needing 3 round trips to exchange data, each at 150ms latency, if you want to), this makes life convenient. You’ll get used to it. You may eventually prefer it, it’s less sensory overload.

Why we use Linux

Arma 3 runs faster (10%, roughly);
Minecraft runs faster (a lot faster);
Restarting is faster;
Updating is easier;
Multi-user access at the same time is easier. Two people connecting at the same time via Remote Desktop on Windows will drop someone off the server;
Docker;
Server-side database management is easier;
We get to say we run Linux and thus are superior.

Docker

I mentioned Docker above. What the fuck is Docker and why is it important? Important enough to force you to drop the convenience of just having a Windows Server with Remote Desktop enabled?

Docker is a tool for running containerized applications (programs, software) based off images.

Got that? Yes? Really? Don’t lie to me. You didn’t get it.

Docker for Dummies

Most useful part of Docker: it takes away setup (if done well). Someone writes a Dockerfile describing an image, which is used to build a container. A container is a process (actively running software) that is isolated from the rest of the operating system. This means other programs can’t fuck with it. It means you can’t delete game files while the server is running (don’t try to, there are exceptions and we use them).

More importantly, it means setting up a server (of anything, Teamspeak, Arma, Minecraft) does not need a tutorial you have to follow. Instead, the Dockerfile is the computer’s tutorial on how to run the software, and it follows it perfectly, every time, without skimming or skipping shit. You, the user, only need to ask it to. Just like Pythagoras created the Pythagorean

Batteries aren’t always included. You may need to provide credentials (jargon: credentials are shit you use to login in to something, like a username and a password), or setup folders in advance, etc. But it does take away the hard part, most of the time.

The point

We run Arma through BrettMayson’s (you may know him as “Brett from Synixe”) Arma3Server image (though it is modified a bit). It handles putting shit in the right place, automatic restarting, downloading and updating mods, etc. All you need to do is give it an HTML mod collection and it just works (insert Todd Howard).

We run Teamspeak through Docker. The database for keeping all your loadouts, position, medical info, rank, admin status, certifications, bans, etc. is ran through Docker. Any Minecraft servers on the box are ran through Docker.

Docker is love, Docker is life. It makes shit easy, it makes shit not interfere with other shit. You may or may not touch it directly, but you should know it’s there (and read up on it/learn how to use it basically, it’s cool tech).

Technical Jargon

Container: running software
Image: template for building a container
Compose Stack: a bundle of containers & configuration described in a docker-compose.yml file (filename may vary but this is the default)
To spin up: to run
To build : to make runnable, typically by compiling and/or downloading dependencies

A break

Survived that? Good. That section will be expanded. This is a promise; not a threat. Go have some coffee.

Accessing the server - Part 3

First thing you need to do is ask Grim (me) for an account. Everyone gets their own account. You don’t share your account. What you do gets logged quite conveniently. You don’t fuck with the box. You share your account and someone else fucks with the box, you both get booted. Got that? Great!

You read this whole thing through first and commit it to memory before asking me for an account.

At the point of making your account, I will have given you three things: a username, a password, and an SSH key. An SSH key is, essentially, a non-human readable password. It is stored as a file on your computer and you use it for logging in via SSH.

What the fuck is SSH

SSH is remote terminal access. Every command you run within an SSH session (an SSH session is the terminal window after you run the ssh command in the next section) is executed on the server you are connecting to. In short, you are moving folders, copying and deleting files, and running software “remotely”.

“Remotely” is kept in quotes because it’s not exactly right. You’re not ordering the server to do something: you are doing something on the server. The filesystem (files, folder) you will see within an SSH session is the server’s, the processes you will see running are the server’s, etc.

Google if you want a longer explanation.

Continuing

So, you have the server IP or hostname, you have your account’s username, you have your password and SSH key.

A hostname is a human-readable IP address. IP means numbers (we don’t talk about IPv6 IPs), like 192.168.10.1. A hostname is something readable, like skua.elephant.com, though someone can also use hostname to refer to an IP.

How the fuck do you log in? A few options.

Terminal (SSH)

You open up Windows Terminal or PowerShell or the preferred terminal of your choice and type in ssh -i <the-path-to-the-ssh-key-on-your-drive> <your-username>@<the-server-ip>.

It just works. You are now operating a terminal that can do shit on the server box itself. If I’m doing my job right, you can’t blow it up, but don’t try to. Please.

RDP (Remote Desktop Protocol) - A GUI, for normies

You’re on Windows? Press Windows and type rdp. It’ll bring up Remote Desktop or something similar. Enter the server IP/hostname and your username and password. Connect. You now have a very laggy video connection to another computer.

A note on credentials

We keep various sorts of credentials on the server box: database passwords, admin passwords for various servers, the password for Skua’s Steam account, etc.

Take care not to leak anything: don’t screen share, don’t screenshot, copy over files, etc. unless you have good reason to.

If you think you’re smart and can fuck with shit maliciously: first, you have to fool me into allowing you to; second, you will inconvenience me particularly and others mildly at most. There is nothing irreparable on the server, we can always hit the big reset button on the provider panel and rebuild in the worst case. We’ve done it once and can do it again.

If you do fuck shit unintentionally: own up to it and ask for help fixing it. You might get bitched at and/or be handheld through fixing your mess, but you’ll learn something doing it.

Regarding personal usage of the server

I’m going to be honest, I don’t give a shit so long as you:

Communicate it;
Don’t be an entitled bitch;
Don’t fuck with the firewall;
Be organized;
Ask for help if you’re not sure of what you’re doing.
Don’t fuck with other people’s shit;
Don’t fuck with Arma;
Don’t fuck with the unit.

You want to run minecraft? Go for it. Ark? Sure, do whatever. If it starts getting too resource-intensive or fucks with people’s attention spans (I will not tolerate unit members playing Ark hosted on the same server while an Arma operation is ongoing), I will first communicate expecting cooperation, then pull the plug.

Otherwise, do whatever as long you communicate.

And don’t use the default ports for hosting your shit.

Linux for Dummies - Part 4

Basic commands:

List files in the current folder: ls
List files in a folder inside the current folder: ls <folder-name>
Move to a different folder: cd <folder-name>
Move up a folder: cd ..
Mess with Docker: docker
See running Docker containers: docker ps
See all Docker containers: docker ps -a
Start a Docker Compose Stack: cd into the directory (folder) with the docker-compose.yaml
Open a text editor: nvim <path-to-file> (press ESC, then :, then wq, then Enter to quit out)
Check disk usage of the current folder: du -shL .
Check general resource usage: htop (press Q to quit)

Where to keep stuff

General software (servers, teamspeak, etc.): save to /opt/<software-name>/<use-case>. Skua’s Arma server is saved to /opt/arma3/skua for example; teampeak in /opt/teamspeak/skua.
Personal use stuff: save to /home/<your-username>. This is your home folder, its equivalent is C:\Users\<Username> in Windows. Organize it however you like. Note that stuff in your home folder can still be seen and read by other users.

How to figure out how to do something

For non-game-specific crap LLMs are pretty good, and you can find good answers on StackOverflow/StackExchange. Google “ Ubuntu”, e.g., “change username Ubuntu”.

Coffee Break 2 - Electric Boogaloo

Go take a piss if you’ve had too much coffee the first time.

Arma 3 - Part 5

Congrats, you made it this far. Here’s what you’re interested in.

Preliminary knowledge

What? Thought you’d just go spin up a server?

HTML Files

Starting with something basic: you may know HTML files as the on-disk representation of a web page. Bohemia (Arma’s developer) decided in their wisdom to use this as a means to store the on-disk representation of a collection of mods. Thus, within the context of Arma, you can interpret “HTML files” as collections of mods available on the Steam Workshop.

An HTML file will contain the names of all its mods as well as links to their Steam Workshop pages and can be used by the Arma 3 Launcher (and our server setup, more on that later) to automatically subscribe and load a bundle of mods.

You can create HTML files for either your currently loaded or all subscribed mods by opening the Arma 3 Launcher, changing to the Mods tab, and clicking “Export Mod List to File”. The inverse process for loading is described by opening said exported file in your browser and following the instructions at the header. Please familiarize yourself with this process.

Collections

Collections are a list of mods on the Steam Workshop and are useless besides letting you subscribe to mods in bulk.

CBA Settings

CBA, short for Community Base Addons, is the pillar upon which the sane part of the Arma 3 modding community is built. Among many other features (like inter-mod magazine compatibility) and utility functions, CBA provides a standardized, unified Settings System that, generally, all mods use. RHS is stupid and doesn’t use it because RHS is stupid.

CBA Settings are used to configure many aspects of gameplay, like timers for various tasks, difficulty, AI skill, view distance, what actions a player can do, positioning of UI elements, and more.

With ACE being our primary realism mod and built for configurability and modularity in mind, there a lot of CBA Settings for it. You should get familiar with them. You can access the CBA Settings Menu by pressing Escape, clicking Configure, then Addon Options.

Settings can be set by the client (for trivial or tasteful settings), the mission (as a preferred default), or the server (overwriting the mission). The server or mission may force some settings that would otherwise be up to the client’s discretion, following this order of priority: server beats mission beats client. Some settings are clientside only: this is determined by the mod author who created the setting. Given how much of gameplay settings can control, most settings are going to be set by the mission or server, with no allowance for the client to set them.

Your clientside settings are saved to your Arma 3 profile. Annoyingly, when opening a mission in the Eden Editor or Singleplayer, Client settings will be mixed with Server settings under the Server category in the server menu, this may cause confusion for beginners. You will eventually get a feel for what is mission/server-controlled or client controlled. UI/cosmetics are typically client-controlled.

Settings are pretty important for gameplay and may be the single most essential part of a unit’s identity: biased me would say it is even more important their mod list. A unit running ACE Medical with minimalist settings will play pretty differently from a unit with everything cranked to realism. Thus, settings management is a major topic for Server Admins. We will get into how to set server settings, where and how they are stored, etc. later on; this is just an introduction.

SQF

Arma 2 and 3’s proprietary scripting language, allowing you to interact with game objects programatically. Most mods are written in this. It is similar in its usage to JavaScript, but generally the only transferrable knowledge will be working with references vs. values and programming fundamentals.

Some passing knowledge of SQF is recommended for server admins, but you do not need to learn how to code. If you’re interested, you can start reading here.

Debug Console

The debug console is accessible through your pause menu if you have been granted admin permissions. It allows you to write and execute SQF on the fly against entities in the mission. Typically it will be used for granting yourself Zeus access if not available, or observing variables.

“Config”

How Arma 2 and 3 define templates of entities, items, modules, and game logic that can be utilized by modders or mission makers. “Config” defines what model a vehicle uses, how much health it has, what its weapons are, what ammo is available, etc. when a vehicle is first spawned.

PBOs

According to the wiki, PBO stands for “Packed Bank of Files”. You can think of a PBO as essentially a .zip file in a format Arma 3 understands. There are many more considerations regarding PBOs that are relevant for mod development, but for server administration you must simply understand that a PBO is a bundle of data, loadable by the game engine.

Generally, a PBO may be either an Addon or a Mission File.

Addons

An addon is the technical term for loadable content within the context of Arma 3. An addon is, technically, a mod, but mods in the common sense you think of will typically be composed of multiple addons (and thus, multiple PBOs). Arma 3 Base Game (“Vanilla”) content itself is loaded as addons by the game engine.

Addons are not necessarily standalone, and the process of unpacking and repacking a PBO may or may not be destructive depending on the tools used.

Generally, when speaking of PBOs, we are speaking of Addons, and do not refer to Addons as such: instead we refer to individual PBOs that are part of a mod, or a mod as a whole.

Mission Files and Missions

First, let’s talk about Missions.

Each Arma 3 session (we’re taking a session to mean “the playable period of time between server restarts” here) is a playthrough of a Mission. Arma 3 allows users to create missions via its Eden Editor and then play them in Singleplayer or locally-hosted Multiplayer, publish them to the Steam Workshop, or upload them to a server so it can be played in “Dedicated” Multiplayer. The latter case is what we will typically be dealing with.

A mission is composed of various files, described below, but counterintuitively we refer to the collection of files composing a mission as “a/the Mission File”. Particularly due to the practice of packing a mission into a PBO before upload.

The entirety of the contents of a “Mission File” (in this case: the collection of files composing a Mission) are automatically downloaded by the user upon joining a server running said mission.

Missions allow, besides for custom placement of entities (units, vehicles, etc.) and logic, for custom scripting. This means a mission can introduced self-contained new mechanics, cinematic sequences, or modify a mod’s behavior, up to a certain point.

Generally, missions cannot create new content (add a new custom uniform, piece of equipment, vehicle, etc.), while mods can. Ideally, missions should be as lightweight as possible, with the bulk of scripting and custom configuration moved to a mod (like Skua Armory, the unit mod). This allows for easily reutilizing code and reduces the burden on mission makers to correctly utilize templates or copy files.

Unless coded otherwise, missions are self-contained, i.e., whatever happens in the mission, stays in the mission. There are no savegames for Multiplayer, and a mission will be reset to its base-state upon a server restart (or returning to mission selection). Exceptions to this require custom coding, either through mods or the mission file. The concept of saving game data between sessions, even of the same mission, is refered to as “Persistence”. Persistence may be implemented in various means: by saving data to the player’s profile, by use of an external database like PostgreSQL or MariaDB, or by saving files to disk. The latter two cases require use of a special kind of mod called “Extensions”, which can call code not written in SQF. See the Wiki on Extensions if you’re interested.

mission.sqm

Description.ext

initPlayerLocal.sqf

initServer.sqf

Mods

Eden Editor

Zeus (aka Curator, aka Game Master)

Spinning up a server - Pre-requisites

I’m going to preface this by mentioning that these steps are specific to Skua’s setup and may vary wildly from unit to unit: Skua’s setup is not the universal best nor the only way to do things. Pre-requisites below:

Your mission file must be uploaded to the server.
Your mod list, as an HTML preset containing all mods that will be used, must be uploaded to the server. You must know the exact name of the mod list file.
If using a DLC map (Sefrou-Ramal, Livonia, Tanoa, etc.), the server’s Steam account should own that DLC.