Default configuration / config files

[lmeunier]

Hi there, I just started testing stalwart-mail for my next self-hosted mail server, and this project looks very promising.
I've just a couple of questions about the configuration and how should I manage my config files.

As seen in the documentation, I used the /usr/local/bin/configure.sh script to generate my config file (one big config.toml file). I was using v0.3 at the time.
Now I'm in the process of migrating my configuration to v0.4 with the new config layout (the big file is split in multiple toml files).

How should I do it? Should I run again the /usr/local/bin/configure.sh script from scratch? What should be the recommended way to migrate from 0.3 to 0.4?

Thinking about this lead me to some ideas... What if stalwart comes with a default configuration? The one used by the /usr/local/bin/configure.sh script, but the result is one single file containing only configuration that diverge from the default conf.
This config file could use import.files to import the default configuration.

[include]
files = [ "/path/to/stalwart/default_config.toml" ]

[macros]
host = "mail.example.com"
default_domain = "example.com"

[certificate."default"]
cert = "file:///opt/stalwart-mail/etc/certs/mail.example.com/fullchain.pem"
private-key = "file:///opt/stalwart-mail/etc/certs/mail.example.com/privkey.pem"

#...

• this should result in a much smaller (and less scary) config file
• users could easily have access to the default config (just have to follow the file referenced by import.files
• migration should be more easy, users should have to care only for config parameters present in their own config file, all other parameters use default values from the default config

[mdecimus]

Hi,

How should I do it? Should I run again the /usr/local/bin/configure.sh script from scratch? What should be the recommended way to migrate from 0.3 to 0.4?

You should first start a new container with the latest version. Then you can either re-run the configure script or manually migrate the configuration files. Unless you made significant changes, it is recommended to just re-run the config script and apply your changes on the new files. For more details check the UPGRADING document.

Thinking about this lead me to some ideas... What if stalwart comes with a default configuration? The one used by the /usr/local/bin/configure.sh script, but the result is one single file containing only configuration that diverge from the default conf.

Thanks for the suggestions but the current configuration procedure is temporary. As soon as the performance enhancements are completed, the next item on the roadmap is to implement a web-based admin tool that will no longer require configuration scripts or even access to the console.

[DXist]

It will be convenient to support an Ansible role that will render templated configuration in the configured location of a target server.
The same role could generate default configuration bundle for the configure.sh script during the release process.

I personally manage Stalwart via Ansible.

One large config is faster to apply by Ansible than a lot of configs.