These are the instructions for setting up the web generator.
This section details how to download and set up the ctjot web generator. There are two options: running locally or running in Docker.
Browse to your working area and:
git clone https://github.com/Anguirel86/ctjot_web_generator.git
The Jets Of Time randomizer is included in this repo as a submodule. It will need to be initialized. If running with the deploy.sh script then this will be handled automatically. If not, then run:
git submodule init
git submodule update
- Copy an unheadered Chrono Trigger ROM to the repo base directory and name it ct.sfc
The web generator can be run using the built-in Django test server and sqlite database. By default, this server will only be accessible on localhost.
- Create a virtual environment named venv:
python3 -m venv venv
- Enter the virtual environment:
source venv/bin/activate
(Linux)source venv/Scripts/activate
(Windows)
- Install dependencies:
pip install -r requirements.txt
- Set a SECRET_KEY. Either:
- Set the SECRET_KEY environment variable, or
- Modify the SECRET_KEY line in the ctjot/settings.py file
- Set the app to DEBUG mode. Either:
- Set the DEBUG environment variable to '1' or
- Modify the DEBUG line in the ctjot/settings.py file
- This will allow the test server to see static files and allow tracebacks on errors
- Copy or link the following files into the web app's base directory:
- jetsoftime/sourcefiles/names.txt
- jetsoftime/sourcefiles/patch.ips
- jetsoftime/sourcefiles/flux/
- jetsoftime/sourcefiles/patches/
- jetsoftime/sourcefiles/pickles/
- Enter the virtual environment (if not already done):
source venv/bin/activate
(Linux)source venv/Scripts/activate
(Windows)
- Apply database migrations:
python manage.py migrate
- Run the test server:
2.
python manage.py runserver
The repo contains a deploy.sh script that will verify the environment and build/launch the containers.
There are three supported deployment types:
- Development
- Only the web app and database containers, runs with the built-in Django test server
- Staging
- Runs all containers using the letsencrypt staging API and fewer environment checks
- Production
- Runs the full production setup with the live letsencrypt API and full environment checks
This is a configuration is meant for local testing of the web generator. It launches a minimal subset of containers needed for testing, and is not suited for use in a production environment.
Run the deployment script from the repo root directory.
./deploy/deploy.sh -d
- Open a web browser and point it to the webapp on port 8000:
This configuration runs the web generator in a near production environment with all containers. It uses the letsencrypt staging API due to the higher rate limit. This results in self-sighed certificates, so browsers will give security warnings.
- Set an email address in deploy/.env.staging.letsencrypt
- This is the email address used to register the certificates
- (Optional) Update the hostnames in the following environment files if not using test.ctjot.com
- deploy/.env.staging
- Update DJANGO_ALLOWED_HOSTS, VIRTUAL_HOST, and LETSENCRYPT_HOST with the new hostname
- deploy/.env.staging.wiki
- Update VIRTUAL_HOST and LETSENCRYPT_HOST with the new hostname
- deploy/.env.staging
./deploy/deploy.sh -s
- Open a web browser and point it to the webapp
- ie: https://test.ctjot.com
- NOTE: You will need to add a security exception due to the self-signed certificate
This configuration deploys a full production version of the web generator.
- Set an email address in deploy/.env.prod.letsencrypt
- This is the email address used to register the certificates
- Set a password for the database in deploy/.env.prod.db
- (Optional) Update the hostnames in the following environment files if not using ctjot.com
- deploy/.env.prod
- Update DJANGO_ALLOWED_HOSTS, VIRTUAL_HOST, and LETSENCRYPT_HOST with the new hostname
- deploy/.env.prod.wiki
- Update VIRTUAL_HOST and LETSENCRYPT_HOST with the new hostname
- deploy/.env.prod
./deploy/deploy.sh -p
- Open a web browser and point it to the webapp
The deploy.sh script has options to stop and restart the last run configuration.
./deploy/deploy.sh -k
will shut down the web generator../deploy/deploy.sh -r
will rerun the last run configuration
The docker-compose yaml file used for the last run configuration is linked in deploy/docker-compose.yml. This can be used for any manual docker-compose commands.
This is an optional step that can be run to migrate existing (non containerized) DokuWiki data into the DokuWiki container volume. This will copy page data, user settings, plugins, etc.
- Tar up the entire dokuwiki directory on the live server.
tar -czvf wiki_data.tar /path/to/wiki
- Copy wiki_data.tar to the new host and untar it in a temp location
tar -xvf wiki_data.tar
- Run either a staging or production deployment at least once to initialize the wiki volume
- Bring the webapp down
./deploy/deploy.sh -k
- Run the wiki migration
- NOTE: This will require root since some wiki conf data is owned by root in the container
./deploy/deploy.sh -w /path/to/wiki/backup
- Enter your password when prompted
- Rerun the webapp
./deploy/deploy.sh -r
- Browse to the wiki and verify the data migrated successfully
- ie: https://wiki.test.ctjot.com for the default staging address