The next version of MineOS

Development Feature Request
1

MineOS 0.6.x is now over a year old on github, and I feel it meet my expectations of the 0.6.x milestone. In this iteration, I learned how to write code more platform-agnostic, achieving successful installs on more than half a dozen different distinct distributions/package managers.

Also in this iteration, I moved away from heavy-duty webserver models (Hiawatha) to a service-oriented model, much like those found in Plesk or cPanel. There perhaps may be too many things to list of what I’ve learned and how 0.6.x has readied me for the next version, which aims to address the many calls for greater Minecraft-specific functionality.

I have, over the years, repeatedly emphasized how MineOS (at least up through 0.6.x) aimed to focus on the administration side of things, from a Linux admin viewpoint, rather than a Minecraft server admin. Since I feel satisfied that this version can continue to have usability and educational/functional value for time to come, I can now–without reserve–embrace the other side of Minecraft hosting.

Users have, over the years, continually asked for features like:

  • live feed data, such as logs and memory usage
  • plugin downloading and installation
  • plugin configuration
  • firewall configuration
  • file uploading through the web-ui

Put another way, many of these tasks–if automated by a web-ui–would inhibit learning how to be a Linux admin. I still feel that way, but with the end-product of 0.6.x as-is, I am satisfied that for the future MineOS users who still want to learn Linux administration rather than avoid it, they have a polished, accessible means.

I will continue to maintain 0.6.x as the need arises, such as any area where failing to update it would make it obsolete, but I’d like to move my efforts to learning something new: not Python.

Node.js has stuck out as a particularly promising technology to build a new web-ui in. Since I know little of node.js and I can see the merits of event-based web-servers, it is a natural fit. Hopefully, too, by being Javascript it may also encourage new contributors, who previously were deterred by Python.

That said, I welcome any feedback about this–regarding any of the following ideas!

  • feature requests for a new web-ui
  • ideas about the size and scope of a new web-ui
  • pledges of help
  • whatever else!

Will

6 Likes
2

http://mcjsonapi.com/ is very suitable for building a well-featured web-ui

3

One question I have is how should user management be handled? In the current MineOS, user authentication is based on shadow passwords on the system, and thus it leverages both permissions and security from that model.

Having mineos specific users has the benefit of potentially easier management (forces it into the webui) but has the drawback that MineOS must then have its own authentication system and persistent storage, like a SQLite db. This makes the management of the system entirely dependent on the webui, and to some degree, almost inaccessible/useless via CLI.

This of course may not be a bad thing, but it is different, and I’d be interested in hearing from a good sample of admins!

4

I Love the current model that forces admins to use Linux and add users that way. This also has the side effect of keeping MineOs very “Lite” and not needing extra packages like a DB manager of any sort. This is something to keep in mind during evolution of MineOS. Just my thoughts, but I love the “lite” footprint of MineOS as it is now and would hate to have it grow to something that started to require a lot of other stuff that eventually took up more space than the Minecraft install it’s self.

Thank you for your time that you put in to this project Will. I for one appreciate it.
Lee G. Weaver

1 Like
5

I, too, am very much attached to the notion that forces admins to use Linux and learn how to use standard *nix practices to get things done–this has been my position for pretty much the entirety of MineOS up to this point (probably with the exception of microcore days).

That said, it turns out there’s a lot less performance/“bloat” trade-off than I thought. Or rather, it turns out there are alternative technologies out there that can help me add any arbitrary functionality and make it real-time without it being as bloated as if I were to do it in Cherrypy/Python.

That’s where node.js impressed me so much. The whole paradigm shifted from polling to event-based async, which makes all these added functionalities, e.g., real-time logging, monitoring, and file management actually cost negligible amounts of CPU compared to if I did it in Cherrypy. After a lot of research, I found that this paradigm was also embraced by Python’s Twisted, though I ultimately decided on node.js for two reasons:

  1. while Python is the most fun I’ve ever had programming, Cherrypy/web-servers were the least fun.
  2. I actually just wanted to learn a new api that would force me out of my comfort area.

Asynchronous coding has done #2 in spades, so far. And as a result, it is also compelling me to learn MongoDB (NoSQL) and a few other things. I’d say even this far in I made the right choice–everything about node.js is questioning my assumptions in a constructive way and when the new MineOS iteration comes out (which will be a long time from now, trust me), I think I’ll have every reason to believe that it was time exceedingly well spent.

That said, I feel I must reiterate: apparently, using this new async paradigm, I should be able to be very generous in Minecraft-specific functionality and real-time updating without it taking any noticeable amount of resources more than 0.6.x (it might even take less, to be honest), so I look forward to how it goes as much as you!

2 Likes
6

