Sindbad~EG File Manager

# Dynamic Openresty Server

The goal of the Dynamic OpenResty Server is to have a server that rely on a Redis Database for the configuration 
of Vhosts and SSL certificates. It avoids the need to reload the server after each update, the reloading of 
Nginx take a long time (and consume memory * 2) when we have a lot a Vhost with it.

It also allows us to create custom code for custom security, like the Cookie Challenge or the Javascript Challenge.

## Installation

Please check the online documentation, it will be more up-to-date :
* http://o2doc.odns.fr/serveur-edge/build
* http://o2doc.odns.fr/server-edge/installation
* 
## Nginx configuration details

  * nginx.conf : main configuration file, tweaked for performance.
  * internal_vhosts/backends.conf : use to defined `upstream` backend for the cache server. One upstream for Varnish, one for LSLB, one experimental for the chained purge propagation. For the cache servers, we can have multiple cache server or a cache server + a local failback.
  * internal_vhosts/api_vhost_edge.conf : Openresty internal API (for purging internal cache) + Redirect the rest to the PHP API
  * internal_vhosts/api_vhost_mutu.conf : Openresty internal API 
  * internal_vhosts/api_vhost_lslb.conf : Litespeed API
  * internal_vhosts/api_vhost_varnish.conf : Varnish API
  * internal_vhosts/forwarder_vhost.conf : The backup Vhost, the one called when the cache servers are not available.
  * main_vhost.conf : The main Vhost file. The one responsible for all the Vhost.
  * proxy_pass/proxypass_http(s)_default.conf : The proxy pass configuration (called by the main_vhost.conf)
  * proxy_pass/forwarder_proxy_pass.conf : : The proxy pass configuration (called by the forwarder_vhost.conf)
  * custom_security/ : the directory containing all the different WAF rules that a customer can activate. Also contains maps.
  
## Quick explanation of Lua Files

  * api_vhost_internal.lua : the code that defined the Openresty internal API (used to purge cache mainly)
  * forwarder_vhost_access_by_lua_file.lua : will proxy_pass to the OriginalIp (mutu). Failback when cache server failed
  * main_vhost_access_by_lua_file.lua : will proxy_pass to the cache server or the mutu depending on the configuration stored on redis
  * main_vhost_challenge_access_by_lua_file.lua : will return the Challenge Response (cookie or JS) and check for the response (o2s-chl)
  * main_vhost_challenge_js_form_checker.lua : answer for the JS Challenge
  * main_vhost_ssl_certificate_by_lua_file.lua : detect / load the right SSL certificate
  
## Quick explication on how it's stored on Redis

```
$ redis-cli hgetall toto.com
 1) "proxyPassSslIp"
 2) "109.234.163.160"
 3) "sslCaBundle"
 4) ""
 5) "sslKey"
 6) "-----BEGIN PRIVATE KEY-----XXXXXXXXXXX"
 7) "proxyPassPort"
 8) "6081"
 9) "isSslAvailable"
10) "1"
11) "sslCrt"
12) "-----BEGIN CERTIFICATE-----XXXXXXXXXXX"
13) "originalBackendIp"
14) "109.234.164.51"
15) "listenToIp"
16) "109.234.164.18"
17) "proxyPassProtocol"
18) "http"
19) "mainDomain"
20) "toto.com"
21) "proxyPassSslProtocol"
22) "http"
23) "proxyPassIp"
24) "109.234.163.160"
25) "proxyPassSslPort"
26) "6081"
27) "rawSslContent"
28) "-----BEGIN PRIVATE KEY-----XXXXXXXXXX-----BEGIN CERTIFICATE-----XXXXXXXXXXX"
```
## Testing

The Openresty configuration is becoming more and more complicated so we need to have some automated tests or at least
some smoke tests. 

The automated testing is done with the help of `docker-compose` and the directory `tests`. The `tests` directory
contains subdirectories : 
  * `tests/httpd` contains a Dockerfile with the configuration for the `test_httpd` container 
  * `tests/openresty` contains the Dockerfile, configurations and startup scripts for the `test_openresty`
  * `tests/tests` contains the Dockerfile and the small SF app that contains the tests. Related to the `test_suite` container

The main `docker-compose` file will create a few containers : 
  * one container `test_openresty` with openresty. The startup script of this container will add a few test data on Redis
  * one container `test_redis` with just redis
  * one container `test_httpd` apache and some default page to fake the shared hosting / backend
  * one container `test_suite` with a small Symfony app with some phpunit tests

The tests can be run by entering the `test_suite` container. 

```bash
cd openresty
docker-compose up
docker-compose exec test_suite bash
php bin/phpunit 
```