Hey all, recently I’ve gotten back into my programming kick and I’m putting some good, serious effort into completing and deploying MineOS-ruby.
This is long, long, long overdue, since I first started this about 2 years ago and then put it on a hiatus. However, some of the more recent posts to this discourse made me think: “hey, remember that time I made a ruby-based mineos and it solved, like, all the issues I’m seeing show up nowadays?”
Well, I’m glad to announce that the code I wrote 25 months ago still holds up and after a very strong re-read of the code, I feel confident it was engineered well enough to continue today.
I’m now a few dozen commits into modernizing this codebase with all the features I was hoping to back in the day.
I have the S3 interface working nicely (self-hosted is currently the plan) and it seems to work wonderfully for the sake of downloading/storing server profiles and server archives.
I have the hq/worker model working nicely, meaning there’s a server that handles all inbound requests and dispatches it to the appropriate worker (which very well could be a single-machine setup). I have the AMQP messaging system in place (for reliable delivery/requeuing of all requests as necessary).
This all, of course, is just self-adulating name-dropping. While administrators will have to install these lightweight apps, its operation will be largely transparent and admins will not need to learn them in order to use this iteration.
Where I’m at:
ruby interface for Minecraft Jars and Phars complete.
I’ve designed it in a way that means I’m a stone’s throw from being able to also work with normal binaries (e.g., C/C++ servers) without any compromise:Normal binaries–like C/C++ compiled servers–are now implemented; they will beare feature-complete compared to jarfiles.
HQ operates fully with REST API and websockets. The HQ works. What I need now is just the right plan for webui design; the single-host model of
mineos-nodeis now expanded to multiple-hosts, so the webui should be updated to reflect the distributed nature of the numerous supported workers.
Workers now attach directly to the I/O of the processes themselves, so this marks the end of trying to send something to the console that has gotten mangled with escaping; what you want sent to the server process will be exactly what you expect.
The current object store (s3 compatible) is a lightweight binary but also includes a web interface for the uploading and downloading of archives. It’ll also allow point-and-click interfacing for a) deleting archives, b) deleting profiles, c) managing import-archives.
What I haven’t done:
- auth mechanism. This is 1 of the two areas I want any input offered for. Take a look at this auth YAML file.
Right now, you’ll see a list of permissions. It reads like this:
permissions: all: - "linux:will" - "mojang:someotheradmin" delete: - "mojang:hexparrot" modify_sc: - "mojang:hexparrot"
On the HQ, a Linux user named
will exists. When logging into the webui, it can check auth against the shadow passwords of the host. This user,
will has permissions to do anything and everything for all functions for one specific (minecraft) server.
Alternatively, I know how to auth against yggdrasil (mojang official), which means you can log in with your MojangID and have, again, 100% control of the server from all perspectives. In this example, I’m whitelisting about a dozen commands “hexparrot” should be able to execute. “All” is all-inclusive–even for commands not listed–elsewise,
hexparrot only has those perms that are explicitly listed.
Lastly, you’ll notice that
console has permissions given to “mojang:lessertrustedadmin”. Realistically, having console access is still pretty strong, because they can change many options as well as stop the server (and not restart it), but more on that below.