| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| projects:frontier-team-builder [2023/12/03 05:37] – oemb1905 | projects:frontier-team-builder [2023/12/03 06:44] – oemb1905 |
|---|
| 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 [[computing: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. | 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 [[computing: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/development.domain.com/public_html/ |
| cd /var/www/production.domain.com/public_html/ | cd /var/www/production.domain.com/public_html/ |
| Add the following the ''RedirectMath'' rules just below ''DocumentRoot'' in both virtual host configuration files: | Add the following the ''RedirectMath'' rules just below ''DocumentRoot'' in both virtual host configuration files: |
| | |
| <RedirectMatch ^/$ /pvpoke/src> | 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. After that, it's now time to set permissions for the production instance. To do that, let's ensure we have some common read/write/execute permissions on the instance. These are recommendations and took me about 1-2 hours of code review to decide a) what was needed for things to function and b) what we could restrict without harming functionality. Here's the script I came up with; make sure to adjust for the ''domain.com'' and other settings unique to your workflow: |
| | |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/permissions.sh|permissions.sh]] |
| | |
| | Next, we need to harden the production instance and/or optionally white-label it. To harden, we remove the development cog from footer.php and make write.php an empty file. Here's the changes we made: |
| | |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/custom/src/index.php|index.php]] |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/custom/src/footer.php|footer.php]] |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/custom/src/data/write.php|write.php]] |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/tree/main/projects/custom/src/img|img]] |
| | |
| | Now, the repository also has the ability to store overrides on moves and custom meta groups, however, this is optional and more of a choice specific to each meta development team. |
| | |
| | ------------------------------------------- |
| | |
| | At this point, the development and production virtual hosts are created, secured sufficiently, and/or optionally customized. From this point forward, the tutorial is no longer about how to set up the instances, but rather how to leverage those instances to create metas on the development instance and then migrate those development changes to production. In order to do this, one needs to have detailed understanding of how the upstream code from pvpoke.com works. For me, this took weeks of studying the code with a colleague of mine at Antimatter.GG gaming, meetings with the head developer of pvpoke.com, and a bit of trial and error. Once that was done, I created two scripts. The first one creates the pre-requisite back-end files needed for the creation of a new meta on the development instance, and the second one merges the metas you created in development back to production while preserving aforementioned white-labeling and hardening. Below, I've included the wiki post KakunaMatata made about how his stack works, the pre-requisite file creation script, and the merge to production script: |
| | |
| | *[[https://github.com/pvpoke/pvpoke/wiki/Creating-New-Cups-&-Rankings|Creating New Cups]] |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/poke-create-files.sh|poke-create-files.sh]] |
| | *[[https://repo.haacksnetworking.org/haacknet/haackingclub/-/blob/main/projects/poke-rebuild-production.sh|poke-rebuild-production.sh]] |
| | |
| | |
| | |
| | |
| |
| 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: | |
| |
| --- //[[jonathan@haacksnetworking.org|oemb1905]] 2023/12/03 04:48// | --- //[[jonathan@haacksnetworking.org|oemb1905]] 2023/12/03 04:48// |