Somehow I missed that you were switching languages for the next version! Well I wish you well on your journey and as long as it’s not a resource issue then user management may as well be manageable within the interface as long as it’s secure. I certain that you will make as secure as reasonable.

Lee

7

Looking forward to checking the new version of MineOS out.
I have found the current MineOS version suiteable for my needs thus far and i relly love that it works on so many different linux platforms.

My only concern is the security for the next version compared to the security we have now, but im sure you will solve that.

Good luck with the next version of MineOS and hope you learn more about node.js :smiley:

Edit:
As a response to your comment on github:
I would like to see some sort of FTP like file-explorer but accessable from the WebUI. Something like the Net2FTP browser wich uses FTP to access the files (Then i mean just as a visual inspiration on how i think it should look like).
Source: http://www.net2ftp.com/homepage/screenshots.html?PHPSESSID=0arjA65UhDcqm71TIEK1CojYbFc

As for the upgrade system:
You mentioned that you should not change profiles because it is a security risk and hard to go back if the update does not work.
To solve those issues i think it would be better to have a per server upgrade system and by that still keep the profiles intact without changes.

Example: Let’s say you create a new profile called AgrarianSkies314 and you have an old profile called AgrarianSkies212.
Next the users of each server can then go to the upgrade tab for their servers they want to upgrade and performe an upgrade by selecting files and folders to delete, overwrite or keep (using the file-explorer UI then).
Before performing the actuall update the UI should ask the user if (s)he want’s to make a backup/archive of the server before updating to keep as a return point if the update makes the server unusable.

Thats the basic idea that i had for a file-explorer and a update UI for MineOS

8

First, congratulations on the anniversary of 0.6.x!
Since you have already started new version from scratch, can we hope that all UI-text will be in separate files for each language (with fallback to English if there is no match yet)? Avoiding text on images (like in 0.6.x) will be a plus too (or images must be switched between languages also).
About user-management - If new version will be still oriented for learning Linux administration - system passwords are the best. If not, some secure system’s user management, as Lee_Weaver has already said - would be nice, I think.

9

Localization (internationalization) is definitely planned from the beginning, so I have no doubts it will be fully implemented in a way that would’ve required too much rewrite for 0.5.x.

Regarding user-management, I think I’ve decided on yggdrasil, the official Mojang authentication. With plans to integrate existing, well-matured APIs like JSONAPI for bukkit, this should make it seamless for users to log in with their game-credentials and be immediately capable of managing back-end and in-game.

For this model, there will be one group to which users can be assigned, e.g., mineos. Any users assigned to this group (in Linux permissions) will be able to log in and be overlords to the entirety of the webui.

Example:

A user installs MineOS and in the process assigns at least one user to the mineos group, and that user logs into the webui using his normal Linux credentials. He then assigns through an interface individual users access and rights:

GRANT USER ‘hexparrot’:

  • view servers
  • create server
  • delete server
  • manage intervals (backup/archive/restart)
  • manage profiles
  • manage server limits (max java_heap, ports available)
  • add users as webui admins

Manage Server Limits

One thing you’ll notice these all have in common is they’re pretty much exactly the features you can control via 0.6.x. That is, with the exception of manage server limits, which is a new feature I’m currently considering.

Since java heap and what port to host on is now controlled by a user deemed to be a responsible admin–and also since the files are not accessible to change (server.config) by other means such as SFTP/SSH, it means I can enforce resource limits, something previously left to user trust before. This is something that could just as well get the axe, though, since it implies usage and control of iptables, which may not be available everywhere. (I immediately want to make this work on FreeBSD + Jails…). At any rate, the server limits is just a hopeful idea, no more.

Add users as webui admins

The other side of permissions would be that any Mojang account auth could log into the webui (provided they were marked as webui admins). Then, they could perform all the actions that an admin/op might want to do, such as updating plugins, read and type into the console, change server.properties, view logs, create backups, change java tweaks, etc. Immediately you can see this as a more complex model than before, but with this complexity comes greater control of granular functions, like mcjsonapi. Thus, a user who has in-game permissions in bukkit, will have those same permissions in the web-ui (thanks to yggdrasil).

Change in Philosophy

After reading any of this lengthy post you should easily come to the same conclusion that this MineOS interface pretty much is departing from everything that 0.6.x held dear, in terms of teaching a user how to be an admin. Almost nothing about this new interface will encourage learning Linux and its internals. You may ask “why?!” and my answer is: if I just recreated the existing webui in node.js, I’d find it unchallenging and unrewarding. It’s been nearly four years now that I’ve worked on MineOS (Dec 2010) with the intent on educating, and since 0.6.x will still be updated and relevant well past this new iteration’s release, I don’t find it counter-productive to create a web-ui that is cognitively undemanding and doesn’t require Linux skills.

