Awesome, I'll get to script writing when I get the chance.
After testing your modifications, I think I'll have a few more ideas to add in.
I've started working on a restore interface that lists the rdiff-backup backups and lets you pick which one to restore from.
I should probably add it as a feature request in the github issue queue...
That would be wonderful, and should be adaptable to support rollbacks from archives as well since both backup methods are triggered by the same command. Since you've already started, want the assignment on Git?
Wow, it has been a while since I've taken a look at this thread. You all have been busy! I don't have a lot of time to go through all of the suggestions right now, but I do have a couple of points that I would like to hit.
1) RE Github. I'm happy to move the project from Sourceforge over to Github if that is what everyone wants. I'm not familiar with git, but I'll learn. I am also happy to give others commit access to the subversion server on Sourceforge. Let me know what you prefer.
2) RE License. I'm not familar with the Creative Commons licences, although I can look into them if that is what you all think is best. I am used to using the GPL, but didn't feel that it was what I wanted for this project. Perhaps a permisive BSD-like license would work?
Copyright (c) 2013, Jason M. Wood <[email protected]>
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Let me know what you think. I'll review the rest of the thread as I have time.
All things considered, I'd say the most relaxed licensing you can apply without going public domain (which even removes Copyrights) would probably be your best bet. So, what you have there works for me for one.
As for Git/SourceForge/etc., personally I've found Git to be easier to work with than Subversion, and the developer interfaces for both website and client (for Windows, anyway) are very easy to work with. It's entirely possible to develop Linux scripts like this entirely within Windows (using Git as the repo and Notepad++ or any other text editor that understands UNIX linebreak conventions) and still have them actually work on Linux, which is amazing in its own right.
That having been said, I'm flexible - I've got space on Git, as does zanix, and you apparently have SF space, so if we want to come to a quorum on where to host it and just run from there I'm in.
EDIT: Are you the same "sandain" on Git? If so I'll add you to the access list on my implementation of the script.
All things considered, I'd say the most relaxed licensing you can apply without going public domain (which even removes Copyrights) would probably be your best bet. So, what you have there works for me for one.
As for Git/SourceForge/etc., personally I've found Git to be easier to work with than Subversion, and the developer interfaces for both website and client (for Windows, anyway) are very easy to work with. It's entirely possible to develop Linux scripts like this entirely within Windows (using Git as the repo and Notepad++ or any other text editor that understands UNIX linebreak conventions) and still have them actually work on Linux, which is amazing in its own right.
That having been said, I'm flexible - I've got space on Git, as does zanix, and you apparently have SF space, so if we want to come to a quorum on where to host it and just run from there I'm in.
EDIT: Are you the same "sandain" on Git? If so I'll add you to the access list on my implementation of the script.
Yes, I am the same sandain on github. I've created a repo there that has my current version as the base. I've been looking over your work, and I have addressed a couple of the minor changes that you did (mainly formating). I will continue to work on merging the two scripts as I review your code. Do you happen to have smaller single-change type of patches that I could review instead?
ps: I'm used to using RapidSVN as a gui to subversion. Is there anything similar for git? I think I have the command line stuff down, but sometimes a gui is so much easier...
Yes, I am the same sandain on github. I've created a repo there that has my current version as the base. I've been looking over your work, and I have addressed a couple of the minor changes that you did (mainly formating). I will continue to work on merging the two scripts as I review your code. Do you happen to have smaller single-change type of patches that I could review instead?
ps: I'm used to using RapidSVN as a gui to subversion. Is there anything similar for git? I think I have the command line stuff down, but sometimes a gui is so much easier...
Yes, I am the same sandain on github. I've created a repo there that has my current version as the base. I've been looking over your work, and I have addressed a couple of the minor changes that you did (mainly formating). I will continue to work on merging the two scripts as I review your code. Do you happen to have smaller single-change type of patches that I could review instead?
ps: I'm used to using RapidSVN as a gui to subversion. Is there anything similar for git? I think I have the command line stuff down, but sometimes a gui is so much easier...
Sorry, only one giant heavily-edited version since I literally edited it to suit an existing MC server install. I have a propensity toward commenting my code extensively so hopefully what I did will at least seem reasonable.
Sorry, only one giant heavily-edited version since I literally edited it to suit an existing MC server install. I have a propensity toward commenting my code extensively so hopefully what I did will at least seem reasonable.
That's fine. Let me just ask questions of various differences then.
I was never really sure I had the correct values in here, but I would like an explanation of what the changes do. Also, it looks like a s/config/CONFIG/g gone awry in chkCONFIG (and elsewhere in the diff).
+ # Check for a world config file. if there isn't one for this world, create a basic one
+ # and stop.
+ printf " Checking config..."
+ if [ ! -e "$LOCATION/$1.conf" ]; then
+ createWorldCONFIG $1
+ exit 1
+ fi
+
+ # Load the .conf file for this world. This will automagically insert the appropriate
+ # variables for the particular server instance that will power the world.
+ . "$LOCATION/$1.conf"
This is clever, I like it. However, I don't think that we should worry about creating a default config file; if it doesn't exist just use the default values already at the head of the script (assuming they don't get removed). If one of these conf files does exist, it should get loaded as needed to override the default values.
Also, we might want to think about what variables we want to have in this "interface". ie. SERVER_COMMAND should probably be made a local variable in the start method rather than being a global.
+ force-start)
+ # figure out which worlds to start.
+ WORLDS=$(checkOptionalArgument "$ALL_WORLDS" $0 $1 $2)
+
+ # Start each world requested, if not already running.
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
+ for WORLD in $WORLDS; do
+ #if [ $(serverRunning $WORLD) -eq 0 ]; then
+ printf "$WORLD:"
+ start $WORLD
+ printf " Done.\n"
+ #else
+ # printf "$WORLD: Skipped - already running.\n"
+ #fi
+ done
+ printf "=========\n"
+ printf "Finished.\n"
+ ;;
To match other code, something like this would be more consistent:
- start)
+ start|force-start)
- if [ $(serverRunning $WORLD) -eq 0 ]; then
+ if [ $(serverRunning $WORLD) -eq 0 ] || [ "$1" = "force-start" ]; then
I know things start going wonky when you try starting an already started server, which is why I never added this option. I have not tested how this works, but I doubt that it would work as you hope and don't currently recommend this change. If force-start called force-stop prior to starting the server then sure, however that is what the force-restart|force-reload option is for.
- sendCommand $WORLD "say The server is about to go down."
+ printf "$WORLD: Stopping"
+ sendCommand $WORLD "say An Administrator has triggered a server shutdown. Please get somewhere safe."
+ sendCommand $WORLD "say The server is going down in 60 seconds..."
+ printf " in 60s..."
+ sleep 30
+ sendCommand $WORLD "say The server is going down in 30 seconds..."
+ printf " 30s..."
+ sleep 15
+ sendCommand $WORLD "say The server is going down in 15 seconds..."
+ printf " 15s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 10 seconds..."
+ printf " 10s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 5 seconds..."
sendCommand $WORLD "save-all"
sendCommand $WORLD "save-off"
- sendCommand $WORLD "say The server is going down in 5 seconds..."
+ printf " 5s..."
sleep 5
+ printf " stopping..."
Hmmm. I will need to think about this. What if an auto shut down sequence has been started on the server due to a battery backup running out of juice? Do we really want to force an additional minute onto the shut down sequence? If you can convince me this change is necessary, then we should make it so that this is only done when the user count for the world is > 0.
- printf "Starting Minecraft Server:"
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
for WORLD in $WORLDS; do
if [ $(serverRunning $WORLD) -eq 0 ]; then
- printf " $WORLD"
+ printf "$WORLD:"
start $WORLD
+ printf " Done.\n"
+ else
+ printf "$WORLD: Skipped - already running.\n"
fi
done
- printf "\n"
+ printf "=========\n"
+ printf "Finished.\n"
This new style of output breaks Debian policy (not that the script is fully compliant, I just noticed that it is missing a period at the end of the line and some options produce more than one line of output):
This section describes the formats to be used for messages written to standard output by the /etc/init.d scripts. The intent is to improve the consistency of Debian's startup and shutdown look and feel. For this reason, please look very carefully at the details. We want the messages to have the same format in terms of wording, spaces, punctuation and case of letters.
Here is a list of overall rules that should be used for messages generated by /etc/init.d scripts.
The message should fit in one line (fewer than 80 characters), start with a capital letter and end with a period (.) and line feed ("\n").
If the script is performing some time consuming task in the background (not merely starting or stopping a program, for instance), an ellipsis (three dots: ...) should be output to the screen, with no leading or tailing whitespace or line feeds.
The messages should appear as if the computer is telling the user what it is doing (politely :-), but should not mention "it" directly. For example, instead of:
I'm starting network daemons: nfsd mountd.
the message should say
Starting network daemons: nfsd mountd.
init.d script should use the following standard message formats for the situations enumerated below.
When daemons are started
If the script starts one or more daemons, the output should look like this (a single line, no leading spaces):
Starting description: daemon-1 ... daemon-n.
The description should describe the subsystem the daemon or set of daemons are part of, while daemon-1 up to daemon-n denote each daemon's name (typically the file name of the program).
For example, the output of /etc/init.d/lpd would look like:
This makes it possible for the user to see what is happening and when the final daemon has been started. Care should be taken in the placement of white spaces: in the example above the system administrators can easily comment out a line if they don't want to start a specific daemon, while the displayed message still looks good.
When a system parameter is being set
If you have to set up different system parameters during the system boot, you should use this format:
Setting parameter to "value".
You can use a statement such as the following to get the quotes right:
echo "Setting DNS domainname to \"$domainname\"."
Note that the same symbol (") is used for the left and right quotation marks. A grave accent (`) is not a quote character; neither is an apostrophe (').
When a daemon is stopped or restarted
When you stop or restart a daemon, you should issue a message identical to the startup message, except that Starting is replaced with Stopping or Restarting respectively.
For example, stopping the printer daemon will look like this:
Stopping printer spooler: lpd.
When something is executed
There are several examples where you have to run a program at system startup or shutdown to perform a specific task, for example, setting the system's clock using netdate or killing all processes when the system shuts down. Your message should look like this:
Doing something very useful...done.
You should print the done. immediately after the job has been completed, so that the user is informed why they have to wait. You can get this behavior by saying
echo -n "Doing something very useful..."
do_something
echo "done."
in your script.
When the configuration is reloaded
When a daemon is forced to reload its configuration files you should use the following format:
Reloading description configuration...done.
where description is the same as in the daemon starting message.
That is enough questions/comments for now. I'd like to tackle these before I even start to look at the backup changes since they are more complicated. Thanks for your work!
I was never really sure I had the correct values in here, but I would like an explanation of what the changes do. Also, it looks like a s/config/CONFIG/g gone awry in chkCONFIG (and elsewhere in the diff).
Adding runlevel 2 allows starting the script without network services, which is handy for basic testing or if you want to set up a server only locally and not deploy it over a network until it's ready and be able to keep people out of it in the process. (You don't wanna know how many times I had to tell one of my admins to not try to bring up the server I was working on! ) As long as 3, 4, and 5 are in Default-Start, 2 is optional.
It is, I simply left it in place since I live-deploy this thing.
+ # Check for a world config file. if there isn't one for this world, create a basic one
+ # and stop.
+ printf " Checking config..."
+ if [ ! -e "$LOCATION/$1.conf" ]; then
+ createWorldCONFIG $1
+ exit 1
+ fi
+
+ # Load the .conf file for this world. This will automagically insert the appropriate
+ # variables for the particular server instance that will power the world.
+ . "$LOCATION/$1.conf"
This is clever, I like it. However, I don't think that we should worry about creating a default config file; if it doesn't exist just use the default values already at the head of the script (assuming they don't get removed). If one of these conf files does exist, it should get loaded as needed to override the default values.
Also, we might want to think about what variables we want to have in this "interface". ie. SERVER_COMMAND should probably be made a local variable in the start method rather than being a global.
A few things on this:
1. Setting it to auto-create the _world_.conf is basically there so the template file can be left out of the distribution entirely without being a script-breaker. If it does auto-create a _world_.conf, it adds "exit 1" at the end of it so the instance will not be startable until the user edits it.
2. I put SERVER_COMMAND into the _world_.conf instead of making it a local because I cannot be assured that someone at Oracle, etc. won't change the preferred order for command-line arguments in Java. Also, there's more than one Java variant in the *NIX space (e.g., OpenJava) and their argument order may differ wildly from what Oracle's Java wants. Having it in _world_.conf also makes it possible to run more than one Java VM (or even run a custom VM if someone wants to really go nuts, although this strikes me as unlikely) and have each world use whatever/however.
3. As for what vars to have in there, it should only be for vars specific to a single instance of a Minecraft server that would take up more space than you'd want to use in worlds.conf, etc.
+ force-start)
+ # figure out which worlds to start.
+ WORLDS=$(checkOptionalArgument "$ALL_WORLDS" $0 $1 $2)
+
+ # Start each world requested, if not already running.
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
+ for WORLD in $WORLDS; do
+ #if [ $(serverRunning $WORLD) -eq 0 ]; then
+ printf "$WORLD:"
+ start $WORLD
+ printf " Done.\n"
+ #else
+ # printf "$WORLD: Skipped - already running.\n"
+ #fi
+ done
+ printf "=========\n"
+ printf "Finished.\n"
+ ;;
To match other code, something like this would be more consistent:
- start)
+ start|force-start)
- if [ $(serverRunning $WORLD) -eq 0 ]; then
+ if [ $(serverRunning $WORLD) -eq 0 ] || [ "$1" = "force-start" ]; then
I know things start going wonky when you try starting an already started server, which is why I never added this option. I have not tested how this works, but I doubt that it would work as you hope and don't currently recommend this change. If force-start called force-stop prior to starting the server then sure, however that is what the force-restart|force-reload option is for.
Minecraft servers are themselves wonky, and sometimes the script will find a hung process that will satisfy the serverRunning check but is not in fact a valid running process. This is especially so if the server's in the process of crashing or has crashed but the VM hasn't blown up yet (classic example: a mod blows up during startup and stops the startup process). Basically this is only intended for use by admins to bruteforce things for testing, and should never be connected to a web interface, etc.
Hopefully Mojang will provide a workable API that can be hooked to in order to provide a more robust "is it running?" answer, and I fully expect to remove this command later (or have it removed) as the project rolls along.
- sendCommand $WORLD "say The server is about to go down."
+ printf "$WORLD: Stopping"
+ sendCommand $WORLD "say An Administrator has triggered a server shutdown. Please get somewhere safe."
+ sendCommand $WORLD "say The server is going down in 60 seconds..."
+ printf " in 60s..."
+ sleep 30
+ sendCommand $WORLD "say The server is going down in 30 seconds..."
+ printf " 30s..."
+ sleep 15
+ sendCommand $WORLD "say The server is going down in 15 seconds..."
+ printf " 15s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 10 seconds..."
+ printf " 10s..."
+ sleep 5
+ sendCommand $WORLD "say The server is going down in 5 seconds..."
sendCommand $WORLD "save-all"
sendCommand $WORLD "save-off"
- sendCommand $WORLD "say The server is going down in 5 seconds..."
+ printf " 5s..."
sleep 5
+ printf " stopping..."
Hmmm. I will need to think about this. What if an auto shut down sequence has been started on the server due to a battery backup running out of juice? Do we really want to force an additional minute onto the shut down sequence? If you can convince me this change is necessary, then we should make it so that this is only done when the user count for the world is > 0.
Have 20/50/100 users suddenly scream at you over Mumble about how you took the server down with only five seconds' warning while they were in the middle of 20/50/100 different things, and you'll understand why I stretched out the time to one minute.
Players do not want sudden shutdowns with not nearly enough warning to finish the fight they're in, get to a safe spot, port back to their spawn or home point, mine that diamond (or worse, obsidian) block they're whacking at with a pickaxe, etc. And they are very vocal about it.
Having the time stretch only when players are connected sounds like the smart way to do it - no need to delay at all if the server's empty, just drop or restart it.
Oh, that reminds me... the line in the status commanf that reports the number of users on the server (printf "running (%d users online), with PIDs $PID_JAVA (Java) and $PID_SCREEN (Screen).\n" $(cat $WORLDS_LOCATION/$WORLD.users | wc -l) ) reports zero regardless of actual player count with the MCPC+ Legacy 1.4.7 server jar running Feed the Beast Ultimate 1.1.2. Something may be wrong with, or need to be added to, checkForLogin to support nonstandard server jars.
- printf "Starting Minecraft Server:"
+ printf "Starting Minecraft Server(s)...\n"
+ printf "===============================\n"
for WORLD in $WORLDS; do
if [ $(serverRunning $WORLD) -eq 0 ]; then
- printf " $WORLD"
+ printf "$WORLD:"
start $WORLD
+ printf " Done.\n"
+ else
+ printf "$WORLD: Skipped - already running.\n"
fi
done
- printf "\n"
+ printf "=========\n"
+ printf "Finished.\n"
This new style of output breaks Debian policy (not that the script is fully compliant, I just noticed that it is missing a period at the end of the line and some options produce more than one line of output):
I didn't go for any specific coding or reporting convention, since we can work out all those details. I suspect what we'll need to do for consistency's sake is roll a small routine to format (as required/desired) and printf the text we want the way we want it, and have it handle auto-linebreaking to stop wrapping lines, add verbose/terse reporting options, etc. etc. etc. Something like that could make it pretty straightforward to add compliance with any policy or formatting we want without having to do largescale rewrites to make it happen. It'd be a few more lines of code than just printf-ing everything, but it'd make things prettier, and could be useful for web ineterfacing, etc.
That is enough questions/comments for now. I'd like to tackle these before I even start to look at the backup changes since they are more complicated. Thanks for your work!
You're the one whose work needs some more love - all i did was make a mess outta your and zanix's code!
Adding runlevel 2 allows starting the script without network services, which is handy for basic testing or if you want to set up a server only locally and not deploy it over a network until it's ready and be able to keep people out of it in the process. (You don't wanna know how many times I had to tell one of my admins to not try to bring up the server I was working on! ) As long as 3, 4, and 5 are in Default-Start, 2 is optional.
1. Setting it to auto-create the _world_.conf is basically there so the template file can be left out of the distribution entirely without being a script-breaker. If it does auto-create a _world_.conf, it adds "exit 1" at the end of it so the instance will not be startable until the user edits it.
The script should be able to run without a .conf file. If one is present, the values stored in the file can override the default values.
2. I put SERVER_COMMAND into the _world_.conf instead of making it a local because I cannot be assured that someone at Oracle, etc. won't change the preferred order for command-line arguments in Java. Also, there's more than one Java variant in the *NIX space (e.g., OpenJava) and their argument order may differ wildly from what Oracle's Java wants. Having it in _world_.conf also makes it possible to run more than one Java VM (or even run a custom VM if someone wants to really go nuts, although this strikes me as unlikely) and have each world use whatever/however.
3. As for what vars to have in there, it should only be for vars specific to a single instance of a Minecraft server that would take up more space than you'd want to use in worlds.conf, etc.
I'll keep the SERVER_COMMAND variable around. I was just thinking that if we are going to do anything to the variables, we should do it now. Speaking of which, do we have to worry about name conflicts, should we add a MSCS_ prefix of something to all variables? Should we be worried about what is in these files? We will be essentially side loading a whole other script without any form of sanity check.
Minecraft servers are themselves wonky, and sometimes the script will find a hung process that will satisfy the serverRunning check but is not in fact a valid running process. This is especially so if the server's in the process of crashing or has crashed but the VM hasn't blown up yet (classic example: a mod blows up during startup and stops the startup process). Basically this is only intended for use by admins to bruteforce things for testing, and should never be connected to a web interface, etc.
Hopefully Mojang will provide a workable API that can be hooked to in order to provide a more robust "is it running?" answer, and I fully expect to remove this command later (or have it removed) as the project rolls along.
I think in this situation, the admin should be using the force-stop + start combo or just force-restart. I think force-start is a bad idea. I will test it on one of my live servers, but I don't know of a way to test it on a hung server.
Have 20/50/100 users suddenly scream at you over Mumble about how you took the server down with only five seconds' warning while they were in the middle of 20/50/100 different things, and you'll understand why I stretched out the time to one minute.
Players do not want sudden shutdowns with not nearly enough warning to finish the fight they're in, get to a safe spot, port back to their spawn or home point, mine that diamond (or worse, obsidian) block they're whacking at with a pickaxe, etc. And they are very vocal about it.
Having the time stretch only when players are connected sounds like the smart way to do it - no need to delay at all if the server's empty, just drop or restart it.
I'll see what I can come up with when I have the time, unless you can provide a patch against my current code base sooner.
Oh, that reminds me... the line in the status commanf that reports the number of users on the server (printf "running (%d users online), with PIDs $PID_JAVA (Java) and $PID_SCREEN (Screen).\n" $(cat $WORLDS_LOCATION/$WORLD.users | wc -l) ) reports zero regardless of actual player count with the MCPC+ Legacy 1.4.7 server jar running Feed the Beast Ultimate 1.1.2. Something may be wrong with, or need to be added to, checkForLogin to support nonstandard server jars.
I'll need a snippet of the log from when a user logs in/out.
The runlevel changes can be reversed out - it's not a critical change.
The script should be able to run without a .conf file. If one is present, the values stored in the file can override the default values.
The reason I went with creating a blank _world_.conf instead of just running with default values is that the script is capable of running multiple server instances and thus in my opinion should not have default values. Instead, I feel that it should force the system admin to immediately create the defaults for any new instance, and not make assumptions on what to put where, which is why I have it set to throw "exit 1" at the end of the newly-created _world_.conf template to force the admin to edit the file before the server instance can be started with it.
I'll keep the SERVER_COMMAND variable around. I was just thinking that if we are going to do anything to the variables, we should do it now. Speaking of which, do we have to worry about name conflicts, should we add a MSCS_ prefix of something to all variables? Should we be worried about what is in these files? We will be essentially side loading a whole other script without any form of sanity check.
Oh, I agree that now's definitely the time to make such decisions if the per-world conf file is to be kept. While I'm all for sanity checking, I'm not sure if it would be practical - or even possible - to sanity-check a Java command-line parameter set.
As for prefixing the vars from the conf for clarity, I have no opinion on this and think it would be fine with or without it.
I think in this situation, the admin should be using the force-stop + start combo or just force-restart. I think force-start is a bad idea. I will test it on one of my live servers, but I don't know of a way to test it on a hung server.
Like I said, that command can be removed.
I'll see what I can come up with when I have the time, unless you can provide a patch against my current code base sooner.
Same - I wanted to play around with it some more but work keeps interfering with my gaming...
I'll need a snippet of the log from when a user logs in/out.
I'll check the server log when I have a spare moment and see how MCPC+ reports joins/disconnects.
I think we should store per-world config variables in the server.properties file itself rather than an additional .conf file. Our values could have the prefix of mscs-.
This way we could make a function that will parse the setting and get the config and not directly inject additional and pontentially harmful bash script values into the script. setPropertiesValue() already has the code we need to make a getPropertiesValue() function.
Script output should be as minimal as possible, so the return values can be parsed for web control.
I'm not sure what to think about force-start...
There is a way to query Minecraft to see if its running, by using the "enable-query" and "query.port" settings in server.properties.
I use a php script to check if the server is online, as well as some other variables it can return for my website.
I think a longer countdown is a good idea, if the user count is 0.
I made this change on my server to 1 minute so users have some time to get situated.
Maybe we can add another argument for the timeout.
Oh, another thing that we might want to ponder: monitor the crash-reports folder by storing the file count when the server starts, and if any new files appear, force-restart the server. That should (key word!) catch cases where the server blows up and hangs the Java VM without actually stopping it or reporting the crash to console. Since the crash files are date-coded in their filenames, a check for date and compare against start datetime should be a good sanity check.
The reason I mention this is that a few mods use [SEVERE]-level status logging in console for non-severe events such as non-fatal errors (despite how wrong this is) and will trigger the script's auto-restart-on-crash feature if it's enabled. (A couple use [WARNING] level to show their mod names!) Watching for a crash log should avoid this. Some of the bigger offenders here are a few mods in FTB Ultimate that check for new versions but throw a standard Java FileNotFound error (and yes it's marked as [SEVERE]) if they cannot find their remote version check files.
I think we should store per-world config variables in the server.properties file itself rather than an additional .conf file. Our values could have the prefix of mscs-.
This way we could make a function that will parse the setting and get the config and not directly inject additional and pontentially harmful bash script values into the script. setPropertiesValue() already has the code we need to make a getPropertiesValue() function.
That's not a bad idea as well, and would prevent the introduction of harmful code since we'd only be reading the file and stuffing values into variables. My only concern is the fact that Java command-line strings can be a bit long, so as long as the get function can handle a thousand-character var (at the more extreme end - usually an optimized server startup string is 200-300 characters long) that approach should work wonderfully.
Script output should be as minimal as possible, so the return values can be parsed for web control.
Another possibility, and this ties into the earlier conversation above re: return value formatting, would be to add a small formatting routine and switches (or alternate commands, which I suspect would be faster/easier at the cost of a bit of redundancy) to control the output. For example, add a "wstart" command that does what "start" does but emits specifically formatted text for an administration panel to capture. (If I had to hazard a guess I'd say we should plan to have the script emit strings in a format that PHP can work with, such as delimited strings compatible with PHP's "explode" command, JSON-compacted strings, etc.)
I'm not sure what to think about force-start...
Wow, everyone seems to be hung up on that one, hehehe...
There is a way to query Minecraft to see if its running, by using the "enable-query" and "query.port" settings in server.properties.
I use a php script to check if the server is online, as well as some other variables it can return for my website.
This might be the best approach since it takes advantage of an existing mechanism built into the server, and should be consistent on all variants (e.g., Forge, MCPC+, CraftBukkit) of the vanilla server.
I think a longer countdown is a good idea, if the user count is 0.
I made this change on my server to 1 minute so users have some time to get situated.
Maybe we can add another argument for the timeout.
The only tricky part of adding a variable warning period is how best to set up the warnings to the players. I'm picturing an idea on how to do this that I might have to test...
Oh, another thing that we might want to ponder: monitor the crash-reports folder by storing the file count when the server starts, and if any new files appear, force-restart the server. That should (key word!) catch cases where the server blows up and hangs the Java VM without actually stopping it or reporting the crash to console. Since the crash files are date-coded in their filenames, a check for date and compare against start datetime should be a good sanity check.
The reason I mention this is that a few mods use [SEVERE]-level status logging in console for non-severe events such as non-fatal errors (despite how wrong this is) and will trigger the script's auto-restart-on-crash feature if it's enabled. (A couple use [WARNING] level to show their mod names!) Watching for a crash log should avoid this. Some of the bigger offenders here are a few mods in FTB Ultimate that check for new versions but throw a standard Java FileNotFound error (and yes it's marked as [SEVERE]) if they cannot find their remote version check files.
That's kinda messed up, apparently they don't know the meaning of error levels.
That's not a bad idea as well, and would prevent the introduction of harmful code since we'd only be reading the file and stuffing values into variables. My only concern is the fact that Java command-line strings can be a bit long, so as long as the get function can handle a thousand-character var (at the more extreme end - usually an optimized server startup string is 200-300 characters long) that approach should work wonderfully.
I think the only issue would be in how the MC server reads the file.
The bash scripts just reads until the end of the line, so it should be no big deal.
Definitely needs testing.
Another possibility, and this ties into the earlier conversation above re: return value formatting, would be to add a small formatting routine and switches (or alternate commands, which I suspect would be faster/easier at the cost of a bit of redundancy) to control the output. For example, add a "wstart" command that does what "start" does but emits specifically formatted text for an administration panel to capture. (If I had to hazard a guess I'd say we should plan to have the script emit strings in a format that PHP can work with, such as delimited strings compatible with PHP's "explode" command, JSON-compacted strings, etc.)
We could have the web interface call the script using one command, that just passes what it wants to do with parameters.
This might be the best approach since it takes advantage of an existing mechanism built into the server, and should be consistent on all variants (e.g., Forge, MCPC+, CraftBukkit) of the vanilla server.
Yep, I just need to find the PHP library I used to do this.
Hey there! I've been a user of your script for about 7 months now. Its been fantastic and makes managing my minecraft server a breeze!
However, I've seemed to run into a small problem trying to update to 1.6. I have gone into my linux box and typed in /etc/init.d/minecraft_server update and it goes through the motions but my server does not appear to get updated. Is this due to the new launcher they use?
Anyway, I'm not sure what to do at this point. Any help anyone can steer me toward would be awesome!
Yep, I just need to find the PHP library I used to do this.
I've been working on a solution, and here is what I have so far:
#!/bin/sh
# Initialize a connection with a Minecraft query server.
#
# @param 1 world
queryInitialize() {
local NAME PORT
# The name of the Screen holding the Minecraft query server.
NAME="minecraft-query-$1"
# XXX this should be known from $1
PORT=25565
# Start the netcat process in a new Screen.
screen -dmS $NAME sh -c "nc -u 127.0.0.1 $PORT > $NAME.out"
}
# Close the connection with a Minecraft query server.
#
# @param 1 world
queryClose() {
local NAME
# The name of the Screen holding the Minecraft query server.
NAME="minecraft-query-$1"
screen -S "minecraft-query-$1" -p 0 -X quit
}
# Send a challenge packet to a Minecraft query server.
#
# @param 1 The world server of interest.
querySendChallengePacket() {
local ID NAME PACKET RESPONSE
# Use the current time as the packet ID.
ID=$(date +%s)
# The name of the Screen holding the Minecraft query server.
NAME="minecraft-query-$1"
# Pack the challenge packet.
PACKET=$(perl -e "print pack (
'CCCl>CCCCCC', # Format string.
hex('FE'), hex('FD'), # Magic bytes.
hex('09'), # Packet type (challenge).
$ID, # Packet ID (time).
hex('FF'), hex('FF'), hex('FF'), hex('01'), # Necessary padding?
hex('0D'), hex('0A') # CR+LF.
);")
# Send the packet to the Minecraft query server.
screen -S $NAME -p 0 -X stuff "$PACKET"
# Give the query server a second to respond.
sleep 1
# Grab and unpack the response.
RESPONSE=$(perl -e "print join \"\t\", unpack (
'Cl>Z*',
'$(cat $NAME.out)'
);")
# XXX remove these lines.
cp $NAME.out response.9.out
perl -e "print \"$PACKET\";" > packet.9.out
# Remove the response from the buffer file.
printf "" > $NAME.out
# Return the response.
printf "$RESPONSE\n"
}
# Send a information request packet to a Minecraft query server.
#
# @param 1 The world server of interest.
# @param 2 The challenge token.
querySendInformationPacket() {
local ID NAME PACKET RESPONSE
# Use the current time as the packet ID.
ID=$(date +%s)
# The name of the Screen holding the Minecraft query server.
NAME="minecraft-query-$1"
# Pack the information request packet.
PACKET=$(perl -e "print pack (
'CCCl>l>CCCCCC', # Format string.
hex('FE'), hex('FD'), # Magic bytes.
hex('00'), # Packet type (information).
$ID, # Packet ID (time).
$2, # Challenge token.
hex('FF'), hex('FF'), hex('FF'), hex('01'), # Necessary padding?
hex('0D'), hex('0A') # CR+LF.
);")
# PACKET=$(perl -e "print pack (
# 'CCCl>l>CC', # Format string.
# hex('FE'), hex('FD'), # Magic bytes.
# hex('00'), # Packet type (information).
# $ID, # Packet ID (time).
# $2, # Challenge token.
# hex('0D'), hex('0A') # CR+LF.
# );")
# Send the packet to the Minecraft query server.
screen -S $NAME -p 0 -X stuff "$PACKET"
# Give the query server a second to respond.
sleep 1
# Grab and unpack the response.
RESPONSE=$(perl -e "print join \"\t\", unpack (
'H*',
'$(cat $NAME.out)'
);")
# XXX remove these lines.
cp $NAME.out response.0.out
perl -e "print \"$PACKET\";" > packet.0.out
# Remove the response from the buffer file.
printf "" > $NAME.out
# Return the response.
printf "$RESPONSE\n"
}
# Send a status query to a Minecraft query server.
#
# @param 1 The world server of interest.
queryStatus() {
local TOKEN RESPONSE
# Send a challenge type packet to the Minecraft query server.
# Expected output format:
# 9\t<32bit int>\t<null terminated string>
# Use the null terminated string as the challenge token.
TOKEN=$(querySendChallengePacket $1 | cut -f 3)
printf "token:$TOKEN\n"
sleep 5
RESPONSE=$(querySendInformationPacket $1 $TOKEN)
printf "response:$RESPONSE\n"
}
# Initialize the connection with a Minecraft query server.
queryInitialize "world"
printf "query server in 5s...\n"
sleep 5
# Send status query.
queryStatus "world"
#PAYLOAD=$(queryStatus "world")
#printf "payload: '$PAYLOAD'\n"
printf "closing query server in 10s...\n"
sleep 10
# Close the connection to a Minecraft query server.
queryClose "world"
The initial challenge packet seems to work (there are a couple of odd characters that aren't being parsed that show up occasionally), but the information request packet never receives a response from the server for some reason. I feel like I'm close, but I can't figure out what's wrong. Here's hoping that one of you will notice my mistake.
edit:
Perl uses UTF-8 by default, and I'm guessing that Minecraft is using something different. This is probably the source of the extra characters. Now I just need to figure out how to get Perl to use different encodings so I can figure out which one is right.
Hey there! I've been a user of your script for about 7 months now. Its been fantastic and makes managing my minecraft server a breeze!
However, I've seemed to run into a small problem trying to update to 1.6. I have gone into my linux box and typed in /etc/init.d/minecraft_server update and it goes through the motions but my server does not appear to get updated. Is this due to the new launcher they use?
Anyway, I'm not sure what to do at this point. Any help anyone can steer me toward would be awesome!
Thanks.
The download link in the script still points to version 1.5. Past updates from Mojang have updated the link used to point to the latest version. However it seems either someone forgot to update the link, or they have changed their process. Anyway, you can fix the problem by changing the following line near the top of the script:
I don't know the best place to drop a note to these guys to make sure that link stays up to date. Having to update the script each time a new version comes out would be lame... Anyone know who to pester to get this fixed?
edit: I created a Twitter account (yuck) and sent jeb_ a tweet since that seems like the best way to get a hold of the guy. It is a simple fix, lets hope that works.
The download link in the script still points to version 1.5. Past updates from Mojang have updated the link used to point to the latest version. However it seems either someone forgot to update the link, or they have changed their process. Anyway, you can fix the problem by changing the following line near the top of the script:
I don't know the best place to drop a note to these guys to make sure that link stays up to date. Having to update the script each time a new version comes out would be lame... Anyone know who to pester to get this fixed?
edit: I created a Twitter account (yuck) and sent jeb_ a tweet since that seems like the best way to get a hold of the guy. It is a simple fix, lets hope that works.
Awesome, thank you. I will try this tonight and keep an eye on this thread for the future! I appreciate your help!
I've been working on a solution, and here is what I have so far:
...
The initial challenge packet seems to work (there are a couple of odd characters that aren't being parsed that show up occasionally), but the information request packet never receives a response from the server for some reason. I feel like I'm close, but I can't figure out what's wrong. Here's hoping that one of you will notice my mistake.
edit:
Perl uses UTF-8 by default, and I'm guessing that Minecraft is using something different. This is probably the source of the extra characters. Now I just need to figure out how to get Perl to use different encodings so I can figure out which one is right.
The download link in the script still points to version 1.5. Past updates from Mojang have updated the link used to point to the latest version. However it seems either someone forgot to update the link, or they have changed their process. Anyway, you can fix the problem by changing the following line near the top of the script:
HI new here anyway I have several issues I have been battling with this script on my ubuntu server.
1. a screen error...SCREEN failed to create a screen for minecraft..... or something similar to that
2. since the release of 1.6.* when i replace the code above, i still get an error. It seems when you DL the new minecraft server it names it minecraft_jar.1.6.2.jar but fails to do anything with it. Im just guessing its because the script is looking for minecraft_server.jar
still testing and such trying to get these issues worked out any help would be greatly appreciated.
yay i fixed all my issues i think, I manually DLed the new minecraft_server(minecraft_server.1.6.2.jar) and renamed it minecraft_server.jar then commented out the server update url and everything ran smoothly
HI new here anyway I have several issues I have been battling with this script on my ubuntu server.
1. a screen error...SCREEN failed to create a screen for minecraft..... or something similar to that
2. since the release of 1.6.* when i replace the code above, i still get an error. It seems when you DL the new minecraft server it names it minecraft_jar.1.6.2.jar but fails to do anything with it. Im just guessing its because the script is looking for minecraft_server.jar
still testing and such trying to get these issues worked out any help would be greatly appreciated.
yay i fixed all my issues i think, I manually DLed the new minecraft_server(minecraft_server.1.6.2.jar) and renamed it minecraft_server.jar then commented out the server update url and everything ran smoothly
I just posted a new version of the script on github that should fix the server download for you. If you are still receiving a screen error, give me the exact error output and I will look into it.
I got no response from jeb_ on twitter. If anyone finds a download link that will stay stable with future releases, let me know.
That would be wonderful, and should be adaptable to support rollbacks from archives as well since both backup methods are triggered by the same command. Since you've already started, want the assignment on Git?
1) RE Github. I'm happy to move the project from Sourceforge over to Github if that is what everyone wants. I'm not familiar with git, but I'll learn. I am also happy to give others commit access to the subversion server on Sourceforge. Let me know what you prefer.
2) RE License. I'm not familar with the Creative Commons licences, although I can look into them if that is what you all think is best. I am used to using the GPL, but didn't feel that it was what I wanted for this project. Perhaps a permisive BSD-like license would work?
Let me know what you think. I'll review the rest of the thread as I have time.
As for Git/SourceForge/etc., personally I've found Git to be easier to work with than Subversion, and the developer interfaces for both website and client (for Windows, anyway) are very easy to work with. It's entirely possible to develop Linux scripts like this entirely within Windows (using Git as the repo and Notepad++ or any other text editor that understands UNIX linebreak conventions) and still have them actually work on Linux, which is amazing in its own right.
That having been said, I'm flexible - I've got space on Git, as does zanix, and you apparently have SF space, so if we want to come to a quorum on where to host it and just run from there I'm in.
EDIT: Are you the same "sandain" on Git? If so I'll add you to the access list on my implementation of the script.
Yes, I am the same sandain on github. I've created a repo there that has my current version as the base. I've been looking over your work, and I have addressed a couple of the minor changes that you did (mainly formating). I will continue to work on merging the two scripts as I review your code. Do you happen to have smaller single-change type of patches that I could review instead?
ps: I'm used to using RapidSVN as a gui to subversion. Is there anything similar for git? I think I have the command line stuff down, but sometimes a gui is so much easier...
Github has it's own git client
https://help.github.com/articles/set-up-git
Sorry, only one giant heavily-edited version since I literally edited it to suit an existing MC server install. I have a propensity toward commenting my code extensively so hopefully what I did will at least seem reasonable.
That's fine. Let me just ask questions of various differences then.
I was never really sure I had the correct values in here, but I would like an explanation of what the changes do. Also, it looks like a s/config/CONFIG/g gone awry in chkCONFIG (and elsewhere in the diff).
I assume this is a site specific modification.
This is clever, I like it. However, I don't think that we should worry about creating a default config file; if it doesn't exist just use the default values already at the head of the script (assuming they don't get removed). If one of these conf files does exist, it should get loaded as needed to override the default values.
Also, we might want to think about what variables we want to have in this "interface". ie. SERVER_COMMAND should probably be made a local variable in the start method rather than being a global.
To match other code, something like this would be more consistent:
I know things start going wonky when you try starting an already started server, which is why I never added this option. I have not tested how this works, but I doubt that it would work as you hope and don't currently recommend this change. If force-start called force-stop prior to starting the server then sure, however that is what the force-restart|force-reload option is for.
Hmmm. I will need to think about this. What if an auto shut down sequence has been started on the server due to a battery backup running out of juice? Do we really want to force an additional minute onto the shut down sequence? If you can convince me this change is necessary, then we should make it so that this is only done when the user count for the world is > 0.
This new style of output breaks Debian policy (not that the script is fully compliant, I just noticed that it is missing a period at the end of the line and some options produce more than one line of output):
http://www.debian.org/doc/debian-policy/ch-opersys.html
That is enough questions/comments for now. I'd like to tackle these before I even start to look at the backup changes since they are more complicated. Thanks for your work!
Adding runlevel 2 allows starting the script without network services, which is handy for basic testing or if you want to set up a server only locally and not deploy it over a network until it's ready and be able to keep people out of it in the process. (You don't wanna know how many times I had to tell one of my admins to not try to bring up the server I was working on! ) As long as 3, 4, and 5 are in Default-Start, 2 is optional.
It is, I simply left it in place since I live-deploy this thing.
A few things on this:
1. Setting it to auto-create the _world_.conf is basically there so the template file can be left out of the distribution entirely without being a script-breaker. If it does auto-create a _world_.conf, it adds "exit 1" at the end of it so the instance will not be startable until the user edits it.
2. I put SERVER_COMMAND into the _world_.conf instead of making it a local because I cannot be assured that someone at Oracle, etc. won't change the preferred order for command-line arguments in Java. Also, there's more than one Java variant in the *NIX space (e.g., OpenJava) and their argument order may differ wildly from what Oracle's Java wants. Having it in _world_.conf also makes it possible to run more than one Java VM (or even run a custom VM if someone wants to really go nuts, although this strikes me as unlikely) and have each world use whatever/however.
3. As for what vars to have in there, it should only be for vars specific to a single instance of a Minecraft server that would take up more space than you'd want to use in worlds.conf, etc.
Minecraft servers are themselves wonky, and sometimes the script will find a hung process that will satisfy the serverRunning check but is not in fact a valid running process. This is especially so if the server's in the process of crashing or has crashed but the VM hasn't blown up yet (classic example: a mod blows up during startup and stops the startup process). Basically this is only intended for use by admins to bruteforce things for testing, and should never be connected to a web interface, etc.
Hopefully Mojang will provide a workable API that can be hooked to in order to provide a more robust "is it running?" answer, and I fully expect to remove this command later (or have it removed) as the project rolls along.
Have 20/50/100 users suddenly scream at you over Mumble about how you took the server down with only five seconds' warning while they were in the middle of 20/50/100 different things, and you'll understand why I stretched out the time to one minute.
Players do not want sudden shutdowns with not nearly enough warning to finish the fight they're in, get to a safe spot, port back to their spawn or home point, mine that diamond (or worse, obsidian) block they're whacking at with a pickaxe, etc. And they are very vocal about it.
Having the time stretch only when players are connected sounds like the smart way to do it - no need to delay at all if the server's empty, just drop or restart it.
Oh, that reminds me... the line in the status commanf that reports the number of users on the server (printf "running (%d users online), with PIDs $PID_JAVA (Java) and $PID_SCREEN (Screen).\n" $(cat $WORLDS_LOCATION/$WORLD.users | wc -l) ) reports zero regardless of actual player count with the MCPC+ Legacy 1.4.7 server jar running Feed the Beast Ultimate 1.1.2. Something may be wrong with, or need to be added to, checkForLogin to support nonstandard server jars.
I didn't go for any specific coding or reporting convention, since we can work out all those details. I suspect what we'll need to do for consistency's sake is roll a small routine to format (as required/desired) and printf the text we want the way we want it, and have it handle auto-linebreaking to stop wrapping lines, add verbose/terse reporting options, etc. etc. etc. Something like that could make it pretty straightforward to add compliance with any policy or formatting we want without having to do largescale rewrites to make it happen. It'd be a few more lines of code than just printf-ing everything, but it'd make things prettier, and could be useful for web ineterfacing, etc.
You're the one whose work needs some more love - all i did was make a mess outta your and zanix's code!
Ok, that works.
The script should be able to run without a .conf file. If one is present, the values stored in the file can override the default values.
I'll keep the SERVER_COMMAND variable around. I was just thinking that if we are going to do anything to the variables, we should do it now. Speaking of which, do we have to worry about name conflicts, should we add a MSCS_ prefix of something to all variables? Should we be worried about what is in these files? We will be essentially side loading a whole other script without any form of sanity check.
I think in this situation, the admin should be using the force-stop + start combo or just force-restart. I think force-start is a bad idea. I will test it on one of my live servers, but I don't know of a way to test it on a hung server.
I'll see what I can come up with when I have the time, unless you can provide a patch against my current code base sooner.
I'll need a snippet of the log from when a user logs in/out.
The runlevel changes can be reversed out - it's not a critical change.
The reason I went with creating a blank _world_.conf instead of just running with default values is that the script is capable of running multiple server instances and thus in my opinion should not have default values. Instead, I feel that it should force the system admin to immediately create the defaults for any new instance, and not make assumptions on what to put where, which is why I have it set to throw "exit 1" at the end of the newly-created _world_.conf template to force the admin to edit the file before the server instance can be started with it.
Oh, I agree that now's definitely the time to make such decisions if the per-world conf file is to be kept. While I'm all for sanity checking, I'm not sure if it would be practical - or even possible - to sanity-check a Java command-line parameter set.
As for prefixing the vars from the conf for clarity, I have no opinion on this and think it would be fine with or without it.
Like I said, that command can be removed.
Same - I wanted to play around with it some more but work keeps interfering with my gaming...
I'll check the server log when I have a spare moment and see how MCPC+ reports joins/disconnects.
This way we could make a function that will parse the setting and get the config and not directly inject additional and pontentially harmful bash script values into the script. setPropertiesValue() already has the code we need to make a getPropertiesValue() function.
Script output should be as minimal as possible, so the return values can be parsed for web control.
I'm not sure what to think about force-start...
There is a way to query Minecraft to see if its running, by using the "enable-query" and "query.port" settings in server.properties.
I use a php script to check if the server is online, as well as some other variables it can return for my website.
I think a longer countdown is a good idea, if the user count is 0.
I made this change on my server to 1 minute so users have some time to get situated.
Maybe we can add another argument for the timeout.
The reason I mention this is that a few mods use [SEVERE]-level status logging in console for non-severe events such as non-fatal errors (despite how wrong this is) and will trigger the script's auto-restart-on-crash feature if it's enabled. (A couple use [WARNING] level to show their mod names!) Watching for a crash log should avoid this. Some of the bigger offenders here are a few mods in FTB Ultimate that check for new versions but throw a standard Java FileNotFound error (and yes it's marked as [SEVERE]) if they cannot find their remote version check files.
That's not a bad idea as well, and would prevent the introduction of harmful code since we'd only be reading the file and stuffing values into variables. My only concern is the fact that Java command-line strings can be a bit long, so as long as the get function can handle a thousand-character var (at the more extreme end - usually an optimized server startup string is 200-300 characters long) that approach should work wonderfully.
Another possibility, and this ties into the earlier conversation above re: return value formatting, would be to add a small formatting routine and switches (or alternate commands, which I suspect would be faster/easier at the cost of a bit of redundancy) to control the output. For example, add a "wstart" command that does what "start" does but emits specifically formatted text for an administration panel to capture. (If I had to hazard a guess I'd say we should plan to have the script emit strings in a format that PHP can work with, such as delimited strings compatible with PHP's "explode" command, JSON-compacted strings, etc.)
Wow, everyone seems to be hung up on that one, hehehe...
This might be the best approach since it takes advantage of an existing mechanism built into the server, and should be consistent on all variants (e.g., Forge, MCPC+, CraftBukkit) of the vanilla server.
The only tricky part of adding a variable warning period is how best to set up the warnings to the players. I'm picturing an idea on how to do this that I might have to test...
That's kinda messed up, apparently they don't know the meaning of error levels.
I think the only issue would be in how the MC server reads the file.
The bash scripts just reads until the end of the line, so it should be no big deal.
Definitely needs testing.
We could have the web interface call the script using one command, that just passes what it wants to do with parameters.
Its not that I have an issue with it, I'm still unsure why it's needed.
Yep, I just need to find the PHP library I used to do this.
However, I've seemed to run into a small problem trying to update to 1.6. I have gone into my linux box and typed in /etc/init.d/minecraft_server update and it goes through the motions but my server does not appear to get updated. Is this due to the new launcher they use?
Anyway, I'm not sure what to do at this point. Any help anyone can steer me toward would be awesome!
Thanks.
I've been working on a solution, and here is what I have so far:
The initial challenge packet seems to work (there are a couple of odd characters that aren't being parsed that show up occasionally), but the information request packet never receives a response from the server for some reason. I feel like I'm close, but I can't figure out what's wrong. Here's hoping that one of you will notice my mistake.
Some conflicting resources:
http://wiki.vg/Query
http://wiki.unrealadmin.org/UT3_query_protocol
http://dinnerbone.com/blog/2011/10/14/minecraft-19-has-rcon-and-query/
http://pastebin.com/zqydiqn5
https://github.com/rmmccann/Minecraft-Status-Query
edit:
Perl uses UTF-8 by default, and I'm guessing that Minecraft is using something different. This is probably the source of the extra characters. Now I just need to figure out how to get Perl to use different encodings so I can figure out which one is right.
The download link in the script still points to version 1.5. Past updates from Mojang have updated the link used to point to the latest version. However it seems either someone forgot to update the link, or they have changed their process. Anyway, you can fix the problem by changing the following line near the top of the script:
I don't know the best place to drop a note to these guys to make sure that link stays up to date. Having to update the script each time a new version comes out would be lame... Anyone know who to pester to get this fixed?
edit: I created a Twitter account (yuck) and sent jeb_ a tweet since that seems like the best way to get a hold of the guy. It is a simple fix, lets hope that works.
Awesome, thank you. I will try this tonight and keep an eye on this thread for the future! I appreciate your help!
Here is the PHP library I was talking about
https://github.com/x...Minecraft-Query
It might help in making your bash script work correctly
HI new here anyway I have several issues I have been battling with this script on my ubuntu server.
1. a screen error...SCREEN failed to create a screen for minecraft..... or something similar to that
2. since the release of 1.6.* when i replace the code above, i still get an error. It seems when you DL the new minecraft server it names it minecraft_jar.1.6.2.jar but fails to do anything with it. Im just guessing its because the script is looking for minecraft_server.jar
still testing and such trying to get these issues worked out any help would be greatly appreciated.
yay i fixed all my issues i think, I manually DLed the new minecraft_server(minecraft_server.1.6.2.jar) and renamed it minecraft_server.jar then commented out the server update url and everything ran smoothly
I just posted a new version of the script on github that should fix the server download for you. If you are still receiving a screen error, give me the exact error output and I will look into it.
I got no response from jeb_ on twitter. If anyone finds a download link that will stay stable with future releases, let me know.