Re: [webmin-l] Virtualmin-user in MySQL database store

[Kris D. <kd...@vi...>]

(FWIW:  Given another few years as sysadmin at a small ISP I might well 
have tried out Virtualmin for webhosting;  I had written some tools to 
create sites and manage email users, but many other pieces of the puzzle 
were missing and I never did get quite a few things working for 
webhosting customers as well as for the main ISP customers.  However, 
that small ISP got bought out by a much larger one...  whose systems 
were already split into "webhosting", "legacy email", "main ISP email", 
etc.)

Jamie Cameron wrote:
> On 27/Oct/2011 08:47 Kris Deugau<kd...@vi...>  wrote ..
>> Jamie Cameron wrote:
>>> MySQL support isn't planned currently - the main issue is that Virtualmin
>>> uses have to be Unix users,
>>
>> Is there any underlying reason for this requirement?  A great many other
>> full hosting platforms and homegrown solutions seem to work just fine
>> with their users defined in other ways.
>
> The reason is that mailboxes which are not Unix users cannot make use of Unix
> quotas, login via FTP, use procmail, Usermin and any other service that requires
> running commands or owning files as a regular user.

I can say for sure that quotas and FTP work fine with virtual users that 
have real UIDs but no entry in /etc/passwd (depending on the FTP 
software, anyway).  I'd be surprised if procmail can't be configured to 
cope too.

We actually still use flatfiles to store the user data for our email and 
web services;  they're just separate from /etc/passwd and use UIDs/GIDs 
in the extended 32-bit range (starting at 100000, IIRC).

For mail service, they're also created for specific Postfix data 
sources, and use the hashed cdb database format for the actual live 
files.  At 50K accounts, this *does* show a minor performance benefit 
over potentially scanning a straight flatfile or /etc/passwd, IIRC.

Moving to a full DBMS-backed user table has been on the to-do list for a 
while though;  it would mean changes from our billing/customer database 
backend would show up in near-realtime on the mail system.

> My counter-question is : what is the advantage of storing mailboxes in MySQL?
> If the scalability of /etc/passwd is an issue, LDAP seems like a good solution..

I can't say much about LDAP other than the little I've seen makes it 
look like a minor nightmare to configure and maintain without a 
fullblown GUI tool of some kind.  SQL seems to be simpler, too.

The advantage to not using flatfiles or hash tables is that updates show 
up "right now" (within a few seconds, at least) without having to signal 
the MTA or FTP server.

-kgd