While I see the effort you did in porting everything, a couple of things instantaneously catch my eye.

1. Dedicated service user: You install everything under your user, which most likely is able to do sudo. Not a good idea securitywise. Use dedicated system users with minimal permissions and no shell.
2. screen is outdated. tmux is far better supported, updated and used.
3. Long running processes are better to be started with systemd services; this way you can also limit resources in a better way.

While I only did stuff for CSS, you might be able to fetch some ideas out of this script:
https://github.com/M3tal-Warrior/installers/blob/master/cssource/install.sh

I focused on ease of installation as well as security, as I... well, do this professionally ;) So if you need further help (or encounter bugs/issues with my stuff), feel free to drop me some lines.

Originally posted by Metal_Warrior:

While I see the effort you did in porting everything, a couple of things instantaneously catch my eye.

1. Dedicated service user: You install everything under your user, which most likely is able to do sudo. Not a good idea securitywise. Use dedicated system users with minimal permissions and no shell.
2. screen is outdated. tmux is far better supported, updated and used.
3. Long running processes are better to be started with systemd services; this way you can also limit resources in a better way.

While I only did stuff for CSS, you might be able to fetch some ideas out of this script:
https://github.com/M3tal-Warrior/installers/blob/master/cssource/install.sh

I focused on ease of installation as well as security, as I... well, do this professionally ;) So if you need further help (or encounter bugs/issues with my stuff), feel free to drop me some lines.

Thanks for the feedback!
Some points ...

• Actually in the guide, I specifically say NOT to run the games under "root" (or any sudo-enabled account). Only OS prep type stuff (installing packages, etc.) is done under root or sudo.
  
• yeah "screen" is old, but its what I had already coded for years ago.
  
• All the "run" scripts have executables wrapped in "nice". But yeah, there's always going to be a better way - for those the really know their way around Linux anyway. This is kind of for relative Linux noobs.

But any additional notes for others I am sure will be appreciated!

Originally posted by Weasel Ⓢ (Probably AFK):

Actually in the guide, I specifically say NOT to run the games under "root" (or any sudo-enabled account). Only OS prep type stuff (installing packages, etc.) is done under root or sudo.

Yes, but the installer uses $HOME, which is the home directory of the installing user. Alas I didn't entirely work through all the script, things like that catch my eye ;)

Originally posted by Weasel Ⓢ (Probably AFK):

yeah "screen" is old, but its what I had already coded for years ago.

You will find if you execute the stuff with systemd services, you don't need tmux/screen any more. Furthermore the servers do start on reboot automatically and can be restarted with single commands without switching users, or can be restarted all automatically if they bail out for some reason. I'd wholly recommend that, especially since the executing user doesn't need a shell associated with it, so even if an attacker gains permissions to do stuff on the system, not having a shell is an additional obstacle.

Originally posted by Weasel Ⓢ (Probably AFK):

All the "run" scripts have executables wrapped in "nice". But yeah, there's always going to be a better way - for those the really know their way around Linux anyway. This is kind of for relative Linux noobs.

Using nice to start services shouldn't be necessary, as all crucial services already run with higher priorities (-10 and below). And nice only accounts for CPU. Limits in systemd are a lot more sophisticated; RAM, CPU, disk space, (forced volatile) private file systems (like in docker, but better), file descriptors...
Point is: A lot of stuff you have to do with your scripts manually is taken care by systemd out of the box, like logging (as everything that the server burbs out on STDOUT is being logged directly with the standard system log facilities).

If you're interested, we could talk a bit while gaming together ;)

P.S.: I didn't mean to criticise you, quite the contrary. I know how much work went into those scripts, I do shell scripting quite a lot. So please don't feel down due to my comments, I very much appreciate your work and wish I'd find more time for doing that too...

Originally posted by Metal_Warrior:

P.S.: I didn't mean to criticise you, quite the contrary. I know how much work went into those scripts, I do shell scripting quite a lot. So please don't feel down due to my comments, I very much appreciate your work and wish I'd find more time for doing that too...

No worries man! Everybody's got a different way of doing things!

Some people over the years had asked me to explain how I had things setup and share my scripts with them. But, I had way too much dirty stuff in my scripts (hard-coded accounts, passwords, keys, etc.) to share them. So, when I finally got-around to cleaning things I up, I made sure I made them more cleanly publishable for anyone who might want them.

In particular, used to host a bunch of TF2 and FoF stuff, and would get alot of questions from FoF community on how to host this stuff.

Take care!

PS: Also just added a sample virtual machine for VMWare Player in the last section of the guide.

Originally posted by Weasel Ⓢ (Probably AFK):

Some people over the years had asked me to explain how I had things setup and share my scripts with them.

Guess who wrote a quite prominent Minecraft server admin script back in his first years on Linux, prior to the advent of systemd ;)