Browse Source

Updated caveats of api

Hamzah 2 months ago
1 changed files with 30 additions and 0 deletions
  1. +30

+ 30
- 0
docs/ View File

@@ -2,11 +2,14 @@

## Redbrick Administrator Web API

The source code for the API can be found [here](

The Redbrick web API serves as an easy interface to carry out administrator tasks (mainly LDAP related), and for use in automation.

This saves time instead of accessing machines, and formulating and executing manual LDAP queries or scripts.

The server code for the API is hosted on Zeus in a docker container called 'api-redbrick', written in Python with [FastAPI](
This container is then served to the public using traefik, you can view the dashboard [here](

### Reference

@@ -58,4 +61,31 @@ response = requests.request("GET", url, headers=headers, data=payload)

### Important Notes and Caveats

As the FastAPI server for the API is hosted inside of a Docker container, there are limitations to the commands we can execute that affect the "outside" world.

*This is especially important with commands that rely on LDAP.*

For example inside the `` script used by the `/register` endpoint.

- Commands like `chown` which require a user group or user to be passed to them will not work because they cannot access these users/groups in the container.

- This is prevalent in our implementation of the API that creates and modifies users' `webtree` directory.

As a result, the API has a hard dependancy on manually granting the user permissions to their webtree directory - when the `webtree` dir is created it is owned by root.

**Why not just do this inside** `/scripts/`?

- The creation of the `webtree` directory for the user requires `chown` to be run, to give the user permissions for their respective directory (i.e `/storage/webtree/U/USER_NAME`)

- In the command `chown USER_NAME:member /storage/webtree/U/USER_NAME`, the `USER_NAME:member` arg is dependant on the LDAP user and group (member) being available.

- This is not possible inside the docker container.

For this reason, the webtree permissions portion of `/register` is outsourced to being done manually (usually at the same time as when an account is created).

A possible current solution is to run this permissions updating on a job at some interval, and setting permissions for anyone with 'NEWBIE: TRUE' in their ldap data.