2. System Configuration

2.1. Configuration Files

The majority of configuration settings are stored in the following files:

• dc_config/cybercom_config.env

  • Used for general application settings and container versions

  • Configure Nginx to use Let’s Encrypt

  • Configure MongoDB database name and Docker volume prefix

  • Set the ALLOWED_HOSTS setting - this must be updated if running on a publicly accessible server!

• dc_config/secrets.env (This should be copied from dc_config/secrets_template.env as a starting point)

  • !!! Once created, you should change the default credentials as they are not secure !!!

  • Used to store sensitive variables that should not be tracked in version control

  • Set MongoDB and RabbitMQ credentials

  • Configure email server connection

  • SSL configration

  • Configure Let’s Encrypt reminder notification email address (NOTIFY_EMAIL)

• requirements.txt

  • Python requirements for the API / Django

• dc_config/images/celery/requirements.txt

  • Python requirements for the dockerized Celery container

It is recommended to copy dc_config/secrets_template.env to dc_config/secrets.env as a starting point. Once created, you should change the default credentials as they are not secure!

2.2. Generating SSL Keys and Where They are Stored

Rabbitmq and MongoDB are configured to use SSL certificates to secure their communications. By default, during the setup of cyberCommons, these certificates are configured to be valid for 365 days. This default can be changed by editing the CA_EXPIRE value in the dc_config/secrets.env file. Once the certificates expire, they will need to be regenerated by running shell make initssl

2.2.1. Generating SSL certificates

Self-signed certificates are automatically generated on first run for RabbitMQ and MongoDB. Generation of self-signed certificates for NGINX is currently not implemented. LetsEncrypt - refer to the LetsEncrypt section of the installation instructions.

2.2.2. Renewing SSL Certificates

1. Self-signed certificates can be updated by running the following command from the cyberCommons root directory:

$ make initssl

All remote Celery workers will need the new SSL client certificates to resume communications. See the section below on where these certificates are stored

1. LetsEncrypt certificates can be renewed by running the following from the cyberCommons root directory:

$ make renew_certbot

Follow LetsEncrypt’s prompts

2.2.3. SSL Certificate Locations

1. Self-signed locations:

   • MongoDB

     • dc_config/ssl/backend/client/mongodb.pem

     • dc_config/ssl/backend/server/mongodb.pem

     • dc_config/ssl/testca/cacert.pem

   • RabbitMQ

     • dc_config/ssl/backend/client/key.pem

     • dc_config/ssl/backend/client/cert.pem

     • dc_config/ssl/backend/server/key.pem

     • dc_config/ssl/backend/server/cert.pem

     • dc_config/ssl/testca/cacert.pem

2. LetsEncrypt location:

   • NGINX

     • dc_config/ssl/nginx/letcencrypt/etc/live/*

2.3. Configure Email Backend

• Populate the Email Configuration section in dc_config/secrets.env. The following is an example using gmail.

EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend
EMAIL_HOST=smtp.gmail.com
EMAIL_PORT=587
EMAIL_HOST_USER=username@gmail.com
EMAIL_HOST_PASSWORD=password
EMAIL_USE_TLS=True

2.3.1. Turn On Debug Mode for RESTful API

The Debug mode is turned off by default. If you need debug messages

1. Set DEBUG=True in dc_config/cybercom_config.py

2. Add host(s) to ALLOWED_HOSTS list if needed. See Django’s documentation on the ALLOWED_HOSTS setting for more detail.