Fun and games in the DigitalOcean: Pterodactyl game server hosting.
Hello folks, apologies for a very long blogging absence on my part. Work and life have taken a good amount of twists and turns. Things have progressed in both my personal health and career as I’ve started to change my diet, exercise and habits as the summer season began.
My time spent with in tech shifted away from IT and more into my 3d hobby, of which I have a new portfolio featured on mywebsite! This portfolio consists of some of my hobbyist work, spending hours in blender, unity and other visual coding programs centered around virtual reality development from the past months. I hope you’ll give it a look. [1]
I also have started a part time job in another area, which has taken a good portion of time and transition since May. What this means however is that my work in developing an embedded system within the Lockly infrastructure has come to an end. Having considered other similar reverse engineering projects, user license agreements with proprietary hardware and the ever-changing IT sphere, there’s greater risk associated with making systems designed to run on hardware which the developers exercise a great deal of control over. Not all developers champion FOSS in the same manner, so it is best to set the project aside for now despite initial interest.
One of my activities over the summer has been to prepare for my full time college semester in the fall. My coursework in project management, java and system administration will surely help me to pursue appropriate certifications to pair with these areas. Indeed, Microsoft and Google project management and system administration certifications have started showing up on job applications, which is highly promising for my work. As such, I’ve been working on cloud servers once again, namely through the services provided in DigitalOcean.
I set out to see how easy it is to host a game server in the cloud, and sure enough the internet is very ready with servers provided from docker containers to run classic and modern game servers on internet connected infrastructure. I got the services set up and connected in only a couple days due to how easy it is to access and use public IP address space with linux servers to connect to containerized backends of all the classics like Titanfall 2. I even applied the popular modding solution to run the server via Northstar launcher [2].
Indeed this project was great, and another opportunity arose to build network services for my peers a month ago. I had worked with Minecraft in the past with my VR hobby, but now I was given the chance to run a server for a friend to host their own system. I wanted to design a system that we could both easily manage, and was also cost effective to run. After learning my options and what other Minecraft cloud providers offered, such as the first party realms and Shockbyte, I was pointed in the direction of Pterodactyl, which takes the docker server idea and applies super convenient layers of orchestration on top of it. [3]
This solution was perfect. We could delegate roles between each user and the server would take care of itself as needed through the use of providing updates, management of mod versions, and could even have other games plugged in as time went on.
I spent about a week setting up the system. The team’s documentation was effective in conveying how to set it up for local use on one single system. I settled on a $20/m plan with DigitalOcean for the cost and budget, allocating 4 Gb of RAM, 60 Gb of disk space and configuring SWAP to handle the rest of the interactions between OS and game server memory management. I learned how docker by default copies the system’s RAM use indications, so any systems inside of docker would follow the restrictions and allocations based off of the percentage given to the swapon systemctl manager. This was the biggest jump in quality, as now the system would run effectively, but not require higher amounts of RAM that most games demand.
Having managed this, we had a number of other challenges to solve. The way the node management system is handled, there was an SSL layer issue that needed to be resolved. Pterodactyl requires 2 subdomains to run, one for the web management console and one for the game package repository, aka the node server. Hosting both of these on the same system proved questionable for SSL to convey that the system could work freely, so using a blended solution of HTTP for the console commands and HTTPS for secure logins, account management and system administration, compliance would be kept in check. All of this was made possible through Cloudflare’s flexible SSL system, letting the data in transit maintain integrity while allowing plaintext messages in the backend move as necessary for the system to operate in a cost effective manner.
DNS was also handled by Cloudflare, directing to a web portal subdomain. The server’s IP allows connections to the well known Minecraft port of 25565, but only when the allowed user wants the server running. It can be started and stopped at the click of a button, and updates are as easy as bringing the forge version into the docker repo, refreshing the system cache, and relaunching with all data still in tact for long-term play. There is a txt file available for DNS servers to advertise public Minecraft services, but I chose not to advertise this due to security concerns I’ve listed below.
Parts of the Pterodactyl setup required the system to not be in a user account, so a less privileged user was made to accommodate. The backend uses an SQL database to maintain logins, records and system properties. These can only be accessed through appropriate systems on the local client, and the only way to get there is through SSH into a linux user or through SSH plus VNC. Yes that’s right, for setting up the system and to keep resource use low, we went with a Virtual Network Connection to access a GUI. The GUI of choice was XFCE, as it was lightweight and lets us poke around graphically at whatever we needed.
By the end, there was still more data to collect. Would the server run over the long term without issues? Would it require reboots occasionally due to memory leaks or other problems? Would leaving the public IP exposed open the door for potential malicious attackers to find the server and deliver payloads? We needed time to answer these questions.
Well currently, we have a service running in the cloud incurring monthly charges at a rate of about $25/M. Ideally, we could get this lower by moving to a local system and trying to provide connections through a VPN proxy. This is exactly what we’ll be trying to do in the next blog post. I hope to get this out by the time my semester of school starts in September, so please look forward to hearing about more.
Thanks for reading, stay safe.
[1]https://masq31.dev/portfolio
