>-----Original Message----- >From: Jeremy Kitchen [mailto:[EMAIL PROTECTED] >Sent: Friday, May 20, 2005 8:27 AM >To: vchkpw@inter7.com >Subject: Re: [vchkpw] read DB vs. write / update DB - Qmail, Vpopmail >(authvchkpw & Mysql replication), Courier-pop3d > >On Friday 20 May 2005 09:48 am, Shane Metler wrote: >> Hi list, >> >> I have a Qmail cluster running, using Gentoo's patched versions of >> Qmail, vpopmail (using MySQL replication), Courier-imap, and then >> Courier-authlib linked to authvchkpw for IMAP & POP3 authentication. >> >> qmail-1.03 >> vpopmail-5.4.6 >> courier-imap-4.0.1 >> courier-authlib-0.55 >> >> MySQL replication is set up with a remote Master server for >> writes/updates, and a local Slave server for authentication reads. >> >> This setup works fine. MySQL is replicating, SMTP and POP3 >> authentication is working, and all mail delivery is fine ... On the >> surface there are no issues with these mail servers. >> >> But I noticed (while testing POP3 connections) that both the read and >> the write MySQL servers have persistent connections opened up (user: >> vpopsqluser, table: vpopmail ) after checking mail once via POP3. > >all vpopmail processes are short lived. If there is an open mysql >connection >for any reason for more than about 3 seconds, there's a bug. > >I would recommend upgrading to a newer version, as I believe this bug has >been >squashed. > >Then again, I would also recommend removing gentoo's qmail ebuilds and >installing it by hand.. but that's a discussion for another day. > >-Jeremy > >-- >Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, >Inc. > [EMAIL PROTECTED] ++ inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l > kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail > GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED]
I too have seen this behavior. Running vpopmail 5.4.7 with everything built from source. I am still using courier 3.0.8, so I believe this issue to be in vpopmail somewhere, most likely vchkpw. I do not have logging going to the mysql server, so in essence there should be no need to write. It is frustrating to have a cluster built using replication and then still have a single point of failure. If my mysql master goes down for whatever reason, then it doesn't matter how many other hosts I have to handle requests or how solid my file server is, authentication will fail and my users can't get in. I have not seen any notes in the change logs about this being fixed or else I just flat out missed it. Can't say that I have problems with "persistent" connections, however, I would like to see true use of the read/write setup. Would be happy to supply more info. Brian
