App Skeleton

[NorseGaud]

Related: #1

---

Goal: Generate the app skeleton which will eventually run the API

[NorseGaud]

Hey @LukeMarlin , what is the language/tool you're choosing for the app and API?

[LukeMarlin]

Python with FastAPI, as discussed in other issues.
Most people leaned toward python so I'm pretty sure it's the best choice (possibly more contributors afterwards!).

When it comes to the framework itself, I'm more experienced with Flask, but FastAPI has a lot of nice things (like type checking, automatic "console" to explore the API) so I wanted to use it. I don't think we're going to have very specific development needs anyway, so I'm pretty sure any (light) framework will do just fine.

When it comes to project/packaging management, I'm going to use Poetry, and for testing management I'd go with Tox. These are tools that I'm using quite a lot at work and they've proved very nice so far.

As said before, if anyone has strong feelings against a tool, let's discuss this in this issue!

[NorseGaud]

Most people leaned toward python so I'm pretty sure it's the best choice (possibly more contributors afterwards!).

Two of the most active developers don't either like Python or have much experience with it (myself making it three). I'm curious how active @DerOetzi and @simonwiles will ultimately be to help (please chime in).

What would objections be to something like golang?

Lastly, I will say that FastAPI looks sweet and I'd be willing to learn more Python to get a feel for it. Just worry about maintainability for folks who are consistently active in the repos.

[DerOetzi]

I have more experience with Flask myself, but trying to switch to FastAPI with another project. For this I have the time to give some discussion input and review PRs, but I don't have time to develop the service by myself.

[LukeMarlin]

@NorseGaud Valid points, I mentioned people from the thread indeed, as it is a sidecar, so I hope your team won't be bothered too much with it.

I don't think golang is unfit to do this, plenty of libs exist already for APIs, but what I like about python for such simple jobs is how the code will be understandable to anyone, even non-python devs. It also mean that when it comes to small bugfixes, mostly anyone could do it.

Obviously the choice is up to you guys, I however don't intend to dive more into golang than I have (which isn't much), as I'm already trying to learn Rust on the side!

If you wish, you can even decide once you've seen the skeleton + first route: if it looks too complex to maintain in case external people bail out, feel free to choose another way, it would be understandable ;)

[NorseGaud]

For sure, please proceed. As long as it works, I'm ok with it :)

[thehunt100]

I'm very interested in this. Did someone already start building? And is there anyone that is taking the lead in this project? I saw that there was still no decision made between Flask and FastAPI. I would be interested in contributing to a FastAPI application.

[LukeMarlin]

@thehunt100, since there's no voice clearly against, I started with fastAPI. Going to push the draft skeleton soon.

[thehunt100]

OK, great, is there anything you need help with?

[LukeMarlin]

Opened #4, which shows how I'd organize the app, feel free to comment about python stuff there!
There still much to do, but the most important part is to first know how to call the bash scripts. We can't just use setup.sh , because it is meant to be ran on the host machine, not inside a container.

My current idea, that I'll try tomorrow, would be to build this Dockerfile on top of docker-mailserver's so that all scripts are loaded and necessary packages installed. Then provide a docker-compose that gives access to postfix-accounts.cf, enabling us to call updateuseremail... One issue being that the image will be way bigger than a simple python one... Any other ideas/pointers welcome here :)

[NorseGaud]

My current idea, that I'll try tomorrow, would be to build this Dockerfile on top of docker-mailserver's so that all scripts are loaded and necessary packages installed. Then provide a docker-compose that gives access to postfix-accounts.cf, enabling us to call updateuseremail... One issue being that the image will be way bigger than a simple python one... Any other ideas/pointers welcome here :)

I think this is a great idea. What we can do is PR in docker-mailserver to split the dockerfile into multiple layers so that you only build from what you need to execute the various inner-scripts.

[thehunt100]

@LukeMarlin I struggled with accessing the config files and scripts in my current solution, and I came up with some unconventional solutions.

In my situation, it was important to separate the admin part from the server part since I don't maintain the docker mailserver project and didn't want update conflicts.

I didn't want to let the admin run with mailserver editing permissions and be directly accessible from the internet in case of a security problem.

So the solution I came up with was to create a /config/run directory inside the docker volume.

The admin now creates the commands to execute on the mailserver and saves them as a file in the /config/run dir so a cronjob or inotifywait powered script with the right permissions can execute them.

This setup has a few added benefits.

It is straightforward to create an audit log to see when and who executed commands.

The admin can now run in its container with a low permission level since it only needs to access the /config/run for security and maintenance benefits.

Also, it is now easy to test the admin code since you only need to check the outputted commands.

It allows for extra validation on the server side, so the script that executes the commands can catch bugs or security problems.

I realize that this strong decoupled setup also has some downsides. For example, there is no direct feedback to give to the user. I do think this is possible when you run the command executer at a high frequency or on the command creation event with something like inotifywait. Also, to get the server's current state, it needs to provide that in the run dir, which is possible by copying the config files after they have changed. For my use case, this was not a big problem.