The idea behind this project is to provide a dashboard showing the status ofthe ACNodes in the system.
This is really intended to be deployed as a docker container. There's an included Dockerfile for building this. It uses a multipart build to keep the final container as small as possible.
It is possible for the dashboard to read configuration from a JSON file, however since it is intended for container deployment, it also reads from environment variables:
| Env Var | Name | Default |
|---|---|---|
| MQTT_SERVER | MQTT Server to connect to | (None) |
| MQTT_CLIENTID | MQTT Client Id | ACNodeDash |
| ACSERVER_URL | ACServer URL | https://acserver.london.hackspace.org.uk |
| ACSERVER_APIKEY | ACServer API Key | (None) |
| LDAP_SERVER | LDAP Server to use for auth | (None) |
| LDAP_ENABLE | Enable LDAP authentication | false |
| LDAP_BASEDN | Base to search for users and groups in | (None) |
| LDAP_BINDDN | Bind DN to use when connecting to the LDAP server | (None) |
| LDAP_BINDPW | Password to use when connecting to LDAP | (None) |
| LDAP_USEROU | OU to search for users | ou=Users |
| LDAP_GROUPOU | OU to search for users | ou=Groups |
| LDAP_SKIPTLSVERIFY | Ignore certificate errors on LDAP connection (for testing only!) | false |
| REDIS_ENABLE | Enable Redis persistence | false |
| REDIS_SERVER | Redis server to connect to | (None) |
| ADMIN_GROUPS | Comma separated list of admin user groups | (None) |
| LOG_FMT_JSON | Boolean, should logs be emitted as JSON? | false |
This is likely to require some tweaks if it were to be used with an LDAP server that doesn't use the same structure as LHS's:
- Users are in an OU
- Groups are in a (separate) OU
- users are linked to groups via the memberUid attribute on the group
Redis serves as a caching layer and persistence store. It is an in-memory cache, but periodically saves state to disk, so can also be used for longer term persistence.
If enabled, it is used as a session store, user store, and general data persistence store for node data.
The code supports multiple authentication providers. It is envisaged that LDAP will be the main one in use, however there are a few cases when another source of users may be preferred:
- development
- Use somewhere other than LHS
- Storing machine accounts for API use
There is a utility in bootstrapper which creates a default "admin" user, for bootstrapping new systems. It uses the same configuration environment variables and/or file as the main dashboard process. It will create a user in the Redis provider, though it could easily be extended to support other writable providers.
There's an API spec in /static/api.yaml - it's worth keeping this up to date since it can be browsed and interactively played with at /swagger/
The template /templates/swagger.gohtml is basically the standard swagger standalone html, however it has been tweaked to make it work with the cache breaking and general static file handling.
The server will serve out of frontend/dist if it exists, otherwise it serves out of static/ - this is so when you are developing, it will use a UI build if you have one.
The frontend is a React app in frontend/ - to work with it:
npm run serve- serves a development server, with live updatesnpm run build- builds a production build to dist/npm run builddev- builds a development build to dist/
The development server runs on port 3000 and forwards /api requests to http://localhost:8080/api - this is assumed to be your local API server.