[TOOL] L2J AIOLS - v2.2 - 10.10.15
Posted: Thu May 13, 2010 9:46 pm
SUMMARY
Name: L2J AIOLS (All In One Linux Script)
Description:
Script for Linux (with bash 4.x.x or bash 4.x.x compatible shell) based L2J Servers created to simplify routine admin tasks. It provides functionality of "init" script for running/stopping/restarting your server, pull/build/install/reinstall/update/backup automation functions and other useful stuff.
Since v1.0 branch it replaces functionality of loader and loop scripts from DP and provides wide configuration of startup parameters. You can edit XmX, XmS, etc. right in well commented config section and fine-tune startup parameters as you wish.
Downloads:
Stable version: Very old, simple and stable: Capabilities:
Basic "init" functions to start/stop/restart server.
Function to terminate hanged server if nothing else works.
Support of multiple Login or Game servers on one machine using PIDfiles.
Automatic install/reinstall/update with run of dbinst_** and chmod of *.sh executables.
Automatic backup during reinstall/update to configurable folder with date/time based naming and zipping/tar7zipping.
Automatic download of Server/Datapack archives from provided links.
Automatic pull of Server/Datapack projects from provided GIT URL's.
Automatic building of projects using new Gradle build system.
Standalone pull/build/update/backup commands with same capabilities.
Automatic restoring of old geodata/pathnodes from last backup after reinstalling.
Function to show stdout.log output in realtime.
Basic commands:
"start" - Start server.
"start tail" or "stail" - Start server and show output.
"stop" - Stop server.
"stop tail" or "stoil" - Stop server and show output.
"restart" - Restart server.
"restart tail" or "restail" - Restart server and show output.
"kill" - Kill hanged server.
"kill tail" or "kitail" - Kill hanged server and show output.
"rekill" - Kill and then start hanged server.
"rekill tail" or "rekitail" - Kill and then start hanged server and show output.
"tail" - Show server's stdout.log output in realtime.
Advanced commands:
"pull" - Pull ZIP archive/clone GIT repo.
"make" or "make target" - Build local/cloned Gradle project.
"update" - Stop, backup and update server.
"backup" - Stop and backup server.
"clean" - Clean temp and build folders if any.
"clean all" - Clean temp, build and grails cache if any.
Shorthands:
"pm" or "pm target" - Pull, make.
"pu" - Pull, update.
"mu" or "mu target" - Make, update.
"pmu" or "pmu target" - Pull, make, update.
HOWTO
Install the script:
Depending on the system you need to put the script into init directory, "/etc/init.d" on Debian based systems for example. Edit config section as you like and don't forget to chmod +x it! To use the script with multiple servers on one machine you need to install and configure it several times, one script per server. It uses PIDfiles to determine the server to work with.
Update your server:
First thing is what's happening when you are using "install/reinstall" option when prompted. Most of devs want to keep their projects and deployed builds very clean. When such dev is updating something he always backups current deployed build then fully removes it and replaces with freshly generated build from his project. This logic will prevent very many mistakes/trash in future and you may be sure that deployed server fully corresponds to the project. So, "install/reinstall" option will update the server by using this logic exactly, it will remove old deployed build and fully replace it with a new one.
Second thing is what's happening when you are using "update" option when prompted. Unlike the previous example this option does not remove old deployed build at all, it will replace only older files in current deployed build to newer files from the freshly generated build by comparing "last modified" date. So, if file in current deployed build have the same or newer "last modified" date than file from freshly generated build it will not be replaced. That sounds good but i really not recommend you to use this option because there is a lot of ways to accidentally change the "last modified" date, for example by simply copying the file. That makes the update process unpredictable and unsafe and as a result you can loose your work.
Use predefined answers:
There is a WORKFLOW DEFAULTS section where you can find all default answers that can de asked during the script exec. I have no time to describe each of them and they can be changed in future so you need to read the code and find yourself what they do. You can predefine the workflow and change ASK variable to "false" to achieve automatic backup, update, etc. Another way to use this awesome ability is to pass answers as parameters at command line.
Use other functions:
All functionality is made to be self-descriptive or descripted in config section of the script. Please read it carefully before asking here
Name: L2J AIOLS (All In One Linux Script)
Description:
Script for Linux (with bash 4.x.x or bash 4.x.x compatible shell) based L2J Servers created to simplify routine admin tasks. It provides functionality of "init" script for running/stopping/restarting your server, pull/build/install/reinstall/update/backup automation functions and other useful stuff.
Since v1.0 branch it replaces functionality of loader and loop scripts from DP and provides wide configuration of startup parameters. You can edit XmX, XmS, etc. right in well commented config section and fine-tune startup parameters as you wish.
Downloads:
Stable version: Very old, simple and stable: Capabilities:
Basic "init" functions to start/stop/restart server.
Function to terminate hanged server if nothing else works.
Support of multiple Login or Game servers on one machine using PIDfiles.
Automatic install/reinstall/update with run of dbinst_** and chmod of *.sh executables.
Automatic backup during reinstall/update to configurable folder with date/time based naming and zipping/tar7zipping.
Automatic download of Server/Datapack archives from provided links.
Automatic pull of Server/Datapack projects from provided GIT URL's.
Automatic building of projects using new Gradle build system.
Standalone pull/build/update/backup commands with same capabilities.
Automatic restoring of old geodata/pathnodes from last backup after reinstalling.
Function to show stdout.log output in realtime.
Basic commands:
"start" - Start server.
"start tail" or "stail" - Start server and show output.
"stop" - Stop server.
"stop tail" or "stoil" - Stop server and show output.
"restart" - Restart server.
"restart tail" or "restail" - Restart server and show output.
"kill" - Kill hanged server.
"kill tail" or "kitail" - Kill hanged server and show output.
"rekill" - Kill and then start hanged server.
"rekill tail" or "rekitail" - Kill and then start hanged server and show output.
"tail" - Show server's stdout.log output in realtime.
Advanced commands:
"pull" - Pull ZIP archive/clone GIT repo.
"make" or "make target" - Build local/cloned Gradle project.
"update" - Stop, backup and update server.
"backup" - Stop and backup server.
"clean" - Clean temp and build folders if any.
"clean all" - Clean temp, build and grails cache if any.
Shorthands:
"pm" or "pm target" - Pull, make.
"pu" - Pull, update.
"mu" or "mu target" - Make, update.
"pmu" or "pmu target" - Pull, make, update.
HOWTO
Install the script:
Depending on the system you need to put the script into init directory, "/etc/init.d" on Debian based systems for example. Edit config section as you like and don't forget to chmod +x it! To use the script with multiple servers on one machine you need to install and configure it several times, one script per server. It uses PIDfiles to determine the server to work with.
Update your server:
First thing is what's happening when you are using "install/reinstall" option when prompted. Most of devs want to keep their projects and deployed builds very clean. When such dev is updating something he always backups current deployed build then fully removes it and replaces with freshly generated build from his project. This logic will prevent very many mistakes/trash in future and you may be sure that deployed server fully corresponds to the project. So, "install/reinstall" option will update the server by using this logic exactly, it will remove old deployed build and fully replace it with a new one.
Second thing is what's happening when you are using "update" option when prompted. Unlike the previous example this option does not remove old deployed build at all, it will replace only older files in current deployed build to newer files from the freshly generated build by comparing "last modified" date. So, if file in current deployed build have the same or newer "last modified" date than file from freshly generated build it will not be replaced. That sounds good but i really not recommend you to use this option because there is a lot of ways to accidentally change the "last modified" date, for example by simply copying the file. That makes the update process unpredictable and unsafe and as a result you can loose your work.
Use predefined answers:
There is a WORKFLOW DEFAULTS section where you can find all default answers that can de asked during the script exec. I have no time to describe each of them and they can be changed in future so you need to read the code and find yourself what they do. You can predefine the workflow and change ASK variable to "false" to achieve automatic backup, update, etc. Another way to use this awesome ability is to pass answers as parameters at command line.
Use other functions:
All functionality is made to be self-descriptive or descripted in config section of the script. Please read it carefully before asking here
! works pretty well...