NixOS: The last word in Armagetron hosting

[numinit]

Hi there,

Long time lurker since 2008. I used to run the iD Tech Camps High Rubber and Racing back when I was a teenager. I recently turned 30, and realized that I've been doing Linux hosting for the majority of the time I've been alive, and it sort of began with this game.

15 years later, it's time to give back to the community that got me started with a career in computer engineering.

We've come a long way since the times of PHP scripts for server management and handing out the root password to random people. However, Docker was a huge step in the wrong direction. It's easy, yes, but shipping an entire Linux distribution to run applications is a terrible idea. What happens when you need to update any of the binary dependencies? Bitrot and throwing everything in /home happens, and things tend to be hard to maintain.

nixpkgs solves these problems, and now lets you build the following Armagetron servers or clients using this pull request:

• pkgs.armagetronad
• pkgs.armagetronad.dedicated
• pkgs.armagetronad."0.2.9-sty+ct+ap"
• pkgs.armagetronad."0.2.9-sty+ct+ap".dedicated
• pkgs.armagetronad."0.4"
• pkgs.armagetronad."0.4".dedicated

So, once it's merged into nixpkgs, you can do something like:

Code: Select all

nix run 'nixpkgs#armagetronad."0.2.9-sty+ct+ap"'

In the meantime, you can try this, swapping out the attribute with one of those in the above list to get any of the major branches of Armagetron:

Code: Select all

nix run 'github:numinit/nixpkgs/armagetronad#armagetronad."0.2.9-sty+ct+ap"'

Not content with that, I created another pull request creating a NixOS module with automated end-to-end integration tests that verify that two users can join the same server and that one can coredump another. It steps through the tutorial, using OCR to click menu entries.

So, here's how you conjure multiple dedicated servers from thin air now:

Code: Select all

services.armagetronad.servers = {
  high-rubber = {
    enable = true;
    name = "My High Rubber Server";
    port = 4534;
    dns = "mydomain.example.com";
    settings = {
      SERVER_OPTIONS = "Example high rubber server.";
      CYCLE_RUBBER = 40;
      SIZE_FACTOR = 0.5;
    };
    roundSettings = {
      SAY = [
        "Maybe you should try NixOS..."
        "https://nixos.org"
      ];
    };
  };
  low-rubber = {
    # Another config goes here ...
  };
};

Please enjoy hosting whatever servers you damn please, in perpetuity, using NixOS.

The cost: $0.

----

Since it's been a while, greetz to SmOoThIcE and Puffyfluff. Thanks guys.

-Morgan [numinit]
https://github.com/numinit/

[Z-Man]

That sounds absolutely fantastic! I'll try this out as soon as possible.

(I do love me some docker for building software. Gives a nice, stable, reproducible environment. Sure, it's just chroot on steroids when used like that, but... it's chroot on steroids.)

[numinit]

That sounds absolutely fantastic! I'll try this out as soon as possible.

(I do love me some docker for building software. Gives a nice, stable, reproducible environment. Sure, it's just chroot on steroids when used like that, but... it's chroot on steroids.)

Cool. Questions for you.

• I noticed a compile error with sty+ct+ap related to player shuffling only making sense on the dedicated server, here's a patch. Would be great if this was upstreamed.
• Are you aware of crashes with --enable-memmanager such as this one? https://github.com/NixOS/nixpkgs/issues/263244
• Should we be pulling from Bazaar or Git? Right now I'm pulling from Bazaar but could switch to Git.
• What analog to https://launchpad.net/armagetronad/${la ... rsion}.tbz could be directly fetched from Bazaar or Git? Nix performs the bootstrap.sh and I noticed that tarball is already bootstrapped.
• Should the input file just be an empty file? (A fifo freezes the entire server.)
• Any chance you could change this account name to numinit (and delete the account "numinit" that I already created)? I like the 15 year history on this one better but haven't gone by this dumb username since high school.

[aP|Nelg]

Neat!

I noticed a compile error with sty+ct+ap related to player shuffling

