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

[Jamie C. <jca...@we...>]

On 31/Oct/2011 08:08 Kris Deugau <kd...@vi...> wrote ..
> (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.

An MTA or FTP server reload shouldn't be needed to pick up a new user added
to /etc/passwd though - if this is the case on your system, make sure you aren't
running "nscd", which is a caching daemon that stores /etc/passwd in memory for
fast access, but at the expense of making changes slower to become visible..

 - Jamie