An ideal panel in my opinion would

Blue Skies
1

Some great suggestions to improve Virtualmin from Nick Hill.
Nick can be contacted at http://ubuntuforums.org/member.php?u=337788

source: http://ubuntuforums.org/showpost.php?p=7837748&postcount=3

=================================

I have spent about a week trying out the different control panels for web hosting. sysCp, ISPconfig, virtualmin, ebox.

I have had past experience with Cpanel and Plesk6, which are both commercial offerings.

The free control panels are not close to the user friendliness and ease for end users compared to those two. However, those commercial panels I have tried are poor when you need custom apache configs. They tend to overwrite your custom config.

An ideal panel in my opinion would

1 ) Each domain name must be attached to a control panel user.

2 ) Each user can, depending on privileges given by the administrator, log into the control panel.

3 ) The administrator should be able to disable the user and by extension all services under that user.

4 ) For each domain name, it should be possible to enable and disable email, FTP, web service individually.

5 ) For each web host (under the user and domain name) it should be possible to enter custom apache configurations. Users should only be allowed to do this if granted by admin as these can prevent apache from restarting.

6 ) Users should be able to set up mail boxes, aliases and redirects according to limits set by administrator if the administrator has granted this privilege.

7 ) Mailbox username and passwords should not be mapped to POSIX usernames and passwords. It is completely nonsensical. It is very rare these days for a one email address per posix login account set-up. This relationship needs to be broken, as it just makes configs unnecessarily complicated and danger-prone. Most email is fetched either by webmail, Imap or POP3. POSIX user account mboxes are a broken implementation 99% of the time. Mail collection username should be mailboxname@domainname.tld so that multiple users can share mailboxes of the same name, without messing with redirects. This could be implemented with a simple mapping file rather like /etc/shadow, with a standard layout, understood by both the MTA and by a POP/Imap daemon. This would be a simple piece of integration that will make a lot of difference. A patch by the distribution for the key supported MTA and pop/imap daemons would do the trick. This must be implemented at the distribution level, not the control panel vendor level.

8 ) The control panel and the daemons it controls should receive security updates through the package management system. There should not be any part of the standard system which requires the sysadmin to manually patch security flaws.

Other things would be nice, but not important such as user configurable cron, per directory access configuration, file manager.

To achieve these goals, the user on the control panel should not link to a user on POSIX/PAM. There should be one POSIX username per domain name which Apache SUexecs in that virtualhost. FTP username/password on a per-domain name basis which matches the Apache SUexec POSIX user.

How close are the control panels?
SysCP offers much of the above, but with what appears to be a highly customised configuration system for mail and FTP. I have a copy running on Debian and an update sent the system Fubar. The config system is supported by SysCP but not by Debian.

Ebox. Offers individual configuration of core linux services, but is clearly not designed for virtual host administration. Offers little to none of the above.

ISPconfig. I installed the system with some hesitation based on the fact that parts are compiled from source, not sourced via package management. Uses special configurations. I have spent an hour playing with it, but I find it frustrating. I have not yet been able to determine how much of the above it offers, as much of the language it uses is wrong. For example, fileserver - is that FTP? I am wary that given that the core of the system is not via package management, and given the custom configurations, believe it could break package management and updates, like syscp did for me.

Virtualmin - Misses many of the above functions. In particular, dos not allow creation of mailboxes not mapped to POSIX/PAM accounts. This is understandable given that Ubuntu don’t appear to officially support this. Virtualmin appears to use standard configuration files as per usual Ubuntu system administration. The install was logical, and the user interface logical and consistent. I am leaning towards virtualmin in the hope that Ubuntu will one day introduce a supported method of full virtual mail. MTA -> pop/imap without needing a PAM/POSIX account as an intermediary.

I feel it is far less likely that updates to the Ubuntu system will break Virtualmin or the services it delivers. I expect that if I stripped virtualmin from the system, services it supports will still operate with little or no re-configuration. Combined with it’s more logical arrangement, I feel virtualmin is on the right lines. I have not made a final decision as I need to spend more time with ISPconfig to make sure, but Virtualmin is looking the best right now.

I’ll re-iterate. Ubuntu, please deliver explicit support for integration of MTA (postfix or Exim) and POP/IMap in such a way that a POSIX PAM account is not necessary as an intermediary for the authentication and collection of mail. This isn’t so much a coding but a management issue,

Nick Hill

2

as far as I can tell all your points can be (is being) done by virtualmin, so it actually misses none of the above functions. Per haps you haven’t found your way around yet?

3

Ronald’s right. Almost everything you’ve asked for already exists in a quite functional and flexible form in Virtualmin.

There is one issue, which seems to be a major sticking point for you, but I’m not sure why you consider it so important. Virtual mail accounts vs. PAM-based mail accounts. I’ve never seen a compelling case for virtual accounts for mail, and it is not something we have any desire to address.

Most virtual account systems I’ve experimented with are an absolute mess; poorly thought out, buggy implementations, and reliant upon needlessly complex additional layers (like relational databases and layers of integration tools to make it all fit together). So, the things you seem to believe they improve upon they actually make dramatically worse. They’re not easier to manage; what could be easier than standard native UNIX accounts for which there are tons of standard tools and everybody agrees on how those accounts work? When you cram users into a non-standard, and complicated database like MySQL, nothing standard works anymore. You don’t gain performance…flatfiles are dramatically faster for anything less than a few tens of thousands of users. You don’t gain security; a no login account is every bit as secure as any virtual account (you don’t worry about Apache having an account, even though it has potentially dangerous permissions).

LDAP is well-supported, if you really want a database holding your users rather than a flat file. But that is still a PAM-based user store (because, again, we think regular users are the right way to do users on UNIX; and virtual users were a side effect of poorly implemented mail infrastructure rather than a brilliant move into the future).

The username format, which seems to be a big part of your argument, is orthogonal to whether the account is virtual or not. UNIX users can be named user@domain.tld. No problem at all. Postfix doesn’t like it, but Virtualmin transparently works around that and you never have to think about it beyond making sure saslauthd is configured correctly as documented in the Email FAQ.

I’d encourage having another look around Virtualmin, since nearly everything being wished for is already well covered. We do, of course, welcome feedback on how those concepts are implemented and how the UI and overall experience can be improved. (But we probably aren’t going to be changing to virtual mail accounts, since I feel so strongly that they’re a bad idea.)

Oh, one more little data point (not a recommendation): qmail support in Virtualmin does include some sort of virtual user support. But I do not recommend it, for all the reasons I mentioned earlier, and the additional reason that qmail is a pretty poor MTA option, without heavy patching, compared to Postfix. I’m merely mentioning that it exists in Virtualmin (just another example of everything under the sun already existing in Virtualmin; you just gotta turn it on, and maybe configure it a little bit).