Ah, looks like I lazily cut'n'pasted an AccessLevelSetter line from somewhere and failed to properly update it for SHUFFLE_PLAYER, whoops.

Fixed now.

[numinit]

Perfect, confirmed working.

Regarding the source tarball, it doesn't look like there's a release for 0.2.9.1.1 on github so I'm just using bzr for everything for now.

[Z-Man]

[*]Are you aware of crashes with --enable-memmanager such as this one? https://github.com/NixOS/nixpkgs/issues/263244

No, but we no longer use that in any way, it used to be faster that the system memory manager and used to give good leak finding results, but these days, it's mostly useless. I should remove it from the configuration.

[*]Should we be pulling from Bazaar or Git? Right now I'm pulling from Bazaar but could switch to Git.

Git is our primary now.

[*]What analog to https://launchpad.net/armagetronad/${la ... rsion}.tbz could be directly fetched from Bazaar or Git? Nix performs the bootstrap.sh and I noticed that tarball is already bootstrapped.

Gitlab provides source archives of the form https://gitlab.com/armagetronad/armaget ... .9.tar.bz2, replace "legacy_0.2.9" with the desired branch name. I guess those would do.

[*]Should the input file just be an empty file? (A fifo freezes the entire server.)

I don't follow; input for what?

About the forum name change, I pinged that to tank/guru3 on IRC, he is the only one who can do it.

[numinit]

No, but we no longer use that in any way, it used to be faster that the system memory manager and used to give good leak finding results, but these days, it's mostly useless. I should remove it from the configuration.

I've added --disable-memmanager to our compiles for NixOS. That seemed to help the user that was having memory manager crashes.

Git is our primary now. Gitlab provides source archives of the form https://gitlab.com/armagetronad/armaget ... .9.tar.bz2, replace "legacy_0.2.9" with the desired branch name. I guess those would do.

Switched to gitlab, nixpkgs has a helpful fetchFromGitLab function that worked.

I don't follow; input for what?

The --input file used as an alternative to stdin. The NixOS module runs it as a systemd service and uses --daemon --input /var/lib/armagetronad/${server}/input. It seems like this just has to be an empty file instead of a fifo or the server will just block on reading it, which makes sense.

About the forum name change, I pinged that to tank/guru3 on IRC, he is the only one who can do it.

Appreciate it.

[numinit]

Neat!

I noticed a compile error with sty+ct+ap related to player shuffling

Ah, looks like I lazily cut'n'pasted an AccessLevelSetter line from somewhere and failed to properly update it for SHUFFLE_PLAYER, whoops.

Fixed now.

https://gitlab.com/armagetronad/armaget ... 39a1720186 seems to fail to compile the dedicated server now, FYI. Lots of opengl functions missing. I just packaged the preceding git revision.

In any case, if users want to override the source input they can with something like

Code: Select all

environment.systemPackages = with pkgs; [
  (armagetronad."0.2.9-sty+ct+ap".dedicated.overrideAttrs (prev: {
    src = fetchFromGitLab {
      # insert your custom fetcher here to use whatever sty+ct+ap you'd like...
    };
  }))
]

[Lucifer]

The --input file used as an alternative to stdin. The NixOS module runs it as a systemd service and uses --daemon --input /var/lib/armagetronad/${server}/input. It seems like this just has to be an empty file instead of a fifo or the server will just block on reading it, which makes sense.

I don't know whose idea that was, but they should be fired. If there is no other process connected to the pipe, the kernel will not start the process. In other words, both sides of the pipe have to be connected to something before any associated processes can start.

So the file *should* be a text file, and you should be able to echo to it to send it commands. That's how I wrote it for a little project awhile back.

[numinit]

I don't know whose idea that was, but they should be fired.

I totally forgot about the process spawning behavior with named pipes. Yikes. Reason #100 why I don't bother with them.

In any case, the text file works (and has a unit test in the NixOS module )

[numinit]

