The next version of MineOS


Actually, I did not ask for individual file restoration, but full restoration of all server files to another folder (like create server from archive, but from backup).
Something like this:
rdiff-backup -r 5B backup/servername/* servers/new_servername/*

Anyways, thanks for the commands and quick reply.


Pretty much anything that can be done in command line can be automated, but the question unfortunately isn’t “how difficult is it”, rather than “how difficult is it, how hard is it to program, and what is the cost saved?”

To automate this process, I’d have to get pretty familiar with Forge servers, which is something I have arguably zero experience in. Forge servers for me have always just “worked” because I could download them and voila. In much of the MineOS coding trying to determine Forge versions, Minecraft vanilla versions and etc from the files themselves, I’ve found the task to be quite difficult among all the varieties that get released.

For example, I’ve had to code in 5 unique variants of version-detecting to figure out versions so far of various softwares:


Hardcoding paths, etc. isn’t a great practice because it lends for the code to go obsolete over time. In addition, if new variants come up and if I do not code it into the scripts (or users don’t update to the newest scripts), things break and it usually falls back to “I’m using Software X and the web-ui is broken, and I’ve reinstalled and it’s still not fixed”).

Because of this, I try to limit MineOS’ interaction with Java and the Jars itself, rather than the construction of the jars. This problem would be exacerbated if MineOS could construct the jar, but couldn’t even detect the version!

TL;DR; I think creating Forge jars might be outside my goals a bit. If you can provide any documentation that shows it’s an easier task than I currently think (in my head), I’d be happy to reevaluate.


Well, what I was thinking was not even to worry about what is the best version of a file. Typically, I cant say always, a developer will mark something as latest or recommended. You could probably pull from those links instead of from the newest created link as the process is already done for you.

As for the formulation of a forge server the process is just mundane, not difficult.

  1. Collect minecraft_server.jar, activate jar, then shut down server
  2. collect forge.jar, rename to modpack.jar, activate jar, then shut down server
  3. collect mods.jar, store them in mods folder, activate server, then shut down
  4. configure mods, using the config folder
  5. Finalize collected mods by archiving working folder
  6. Start the server and enjoy!

This is the process that I have been following the last two times that I created a modpack on my own and it has worked out for me each time. Getting the experience is great, however its very tedious because everything you need is scattered in dozens of places. Having the ability to create the forge server, and select from curse forge the mods that I wish to place in the modpack, would give me the ability to try a bunch of different types of servers without worry of messing something up in the collection of the jars.

Also Instead of hardcoding the paths you could just modify the profile section to pay attention to forge requirements? This way it can still automate the process while not requiring much extra coding procedures.


One of the largest problems is that it is required for MineOS to be able to accurately determine the versions, because it will determine which “ping” protocol to use. Protocols have changed much from 1.5 (still in use), 1.6.4, 1.7, and will continue to change going forward as Mojang creates new aspects of the world.

Now, I need to accurately determine the version because I have to send the correct ‘Send me your server status’ packet. Sending the correct packet gives an immediate response and an immediate socket closure, whereas sending the wrong packet gives a response sometimes delayed 3 or more seconds and a socket timeout at 20. 3 seconds, even if constant, would make the web-ui unusable (because that would be the delay for each request that checks if the server is online).

Now, ultimately, most of the forge jars created will still be similar in nature and could possibly still use the same 5 (or a few more) hard-coded paths I have put in place, but it’s not really the technical reason there that is most deterring: it is the notion that if a server doesn’t start up properly or is unbearably delayed, it would not be feasible for the end-user admin to determine whether the problem is in the MineOS scripts (version detection), the Forge jar-creating process, or some other facet of the creation process. In other words, I’d be relegating the responsibility of creating a working jar to myself (which is something I have no experience in) and opening up endless combinations of forge mods which I myself am not entirely certain I can anticipate.

At least with self-made forge jars, when it doesn’t work, an admin knows to try starting up the server manually (most of the time), by opening it at the command line. When it doesn’t work, they know it’s not in the MineOS workflow, so they know how to hone in on the problem. By trying to create the jar for them, that distinction is muddled.

Let’s put it another way: I’m not familiar (or even very inclined) to learn how to create forge jars, but if any users out there can lay down the foundation work for automating jar creation and validating its mods, I’d be happy to integrate it into the MineOS workflow. Short of that (getting help from admins interested in using it, trusting it), it is unsure whether this endeavor will have a good effort/payout ratio.

As a side note, you’ll see that this workflow for creating jars is useful even if one didn’t use MineOS, which is another reason for its separation from the main product (i.e., a different git-hosted project).


Maybe if you had a way to add hooks inside of minecraft like your own addon. The addon would have to change depending on version, so you would know for a fact what version it would be, and then this way you have stronger control over what happens in the game from the web-ui because you will be collecting a lot more information. You could even provide a dynmap like sub-application for administrators. Not sure, just saying a lot of avenues you can explore with what you have got here.

Making so that you can have your own hooks into minecraft itself with your own Mod seems pretty awesome, alternatively, you could ask the user to define what version of minecraft it is, this way you will know what version it is and can code for it specifically with a class that takes version as an input.


@above I agree with this.

Also I love the lightness of Minos and use it as a base to host other things such as a teamspeak server on the same pc. In the new version please maker sure there is still cli access for the people who want/need it.


Command line access is something that comes with the distro, not the control panel you install atop it to manage Minecraft.


Not knowing all of the technical stuff you’re speaking of, I ask of you this.

Keep it as lite as possible, because it is great as it is now. I run an 8 player server on a hacked Acer C710 Chromebook, with an Intel 847 Dual core (only 2 total threads) @ 1.1 Ghz with 4Gb Ram, and have never had a lag or timings problem. MineOS is running as a native install. With a laptop with such little processing power to run as well as it does, it tells you that MineOS is definitely a lite weight OS.

Don’t get too caught up in adding so many features that it bogs it down. If someone can’t handle a command line function every once in awhile, they should either learn or move on.

Thanks again for a great package.


Another idea for new version.
Creating several MC servers on same machine has some disadvantages, like one of them consuming all resources - e.g. CPU, RAM or disk space. And it is more convenient to create separate virtual machine for each server - at least for me. But when it comes to check up all server’s status - I need to login to each server. So idea is simple to imagine, but seems not easy to implement - to have dashboard for MC servers from several hosts. Autologin to another host from consolidated dashboard without authorization will be another useful option.
This can be separate project, though.


If you want people to contribute it would be easier if you had commented your work, instead of us having to figure out what you’re doing.


I agree that having more commented code would better facilitate contributions, though I’ve long conceded that comments aren’t enough to entice contributors; I’ve much more thoroughly commented on the Python-based MineOS scripts and pretty much all contributions were localization and bug fixes, rather than code that adds features.

A zero-fork count for mineos-node tells me that nobody is interested in writing code. One can blame having too few comments, but that explanation doesn’t stick with me, because if somebody were interested in writing any code, they’d be required to reach out to me somehow, to get a top-down picture of what mineos-node is going to be. After all, mineos-node is a moving target with not-yet-set-in-stone goals, with variable amounts of integration that doesn’t exist in the mature Python counterpart.

With the Python mineos github, there was a spectrum of people who forked and coded changes independently and some who asked for direction and guidance, which we’re not seeing here in either form. 350 lines of node code isn’t that demanding, especially since the codemap looks pretty much identical to Python with functionalized “backup”, “restore”, “start”, etc. functionality.

I surmise that much like with the Python fork, contributors will only come on a near-production-ready product, to fine tune it to personal taste, rather than fashion it’s creation, which admittedly is much less democratic than something like bukkit/sponge, etc.


I’d like to help. Here are my issues, I’m a git noob and only recently learned how to upload my own stuff let alone forking yours or realising that I had to fork it., I don’t know where to start with your code. I see the master, server and webui branches and have read through the code for mineos.js. I was looking to try and keep to your style and implement the advertiser (as a start) but not sure exactly how you’re running your commands etc.
I’m on brake from Uni and while I do have other things I’d like to do I though I’d like to contribute.
Please go through and jot down some comments and I’ll jump on. I also want to add the ability of a live console and a player list.

Contributing to mineos-node

it will be perfect to have an option of loading worlds from ramdisk


Can we get a DDNS configuration tool in the OS? I’m running a DDNS client on my server and it is a huge pain to try and install and configure through the shell. I managed to get it working properly but within the next few years I’m going to be upgrading my machine to running the NodeJS versions of MineOS(currently my hardware can’t support it so I’m on the Python 32-bit version). It’d be greatly appreciated.


I’d say there’s not really a chance that this would happen. DDNS is not universally used by everybody (nor need it be), but especially even with the numerous DDNS services available, I don’t think it’s possible that I can add a configuration tool that would make everybody happy (for those who don’t want the bloat), much less those that find their DDNS service isn’t supported by whatever tool.

That’s an awfully far-reaching timeframe. In the next few years, MineOS Node might not even be the project that is current.

Your hardware can’t support it?


It might be a sooner timeframe than that depending on my financial situation. lol. I could install the turnkey OS but when I went to launch MineOS it would give me an illegal operation error. I’m running this on an old box I had sitting around from 2004. After I reinstalled everything with the Python version it corrected the issue and I was able to get everything working just fine. Even tested out a Tekkit Lite server through my DDNS client and it connected and started just fine.