I hope MineOS users can see this departure as a good thing, as I do. I hope that being able to do new things with “0.7.x” such as plugin management wouldn’t feel like 0.6.x is obsolete, as 0.6.x had done to 0.5.x. It’s a new product with a new target audience (and perhaps warrants a new branding). I’m excited, at any rate, for the challenges ahead!

Will

2 Likes
10

Add a button to restart the servers?

11

Restarting servers would be a button now if there were a foolproof way to know the server stops and restarts without issue. Restarting is to the best of my knowledge going to still require admin supervision because of the lack of a minecraft api (that inducates successful shutdowns).

This is all because Some servers take a few moments to shut down gracefully and some take MINUTES. So I cant just add an arbitrary “force close after x minutes.”

After years, I’ve still to see a universal solution :confused:

12

Oh ok, it was just a suggestion :slight_smile:

1 Like
13

Would you beable to check to see if the pid for that server is there or not?

14

MineOS already uses PIDs to determine whether a server is up or not, so the approach is generally pretty straightforward for restarting. However, I believe there are far too many places for error in all the server jars that exist and all the configurations around that make it more complicated, such as “timeout” values and stalled instances.

If you start a new server and then stop it, it will typically end on the order of seconds. For some larger servers, it takes lots of time, often more than 60 seconds. So, MineOS right now errs on the side of caution and says “when restarting, be present and check everything goes okay” because on some occasions, what if that ‘stop’ command stalls? What if the jar somehow glitches out and the server never fully closes the PID?

Does MineOS kill the PID after x seconds? Does it let it run indefinitely? What would the possible implications be for an admin who regularly sets his servers to restart, only to find that one or more servers have been stalled for several hours?

I guess in more realistic terms, restarting isn’t that hard… damage control and liability are. I already get many emails talking blaming my work for failed backups, archives, and loss of construction. If adding a error-prone feature can increase admin inattention, it’s something I have to hold back on, at least until perfected for all use cases.

15

Thats seems very sensible and makes sense.

16
17

This might be a dead topic, however I would like to state that I am member of the Mine OS family for about 2-3 months, and I have loved every moment of it. It is easy to use, sometimes I tear my hair out because I forget how to properly place the files so the server can see it. That aside, I have found this Streamlined Minecraft server hosting OS to be an amazing feat, and would love to see more of it happen.

However I would like to also make a suggestion. I host modpack servers, and create my own modpacks, and this might be a little much to ask for, however is there a way we can get CurseForge compatibility? A way to build a server from the starting points, such as collecting the peices of the forge server together, like, the Forge version, minecraft server jar, mod jars, and then set it up as a server. There are a lot of tutorials out there that show you how to build a minecraft forge modpack server, I think that you would be able to find a way to automate the process.

This will also make it so that this server OS is very friendly to Minecraft Modpacks, and give you a very good portion of the community to come and test your already amazing platform for server hosting.

Heres hoping that I am able to convince you enough to give it a try.

18
19

May be it must be feature request for 0.6.x version, but I decided to write it here.
Okay, this is the point: MineOS has two useful features - rdiff-backups and tar-archives.
But using rdiff-backup we can only restore server (all files), thus, overwriting live server files and/or create ANOTHER server from tar-archive, without touching live server. Rdiff backups consume far less disk space than .tar archives, but we have no possibility to restore SOME corrupted server files.
With .tar archive we can create new server, replace needed files to live server, and delete temporary one, but archives take a lot of diskspace. Also archive is useful when we need to move server files (to another host, for example.) Having both features scheduled consume disk even more faster.
If we had an option to recreate certain rdiff-backup to another folder while server is still running - it will be optimal solution in my point of view.
If it is not possible/applicable in 0.6.x, can we expect some more sophisticated backup handling in the next version?

20

It’s unlikely that I’ll code that into MineOS. The delicacy of individual file restoration is something that I’d be afraid to touch, because for the most part, this skirts around data-loss and user error (and subsequent “your UI is bad and I lost my progress” emails).

You can actually use the cp command instead when trying to restore from the most recent restore point:

cd /var/games/minecraft
cp backup/servername/server.properties servers/servername/

(even copying from SFTP will work too).

So basically, if you want to restore using the most recent restore point, use cp. If you want to retrieve from older restore points, you can do so with the rdiff-backup command:

cd /var/games/minecraft
rdiff-backup -r 5B backup/servername/server.properties servers/servername/server.properties

This will restore the server.properties file from 5 backups ago (not time specific). There are other time formats available.

Put short, the capability to do individual file restoration is there, by MineOS simply using rdiff-backup, but it’s not likely going to get coded into the UI because I’m bad with UI and I want to avoid accidental loss from user error.