Groundwork of Amistr and Koma's Farewell

Anything related to your server.
User avatar
Posts: 708
Joined: Sat Jul 25, 2009 7:05 pm

General Server Setup Steps (Possibly Outdated)

Post by Koma »

Here are the general "base" server setup steps. This excludes installing and setting up eAthena, and excludes setting up user permissions. This process generally took less than an hour to accomplish. So if you go to a server that takes days, ask them why.

From Crescendo's Forums About Server Migration (since the general information is still accurate but not precise):
1.Choosing A Host
2.Host Approval and System Hardware and Operating System Installation
3.SSH Information Obtained
4.Install Following:
-Establish Firewall Permissions: eAthena 5221-5222, 6221-6222, 6990-6991, MySQL 3306, SSH 22)
-MySQL-Server (5.0)
-MySQL-Client (5.0)
-MySQL-Common (5.0)
-Secure MySQL
-Create Databases and Permissions (Hostmasks and Passwords)
-Website/Control Panels
-Obtain eAthena Builds
-Compile eAthena Builds
5.Test eAthena Operation
-Load Test Databases
-Wipe Clean In Preparation
6.Prepare Backup Crontabs
7.Install Monitoring And Maintenance Tools
-Schedutils (For Threading)
-Iptraf (Monitoring Network Input/Output)
-Vnstat (Bandwidth Consumption Logging)
-Bzip2 (Compression For Backups)
8.Setup Extra Emergency Website Additions
-Backup Control Panel Setup
-Backup Development SVN Information
9.Announce ~One Hour Downtime
10.Bring Down Current Server
11.Transfer MySQL Databases Between Servers
12.Final Clean-Up Checks
13.Launch New Server
14.Direct Players To New Client Installation
15.We Have Moved
Server Setup
Update /etc/apt/sources.list

deb lenny main
deb-src lenny main
deb lenny/updates main contrib
deb-src lenny/updates main contrib
#deb lenny/volatile main
#deb-src lenny/volatile main

apt-get update
apt-get upgrade

apt-get install mysql-server-5.0
apt-get install mysql-client-5.0
apt-get install mysql-common
apt-get install libmysqlclient15-dev

* Modify /etc/mysql/my.cnf to allow outside connection by commenting out "bind-address ="
Grant ALL Access By Logging Into root MySQL:
--> mysql -p'Password'
--> USE mysql;
--> SELECT * FROM user;
--> GRANT ALL privileges ON *.* TO 'root'@'%' IDENTIFIED BY 'Password' WITH GRANT OPTION;
mysqladmin flush-hosts
mysqladmin flush-privileges

apt-get install subversion

Extra Tools
apt-get install schedutils
apt-get install iptraf
apt-get install vnstat
apt-get install bzip2

--> g++ -v
-bash: g++: command not found
--> apt-get install g++

--> perl -v | grep perl
This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at, the Perl Home Page.
--> apt-get upgrade perl-base

Perl Time
--> perl -e 'use Time::HiRes;'
(If No Output, Stop)
--> apt-get install libtime-hires-perl

Perl Compress
--> perl -e 'use Compress::Zlib;'
(If No Output, Stop)
--> apt-get install libcompress-zlib-perl

--> apt-get install libreadline5-dev

--> gmake -v (make -v)
-bash: gmake: command not found
--> apt-get install make

--> echo 'print "Blah"' | python
-bash: python: command not found
--> apt-get install python

--> curl-config --version
-bash: curl-config: command not found
apt-get install libcurl3-dev (updated: libcurl4-openssl-dev)

Extra Website
- Backup Control Panel Setup
- Backup Development SVN Information


Crontab Setup
--> crontab -l
# m h dom mon dow command
0 0 * * * /home/Amistr/Archive/
30 * * * * /home/Amistr/Archive/

apt-get update
# apt-get install libpcre3 libpcre3-dev
User avatar
Posts: 708
Joined: Sat Jul 25, 2009 7:05 pm

How-To List Of Stuff

Post by Koma »

