Central server companion #11

New Issue

Jef Roosens · 2024-01-04T10:11:40+01:00

Jef Roosens commented

2024-01-04 10:11:40 +01:00

Considering I usually play on servers with some friends, I'd like to be able to give them access to the server backups as well.

To accomplish this, I'd like to introduce a central server component where my running Alex instances can publish certain layers to. This would aggregate the backup files into a single server that can then host them as a very basic web page.

For authentication, a server's backups could either be public or protected by HTTP Basic Authentication, as this should be supported by all major browsers. The server would have a basic user management system where each user is given access to a defined list of servers (or they're an admin, in which case they can see everything and add/remove users from servers). For user management, a simple API would need to be included, as well as a CLI tool. This information would probably be stored in an SQLite database. I would probably also expose access to the backup files through the API as well.

Besides backups, the Alex instances could perhaps also stream the server's logs to the server, so users can see these as well.

The main server instance could also be responsible for managing the server backups in an S3 store to store backups "in the cloud".

Considering I usually play on servers with some friends, I'd like to be able to give them access to the server backups as well. To accomplish this, I'd like to introduce a central server component where my running Alex instances can publish certain layers to. This would aggregate the backup files into a single server that can then host them as a very basic web page. For authentication, a server's backups could either be public or protected by HTTP Basic Authentication, as this should be supported by all major browsers. The server would have a basic user management system where each user is given access to a defined list of servers (or they're an admin, in which case they can see everything and add/remove users from servers). For user management, a simple API would need to be included, as well as a CLI tool. This information would probably be stored in an SQLite database. I would probably also expose access to the backup files through the API as well. Besides backups, the Alex instances could perhaps also stream the server's logs to the server, so users can see these as well. The main server instance could also be responsible for managing the server backups in an S3 store to store backups "in the cloud".

Jef Roosens added the

Idea

label 2024-01-04 10:11:40 +01:00

Jef Roosens commented

2024-05-28 10:02:08 +02:00

Poster

It might be best to rebuild the application as an Async-first implementation using Tokio.

We could then start by implementing an Axum-based HTTP server that serves its routes over a unix socket, which could then be used by the client to communicate with the server. We could for example use the broadcast channel to implement a system to stream logs to multiple readers. This API could then also allow for requesting generated backups from the server, or any other useful feature that we might need.

It might be best to rebuild the application as an Async-first implementation using Tokio. We could then start by implementing an Axum-based HTTP server that serves its routes over a unix socket, which could then be used by the client to communicate with the server. We could for example use the [broadcast](https://docs.rs/tokio/latest/tokio/sync/broadcast/index.html) channel to implement a system to stream logs to multiple readers. This API could then also allow for requesting generated backups from the server, or any other useful feature that we might need.

Sign in to join this conversation.