diff --git a/README.md b/README.md index bc044fe9..819e30b8 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ micro-services : only dynamic part accessibe to players, so it's codebase is reduce to the minimum. It does not parse or try to understand players submissions, it just write it down to a file in the file - system. Parsing and treatment is made by the `backend`. + system. Parsing and treatment is made by the `checker`. - `remote/challenge-sync-airbus` is an inotify reacting service that allows us to synchronize scores and exercice validations with the Airbus scoring platform. @@ -55,6 +55,8 @@ So, the general filesystem is organized this way: accessible without authentication and to avoid bruteforce, each file is placed into a directory with a hashed name (the original file name is preserved). It's rsynced as is to `deimos`. +- `GENERATOR` contains a socket to allow other services to communicate + with the `generator`. - `PKI` takes care of the PKI used for the client certiciate authorization process, and more generaly, all authentication related files (htpasswd, dexidp config, ...). Only the `shared` subdirectory @@ -67,14 +69,14 @@ So, the general filesystem is organized this way: - `startingblock` keep the `started` state of the challenge. This helps `nginx` to know when it can start distributing exercices related files. -- `TEAMS` stores the static files generated by the `backend`, there is +- `TEAMS` stores the static files generated by the `generator`, there is one subdirectory by team (id of the team), plus some files at the root, which are common to all teams. There is also symlink pointing to team directory, each symlink represent an authentication association (certificate ID, OpenID username, htpasswd user, ...). -- `submissions` is the directory where the `frontend` writes +- `submissions` is the directory where the `receiver` writes requests. It creates subdirectories at the name of the - authentication association, as seen in `TEAMS`, `backend` then + authentication association, as seen in `TEAMS`, `checker` then resolve the association regarding `TEAMS` directory. There is also a special directory to handle team registration. @@ -86,7 +88,10 @@ Local developer setup Use `docker-compose build`, then `docker-compose up` to launch the infrastructure. After booting, you'll be able to reach the main interface at: - and the admin one at: . + and the admin one at: (or at ). +The dashboard is available at and the QA service at . + +In this setup, there is no authentication. You are identfied [as a team](./configs/nginx/get-team/team-1.conf). On first use you'll need to register. #### Import folder @@ -114,20 +119,27 @@ If your are trying to use the folder available with the Owncloud service, make t ### Manual builds Running this project requires a web server (configuration is given for nginx), -a database (currently supporting only MySQL/MariaDB), a Go compiler for the revision -1.16 at least and a `inotify`-aware system. +a database (currently supporting only MySQL/MariaDB), a Go compiler for the +revision 1.16 at least and a `inotify`-aware system. You'll also need NodeJS to +compile some user interfaces. -1. First, you'll need to retrieve the dependencies: +1. Above all, you need to build Node projects: + + cd frontend/fic; npm install && npm run build + cd qa/ui; npm install && npm run build + +2. First, you'll need to retrieve the dependencies: go mod vendor 2. Then, build the three Go projects: go build -o fic-admin ./admin - go build -o fic-backend ./backend + go build -o fic-checker ./checker go build -o fic-dashboard ./dashboard - go build -o fic-frontend ./frontend + go build -o fic-generator ./generator go build -o fic-qa ./qa + go build -o fic-receiver ./receiver go build -o fic-repochecker ./repochecker ... @@ -153,22 +165,32 @@ a database (currently supporting only MySQL/MariaDB), a Go compiler for the revi After initializing the database, the server will listen on : this is the administration part. - ./fic-backend & + ./fic-generator & This daemon generates static and team related files and then waits - for new submissions (expected in `submissions` directory). It only - watchs modifications on the file system, it has no web interface. + another process to tell it to regenerate some files. - ./fic-frontend & + ./fic-receiver & This one exposes an API that gives time synchronization to clients and handle submission reception (but without treating them). + ./fic-checker & + + This service waits for new submissions (expected in `submissions` + directory). It only watchs modifications on the file system, it has no web + interface. + ./fic-dashboard & This last server runs the public dashboard. It serves all file, without the need of a webserver. It listens on port 8082 by default. + ./fic-qa & + + If you need it, this will launch a web interface on the port 8083 by + default, to perform quality control. + For the moment, a web server is mandatory to serve static files, look at the samples given in the `configs/nginx` directory. You need to pick one base configation flavor in the `configs/nginx/base`