rimas-kudelis
commented
10 months ago I personally would prefer to keep a set of patches to the stock config file, and/or a patcher script, instead of a copy of said stock config file with our patches already applied.
Exim may introduce new and useful features over time, and may deprecate or change some existing functionality (like already happened in #232, for example). When that happens, we're kinda being thrown in a limbo, because for a while, that means that the Exim versions we can work with have different features and may need to be configured differently. And I think this especially becomes more burdensome than useful when these things aren't directly related to virtual hosting.
Furthermore, a lot of these things are not directly related to virtual mail hosting per se, but are things that can be useful in general.
For Vexim, I think it would make sense to ship only the snippets that are directly related to multi-domain virtual hosting. For example:
| Feature | Should provide? |
|---|---|
| domain-specific mailboxes | yes |
| domain-specific TLS certificates | yes |
| automatic rejection of potentially harmful content (configurable per domain) | yes |
| automatic rejection of potentially harmful content (regardless of the domain) | no |
| mailing list software integration (assuming we have means to toggle this functionality per domain) | yes |
| mailing list software integration (where we have no means to toggle this functionality per domain) | no |
The last four rows in this table should say everything about my vision. :)
@runout-at
For Exim configuration I prefere the Debian split config as it is much easier for me to handle it and it won't break easily on Exim upgrades. However, Debian will build the full configure file anyways so it should be easy to provide that too. I'd be happy if we will provide at least some Vexim related files for the split config. It should be easy to merge those into a monolithic config file.
I think a Debian-like split config would be awesome. And it's much easier to build a monolitic file from split config than it is the other way around. We could provide a simple shell script for that. I mean, all you have to do is concatenate these files in order, what could be easier, right?
But this doesn't solve the problem that our config could become outdated (or too "updated" for some) at any point in time. Furthermore, even by default it's already huge enough. If we start adding hooks specific to various mailing list software, virus scanners, spam checkers etc, it will only become bigger and more difficult to maintain. Which is why I think a fully configured out-of-the-box experience, or a friendly configuration wizard should be a goal of a different project/repo than this one. Like I mentioned elsewhere, there's the Exim4u project which strived to do something like that, but still it seems like their main means of installation was following a README guide, not a "turnkey solution".
I see a few strategies we could employ to provide such "turnkey solution":
- create a mailserver-oriented "Debian flavour" (some may complain that it's not SuSE or FreeBSD or whatever else they prefer to Debian).
- or a deploy-ready monolitic Docker image with all services preinstalled in it (not really the "Docker way", I think)
- or a set of Docker images grouped via Docker Compose or Swarm or Kubernetes or whatever (I love Docker Compose, but I've mostly used it for local development and have no proper experience with running it in production)
- an installer script (which would either be very distribution-specific, or quite complicated due to the specifics in each distro; per-distro scripts also an option, but then we get to duplicate a lot of stuff in them, or just generate them from that same complicated if-distro-elseif-distro-else-endif mess).
But again, I think these strategies could be explored in a separate repository (or multiple repositories).
BTW, I just tested out a fresh Debian installation in a VM and it looks like Debian actually defaults to non-split config now (when it asks if you want it split, No is the button that is selected by default). Their debconf wizard also explains pros and cons of both approaches in short. They say the monolitic config is better for big changes, and split config is better for small ones. Not sure if I agree with such assessment though. :smile:
runout-at
I split this discussion out from #282.
What we have so far:
@rimas-kudelis
@kaluang
@runout-at