Re: [Dovecot] Unbreakable NFS locking issues...
On Nov 20, 2008, at 4:15 AM, Rod Treweek wrote: Hi Timo, Thanks Timo. This is great. I followed your instructions, and sure enough, everything is working as expected now. Thank you very very much. One question I have, What's the advantage of using prefetch? Is this a considerable performance benefit, or is it just more or less another way to do things? Thanks again. With prefetch you're doing a single SQL query. Without prefetch you're doing two. If your SQL server isn't loaded, I doubt it helps much. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Unbreakable NFS locking issues...
Hi all,
I've got an isolated test environment set up now, and am trying to figure
out how to get the index files to populate. So far, I cannot seem to get
them to appear in the /usr/local/dovecot/indexes directory as referenced
below. Here is the sql string:
[EMAIL PROTECTED] /usr/local/etc]# grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location, 143 AS uid,
143 AS gid, concat('*:storage=', floor(quota*1024)) AS quota_rule FROM
mailbox WHERE username = '%u' AND active = '1'
[EMAIL PROTECTED] /usr/local/etc]#
I've got mail working more or less, however the indexes simply will not
appear in the path referenced above. My suspicion has been that this is
where my nfs locking problems are occurring, as the indexes are just not
getting populated. Any ideas? I gather that the cacheing done through the
mysql database is desirable as it would tend to speed things up quite a
bitany ideas on how to pass the index location through the string as
well? Or is this generally regarded as a negligible gain?
Thanks everyone.
-Rod
On Thu, Nov 13, 2008 at 10:22 AM, Rod Treweek [EMAIL PROTECTED] wrote:
I'm also noticing that the INDEX=/usr/local/mail/indexes/ path is
completely emptyshouldn't this get populated if the config is getting
read properly?
On Thu, Nov 13, 2008 at 9:24 AM, Rod Treweek [EMAIL PROTECTED] wrote:
Thanks for the response. I also forgot to mention that this is on FreeBSD
6.3. Not sure if that makes a difference.
On Wed, Nov 12, 2008 at 4:07 PM, Seth Mattinen [EMAIL PROTECTED]wrote:
Rod Treweek wrote:
Yeah, Sorry, still kind of figuring out list protocol. Thanks for the
responses.
I've not built this system, but I've inherited the responsibility of
maintaining it, so I'm still kind of trying to gradually learn about how
everything works together.
I think that the main things are:
fcntl; pretty sure that dotlock is what we should be using, however, I
was
under the impression that lockd would/could deal with the file locking
issues, if it were present on both client and server.
Maybe, maybe not. I'd try dotlock and see if it helps.
~Seth
Re: [Dovecot] Unbreakable NFS locking issues...
On Nov 19, 2008, at 9:01 PM, Rod Treweek wrote:
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/
mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=',
floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
The userdb_* fields here are used only if you're using prefetch userdb.
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as
home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location,
mail_location field is ignored. It's called mail, which you're also
returning without the :INDEX.
So I guess you're 1) not using prefetch userdb so the userdb_mail in
password_query doesn't get used and 2) the mail field without :INDEX
is used from user_query.
I've got mail working more or less, however the indexes simply will
not
appear in the path referenced above. My suspicion has been that this
is
where my nfs locking problems are occurring, as the indexes are
just not
getting populated. Any ideas? I gather that the cacheing done
through the
mysql database is desirable as it would tend to speed things up
quite a
bitany ideas on how to pass the index location through the
string as
well? Or is this generally regarded as a negligible gain?
What caching? I'm not really sure what you're asking here.
PGP.sig
Description: This is a digitally signed message part
Re: [Dovecot] Unbreakable NFS locking issues...
Hi Timo,
Thanks Timo. This is great. I followed your instructions, and sure enough,
everything is working as expected now. Thank you very very much. One
question I have, What's the advantage of using prefetch? Is this a
considerable performance benefit, or is it just more or less another way to
do things? Thanks again.
-Rod
On Wed, Nov 19, 2008 at 4:54 PM, Timo Sirainen [EMAIL PROTECTED] wrote:
On Nov 19, 2008, at 9:01 PM, Rod Treweek wrote:
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
The userdb_* fields here are used only if you're using prefetch userdb.
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location,
mail_location field is ignored. It's called mail, which you're also
returning without the :INDEX.
So I guess you're 1) not using prefetch userdb so the userdb_mail in
password_query doesn't get used and 2) the mail field without :INDEX is
used from user_query.
I've got mail working more or less, however the indexes simply will not
appear in the path referenced above. My suspicion has been that this is
where my nfs locking problems are occurring, as the indexes are just not
getting populated. Any ideas? I gather that the cacheing done through
the
mysql database is desirable as it would tend to speed things up quite a
bitany ideas on how to pass the index location through the string as
well? Or is this generally regarded as a negligible gain?
What caching? I'm not really sure what you're asking here.
Re: [Dovecot] Unbreakable NFS locking issues...
Thanks for the response. I also forgot to mention that this is on FreeBSD 6.3. Not sure if that makes a difference. On Wed, Nov 12, 2008 at 4:07 PM, Seth Mattinen [EMAIL PROTECTED] wrote: Rod Treweek wrote: Yeah, Sorry, still kind of figuring out list protocol. Thanks for the responses. I've not built this system, but I've inherited the responsibility of maintaining it, so I'm still kind of trying to gradually learn about how everything works together. I think that the main things are: fcntl; pretty sure that dotlock is what we should be using, however, I was under the impression that lockd would/could deal with the file locking issues, if it were present on both client and server. Maybe, maybe not. I'd try dotlock and see if it helps. ~Seth
Re: [Dovecot] Unbreakable NFS locking issues...
I'm also noticing that the INDEX=/usr/local/mail/indexes/ path is completely emptyshouldn't this get populated if the config is getting read properly? On Thu, Nov 13, 2008 at 9:24 AM, Rod Treweek [EMAIL PROTECTED] wrote: Thanks for the response. I also forgot to mention that this is on FreeBSD 6.3. Not sure if that makes a difference. On Wed, Nov 12, 2008 at 4:07 PM, Seth Mattinen [EMAIL PROTECTED] wrote: Rod Treweek wrote: Yeah, Sorry, still kind of figuring out list protocol. Thanks for the responses. I've not built this system, but I've inherited the responsibility of maintaining it, so I'm still kind of trying to gradually learn about how everything works together. I think that the main things are: fcntl; pretty sure that dotlock is what we should be using, however, I was under the impression that lockd would/could deal with the file locking issues, if it were present on both client and server. Maybe, maybe not. I'd try dotlock and see if it helps. ~Seth
Re: [Dovecot] Unbreakable NFS locking issues...
Like you said before, the SQL user_query is overriding mail_location setting completely. On Nov 13, 2008, at 8:22 PM, Rod Treweek wrote: I'm also noticing that the INDEX=/usr/local/mail/indexes/ path is completely emptyshouldn't this get populated if the config is getting read properly? On Thu, Nov 13, 2008 at 9:24 AM, Rod Treweek [EMAIL PROTECTED] wrote: Thanks for the response. I also forgot to mention that this is on FreeBSD 6.3. Not sure if that makes a difference. On Wed, Nov 12, 2008 at 4:07 PM, Seth Mattinen [EMAIL PROTECTED] wrote: Rod Treweek wrote: Yeah, Sorry, still kind of figuring out list protocol. Thanks for the responses. I've not built this system, but I've inherited the responsibility of maintaining it, so I'm still kind of trying to gradually learn about how everything works together. I think that the main things are: fcntl; pretty sure that dotlock is what we should be using, however, I was under the impression that lockd would/could deal with the file locking issues, if it were present on both client and server. Maybe, maybe not. I'd try dotlock and see if it helps. ~Seth PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Unbreakable NFS locking issues...
Rod Treweek wrote: Yeah, Sorry, still kind of figuring out list protocol. Thanks for the responses. I've not built this system, but I've inherited the responsibility of maintaining it, so I'm still kind of trying to gradually learn about how everything works together. I think that the main things are: fcntl; pretty sure that dotlock is what we should be using, however, I was under the impression that lockd would/could deal with the file locking issues, if it were present on both client and server. Maybe, maybe not. I'd try dotlock and see if it helps. ~Seth
Re: [Dovecot] Unbreakable NFS locking issues...
Firstly, posting the same message with a slightly modified subject wont get you any answers any sooner, please refrain from doing this, it only gives you a bad name and may have the opposite affect to one you desire. On Tue, 2008-11-11 at 10:06, Rod Treweek wrote: Hello All, We are struggling to find a solution to a problem we are encountering with a load-balanced email setup. Currently, we have a Coyote loadbalancer, and 3 Postfix/Dovecot nodes that then get their information from a mysql database. The problem is that after a couple weeks, we start seeing NFS locking issues occur, which then takes email completely down, requiring a site visit to basically do an interactive mode reboot to shut off NFS so that we can remount the filesystem again. We have our mailstore on an Aberdeen NAS which is accessed over NFS v. 4. Not seen this before, but we use Foundry LB's and NetApp filers. Coyote Is BSD based isn't it... How is your setup, you are not running the NFS mounts through the LB as well are you? I would hope they are on a separate private LAN Dovecot version 1.1.2 Generally when lodging requests for help, it pays to use the latest version of software, 1.1.2 is old. Here's the relevant mysql string: If the queries work at all, there's nothing wrong with them. mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexes/%d/%1n/%n mbox over NFS ? That is asking for trouble, mbox is *not* NFS safe, you are best changing to maildir which is. Cheers
Re: [Dovecot] Unbreakable NFS locking issues...
Sounds like an issue with nfs 4 to me? We're running nfs3 very happily
no issues like this have happened. I don't see that running nfs4 offers
many advantages over v3 for the email workload.
Mark
--
Mark Zealey -- Shared Hosting Team Leader
Product Development * Webfusion
123-reg.co.uk, webfusion.co.uk, donhost.co.uk, supanames.co.uk
This mail is subject to http://www.gxn.net/disclaimer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Rod Treweek
Sent: 11 November 2008 00:07
To: dovecot@dovecot.org
Cc: Tait Grove
Subject: [Dovecot] Unbreakable NFS locking issues...
Hello All,
We are struggling to find a solution to a problem we are
encountering
with a load-balanced email setup. Currently, we have a Coyote
loadbalancer,
and 3 Postfix/Dovecot nodes that then get their information
from a mysql
database. The problem is that after a couple weeks, we start
seeing NFS
locking issues occur, which then takes email completely down,
requiring a
site visit to basically do an interactive mode reboot to shut
off NFS so
that we can remount the filesystem again. We have our mailstore on an
Aberdeen NAS which is accessed over NFS v. 4.
Dovecot version 1.1.2
Here's the relevant mysql string:
grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
connect = host=X.X.X.X dbname=Something user=Something
password=Something
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/', maildir) as userdb_home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as
userdb_mail, 143 as
userdb_uid, 143 as userdb_gid, concat('*:bytes=',
floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/',
maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as
maildir, 143 AS uid,
143 AS gid, concat('*:bytes=', floor(quota*1024)) AS
quota_rule FROM mailbox
WHERE username = '%u' AND active = '1'
And here's what our configuration is on each of the nodes:
dovecot -n
# 1.1.2: /usr/local/etc/dovecot.conf
protocols: imap pop3
ssl_ca_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_cert_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_key_file: /usr/local/etc/dovecot/certs/tdpserver.key
ssl_parameters_regenerate: 0
ssl_cipher_list: ALL:!LOW:!SSLv2
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: postfix
login_greeting: Something witty here..
login_process_per_connection: no
login_max_connections: 512
max_mail_processes: 2048
mail_max_userip_connections: 50
verbose_proctitle: yes
first_valid_uid: 69
last_valid_uid: 500
first_valid_gid: 69
last_valid_gid: 500
mail_access_groups: postfix
mail_privileged_group: postfix
mail_location:
mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexe
s/%d/%1n/%n
mmap_disable: yes
dotlock_use_excl: no
mail_nfs_storage: yes
mail_nfs_index: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
mechanisms: login plain
user: dovecot
passdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
userdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 384
user: dovecot
group: dovecot
plugin:
quota: dict:user::proxy::quota
imap_quota: dict:user::proxy::quota
quota_rule: *:storage=528576
dict:
quota: mysql:/usr/local/etc/dovecot/dovecot-dict-quota.conf
Any help you can offer is greatly, greatly appreciated, as
well as opinions
on any other 'validated' postfix/dovecot email enterprise
design solutions.
Thanks Very Much In Advance,
R.T
Re: [Dovecot] Unbreakable NFS locking issues...
Thank you very much for your reply, Noel, Firstly, posting the same message with a slightly modified subject wont get you any answers any sooner, please refrain from doing this, it only gives you a bad name and may have the opposite affect to one you desire. Yeah, typical rookie move by posting twice...didn't see my post, so went into the dovecot list setting for my account to adjust it to get a confirmation, and then sent the message again. Really stupid, and I apologize. Generally when lodging requests for help, it pays to use the latest version of software, 1.1.2 is old. Definitely will be doing this, but just wanted to get some information on the locking issue first. mbox over NFS ? That is asking for trouble, mbox is *not* NFS safe, you are best changing to maildir which is. Yeah, this is definitely wrong. Everything is in maildir format on the mailstore. Question is, why would this even be working at all if it's wrong in the config? The sql connection string has maildir defined in it, so, I'm wondering if that might explain it. Also, the indexes are not local which I believe has been the recommendation. Also Lockd appears to be enabled on both sides. -Rod Firstly, posting the same message with a slightly modified subject wont get you any answers any sooner, please refrain from doing this, it only gives you a bad name and may have the opposite affect to one you desire. On Tue, Nov 11, 2008 at 4:13 AM, Noel Butler [EMAIL PROTECTED] wrote: Firstly, posting the same message with a slightly modified subject wont get you any answers any sooner, please refrain from doing this, it only gives you a bad name and may have the opposite affect to one you desire. On Tue, 2008-11-11 at 10:06, Rod Treweek wrote: Hello All, We are struggling to find a solution to a problem we are encountering with a load-balanced email setup. Currently, we have a Coyote loadbalancer, and 3 Postfix/Dovecot nodes that then get their information from a mysql database. The problem is that after a couple weeks, we start seeing NFS locking issues occur, which then takes email completely down, requiring a site visit to basically do an interactive mode reboot to shut off NFS so that we can remount the filesystem again. We have our mailstore on an Aberdeen NAS which is accessed over NFS v. 4. Not seen this before, but we use Foundry LB's and NetApp filers. Coyote Is BSD based isn't it... How is your setup, you are not running the NFS mounts through the LB as well are you? I would hope they are on a separate private LAN Dovecot version 1.1.2 Generally when lodging requests for help, it pays to use the latest version of software, 1.1.2 is old. Here's the relevant mysql string: If the queries work at all, there's nothing wrong with them. mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexes/%d/%1n/%n mbox over NFS ? That is asking for trouble, mbox is *not* NFS safe, you are best changing to maildir which is. Cheers Thank you very much for your reply, Noel, Yeah, typical rookie move by posting twice...didn't see my post, so went into the dovecot list setting for my account to adjust it to get a confirmation, and then sent the message again. Really stupid, and I apologize.
Re: [Dovecot] Unbreakable NFS locking issues...
Well, you just posted your message three times... Rod Treweek wrote: Yeah, typical rookie move by posting twice...didn't see my post, so went into the dovecot list setting for my account to adjust it to get a confirmation, and then sent the message again. Really stupid, and I apologize. It's a gmail feature: you do not see your own posts to a list, at least not until you get a reply to them. -- Bell Labs Unix -- Reach out and grep someone. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb
[Dovecot] Unbreakable NFS locking issues...
Hello All,
We are struggling to find a solution to a problem we are encountering
with a load-balanced email setup. Currently, we have a Coyote loadbalancer,
and 3 Postfix/Dovecot nodes that then get their information from a mysql
database. The problem is that after a couple weeks, we start seeing NFS
locking issues occur, which then takes email completely down, requiring a
site visit to basically do an interactive mode reboot to shut off NFS so
that we can remount the filesystem again. We have our mailstore on an
Aberdeen NAS which is accessed over NFS v. 4.
Dovecot version 1.1.2
Here's the relevant mysql string:
grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
connect = host=X.X.X.X dbname=Something user=Something password=Something
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/', maildir) as userdb_home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as userdb_mail, 143 as
userdb_uid, 143 as userdb_gid, concat('*:bytes=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as maildir, 143 AS uid,
143 AS gid, concat('*:bytes=', floor(quota*1024)) AS quota_rule FROM mailbox
WHERE username = '%u' AND active = '1'
And here's what our configuration is on each of the nodes:
dovecot -n
# 1.1.2: /usr/local/etc/dovecot.conf
protocols: imap pop3
ssl_ca_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_cert_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_key_file: /usr/local/etc/dovecot/certs/tdpserver.key
ssl_parameters_regenerate: 0
ssl_cipher_list: ALL:!LOW:!SSLv2
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: postfix
login_greeting: Something witty here..
login_process_per_connection: no
login_max_connections: 512
max_mail_processes: 2048
mail_max_userip_connections: 50
verbose_proctitle: yes
first_valid_uid: 69
last_valid_uid: 500
first_valid_gid: 69
last_valid_gid: 500
mail_access_groups: postfix
mail_privileged_group: postfix
mail_location:
mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexes/%d/%1n/%n
mmap_disable: yes
dotlock_use_excl: no
mail_nfs_storage: yes
mail_nfs_index: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
mechanisms: login plain
user: dovecot
passdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
userdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 384
user: dovecot
group: dovecot
plugin:
quota: dict:user::proxy::quota
imap_quota: dict:user::proxy::quota
quota_rule: *:storage=528576
dict:
quota: mysql:/usr/local/etc/dovecot/dovecot-dict-quota.conf
Any help you can offer is greatly, greatly appreciated, as well as opinions
on any other 'validated' postfix/dovecot email enterprise design solutions.
Thanks Very Much In Advance,
R.T
