2566: Make it clear that we don't delete users r=mergify[bot] a=nextgens
## What type of PR?
bug-fix
## What does this PR do?
Make it clear that we don't delete users. Users can and should be disabled when not in use anymore.
### Related issue(s)
- closes#1820
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [ ] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Florent Daigniere <nextgens@freenetproject.org>
Co-authored-by: Alexander Graf <ghostwheel42@users.noreply.github.com>
Co-authored-by: Dimitri Huisman <diman@huisman.xyz>
Co-authored-by: Dimitri Huisman <52963853+Diman0@users.noreply.github.com>
2705: Switch from docker.io to ghcr.io for deploying images r=nextgens a=Diman0
## What type of PR?
enhancement
## What does this PR do?
As we all know, docker has announced that they will stop with free docker organisations. The Mailu project used this. In about a month, the mailu docker org stops to exist and all images will be deleted.
This PR modifies the CI/CD workflow (github actions) to use ghcr.io as the container registry for deployed images. The images are first build with `-build` appended to the tag. These images are also used in the test step. Only in the deploy phase, are the final tags added (as it should be). This makes sure new images are only available after the deployment step.
The setup utility is updated to use `ghcr.io/mailu` as the docker_org.
All references to the docker org `mailu` have been replaced with `ghcr.io/mailu` in the documentation.
I confirmed via my Mailu_Fork repo that the github workflow works fine.
https://github.com/Diman0/Mailu_Fork/actions/runs/4440118095
### Related issue(s)
- closes#2704
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Dimitri Huisman <diman@huisman.xyz>
to ghcr.io (github). Images are now first build with '-build'
appended to the tag. E.g. ghcr.io/mailu/admin:master-build.
This is to prevent the image being available before automatic testing has completed.
In the deploy job, the final image is pushed (this still works the same).
Update setup & documentation for switch to ghcr.io
2638: further finishing touches for restful api r=mergify[bot] a=Diman0
- Fix setup utility setting correct value to env var API. It now also sets `false` when the API is disabled in the setup utility.
- Fix IF statement for enabling API in nginx.conf. Setting a different value than `API=true` in mailu.env now disabled the API endpoint in nginx.
- Use safer command for regenerating example API token. It uses crypto.getRandomValues() (as suggested by nextgens) which should be more random than the previously used method.
## What type of PR?
bug-fix
## What does this PR do?
### Related issue(s)
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [ ] In case of feature or enhancement: documentation updated accordingly
- [ ] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Dimitri Huisman <diman@huisman.xyz>
2631: Restful api finishing touches r=mergify[bot] a=Diman0
## What type of PR?
enhancement
## What does this PR do?
Some finishing touches for the restful api.
- Make the API configurable via the setup utility.
- Configured exactly the same as the ADMIN and WEBMAIL.
- We have a single config (API) that configures whether it is exposed (via front). Just like ADMIN. The API is always reachable by directly connecting to the admin container.
- API_TOKEN does not enable/disable the API anymore. When it is not configured, an error is returned (via the internet browser) that the API_TOKEN must be configured in mailu.env.
- Fix some small bugs in the setup utility ( selecting none in the dropdown boxes, now correctly changes the config)
- Update Flask-RestX to 1.0.5. This resolves the deprecation warnings introduced by Flask-RestX.
### Related issue(s)
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Dimitri Huisman <diman@huisman.xyz>
In fail2ban example configuration for ipset option, there was a duplicated string which makes the ipset and fail2ban fail to create the set.
Fail2ban will never ban any ip due to this error.
Anything that can be configured in the web administration interface,
can also be configured via the Mailu RESTful API.
See the section Advanced configuration in the configuration reference
for the relevant settings in mailu.env for enabling the API.
(API, WEB_API, API_TOKEN).
bors[bot]