From a practical standpoint, I don’t think there will be any issue with having the Minecraft servers start/stop on the same initscript. I kept them separate so that users could–if they desired–manage them separately via:
service minecraft [stop|start]
service mineos [stop|start]
But in practice, I don’t believe anybody is actually using these methods, so the loss of granular control is likely to go unnoticed.
That said, in looking at your port, I’m curious about a few elements:
In line 28, there is a restore on the start command. Is there a chance that this could inadvertently replace regularly committed data with a previous backup? I’m not sure a restore will be appropriate for all use cases here.
As an example, a 0200 hour backup will lose progress if the server is manually stopped at 0230 (and the jar disk-commits) and then restarted in this method.
Second item:
Will this port be hosting on HTTP rather than HTTPS? Considering the service’s dependency on shadow passwords, HTTP by default will mean that usernames and password will get sent in plaintext. This seems particularly undesirable if the user logs in as root (or any username, really). Was “HTTP” intentional or is it just a typo on this pkg-message.in file?
Let me know!
Also, thanks for your work on MineOS with regard to FreeBSD–I’ve seen an amazing increase in MineOS use on FreeBSD thanks to your FreeNAS plugin!
I have restore in there cause I thought I saw it in your minecraft script, but I’d gladly remove it if it’s unneccesarry
i patched your to config to make http default. I did this cause I wanted my plugin work out-of-the-box without touching the commandline, and didn’t want to auto generate an SSL cert that scared people, lol. most freenas users are connecting to their jails locally but I see the security issue here.
for a proper freebsd port I’d make several changes based on what freebsd wants/users comfortability with the command-line.
not add the ‘mcserver’ user by default
base source on release tags, which means I’d need to submit a bug to freebsd to update MineOS whenever you make a release. =[
not make SSL off by default
freebsd users would need to do the following to get started
Ack, I’m embarrassed! Yes, the restore is definitely part of the existing initscript.
I suppose I confused because of the re-appropriation of the initscript. Some time ago I must have already conceded due to its lack of use, that it really should only be invoked by the system rather than the user, in which case, the restore being present is exactly as intended. Thus, please ignore that entire bit about it being there.
Moving on, yes, that workflow for creating the port seems just great. At one point, perhaps the users can at least be highly encouraged to do that extra SSL cert step because I’d hate to see users bypass 30 seconds of work at the cost of plaintext transmission.
OK, I won’t remove the restore. correct me if I’m wrong
ok, as time permits I’ll work towards submitting a proper freebsd port. the pkg-message is echoed to the console upon port and I believe package installation. I can try organizing the important information there, or just point to the MineOS wiki.
Alright, while not at the end of a 10 hour day, hopefully I’ll succeed at better explaining usage of restore.
When initially reading your post, I took note of the START MANUALLY line, encouraging or advising users to use the initscript to start the server jars and webui. While I had originally intended for this method to be used to start up, I have since changed my stance for it to be invoked only by initscripts. This is because if a user has the [onreboot]-Restore option checked and they manually cycle their servers, they would not expect RESTORE to occur (as it was not a reboot). This could cause potential loss up to their most current restore point.
So, to distill it down as cleanly as possible:
“restore” OK in initscripts.
“START MANUALLY: … start” NOT OK in pkg-message, or manual invocation
As an alternative, pkg-message can introduce mineos_console.py (or a symlink to it). The comparable command line would then be:
./mineos_console.py start
This command auto-appends -d /var/games/minecraft (or more accurately, the value in mineos.conf, misc.base_directory).
MineOS Turnkey ships with the symlink /usr/local/bin/mineos → /usr/games/minecraft/mineos_console.py, which enables quick access like:
mineos start
mineos stop
mineos backup
When omitting -s servername, it iterates each available known server. Hopefully this clears up a little bit why I was surprised restore was in there, and why it’s OK to keep it in the initscript, etc.