[DISCUSSION] Rust Server v2 (feedback requested)

[Dids]

Please post ideas and suggestions regarding this Rust Server image here.

The plan right now is to rewrite this entire image from scratch, with much more customizability and more unique features, but still providing the core features of the image, such as automatic updates, Oxide/uMod installation and built-in RCON support (included RCON web-interface is still under consideration).

At least the following more or less major changes would be happening:

• Environment variable names would change, some more drastically than others (this would become more dynamic, where env vars would be automatically parsed and fed to the appropriate systems, such as the Rust Server binary)
• All custom tools rewritten in Go (this would not only provide stability, but also remove Node.js as a depedency, allowing a base image change, as well as making them much faster to run and lowering the maintenance cost)

[Luxian]

An upgrade path for existing servers.

Other than that, the web UI doesn't support HTTPS. ws:// is hardcoded (should be wss:// when loaded using https).

[Dids]

Upgrade path/migration sounds good!

Last I checked, Rust itself doesn't support wss:// (SSL), unfortunately. Not sure if that has changed though.

[Luxian]

Upgrade path/migration sounds good!

Thanks!

Last I checked, Rust itself doesn't support wss:// (SSL)

I currently run a nginx reverse proxy in "front" of the container. The nginx does SSL termination, so the container should not care about the SSL (handled by the reverse proxy). My assumption is that the problem is in the rconService.js, where the protocol is hardcoded (line 19). In my opinion, it should be a check there for the https/http handling. Unfortunately, I could not find a repo to send a PR for it.

Later edit: I'm not sure where this is coming from (if it's this container or Rust itself), but having the password in the path sounds like a bad idea. The password will end up in the access logs, in plain text.

[Dids]

Last time I tried it, I used Traefik + Let's Encrypt to implement SSL for it, and while the web app itself was secure, the websocket connection was not (with the websocket protocol replaced, it just failed the connection).

As the web UI is an old proof-of-concept by Garry himself, it might make more sense to just create a new one from scratch, otherwise we'll need to maintain an up to date fork of it. All that said, securing it is definitely more than a good idea and should be implemented where possible.

Regarding the password in the path, that's unfortunately how it's implemented in the Rust server itself. Not sure if there are alternate means though, such as passing it in the header.

[Luxian]

Last time I tried it, I used Traefik + Let's Encrypt to implement SSL for it, and while the web app itself was secure, the websocket connection was not (with the websocket protocol replaced, it just failed the connection).

I have no experience with Traefik, but it sounds like the port 28016 wasn't doing proper SSL. I need to run more tests, but I've seen this work in other places (here + issue)

Later edit:
I added a filter in my nginx reverse proxy config that replaces ws: with wss: in all javascript files on the fly and it works. It's definitely a limitation of the JS code.

[Hardcore-fs]

What we have now is really good but just a few changes:

1. be able to pass files in for things like server description, so the command line will not get overly large. might even work for the password.... have it in a secure file accessed by the docker container on the attached volume., pull from file assemble internally & inject internally. The fact they messed it up & pass it in as a "Text string" is not something you can fix.....

2. change seed & config values by a simple config file & "docker restart".

3. move to a slimmer version of O.S inside container (cent-os7) enterprise base kernels most other stuff can be solved with scripts & K8s certainly the firewall stuff should go outside the container... for better integration. Also who knows what goes on with their "anti-hack" & other "EAC" systems

[Luxian]

@Hardcore-fs you can already 1) do that by using .env file (docker functionality). It's explained in the tutorial. Alternatively you can use docker-compose and define everything there.

Since 1) it's doable, 2) already works the way you want.

[Hardcore-fs]

You are confused..... good luck on changing the : RUST_SERVER_DESCRIPTION=

to all the text , carriage returns & HTML you would need, FIRST TIME so that the server can accept it, without spending 10 minutes shutting it down, cleaning it up &before you can be trying again.....

[Luxian]

Sorry I misunderstood you.

[D0tty]