Considering that I'll be busier within the coming weeks, it's time I start outlining a few processes for the server. This is especially for those with little-to-no Linux experience. Note that all directories are simply used as examples and it is recommended to use more secure paths.

SSH Login
If you have access to this, you know the server's address, account, and password. Simply use Poderosa or any other SSH-compatible program.

Getting to the Server Location on SSH
The files for the server are located within /home/Amistr/. We also have a mirrored configuration that runs off of Crescendo's old database in /home/Crescendo/.
  1. To access Amistr, simply type "cd /home/Amistr/".
  2. To access Crescendo, simply type "cd /home/Crescendo/".
  3. To view files in any Linux directory, you can use "ls".
Starting the Server
There are three scripts to do this (in either Crescendo or Amistr):,, and They are used to launch the firewall and start all servers if they're not running. They also have an automatic restoration if any of these processes are closed unintentionally.
  1. Use "./" to start up both the Main server and the Test server.
  2. Use "./" to start up only the Main server.
  3. Use "./" to start up only the Test server.
Stopping the Server
Just like the start procedure, there are three files to kill the servers:,, and Before running these scripts though, the automatic restoration needs to be killed off with a "killall sh".
  1. First, do a "killall sh" to make sure that the Automatic Restarts don't happen.
  2. IMPORTANT NOTE BEFORE CONTINUING: It is recommended to use @kickall first (two to three times) and then a @mapexit from in-game to terminate the main server rather than killing the server immediately. This prevents any data-loss as all characters are saved upon logoff.
  3. Use "./" to kill both the Main server and the Test server.
  4. Use "./" to kill only the Main server.
  5. Use "./" to kill only he Test server.
Server Updates
To do server updates, you'll need to make sure that the SVN server-side has been updated. It is not recommended to rebuild the server SVN core unless you specifically know what you're doing. For this procedure, five scripts exist to make this an easy process.
  1. If doing general maintenance and Test server purging, use "./". This one is NOT used often as clearing the Test server too much can lead to complaints.
  2. If purging the logs and doing Main server maintenance, use "./". This one should be done once in awhile to keep the log databases from getting too large.
  3. To update the core (as in pull down the source files from eAthena and merge them with our source changes and recompile the executables), use "./". This should ONLY be done IF YOU'RE 100% CERTAIN that no crash will come of it. Usually I do some testing before implementation via Crescendo's configuration. This automatically deploys the executables to the places they need to go too.
  4. To update files such as CONF, DB, and NPC changes that we do to our Amistr SVN, use "./". this is usually okay to do unless you know you have a broken script implemented.
  5. To also update all files for the Crescendo configuration, there is a "./" script that will push files there as well.
General Debugging
Before launching a server, you can test the servers individually by using "./home/Amistr/Main/map-main" and so forth to debug.

Also, you can use SFTP to check the server output logs (which include WPE warnings and script errors) as those are located in "/home/Amistr/Archive/Output/".

All server backups are stored on a daily-basis to "/home/Amistr/Archive/Backups/". Usually, I purge the hourly backups as they start stacking up.

Rebuilding the Mapcache
Located in the "/home/Amistr/Maps/" folder are the scripts and maps for duplication or customs and from the alpha, kRO, Renewal, and Sakray. The scripts automatically reconfigure the settings to build each part appropriately intto the full mapcache database.
  1. Use "./", to shove all of the maps into the database.
  2. Use "./", to shove the Duplicate maps into the database.
User avatar
Posts: 708
Joined: Sat Jul 25, 2009 7:05 pm

Tuesday Maintenance

Post by Koma »

