THOT

Trouble Handling Operations Terminal

THOT is a specialized operations tool for CERT medical service team on Chaos Communication Congresses and similar CCC events.

It is named after the ancient egyptian god Thot or Thoth, also called the scribe of the gods. His representation in the form of an Ibis, also serves as the logo of this project. The Ibis spends significant time knee-deep in muddy water and using its long curved beak to extricate the best out of trying conditions - so it seemed a fitting choice for anything C3CERT-related.

Contributing

There are two basic rules regarding branching and merging: For changes intended to be merged on main, please create feature/issue branches. You can create personal branches for testing, but they will NOT be merged. Only feature/issue branches will be merged.

Merge Requests can only be approved and merged by owners and maintainers of this repo.

Setup and run

• clone the repository
• cd [repository]/docker
• docker compose up -d --build
• open http://localhost:3000
• login as testadmin/test or using any of the other credentials below.

Security Scanning

Please note that all THOT Docker containers are checked for known security vulnerabilities by Trivy, and build pipelines will be rejected if any fixable vulnerabilities of severity HIGH or CRITICAL are present. Fixable, in Trivy-speak, means that a newer version of the vulnerable software or library has been released, and it contains a fix for the security issue.

Checking containers for security issues before submitting a patch

If you want to check the containers you built for security issues before submitting a merge request, you should run Trivy yourself. Please refer to the Trivy documentation for installation instructions. In a nutshell, you can either install Trivy on your development machine or you can run it from inside its docker container. The following sections contain one example command for each option, each scanning THOT's api container for vulnerabilities. Repeat as necessary for other containers you wish to check.

Run trivy locally

# Run Trivy directly on your development machine
trivy image --ignore-unfixed thot-dev/api

Run trivy in Docker

# Run Trivy inside a Docker container (if you don't wish to install it locally)
docker run -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image --ignore-unfixed thot-dev/api

Making our linters happy

We are intentionally very strict about enforcing adherence to code quality standards. The python code for our backend applications and the Typescript and SCSS code for our react-based frontend are both controlled by their own linters.

Python code

Our python code's code style adherence is still a work in progress. While it is already enforced in the CI pipeline for the angelsys container, the linter is run for the api and medend containers, but its errors are currently ignored.

To check your code against our coding styleguide, and fix auto-fixable issues, you can do the following:

• If you have an appropriate virtualenv and have run pip install -r requirements.txt there, you can just execute ruff check --fix in the main project directory, or the subdirectory you were working in.
• Alternatively, run the linter using docker:

  cd docker && \
  docker compose run --remove-orphans angelsys ruff check --fix && \
  docker compose run --remove-orphans api ruff check --fix && \
  docker compose run --remove-orphans medend ruff check --fix
  

React-Frontend

NOTE: While the frontend will start and work in dev mode even if linting steps fail, this is not the case when run in production mode. To wit:

• The code must fulfill our styleguide as defined by the prettier block in package.json
• eslint --max-warnings 0 must not complain about your typescript code
• The typescript compiler must be happy with your code as configured in tsconfig.json.

Luckily, most issues that prettier and eslint complain about can be automatically fixed. You can run one of the following commands to repair them:

• If you have appropriate pnpm and node versions installed: cd reactFrontend && pnpm lint:fix
• Alternatively, run the script using docker: cd docker && docker compose run --remove-orphans react-frontend lint:fix

This will repair all auto-fixable lint issues and give you detailed output about those that couldn't be auto-repaired.

Default Users (Development Data)

uid	pw	group
testadmin	test	backoffice
testdispo	test	dispo
testleitung	test	backoffice leitung
testmedic	test	raumschicht
testuser	test	backoffice dispo

Building individual docker images

In case you want to build individual docker images for testing purposes outside of the docker-compose context, you need to keep in mind that the Dockerfile assumes its build context to be the project root directory. You can build an individual Docker image from any working directory inside the repository using the following command:

docker build -f $(git rev-parse --show-toplevel)/docker/src/Dockerfile \
  --target the_container_you_want_to_build \
  $(git rev-parse --show-toplevel)

For example, to build the API container, you can run the following:

docker build -f $(git rev-parse --show-toplevel)/docker/src/Dockerfile \
  --target container_api \
  $(git rev-parse --show-toplevel)

If you're already in the project root directory, you can use the following simplified version:

docker build -f docker/src/Dockerfile --target container_api .

Do keep in mind that most of the time, you will probably want to be working within the docker compose setup as outlined above.