From Sector Alpha Wiki
Jump to: navigation, search

The general idea is that we want a tool that will let users start servers easily and also let us admins manage them easily.

The code is maintained in a private repo at


General Plan

  • Run game servers inside of screen sessions (with a specially formated session name) as the user
  • Games are started either directly by the user or by @reboot cron jobs for the user
  • Admins connect using a managment script run as root that changes users with su and then runs commands on the server as the relevent user
  • Admins can also run commands on all available servers which just does the above on a list of session found using ls
  • Commands will include at least the following
    • Create - setups a new game server either using the supplied args or by prompting the user for information
    • Start - starts a game server
    • Stop - stops the game server
    • Message - sends a message to all users on the game server
    • Connect - connects to the game server directly in such a way that you can directly send commands to it
    • Status - check the status of the server
    • Set - set a setting in the servers data dump
    • Backup - backup the game servers data and settings
  • if a wildcard stop is done a list of all servers stopped is stored in a file in roots homedir so root can restart with a wildcard start command


The plan is to implement this using a set of scripts probably mainly written in python.

The first step is to write a basic "connect and send commands to screen sessions" module. Then each game server can have module that translates a request into the input to send to screen.

Then we need to implement a module for each game server. Each game server will have a settings file stored in json format in the users ~/.gsm-games/ folder which at the least will store the info of which game server module to load. Beyond that all interpretation of config is up to the game server module.

The top level script will be run with commands line of the form


This will depending on the first argument do one of the following

  • SERVERNAME - load the config for the server and translate COMMAND and ARGS to a format to send to the screen session and then send it.
  • USER/SERVERNNAME - use sudo to try and run itself as the relevent user and with just SERVERNAME instead of USER/SERVERNAME
  • * - depending on the command build a list of "all" servers and then run itself on each of them with the command and args as specified
    • For Stop, Status and Message this will mean get a list of all screen sockets and use that to get a list of all game servers. For stop it will also write a list of the stopped servers in the current users home directory.
    • For Start use the list of servers stopped by the latest stop command
    • For all others if run as a normal user then pick up allthe configs from their config directory
    • For all others if run as root fail


  • The general framework is now implemented and works
  • We don't currently have logic for finding "all" servers. I will add this shortly
  • Docs are being added as I get round to it
  • The Minecraft backend is mostly there but needs a few more features.
  • All other backends are still to implement
  • There is a slight bug on running command on a single server owned by another user in that it shows the internal "flag string" (this "flag string" is needed so that when multiple are run it can tell when sudo has finished processing)

Usefull Bits and Pieces

  • Command to start screen session disconnected
  • Command to send some input to the program in a screen session
    screen -S SESSIONNAME -p 0 -X stuff "INPUT"
  • Code to emulate tail -f - This is needed to programatically check the output of a server.
    Basically we open the log before we send a command. Seek to the end, send our command and then keep reading any output given till we decide we have read enough and then close the file.
    • code handles more cases -
    • more pythonic style and returns output as a iterator -

Useful stuff for potentially setting up a bash completion script

  • sudo sudo -llu mc-staircase -U www-data /usr/local/lib/alphagsm/alphagsm-downloads
    • This tells you if a user (e.g. www-data) would be able to run the command (e.g. /usr/local/lib/alphagsm/alphagsm-downloads) as another user (e.g. mx-staircase)
    • The reason for running this as root via sudo is as it then doesn't ask for a password and this seems to be the only way around this. I am suggesting we could add an entry in sudoers that says any user can run this exact command (but with any usernames) but only for a specific command (or maybe two commands)