Joel and i have both been very busy, however, we do have news for you!
After we first deployed the server to the classroom, shortly after - the school break started. The server sat dormant for a while, and we wanted to give the server a checkup before it got deployed for the school year.
But checkups and some fine tuning was not all that we did. We also added automatic backups. Every day at about 4 AM, the server will go down, and perform a backup to a server we have at my apartment. 7 days worth of full backups are kept, the oldest discarded. Basically, if anything ever happens to the server, no data will be lost. We can rebuild the server with whatever parts we have, put the disk image of the server on the disk, run updates, plop the newest backup on the disk, and ship it out - a total of 4 hours at most.
What else did we do? general updates to the system, to bukkit, and to McMyAdmin - as well as a stress test. To stress test the server, we made a giant hole in the ground, very far away from the spawn point - and then filled it with TNT (5 thousand blocks). We detonated the TNT and waited for the server to settle. Good news! The server handled it like a champ. Once we were done doing that, we simply reverted to the last save before the explosion - so we left no evidence.
The server was shipped back out on Thursday, and with any luck, should be online by Monday.
Happy Crafting!
Saturday 20 October 2012
Monday 14 May 2012
What's Left to Do?
What exactly do we have left to do now that the server is operational?
We want to get an SFTP (secure file transfer protocol) server set up to make it easier to transfer files onto and off of the server - plugins especially, though this could easily be done with the use of a flash drive.
We want to make sure that the server starts automatically on boot without interaction by using either the init daemon or by scheduling it on boot with the cron scheduler. Either of these methods makes use of the screen virtual terminal emulator, which basically lets us make a program run in the background, but allows us to view it's output at any time and interact with it without forcing a restart of the server.
We also wanted to get nightly automatic updates working through the YUM package manager and the above mentioned cron scheduling daemon. We use a very similar technique to schedule automatic reboots every 3 months to ensure that the server's Kernel has a chance to update. This is crucial to the continued security of the server.
What does all this mean for the users and administrators? It means that their jobs will be very very easy. This server is more of an appliance than an actual server. Many servers are very needy - they require lots of attention to updates, loads, memory and disk usage, and tons of other stuff besides that. This server is more of an appliance. It has been designed to be plugged in and forgotten as it works nearly silently in a corner.
The final thing that we wanted to do was install a large library of plugins that the user can enable and disable whenever they need, to make changing the configuration easy.
Shortcuts have been placed on the desktop of the server so that when the local admin logs in, they can easily get to where they need to go without having to dig through the file system. TeamViewer is also installed so that if an issue should arise, the users can open up TeamTiewer and have either Joel or I fix anything that does go wrong software wise. Normally this could be done over SSH (Secure Shell) with less network usage and a lot less lag, but since we don't know if we will have access to the network in this way, using TeamViewer gives us a tried and true method for remote administration that is also very easy to both set up and use.
The server is still up at the previously stated address in case anyone still wants to play on the server before it is officially installed later this month.
We want to get an SFTP (secure file transfer protocol) server set up to make it easier to transfer files onto and off of the server - plugins especially, though this could easily be done with the use of a flash drive.
We want to make sure that the server starts automatically on boot without interaction by using either the init daemon or by scheduling it on boot with the cron scheduler. Either of these methods makes use of the screen virtual terminal emulator, which basically lets us make a program run in the background, but allows us to view it's output at any time and interact with it without forcing a restart of the server.
We also wanted to get nightly automatic updates working through the YUM package manager and the above mentioned cron scheduling daemon. We use a very similar technique to schedule automatic reboots every 3 months to ensure that the server's Kernel has a chance to update. This is crucial to the continued security of the server.
What does all this mean for the users and administrators? It means that their jobs will be very very easy. This server is more of an appliance than an actual server. Many servers are very needy - they require lots of attention to updates, loads, memory and disk usage, and tons of other stuff besides that. This server is more of an appliance. It has been designed to be plugged in and forgotten as it works nearly silently in a corner.
The final thing that we wanted to do was install a large library of plugins that the user can enable and disable whenever they need, to make changing the configuration easy.
Shortcuts have been placed on the desktop of the server so that when the local admin logs in, they can easily get to where they need to go without having to dig through the file system. TeamViewer is also installed so that if an issue should arise, the users can open up TeamTiewer and have either Joel or I fix anything that does go wrong software wise. Normally this could be done over SSH (Secure Shell) with less network usage and a lot less lag, but since we don't know if we will have access to the network in this way, using TeamViewer gives us a tried and true method for remote administration that is also very easy to both set up and use.
The server is still up at the previously stated address in case anyone still wants to play on the server before it is officially installed later this month.
Tuesday 8 May 2012
Testing
Please log into vellak.homelinux.org to test the minecraft server. We need your help to get a feeling as to how much it can handle. The server will be located at the standard port.
Back From Exams, and Back To Working on the Server
We Are Back!
Once again we are working to get the server fully operational :)
Exams have finished and now we can finally get serious with the server. Tonight is a testing night, we are working at getting Centos and McMyAdmin to work together. Due to the design of the software MyMcAdmin we needed to run a 64bit java to use all the ram installed due to a limitation in java. this also meant reverting back to the 64bit version of CentOS again. Since we knew that Sun java had issues, we decided to try IBM java.The test are being run in a Virtual Box on Kienan's main desktop. Tonight we finished the tests and are reinstalling the 64bit Centos. The system is now running with IBM Java instead of Sun Java.
Why exactly did we flip-flop on the choice of 32 versus 64 bit operating systems? Partially because we wanted to use the more recommended Sun java which only worked properly with the 32 bit version of the OS we are using, but 32bit java only allows for 2gb of ram to be used - even though our linux OS could see all 16gb of ram. In the end we switched over to IBM java (64 bit) and a 64bit version of CentOS once again (the 32bit version of IBM java still has the 2gb ram limit on 32bit machines) - which turned out to be a better choice since the IBM version of java actually runs McMyAdmin much faster and much more reliably than the standard Sun java.
UPDATE: as of now the server is in testing and stress testing stages, and fully installed. you can log in to help us stress test the server by logging in at vellak.homelinux.org on the standard minecraft ports. there is a limit of 100 users at the moment - which should be more than sufficient to stress test for the intended environment.
Monday 16 April 2012
A few Bumps On The Road
As most people who set out to do anything will know, things never turn out exactly according to plan.
So, the solution we have come up with is to wipe the drives clean and install CentOS 6.2 32 bit. Yes, it does slightly delay the server (very slightly) but in the long run, this change will actually make setting up the server easier since it makes it more compatible.
What else could we have done? We could have run a 32 bit copy of the OS in a virtual machine such as XEN or KVM - but it would have had reduced performance. We could have chosen a different 64 bit OS to use, but they all seemed to have similar issues, so it really would have just wasted our time and you would have had to wait longer before the server got delivered (not THAT much longer, but we sense that you guys are eager to get playing!)
One other thing that we would like to mention while we still have your attention, is that since Joel and I both have exams coming up, we won't be posting quite as much or working on the server quite as much in the next two weeks. We will try to keep you updated as we go along.
WARNING
this post gets fairly deep into computer science subjects and may not be interesting to all audiences.
In this case, we ran into problems getting the McMyAdmin panel working on CentOS 6.2 64 bit. Why is 64 bit important? Because according to reports online, it works perfectly with 32 bit - that might not seem like a big difference, except that normally 32 bit OS's can't handle more than 4gb of ram. Problem? Our server has 16gb, four times more than the standard 32 bit build can handle. Which means that if we want to make use of all 16gb, we will need a special kernel with a special option enabled, and that special option is PAE or physical address extension. basically, it uses two 32 bit words and joins them to address memory and storage in 64 bit. this post gets fairly deep into computer science subjects and may not be interesting to all audiences.
So, the solution we have come up with is to wipe the drives clean and install CentOS 6.2 32 bit. Yes, it does slightly delay the server (very slightly) but in the long run, this change will actually make setting up the server easier since it makes it more compatible.
What else could we have done? We could have run a 32 bit copy of the OS in a virtual machine such as XEN or KVM - but it would have had reduced performance. We could have chosen a different 64 bit OS to use, but they all seemed to have similar issues, so it really would have just wasted our time and you would have had to wait longer before the server got delivered (not THAT much longer, but we sense that you guys are eager to get playing!)
One other thing that we would like to mention while we still have your attention, is that since Joel and I both have exams coming up, we won't be posting quite as much or working on the server quite as much in the next two weeks. We will try to keep you updated as we go along.
Saturday 14 April 2012
Meet The Operating System
For this server, we chose CentOS 6.2 - a version of Linux. We specifically chose CentOS for a few different reasons. We have used it before for other servers and found it to be easy to set up, easy to add programs (and remove them - even remotely), it was very slim on resources (it only uses 400mb of ram after first boot, before the Minecraft server is started), it's very fast and very reliable. CentOS is very secure because of it's built in firewall, permissions systems, intrusion detection systems, and it's Kernel. In simple terms, CentOS was the right choice, it is Open source, and it was free of charge.
Kienan's main desktop is based on Fedora, which uses the same packages and tools for making programs, which makes developing updates and testing changes very easy for us since we already have the development infrastructure in place and ready to go.
One caveat is we knew we would have to install extra repos for our automatic updates to work (which will be using cron to schedule updates and reboots nightly) - specifically the rpmfusion repos. In order for that to work, we had to first enable EPEL from the official CentOS repos.
More information to come! Comment below with any questions you have!
Friday 13 April 2012
Configuring the server
After the hardware is all assembled, the next step is to configure the BIOS - or in this instance (because the board is one of the newer Intel boards) the UEFI firmware. Since our setup uses the two SSD's in a RAID1 configuration, part of the UEFI configuration is setting up the RAID array. We decided to use RAID1 because it offers data redundancy and guards against catastrophic hardware failure - basically, if one of the drives goes down, the server will continue to run - as long as the other drive continues to operate. We are using SSD's in the build because they are more resistant to failure, much better performing, and allow us to have very fast boot/login/shutdown times to minimize any downtime for updates (which would be performed at night when almost nobody would be on the server). SSD's also happen to be very shock tolerant. Basically the whole server could be dropped off a shelf while it's running without any data loss - and with long enough cables, without any interruption in services.
We set up the server to not configure any unnecessary components. In this case, the on board High Definition audio is not really necessary, but it takes up time in the boot sequence - which is why it was disabled. We optimized the available RAM by turning the amount of video memory for the onboard Intel HD 3000 video down to 128mb. If this server was also to be used as a media center, we would have left it at 1gb, but most servers have 8mb of video memory or less (most servers don't even have monitors hooked up to them).
Many of the other settings were left as they were, but the one other setting we changed was a special fast-boot setting that also happened to increase the security of the server many times over. This specific setting both disabled the ability to boot the server from USB keys (which would permit tampering with the server) and it also makes the server boot silently (no boot logo or messages displayed during boot) which makes BIOS tampering more difficult while allowing the server to boot much quicker.
That's all for this post, but expect more soon as we set up and configure the server. Next up: installing CentOS
We set up the server to not configure any unnecessary components. In this case, the on board High Definition audio is not really necessary, but it takes up time in the boot sequence - which is why it was disabled. We optimized the available RAM by turning the amount of video memory for the onboard Intel HD 3000 video down to 128mb. If this server was also to be used as a media center, we would have left it at 1gb, but most servers have 8mb of video memory or less (most servers don't even have monitors hooked up to them).
Many of the other settings were left as they were, but the one other setting we changed was a special fast-boot setting that also happened to increase the security of the server many times over. This specific setting both disabled the ability to boot the server from USB keys (which would permit tampering with the server) and it also makes the server boot silently (no boot logo or messages displayed during boot) which makes BIOS tampering more difficult while allowing the server to boot much quicker.
That's all for this post, but expect more soon as we set up and configure the server. Next up: installing CentOS
Subscribe to:
Posts (Atom)