User Tools

Site Tools


projects:frontier-team-builder

This is an old revision of the document!



  • frontier-team-builder
  • Jonathan Haack
  • Haack's Networking
  • webmaster@haacksnetworking.org

frontier-team-builder


This tutorial is designed for users of Debian GNU/Linux who wish to self-host a version of PvPoke.com, an MIT licensed Pokémon GO project designed by KakunaMatata. The primary purposes of PvPoke.com are to allow lovers of the game to build a collection of Pokémon suited for battle, called a battle party and to provide rankings on Pokémon for particular cups, called metas. In my case, I run two Discord “servers” dedicated to Pokémon battling and both communities have teams that I lead which create custom metas and then host Swiss tournaments (both team and individual) for these metas. A project like PvPoke.com provides a lot of value. It allows our meta development team to create well-built metas and helps participating trainers build battle parties that are well-suited for the associated tournaments that leverage those metas. For this reason, we decided to fork the project so that our meta team could use a development version to design future metas and a white-labeled and stripped down production version that would help our participants build for and participate in those metas. Additionally, I've developed a set of automated bash scripts, production readying/hardening steps, steps for maintaining, updating, and pulling from upstream for both the development and production isntances. Finally, I've also developed documentation on how to use the original project and/or our development and production versions that serve other grassroots Pokémon GO communities interested in doing something similar. The official project is maintained in a self-hosted Gitlab instance over at repo.pvpfrontier.gg.


Now that you understand the context, the first step is to ensure you have a secure VPS accessible with ssh, a FEMP/LAMP stack or equivalent w/ LTS setup, and that you understand the basics of server hardening and/or management of services for public facing instances. If you do not, please begin by reading apachesurvival and then hit me up for next steps. So long as you have those in place, our first step is to clone the repository and then create a redirect rule. The redirect rule redirects traffic to the webroot to the sub-directory that the development project expects (and is also, for security reasons, hard coded to fail if/when it does not exist). Don't worry, we'll protect and/or harden both the development and production instances later in the tutorial. Henceforward my tutorial will assume Debian GNU/Linux and a LAMP stack; adjust accordingly for other stacks.

ssh root@domain.com
cd /var/www/development.domain.com/public_html/
cd /var/www/production.domain.com/public_html/
git clone https://github.com/pvpoke/pvpoke.git
sudo chmod -R 777 /var/www/development.domain.com/public_html/pvpoke/src/
sudo nano /etc/apache2/sites-available/development.domain.com.conf
sudo nano /etc/apache2/sites-available/production.domain.com.conf

Add the following the RedirectMath rules just below DocumentRoot in both virtual host configuration files:

RedirectMatch ^/$ /pvpoke/src

This redirect is simple, stating that anything that requests *.domain.com be redirected to builder.domain.com/src/data. Next, let's make sure to require authentication for the development version so that it is not accessible to the general public. We'll create two different users, one for the webmaster and another for the team:

sudo htpasswd -c /etc/apache2/.security webmaster
sudo htpasswd /etc/apache2/.security devteam

Now, let's activate these credentials by adjusting .htaccess as follows. Additionally, since this is public facing, let's also uncomment the https redirect that's already present in the .htaccess file.

sudo nano /var/www/development.domain.com/public_html/pvpoke/src/.htaccess

Find the following lines and un-comment them:

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If you are also using www.domain.com then uncomment those too (I am not). Next, at the very bottom of the file, add the following:

AuthType Basic
AuthName 'Please authenticate:'
AuthUserFile /etc/apache2/.security
Require valid-user

This takes care of password protecting the development instance and ensuring that LTS is enforced for all url requests. Next, we need to harden the production instance and/or optionally white-label it. This involves customizing index.php, footer.php, and making write.php empty. Here's the changes we made:

The

oemb1905 2023/12/03 04:48

projects/frontier-team-builder.1701584201.txt.gz · Last modified: 2023/12/03 06:16 by oemb1905