Just an update. I couldn't get this into the NixOS 23.11 release due to a lack of code reviews. The PR is still active and just waiting on review. it should be in 24.05; if you think this would be valuable give it a quick review.

https://github.com/NixOS/nixpkgs/pull/263765

EDIT: also bumped git SHAs for 0.2.8-sty+ct+ap and 0.4. This one should merge more quickly: https://github.com/NixOS/nixpkgs/pull/284626

[Z-Man]

This NixOS of yours, very clever.

First post from NixOS. What gave me the final push is this video: https://www.youtube.com/watch?v=CwfKlX3rA6E

Yeah, this looks very tantalizing, especially for developers. Most of the benefits of Docker, Flatpak, ZeroInstall etc. without most of the drawbacks. No complicated call syntax, run any version of any program at any time. We'll see how it goes.

[numinit]

Nice.

All the builds are about to be updated (https://github.com/NixOS/nixpkgs/pull/284626) and the Armagetron Advanced module made it into unstable, for a release in 24.05.

https://search.nixos.org/options?channe ... magetronad

[delinquent]

I love the idea NixOS. I also hate the idea. If you limit yourself solely to single-file config like that, you're somewhat locked-in to a given ecosystem. That's not really linux - but at the same time, there are some very useful fundamentals here. Package managers could use stateful restore functionality, for example. Grub could do with saving the previous configuration and presenting it as an option if the primary config fails to boot.

I actually considered NixOS for a while too. Ended up with Debian after riding through a couple of distros that just didn't suit.

[Z-Man]

Yeah, for someone who loves total and direct control over their system, NixOS is a bad choice. It's the law of leaky abstractions that can strike. You're writing some configuration, and some not entirely clear process creates a different configuration, which some other program then uses. Worst case, you have to debug TWO things, the program you want to configure, what its configuration file should be, and then how to get to that configuration using the single configuration language.
That has not happened to me so far, and I don't see it happening, because I'm mostly a "the defaults are mostly fine"guy. And there always is an escape hatch: you can just order the system to copy a prepared configuration file or script wherever you want.
The configuration can be dead simple. For example, I just want a webserver serving some directory with php enabled, to test our main webside before I publish edits. Previously, I had to make sure php and apache are installed, activate the php module in some configuration, then do stuff I forgot in some other configuration file. On NixOS, it's

Code: Select all

# really my config
services.httpd = {
    enable = true;
    enablePHP = true;

    virtualHosts = {
      localhost = {
        documentRoot = "/home/www";
      };
    };

Where the defaults are NOT fine for me are fonts. I WANT a non-antialiased bitmap terminal font. Disabling antialiasing globally is not an option, because most fonts no longer are usable that way. But with

Code: Select all

  # non-essential bits snipped, there is also which fonts to install...
  fonts.fontconfig = {
      antialias = true;
      allowBitmaps = true;
      useEmbeddedBitmaps = true;
    };

I state my preferences: Can use pure bitmap fonts, use bitmaps in mixed fonts if available, use antialising if you must. I don't know which system configuration files this influences, and I don't care, it works, and the NixOS documentation was good enough to get me there.

And you are right, you are caged in. You can, after an appropriate nix-shell invocation, build arbitrary software with whatever is usual and install them outside the main system; but they will have hardcoded paths to the libraries you had in your store at build time, and those can be gone at any time. So that is not practical.
But again, for me, that cage is a big, roomy box all for myself. It has everything I need in it as native packages. There are 80.000 (though that counts packages and some things have multiple packages, for example for different major versions, so the actual number of things is likely lower) Everything I had to resort to flatpak or AUR or worse previously, it is there.

The one exception to all being open-webui, a frontend to the local AI runner ollama, which only has docker as its supported ways to run it, so there are no native packages anywhere. There I needed to define a service that runs the container, and to do that, I had to reverse the command line they give into NixOS options. That was straightforward enough, though.

So *I* like it quite a lot so far. But I also cannot recommend it to anyone On top of the above disadvantages, most of the documentation is dreadful. Really, after you found out somehow where to start, the global options search function here is your only friend.