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:
META-INF/maven/org.bukkit/craftbukkit/pom.xml
META-INF/maven/mcpc/mcpc-plus-legacy/pom.xml
META-INF/maven/mcpc/mcpc-plus/pom.xml
META-INF/maven/org.spigotmc/spigot/pom.xml
META-INF/maven/net.md-5/bungeecord-api/pom.xml
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.
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.
EDIT:
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.
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.