A nice thing would be a web admin for the Rusts containers (a bit like https://www.portainer.io/ does for regulars Docker containers)

We could manage all our Rusts containers from a web app, edit seed, description, etc

[Hardcore-fs]

Many of the commercial services already offer this..... but if dids can get in some of the changes he is proposing, and that coupled with the new "umod" webfront end instead of Rcon & the promise of getting away from "mysql" by finally using a standardized way of database driver interfaces a lot of this is becoming possible...

[turowicz]

Please add wipe schedule with options such as BPs etc.

[Maelep]

Add the possibility to enable/disable more extensions (with auto updates):

• RustEdit
• Rust:IO
• Discord Extension

These are extensions (not plugins) and enable more customisation for server owner and for plugins developer. As a plugins developer it would be perfect have these extensions integrated by default and autoupdated like uMod.

I'm not developer, I only develop Rust Plugins but I made a small MS-DOS script that could help you to add these extensions. My script also add a plugin updater: a simple txt file that contains some plugins name from uMod to update them at launch. It's great for important plugins like anti-cheat, debug plugins, ...

:discordExtension
echo Updating Discord extension...
curl -L "https://umod.org/extensions/discord/download" > "%cd%\RustDedicated_Data\Managed\Oxide.Ext.Discord.dll"
echo Discord extension updated.
goto rustEdit

:rustEdit
echo Updating RustEdit...
curl -L "https://github.com/k1lly0u/Oxide.Ext.RustEdit/raw/master/Oxide.Ext.RustEdit.dll" > "%cd%\RustDedicated_Data\Managed\Oxide.Ext.RustEdit.dll"
echo RustEdit updated.
goto rustIo

:rustIo
echo Downloading Rust:IO...
curl -L "http://playrust.io/latest" > "%cd%\RustDedicated_Data\Managed\Oxide.Ext.RustIO.dll"
echo Rust:IO downloaded.
goto pluginsUpdate

:pluginsUpdate
echo Updating plugins...
mkdir "%cd%\oxide\plugins"
if not exist pluginsList.txt (
    copy NUL pluginsList.txt
    )
for /F "tokens=*" %%G in (pluginsList.txt) do (
    curl "https://umod.org/plugins/%%G" > "%cd%\oxide\plugins\%%G"
    )
echo Plugins updated.

[Dids]

Sounds like a great idea! I'm a bit out of the loop as to how Rust works nowadays with uMod, but since these extensions require uMod, wouldn't that automatically flag the server as a modded server? If so, that needs to be taken into consideration, as not everyone wants that.

[Maelep]

These extensions requires uMod and, because of uMod, your server will be listed as Modded but you can ask to Facepunch to move your server to the Community section if your server respects the guideline.

Theses extensions doesn't modify the game, they only add the possibility to customize the server deeper.So you'll need to install and update theses extensions only if uMod is installed and if the user want theses extensions.

Enable uMod: True/False     - Enable Rust:IO: True/False     - Enable Discord Extension: True/False     - Enable RustEdit: True/False

[Hardcore-fs]

it aint gonna work...... easily.., please keep the system clean.

Currently there is a battle between various factions... over rust plugins each has their own system for marking and validating plugins, then there are issues related to how the plugins are loaded & unloaded, Then some guys have split off individually..... taking what were opensource plugins with them, not to mention atleast one spat between plugin programmers over not accepting patches....

some have dependencies on other plugins, unload the wrong one & you start abending other plugins. or worse suffer data loss. Not to mention there are thousands of these damned things, and if you start passing this crap on the command line, it is going to get out of hand very quickly. (an average server can easily have 50-100 and some guys are running several hundred.) Plus there are various interactions , between different plugins that impact them negatively.

Also these extensions DO modify the game. or at least the game play, load a bad one and the interactions can easily cascade... so then you need a system that unloads them all and is capable of swapping them in & out live.

(think like conflict catcher on the old mac os7)

You can Easily waste several hours with this garbage...... (and different versions) I actually looked at making a 'rust' plugin to manage all this via a database & SHA 256 checksums, but sadly RUST won't allow plugins to modify the directory structure or file structure of other plugins

The only way currently is some OS infrastructure OUTSIDE of rust, but then you have issues with intercommunication between where you store the plugins,data and other related stuff.

Say for example you run your containerized "rust" with an external system for file storage, that means you have a process inside the container, trying to load & dick about with items outside of the container at an OS level..... and if you have say centos or worse windows as your os, but something else inside the container.... good luck on WHERE you are going to pull these updates from.

I already put a lot of thought into how I can make my life easy on this stuff,.. without it getting massively out of hand... sadly.. it needs the Umod guys to start laying down some SOLID rules about data storage & location, load order & interdependentcy mapping... or expect to have to start keeping records of separate file paths for each plugin to find the s**t they use.

so that above script, won't work reliably...... cos u only gotta have those "curls" in the wrong order to take the server down & people to loose all thier game shit....

[Maelep]

I understand you point of view about conflicts and others but I suggest to allow us to enable/disable each extensions.

Personally, I use this tool to develop plugins on my Macbook and it could be really useful to have an updater that will do that for me.

My script suggestion is just an example, as I said, I'm not developer, I just made this script to help me but curl is probably not the best way to integrate it in a container. @Dids has more knowledge than me, he probably know how to do it better.

What the problem of adding the possibility to add extensions? If you don't need them, don't enable them, that's all.

But a good point to mention, if I enable the extensions then choose to disable it, don't forget to check if the file exist and if it exists, delete it because it will stay there and run if not deleted.

From what I see, the developer of Discord extension is the developer of RustEdit and he is a well know developer of uMod plugins. Then Rust:IO is an extension that is use by MANY servers. The idea isn't integrating these extensions by default but allow user of this tool to easily manage extensions.

[Maelep]

I would like to suggest to add new commands: (I don't know if it's possible but that could be great)

- wipeall [restart]: Delete all files in the server directory except companion.id and the cfg folder.
- wipemap [restart] : Deletes all .map & .sav.
- wipebp [restart] : Deletes bp files.

These commands shutdown the server, execute the command then restart if set.

[Hardcore-fs]

I'm all for stuff that makes my life simpler... Don't think I don't feel the pain of all these damned plugin updates, poor programmer skills leading to multiple updates within HOURS!!! of already released plugins.. then having to run thru a damned audit list of "exploits' every time!!!

I also develop on a mac....(and yep RUST, but my plugins are only for private use/sale), I use containers, VM, K8S extensively.... Putting this inside the container, is not really the way to go, adding s**t in to a docker container means it HAS to be maintained. I'd rather have other more central things added in.

it has to work reliably across MULTIPLE platforms & not clutter things up or make it harder to understand.

Also.... I think you have not looked at all cases..... in some plugins there is crap all over the place....., then others you might want to keep the configs & data

EG( welcome , & kit settings, Copy & paste bldings, multi-lingual files) so your "wipeall" suddenly becomes some system to not "wipeall" and even MORE lists of exclusions....

we STILL come back to HOW it would handle interdependency/load order.........

I'm not clear WHY you would put this inside the container when it is all external FS related..... unless you made the mistake of putting you storage INSIDE the container?

[Maelep]

Add a SSH and FTP access.

[turowicz]

I would like to suggest to add new commands: (I don't know if it's possible but that could be great)

- wipeall [restart]: Delete all files in the server directory except companion.id and the cfg folder.
- wipemap [restart] : Deletes all .map & .sav.
- wipebp [restart] : Deletes bp files.

These commands shutdown the server, execute the command then restart if set.

also add option to generate random seed / provide manual seed.

[Maelep]

Use https://pterodactyl.io/ instead of the current rcon console.

[Hardcore-fs]

Use https://pterodactyl.io/ instead of the current rcon console.

not only is the demosite mostly broken.., bad links, out of date software and general failures it is in no way a replacement for Rcon........

[Morgyn]

For Community vs Modded it's a setting within oxide. (Within oxide.config.json)

I feel strongly that updating extensions and plugins is out of scope of the container.

https://pterodactyl.io/ could be run in another container if required and I feel is out of scope?

Wipe schedules are quite tricky and I've been working on solving this myself, but time is very odd.

An App to manage wiping sounds a like something worth exploring, not sure if you'd do it based on creation of the container or triggering it externally, or even as an exec. At the moment I destroy the container, delete the relevant files then recreate the container.

[Morgyn]

What I'm currently working on and I hope to complete this week is heartbeat for the server so it detects hangs (where the server crashes but doesn't actually exit, leaving the server unresponsive) and support for custom maps.

[Hardcore-fs]

already did this years ago... there are a number of specific cases..

1. the server processes hang (really really rare for linux)
2. The internal timers in rust get backed up and fail to fire, which makes triggering events impossible. Electricity is a massive problem with hangs and backing up queues.

You cannot automate wipes & updates of modded servers, becasue of the nature of rust. Thousands of plugins by different people in different time zones & a continually changing API

i'd watch out for "Pterodactyl" it seems to be getting polished ready for switch over for pay per use model.