For those immediately interested in the amount of work dedicated each week, here is a rundown of steps. Why did we pick Tuesday? It's a general mid-week update which gives priority to giving time for the new build to settle in and raise flags before a WoE if things need to be corrected. This ensured that the server was properly stable and any changes would not affect WoE too heavily as they were given enough time to generate Comments and Suggestions.
  • Tuesday Maintenance
    • All Scripts, Databases, and Configurations Updated - These were pulled from Amistr's private SVN which was merged throughout the week with eAthena's changes along with our very own. This was a quick SVN synchronization.
    • Maps Recompiled - If necessary, we could rebuild the mapinfo.txt via a script simply by adding the map files to our Map folders. This made map implementation a two second process.
    • eAthena Core SVN Updated and Recompiled - This made sure that we operated on the absolute latest executable for the server. This was a simple script that we wrote. Note that all of these updates happened live as they have no effect on the server running in memory.
    • Initial Testing Done on Secondary Server - We made sure that things functioned correctly if we had done any core changes or needed updated SQL tables. The server had processing power to operate this and multiple other servers without problems so it was never noticed.
    • Auto-Restart Scripts Disabled - These made sure that the server came back up if it ever crashed. Funny thing is that Amistr never had that problem. It only had network problems from time to time.
    • Server Closed Gracefully via @mapexit After Kicking Players Off @ ~23:58 - This ensured that all character data was saved prior to a server shutdown and reboot. This prevented any rollbacks or lost items.
    • Server Backups Triggered @ 00:00 - We kept backups everyday and every hour to minimize any harmful effects of possible hacking or data corruption. These were not only kept on the server, but also kept on external servers.
    • Any eAthena SQL Updates Applied - If necessary, these were done here on the main server.
    • SQL Maintenance Completed - This included any data purging to minimize log database growth (conserving resources for the server overall) and insertion to an alternate database for reference. This also performed general table maintenance and compacting.
    • Linux Updates - If any are available, these are done here.
    • Server Host Machine Rebooted - Never hurts to reboot.
    • Server Scripts Initialize Restart - This included bringing up the firewalls, re-synchronizing time to NTP servers, and launching Fleece and Wool (and Counter-Strike or Team Fortress 2 servers).
    • Update Log - I was generally late doing these, when they should have been done ASAP. These usually took the form of spicing up the raw SVN logs of our own Subversion and including any other updates such as forum, Control Panel, important eAthena updates, or client updates.
So if you ever go to a server that takes more than 5-10 minutes to do a server update and maintenance, ask them why they waste so much time.
User avatar
Posts: 708
Joined: Sat Jul 25, 2009 7:05 pm

NeonCube, Control Panel, and Security

Post by Koma »

While some newer servers use different patchers now, we have stuck with a custom build of NeonCube that I've had since compiling it for Crescendo. It included the final fixes to read RAR files properly, insert/replace/delete physical files as well as modify the GRF (insert/replace/delete) efficiently. Additional code allowed us to check executed clients and GRFs CRC as well for reference -- and even know if someone didn't use it at all.

This was tied to our dynamic webpage which pulled the news from the forums much like the front website page -- to make sure that players received any important updates and news. Patches were hosting on the web-host to conserve server resources and as a fail-safe should one server go down (in which, oddly, only the web-server did).

Sadly, more servers are using less stable patchers from what I've seen now since the records of the NeonCube fixes have somewhat faded. However, it's not too different from how many servers are now using the exploitable FluxCP either (which we've also stayed away from). In other words, Amistr used quite a bit of non-standard software coded internally to prevent the majority of hackers and to avoid widespread exploitation -- contributing to our track record of security. On top of this, all privileged account passwords were GRC generated with high security and stored in inaccessible account ID locations to the normal player.
User avatar
Posts: 708
Joined: Sat Jul 25, 2009 7:05 pm

The End

Post by Koma »

The dedicated server has been wiped clean and all data has been safely backed up for archival reasons as of today. Our host has been notified to begin the reclaiming process as of midnight tonight. As of now, the client software is 100% useless so feel free to delete it and clean up some space on your hard drives.

In addition, the forums have been set to Read Only for any Guests/Registered Users with PMs and registration disabled. This is for anyone that may need any information posted over the course of the server's life. The website has also been re-tuned to exist independent of the game server.

It's been a long run. We started the hosted server and software-base of this project back around February of 2009 with initial planning stretching before that. A dedicated server was leased back then and leading up to launch in August of 2009 to get things just about right and to minimize necessary effort for upkeep. Hope you all enjoyed it and best wishes moving forward!