We're planning to use Virtualmin to host some of our customer sites. The target is primarily mail, but we'll definitely take dns, web, and ftp as well. The software has everything we need and then some, and for the most part it's been working exceptionally well, although there is one item related to server aliases that doesn't fit well for what we're trying to do. We want our users to have one main domain per account, in addition to optionally adding a fixed number of plain old mail domain aliases. We don't want them to have the ability to add server aliases with their own separate email accounts.
So when the domain admin uses the Create Virtual Server nav item, they will typically see 3 virtual server types at the top:
- Alias of (domain)
- Alias of (domain), with own email
It's the 3rd option we'd like to restrict.
The plan/owner limits give you two options to cover these three server types:
- Limit on number of alias servers (*) Unlimited ( ) At most [______]
- Limit on number of non-alias severs (*) Unlimited ( ) At most [______]
For our purposes, we've limited non-alias servers to 0, so the domain admin user cannot create these. That just leaves the two alias server types.
Ideally, instead of presenting one alias limit to cover both types, there would be two:
- Limit on number of non-alias servers (without own email) (*) Unlimited ( ) At most [______]
- Limit on number of non-alias servers with own email (*) Unlimited ( ) At most [______]
I did glance at the UI code (virtual-server/domain_form.cgi) to make sure I wasn't missing some setting that might restrict these separately, and saw there was just the one overall alias limit. Looking at the resulting Postfix/system config I can see that these are very closely linked. If it's a regular server alias each account gets a virtual mapping to the main domain. If the alias has it's own email, then the virtual mapping changes to the respective system accounts. I don't know how easy it would be to fully separate the limit controls. Nevertheless I wanted to submit this as a feature request because it would definitely be useful for us, and perhaps for others in general. It would offer a bit more flexibility in this area.