I saw the execute() command, but I was more focusing on the 'usage' example provided in the top posting. Its simply just an observation and edge case if in fact the user running that command is not in /etc/sudoers. And with /etc/init.d, isn't sudo redundant? Shouldn't the script be ultimately run by 'root' anyway, even if the processes that spawn are from the new, unprivileged user?
Maybe there is a better way to do this.
My use case involves a user account (say sandain) needing to send commands to a server run by a different user account, minecraft, and I assume that this is a fairly common use case. As my directions are written, the sandain user account does need to be in the sudoers file. This could also be done by switching to the root user via su, if one didn't want to use sudo for some reason. Since running this script is an admin function, and I want it to be able to startup a server on system boot, it seems like requiring sudo or root access is justified.
However, the script can also be setup to run without using sudo or the root user, and does not have to be installed in the /etc/init.d folder. If I want to install the script, the server, and all of its goodies in the home directory of my own user account (say /home/sandain), all I would have to do is change the USER_NAME variable at the top of the script. With this change I could then run /home/sandain/minecraft_server <option> instead.
My use case involves a user account (say sandain) needing to send commands to a server run by a different user account, minecraft, and I assume that this is a fairly common use case. As my directions are written, the sandain user account does need to be in the sudoers file. This could also be done by switching to the root user via su, if one didn't want to use sudo for some reason. Since running this script is an admin function, and I want it to be able to startup a server on system boot, it seems like requiring sudo or root access is justified.
However, the script can also be setup to run without using sudo or the root user, and does not have to be installed in the /etc/init.d folder. If I want to install the script, the server, and all of its goodies in the home directory of my own user account (say /home/sandain), all I would have to do is change the USER_NAME variable at the top of the script. With this change I could then run /home/sandain/minecraft_server <option> instead.
I definitely see where you're coming from. If I believe I am grasping the technique you're using, then I'm just wondering if this would be a suitable amendment:
point 1) since the script is able to be executed without being root, it can su directly to 'minecraft', e.g.,
su minecraft
Since sudoers isnt being used, it'd require a password (unless you created a user 'adduser -f -u) and the password prompt can be handled with a 0400 file and the 'expect' command.
So basically, just like in your configuration, anybody who has access to user 'sandain' has 100% access to the minecraft user. However, anybody who has access to 'sandain' doesnt also have 'sudo' capabilities, making it more secure. The downside of this implementation is the existence of a 0400 password file on the server--but I actually think that is better than 'root' essentially turning sandain into 'root' via sudo. Sure its possible too to make minecraft passwordless, but then all users, in addition to 'sandain' can 'su minecraft'
point 2) by never requiring 'root' access beyond the creation of the user 'minecraft' (as already is required), the script is still OKAY in /etc/init.d (because it will be su minecraft) and it will be okay in /home/sandain (because of the same reasons)
I guess it all boils down to, simply, sandain doesn't need root/sudo access--and a 0400 file seems to alleviate potential threat. Again, this is all observation--just hoping to shed some light on how I'm seeing it from over here.
I definitely see where you're coming from. If I believe I am grasping the technique you're using, then I'm just wondering if this would be a suitable amendment:
point 1) since the script is able to be executed without being root, it can su directly to 'minecraft', e.g.,
su minecraft
Since sudoers isnt being used, it'd require a password (unless you created a user 'adduser -f -u) and the password prompt can be handled with a 0400 file and the 'expect' command.
So basically, just like in your configuration, anybody who has access to user 'sandain' has 100% access to the minecraft user. However, anybody who has access to 'sandain' doesnt also have 'sudo' capabilities, making it more secure. The downside of this implementation is the existence of a 0400 password file on the server--but I actually think that is better than 'root' essentially turning sandain into 'root' via sudo. Sure its possible too to make minecraft passwordless, but then all users, in addition to 'sandain' can 'su minecraft'
point 2) by never requiring 'root' access beyond the creation of the user 'minecraft' (as already is required), the script is still OKAY in /etc/init.d (because it will be su minecraft) and it will be okay in /home/sandain (because of the same reasons)
I guess it all boils down to, simply, sandain doesn't need root/sudo access--and a 0400 file seems to alleviate potential threat. Again, this is all observation--just hoping to shed some light on how I'm seeing it from over here.
Minecraft Forums seems to have eaten my reply to you that I posted last week. :huh.gif:
Anyway, I think I understand your points, and I have gone ahead and updated the documentation in the OP to reflect what I think you were saying. Let me know if I missed the ball here.
Thanks for your input by the way. I have started using su minecraft rather than sudo simply because it ultimately requires less typing from me. :smile.gif:
CraftBukkit
To use the CraftBukkit server distribution instead of the default Mojang server, change the following code in the script:
# Server software to use.
# mcserver - Minecraft server software.
# bukkit - Craft Bukkit server software.
SERVER_TYPE="mcserver"
to
# Server software to use.
# mcserver - Minecraft server software.
# bukkit - Craft Bukkit server software.
SERVER_TYPE="craftbukkit-0.0.1-SNAPSHOT.jar"
I used to assign strings to designate which server jar to use (e.g., 'pure', 'bukkit', 'hmod', 'canary'), but ultimately I dropped them because it seemed arbitrary/made scripts more constrained.
Instead of SERVER_TYPE where the user has to be aware of all possible options (through your listing in comments), as well as you have to hard-code each option, have you considered just using the jar filename directly? For example
# Server software to use.
# All jars should be commented out except the one you wish to use
SERVER_JAR="minecraft_server.jar"
#SERVER_JAR="craftbukkit-0.0.1-SNAPSHOT.jar"
# default minecraft_server.jar args
SERVER_ARGS="nogui"
# default bukkit args
#SERVER_ARGS=""
This saves you the effort of having to do IF/THEN conditions later in code, and it is more encouraging for users to change, if they feel it is necessary, such as when a new version comes out:
# Server software to use.
# All jars should be commented out except the one you wish to use
SERVER_JAR="minecraft_server-1.7.3.jar"
#SERVER_JAR="minecraft_server.jar"
#SERVER_JAR="craftbukkit-0.0.1-SNAPSHOT.jar"
This way, all configuration a user MIGHT want to change is sectioned off in the 'config' area, rather than the actual code area and a user knows directly what jar will be executed and what that means to the arguments.
This also simplifies your execution code because you can do:
$SERVER_JAR $SERVER_ARGS for all mods, rather than have a $BUKKIT_COMMAND etc
(as a side note, I'd be happy to run through your code with a critical eye if you want, let me know via PM)
I used to assign strings to designate which server jar to use (e.g., 'pure', 'bukkit', 'hmod', 'canary'), but ultimately I dropped them because it seemed arbitrary/made scripts more constrained.
Instead of SERVER_TYPE where the user has to be aware of all possible options (through your listing in comments), as well as you have to hard-code each option, have you considered just using the jar filename directly? For example
# Server software to use.
# All jars should be commented out except the one you wish to use
SERVER_JAR="minecraft_server.jar"
#SERVER_JAR="craftbukkit-0.0.1-SNAPSHOT.jar"
# default minecraft_server.jar args
SERVER_ARGS="nogui"
# default bukkit args
#SERVER_ARGS=""
This saves you the effort of having to do IF/THEN conditions later in code, and it is more encouraging for users to change, if they feel it is necessary, such as when a new version comes out:
# Server software to use.
# All jars should be commented out except the one you wish to use
SERVER_JAR="minecraft_server-1.7.3.jar"
#SERVER_JAR="minecraft_server.jar"
#SERVER_JAR="craftbukkit-0.0.1-SNAPSHOT.jar"
This way, all configuration a user MIGHT want to change is sectioned off in the 'config' area, rather than the actual code area and a user knows directly what jar will be executed and what that means to the arguments.
This also simplifies your execution code because you can do:
$SERVER_JAR $SERVER_ARGS for all mods, rather than have a $BUKKIT_COMMAND etc
(as a side note, I'd be happy to run through your code with a critical eye if you want, let me know via PM)
That is a very good point. There was some serious unnecessary code duplication along with related branching statements because of the way that I handled the server type. I went ahead and simplified the code as suggested.
If you have any other suggestions to clean-up or simplify the code, or add missing features, I'd be happy to listen to your ideas.
So, I have 2 worlds running... world and world2.
But when I try to stop or restart them I get:
Stopping Minecraft Server: worldThere are several suitable screens on:
5609.minecraft-world2 (16. sep. 2011 kl. 23.53 +0200) (Detached)
5564.minecraft-world (16. sep. 2011 kl. 23.53 +0200) (Detached)
Use -S to specify a session.
Error sending command to server world.
and nothing happens...
Now this might not be a problem with your script, but any help would be appreciated.
Edit: This only occurs if I'm NOT specifying a world to stop/restart. Stopping them individually works fine.
So, I have 2 worlds running... world and world2.
But when I try to stop or restart them I get:
Stopping Minecraft Server: worldThere are several suitable screens on:
5609.minecraft-world2 (16. sep. 2011 kl. 23.53 +0200) (Detached)
5564.minecraft-world (16. sep. 2011 kl. 23.53 +0200) (Detached)
Use -S to specify a session.
Error sending command to server world.
and nothing happens...
Now this might not be a problem with your script, but any help would be appreciated.
Edit: This only occurs if I'm NOT specifying a world to stop/restart. Stopping them individually works fine.
Ohh, haha. One of my regular expressions is obviously broken. I'll have a fix for you in a bit.
edit: This is actually a more complex of an issue than I thought. Screen is trying to be smarter than it needs to be.. I should still have a fix soon.
edit again: This was a multi-part problem that involved Screen being smarter than it needed to be combined with an error in one of my regular expressions. Good find! Thank you for posting a note. Let me know if you find any other issues.
The problem was that your two worlds had names that were too similar. The latest version of this script should now be fixed.
Ohh, haha. One of my regular expressions is obviously broken. I'll have a fix for you in a bit.
edit: This is actually a more complex of an issue than I thought. Screen is trying to be smarter than it needs to be.. I should still have a fix soon.
edit again: This was a multi-part problem that involved Screen being smarter than it needed to be combined with an error in one of my regular expressions. Good find! Thank you for posting a note. Let me know if you find any other issues.
I agree you're making it harder than it needs to be! For stopping a given screen, you can do something like this: (this method doesnt require parsing "screen -ls") and should shortcut some work since youre already naming them with -dmS)
I agree you're making it harder than it needs to be! For stopping a given screen, you can do something like this: (this method doesnt require parsing "screen -ls") and should shortcut some work since youre already naming them with -dmS)
The bug in question actually affected more than just stopping the server in this case, it made doing anything but starting the server impossible. The script relies on knowing which PID the Screen and Java processes are running on. Both screen and one of my regular expressions failed at differentiating between a screen named minecraft-world and another minecraft-world2. I fixed this by appending the PID of the Screen to the front of the name (ie. 12345.minecraft-world and 12346.minecraft-world2), and fixing the regular expression.
The screen -X kill method might be worth looking into for the force-stop method, I feel that the current stop code is fairly clean (especially with this bug out of the picture).
The script relies on knowing which PID the Screen and Java processes are running on. Both screen and one of my regular expressions failed at differentiating between a screen named minecraft-world and another minecraft-world2. I fixed this by appending the PID of the Screen to the front of the name (ie. 12345.minecraft-world and 12346.minecraft-world2), and fixing the regular expression.
It's actually for this reason I think its worth using the other method I mentioned. The script relies on knowing the PID and then it has to also have a matching regex--but why scrape for the PID *and* do a regex to match the rest, if you already know you can 100% interact with the screen by simply knowing the name?
In other words, if you can interact 100% with a screen simply by knowing its name--'world' or 'world2', and you can test its existence by checking world.conf, why not go straight to the command, rather than scrape 'screen -ls' with some room for error? For example:
This will 'stop' world2 no matter what--there's no chance of mismatching in regex, there's no grep'ing 'screen -ls'. If the screen exists, it'll close. If the screen doesn't exist, you can act on the retcode to say so. And most importantly, you also can't create multiple screens by the same name, so there's never any worry about creating servers atop one another or closing down more than one with an individual command. Just my 2c
It's actually for this reason I think its worth using the other method I mentioned. The script relies on knowing the PID and then it has to also have a matching regex--but why scrape for the PID *and* do a regex to match the rest, if you already know you can 100% interact with the screen by simply knowing the name?
In other words, if you can interact 100% with a screen simply by knowing its name--'world' or 'world2', and you can test its existence by checking world.conf, why not go straight to the command, rather than scrape 'screen -ls' with some room for error? For example:
This will 'stop' world2 no matter what--there's no chance of mismatching in regex, there's no grep'ing 'screen -ls'. If the screen exists, it'll close. If the screen doesn't exist, you can act on the retcode to say so. And most importantly, you also can't create multiple screens by the same name, so there's never any worry about creating servers atop one another or closing down more than one with an individual command. Just my 2c
I totally see where you are coming from, however I think that you are now punching the 'screen is trying to be smarter than what it needs to be' issue that I was speaking of earlier. As Tachdelan pointed out, when there is both a world and a world2 in the worlds.conf, and you attempt to shut down world, Screen fails to choose just one or the other:
Stopping Minecraft Server: worldThere are several suitable screens on:
5609.minecraft-world2 (16. sep. 2011 kl. 23.53 +0200) (Detached)
5564.minecraft-world (16. sep. 2011 kl. 23.53 +0200) (Detached)
Use -S to specify a session.
I fixed this problem by removing an extra level of ambiguity, appending the PID to the front of the Screen name. I realize that keeping track of the PIDs adds an extra level of complexity to the code, but I feel that it allows for some neat tricks to happen (ie. the log processor closing automatically when the Java process closes). The regular expressions really shouldn't be that error prone..
I'd suggest you add the way to exit the screen when using the screen <world> command: Ctrl+A then d.
Nice, I didn't actually know how to exit the Screen, I never personally use that feature. I'll see if I can add a note and a small delay so that you can actually read it before the screen becomes active.
When using the screen <world> command, if you ever happen to have an error such as:
Cannot open your terminal '/dev/pts/2' - please check.
be aware this is due to screen's restriction regarding the spawning unix user. It could occur after you ssh'ed using a first user then su minecraft. You may fix that by either:
* ssh to your server using the minecraft user directly
* editing the permissions for your screen IO with the following command (edit the number accordingly to your error message): sudo chmod o+rw /dev/pts/2
I've run into that problem before myself, and I should have documented the fix in the OP at that time, but never got around to it. Since you brought it up, I'll go ahead and post that note.
I gotta tell you, this is a very awesome program, I was gonna make something like it, but then I saw this thread and I see it accomplishes more than I want to do with mine :tongue.gif:. BTW: It is somewhat easy to make this have commands similar to MCMYADMIN if it parses the files, havent' checked if it does, or not.
I gotta tell you, this is a very awesome program, I was gonna make something like it, but then I saw this thread and I see it accomplishes more than I want to do with mine :tongue.gif:. BTW: It is somewhat easy to make this have commands similar to MCMYADMIN if it parses the files, havent' checked if it does, or not.
I'm not entirely certain what commands McMyAdmin has that you are talking about, but if you have a certain feature that you think would be useful to add, let me know. This script does perform some log processing: looking for users logging on, logging off, or trying to execute a command, and in the case of severe server events, the script can be configured to automatically restart the server.
The only two user commands that the script recognizes at this point in time are /help and /motd, but that list could easily be expanded. If you are thinking of admin level commands, I could have the script parse ops.txt for a rudimentary permissions system without too many problems.
I'm not entirely certain what commands McMyAdmin has that you are talking about, but if you have a certain feature that you think would be useful to add, let me know. This script does perform some log processing: looking for users logging on, logging off, or trying to execute a command, and in the case of severe server events, the script can be configured to automatically restart the server.
The only two user commands that the script recognizes at this point in time are /help and /motd, but that list could easily be expanded. If you are thinking of admin level commands, I could have the script parse ops.txt for a rudimentary permissions system without too many problems.
McMyAdmin has the following commands (that I know of for sure):
memory - Not quite sure what exact command is but it tells memory usage of server and stuff
Things I think should be implemented:
mapsize - Total Size of Map
restart (param) - Restart either whole server or the MC Software
rank (param) - Set user to a rank (permissions for give and only give or something like that.
map (param) - Delete Currentmap And Generate new or Backup and Generate New
maxp (param) - changes Max Players
settings (param) (value) - set the parameter in server.properties to a value
(maybe some sort of currency?)
I know this is an unrealistic list, but I think it would be cool to use.
PROGRAM="minecraft_server.jar"
NUM=$(ps aux | grep -c $PROGRAM)
if [ $NUM -ge 4 ];
then
/home/minecraft/minecraft_server/./minecraft_server backup
else
exit
fi
PROGRAM="minecraft_server.jar"
NUM=$(ps aux | grep -c $PROGRAM)
if [ $NUM -ge 4 ];
then
/home/minecraft/minecraft_server/./minecraft_server backup
else
exit
fi
Please note that I have the variable set to 4 because I am running 2 servers one is survival the other is creative.
if [ $APPCHK -ge 4 ];
It works for me, is this the correct way to do this sort of thing?
What is the point of seeing how many processes are running? If you are trying to test if the server is active, you could parse the output of the script's status command.
SCRIPT="/home/minecraft/minecraft_server/minecraft_server"
WORLD="world1"
STATUS=$($SCRIPT status $WORLD | perl -ne 'if ($_ =~ /^\s+$WORLD\:\s((not\s)?running)/) { print $1; }')
if [ "$STATUS" = "running" ]; then
$SCRIPT backup $WORLD
fi
What is the point of seeing how many processes are running? If you are trying to test if the server is active, you could parse the output of the script's status command.
SCRIPT="/home/minecraft/minecraft_server/minecraft_server"
WORLD="world1"
STATUS=$($SCRIPT status $WORLD | perl -ne 'if ($_ =~ /^\s+$WORLD\:\s((not\s)?running)/) { print $1; }')
if [ "$STATUS" = "running" ]; then
$SCRIPT backup $WORLD
fi
It was the way I thought of doing it really late in the morning. Of course I cheated and used Google to find a script that could show if a process is running or not. And they did it that way. :tongue.gif: You my friend are a guru I bow to your knowledge. :smile.gif: Thank you so much.
Maybe there is a better way to do this.
My use case involves a user account (say sandain) needing to send commands to a server run by a different user account, minecraft, and I assume that this is a fairly common use case. As my directions are written, the sandain user account does need to be in the sudoers file. This could also be done by switching to the root user via su, if one didn't want to use sudo for some reason. Since running this script is an admin function, and I want it to be able to startup a server on system boot, it seems like requiring sudo or root access is justified.
However, the script can also be setup to run without using sudo or the root user, and does not have to be installed in the /etc/init.d folder. If I want to install the script, the server, and all of its goodies in the home directory of my own user account (say /home/sandain), all I would have to do is change the USER_NAME variable at the top of the script. With this change I could then run /home/sandain/minecraft_server <option> instead.
I definitely see where you're coming from. If I believe I am grasping the technique you're using, then I'm just wondering if this would be a suitable amendment:
point 1) since the script is able to be executed without being root, it can su directly to 'minecraft', e.g.,
su minecraft
Since sudoers isnt being used, it'd require a password (unless you created a user 'adduser -f -u) and the password prompt can be handled with a 0400 file and the 'expect' command.
So basically, just like in your configuration, anybody who has access to user 'sandain' has 100% access to the minecraft user. However, anybody who has access to 'sandain' doesnt also have 'sudo' capabilities, making it more secure. The downside of this implementation is the existence of a 0400 password file on the server--but I actually think that is better than 'root' essentially turning sandain into 'root' via sudo. Sure its possible too to make minecraft passwordless, but then all users, in addition to 'sandain' can 'su minecraft'
point 2) by never requiring 'root' access beyond the creation of the user 'minecraft' (as already is required), the script is still OKAY in /etc/init.d (because it will be su minecraft) and it will be okay in /home/sandain (because of the same reasons)
I guess it all boils down to, simply, sandain doesn't need root/sudo access--and a 0400 file seems to alleviate potential threat. Again, this is all observation--just hoping to shed some light on how I'm seeing it from over here.
Minecraft Forums seems to have eaten my reply to you that I posted last week. :huh.gif:
Anyway, I think I understand your points, and I have gone ahead and updated the documentation in the OP to reflect what I think you were saying. Let me know if I missed the ball here.
Thanks for your input by the way. I have started using su minecraft rather than sudo simply because it ultimately requires less typing from me. :smile.gif:
I used to assign strings to designate which server jar to use (e.g., 'pure', 'bukkit', 'hmod', 'canary'), but ultimately I dropped them because it seemed arbitrary/made scripts more constrained.
Instead of SERVER_TYPE where the user has to be aware of all possible options (through your listing in comments), as well as you have to hard-code each option, have you considered just using the jar filename directly? For example
This saves you the effort of having to do IF/THEN conditions later in code, and it is more encouraging for users to change, if they feel it is necessary, such as when a new version comes out:
This way, all configuration a user MIGHT want to change is sectioned off in the 'config' area, rather than the actual code area and a user knows directly what jar will be executed and what that means to the arguments.
This also simplifies your execution code because you can do:
$SERVER_JAR $SERVER_ARGS for all mods, rather than have a $BUKKIT_COMMAND etc
(as a side note, I'd be happy to run through your code with a critical eye if you want, let me know via PM)
That is a very good point. There was some serious unnecessary code duplication along with related branching statements because of the way that I handled the server type. I went ahead and simplified the code as suggested.
If you have any other suggestions to clean-up or simplify the code, or add missing features, I'd be happy to listen to your ideas.
But when I try to stop or restart them I get:
Stopping Minecraft Server: worldThere are several suitable screens on:
5609.minecraft-world2 (16. sep. 2011 kl. 23.53 +0200) (Detached)
5564.minecraft-world (16. sep. 2011 kl. 23.53 +0200) (Detached)
Use -S to specify a session.
Error sending command to server world.
and nothing happens...
Now this might not be a problem with your script, but any help would be appreciated.
Edit: This only occurs if I'm NOT specifying a world to stop/restart. Stopping them individually works fine.
Ohh, haha. One of my regular expressions is obviously broken. I'll have a fix for you in a bit.
edit: This is actually a more complex of an issue than I thought. Screen is trying to be smarter than it needs to be.. I should still have a fix soon.
edit again: This was a multi-part problem that involved Screen being smarter than it needed to be combined with an error in one of my regular expressions. Good find! Thank you for posting a note. Let me know if you find any other issues.
The problem was that your two worlds had names that were too similar. The latest version of this script should now be fixed.
I agree you're making it harder than it needs to be! For stopping a given screen, you can do something like this: (this method doesnt require parsing "screen -ls") and should shortcut some work since youre already naming them with -dmS)
For stopping all screens:
The bug in question actually affected more than just stopping the server in this case, it made doing anything but starting the server impossible. The script relies on knowing which PID the Screen and Java processes are running on. Both screen and one of my regular expressions failed at differentiating between a screen named minecraft-world and another minecraft-world2. I fixed this by appending the PID of the Screen to the front of the name (ie. 12345.minecraft-world and 12346.minecraft-world2), and fixing the regular expression.
The screen -X kill method might be worth looking into for the force-stop method, I feel that the current stop code is fairly clean (especially with this bug out of the picture).
It's actually for this reason I think its worth using the other method I mentioned. The script relies on knowing the PID and then it has to also have a matching regex--but why scrape for the PID *and* do a regex to match the rest, if you already know you can 100% interact with the screen by simply knowing the name?
In other words, if you can interact 100% with a screen simply by knowing its name--'world' or 'world2', and you can test its existence by checking world.conf, why not go straight to the command, rather than scrape 'screen -ls' with some room for error? For example:
This will 'stop' world2 no matter what--there's no chance of mismatching in regex, there's no grep'ing 'screen -ls'. If the screen exists, it'll close. If the screen doesn't exist, you can act on the retcode to say so. And most importantly, you also can't create multiple screens by the same name, so there's never any worry about creating servers atop one another or closing down more than one with an individual command. Just my 2c
I totally see where you are coming from, however I think that you are now punching the 'screen is trying to be smarter than what it needs to be' issue that I was speaking of earlier. As Tachdelan pointed out, when there is both a world and a world2 in the worlds.conf, and you attempt to shut down world, Screen fails to choose just one or the other:
I fixed this problem by removing an extra level of ambiguity, appending the PID to the front of the Screen name. I realize that keeping track of the PIDs adds an extra level of complexity to the code, but I feel that it allows for some neat tricks to happen (ie. the log processor closing automatically when the Java process closes). The regular expressions really shouldn't be that error prone..
Nice, I didn't actually know how to exit the Screen, I never personally use that feature. I'll see if I can add a note and a small delay so that you can actually read it before the screen becomes active.
I've run into that problem before myself, and I should have documented the fix in the OP at that time, but never got around to it. Since you brought it up, I'll go ahead and post that note.
Thanks!
I'm not entirely certain what commands McMyAdmin has that you are talking about, but if you have a certain feature that you think would be useful to add, let me know. This script does perform some log processing: looking for users logging on, logging off, or trying to execute a command, and in the case of severe server events, the script can be configured to automatically restart the server.
The only two user commands that the script recognizes at this point in time are /help and /motd, but that list could easily be expanded. If you are thinking of admin level commands, I could have the script parse ops.txt for a rudimentary permissions system without too many problems.
McMyAdmin has the following commands (that I know of for sure):
memory - Not quite sure what exact command is but it tells memory usage of server and stuff
Things I think should be implemented:
mapsize - Total Size of Map
restart (param) - Restart either whole server or the MC Software
rank (param) - Set user to a rank (permissions for give and only give or something like that.
map (param) - Delete Currentmap And Generate new or Backup and Generate New
maxp (param) - changes Max Players
settings (param) (value) - set the parameter in server.properties to a value
(maybe some sort of currency?)
I know this is an unrealistic list, but I think it would be cool to use.
Then did,
Added this line to it.
Now I have a backup every 15 minutes.
Please note that I have the variable set to 4 because I am running 2 servers one is survival the other is creative.
It works for me, is this the correct way to do this sort of thing?
What is the point of seeing how many processes are running? If you are trying to test if the server is active, you could parse the output of the script's status command.
It was the way I thought of doing it really late in the morning. Of course I cheated and used Google to find a script that could show if a process is running or not. And they did it that way. :tongue.gif: You my friend are a guru I bow to your knowledge. :smile.gif: Thank you so much.