[vchkpw] Further thoughts on my localrelay patch
I had no idea I'd be opening such a big can of worms when I posted my patch, though thankfully all of the feedback I've gotten has been polite, constructive and coherent even if it's been negative :) As I see it, this patch may fill a need that still exists, but it probably needs a little more work before it hits prime time. First off, lets (re-)examine how Vpopmail handles things without my patch, looking at it from (yet) another direction: Case #1: No auth-before-smtp (POP or IMAP, as opposed to SMTP AUTH) roaming users - tcpserver cdb is statically built. Case #2: Roaming auth-before-smtp (POP or IMAP) is used for all IPs not statically configured in the tcpserver cdb (that is, all static addresses are configured to either allow relaying or deny the connection). Case #3: Roaming auth-before-smtp (POP or IMAP) is used and some or all of the static IPs in tcpserver cdb are allowed to be overridden by pre-authenticating via a non-SMTP method. Case #1 can occur in several different cases (--disable-roaming-users, --disable-rebuild-tcpserver-file, or just not using the dynamic tcpserver file). In any case, my patch is (mostly) irrelevant, as unless you're just nor using the dynamic tcpserver file, the code to update the CDB is not even compiled in, and if that's the case you should reconfigure Vpopmail appropriately in any case. Case #2 is where my patch is most useful: you have specific, statically authorized (or denied) relay IPs that you don't want to take the time to update the cdb for, but need to dynamically allow auth'd clients to relay (for whatever reason - I agree that SMTP AUTH is preferred, but some people still need to support auth-before-smtp for legacy reasons, and I'm not one of thos people who feels that you should eliminate functionality just because you want to discourage its use, unless it's actually broken, violates some part of the official spec, or is actually dangerous. Yes, I know it's a bad idea, and if you want to deprecate it and mark it for elimination 6-12 months from now, that's OK too. But don't just yank it without warning). Also, my patch is pretty much a requirement if you're using webmail, so that the webmail server doesn't keep getting updated in the CDB with every page access... Case #3 is the difficult one - one which my patch doesn't adequately allow for at this time. There has been some discussion about how to dynamically allow for different tcpserver flags to be applied on authentication, rather than the default 'RELAYCLIENT=,RBLSMTPD=', which I think is a good idea. Currently, if you have a static IP address range set to deny a connection, Vpopmail allows clients who have pre-authenticated via POP or IMAP to connect via SMTP for the auth timeout period. Combined with custom tcpserver flags, this can be used to allow connections without necessarily automatically enabling relaying from otherwise denied IPs. It also allows RBL bypassing on authenticated IP addresses that would otherwise still have to bypass the RBL (Note - I don't use rblsmtpd at this time, so I don't know how well it really works. If you want to school me, that's fine, but please either start a new thread or take it offlist - thanks). I believe that I can adjust my patch to do this, but it will take a little thought and mapping out the possibilities to do it both correctly and efficiently. I'll probably try and tackle it this week, but no guarantees. Also, please note that this usage actually improves the standing of auth-before-smtp (if RELAYCLIENT isn't set automatically) by limiting SMTP traffic from non-approved IP addresses to known authorized users' IPs, while still requiring SMTP AUTH to relay mail (which eliminates the possibility of an IP address being hijacked after a legitimate user disconnects but before the open smtp entry expires). So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole roaming users functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT= functionality is deprecated, and schedule it for removal 6-12 months down the line. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users=RELAYCLIENT=\\,RBLSMTPD=\\', but once #1 is finalized the RELAYCLIENT part would be removed. 3) Allow the roaming tcpserver flags to be dynamically modified using either a configuration entry in a file (possibly a a second comment in the tcp.smtp file like my STATICUPDATE tweak) or an environment variable (which could be passed via tcpserver to the POP/IMAP service, coming full circle :)). 4) Implement my localrelay functionality with 2 enhancements: a) Recognize the IP address of 0.0.0.0 or NULL and skip the CDB update altogether (I though of this this morning and have already implemented it). b) Provide some sort of tcpserver flag (e.g., 'UPDATESTATIC=') on
[vchkpw] A vpopmail farm/NFS framework?
Anyone aware of a particularly good discussion of building a farm of vpopmail compliant front-end machines for user access to a central file server via NFS on linux? I'm concerned that I haven't thought through issues in how to properly account for webmail/IMAP, MySQL for storing smtp-auth IPs for relay control, and a few other topics. Googling hasn't yielded much but a few threads from the *BSD folks. My tentative thinking is 2+ front end machines that draw from a common/identical configuration that provide the client interfaces via: - SMTPd, smtp-auth, pop3d, send, IMAPd, anti-virus, anti-spam, webmail (apache + squirrelmail) - CHKUSER talking to the backend server - Local /var/qmail/ (typical) install for queue, bin, supervise, etc... possibly taken from the central, backend server via nightly rsync where needed. - NFS client communication to the central backend server A single, large server provides the backend services to these machines for: - MySQL server (for smtp-auth tracking, squirrelmail prefs/abook/sigs, users, domains) - NFS Service providing Client-mounted folder(s) for the domains' email. Any special compile/configuration suggestions to support this that I wouldn't normally use on a single-box solution? Should the client machines be logging to their local drives, to an NFS mounted drive, or log over the network (like syslog-ng, even possible with multilog???) to any particular host? Any administrative issues that grow through this distributed model? I'm thinking about whether vqadmin or qmailadmin will continue to function correctly when run from any of the farm machines? Would I just allow one admin machine for vqadmin/qmailadmin to prevent issues? Any risks of data collision/overlap or other issues that might surface with this multi-server model? Central MySQL should solve most of this, right? THANKS! D.
Re: [vchkpw] A vpopmail farm/NFS framework?
Dave Richardson wrote: Anyone aware of a particularly good discussion of building a farm of vpopmail compliant front-end machines for user access to a central file server via NFS on linux? I'm concerned that I haven't thought through issues in how to properly account for webmail/IMAP, MySQL for storing smtp-auth IPs for relay control, and a few other topics. Googling hasn't yielded much but a few threads from the *BSD folks. My tentative thinking is 2+ front end machines that draw from a common/identical configuration that provide the client interfaces via: - SMTPd, smtp-auth, pop3d, send, IMAPd, anti-virus, anti-spam, webmail (apache + squirrelmail) - CHKUSER talking to the backend server - Local /var/qmail/ (typical) install for queue, bin, supervise, etc... possibly taken from the central, backend server via nightly rsync where needed. - NFS client communication to the central backend server We use a large MySQL/NFS machine for this here. We have each front-end server (toaster/ecluster/whatever) connecting to a common MySQL DB. We also use a self authored management program to modify vpopmail DB entries. Currently we NFS mount a common directory on each front-end machine. That directory contains the following; domains, qmail-control, webmail. We then use symlinks to map the required directories on each front-end server. front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Make sure your NFS mount is up and operational before starting qmail. A single, large server provides the backend services to these machines for: - MySQL server (for smtp-auth tracking, squirrelmail prefs/abook/sigs, users, domains) - NFS Service providing Client-mounted folder(s) for the domains' email. Any special compile/configuration suggestions to support this that I wouldn't normally use on a single-box solution? Should the client machines be logging to their local drives, to an NFS mounted drive, or log over the network (like syslog-ng, even possible with multilog???) to any particular host? We use local logging, I would advise against NFS logging, it was iffy for us. Never had a need to investigate logging over the network. We only have three front-end machines so it is easy enough to log into the offending machines and tail/grep the logs. Headers will always tell you which machine to investigate. Any administrative issues that grow through this distributed model? I'm thinking about whether vqadmin or qmailadmin will continue to function correctly when run from any of the farm machines? Would I just allow one admin machine for vqadmin/qmailadmin to prevent issues? We use neither. Any risks of data collision/overlap or other issues that might surface with this multi-server model? Central MySQL should solve most of this, right? THANKS! Three years up and running, 50,000 delivered messages a day. No problems ever with lost mail or failures. Clients still scream you lost my message and I prove them wrong each time, but they still try. I hope that helps. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: [vchkpw] A vpopmail farm/NFS framework?
DAve wrote: Sorry, had more thoughts... Dave Richardson wrote: Anyone aware of a particularly good discussion of building a farm of vpopmail compliant front-end machines for user access to a central file server via NFS on linux? I'm concerned that I haven't thought through issues in how to properly account for webmail/IMAP, MySQL for storing smtp-auth IPs for relay control, and a few other topics. Googling hasn't yielded much but a few threads from the *BSD folks. My tentative thinking is 2+ front end machines that draw from a common/identical configuration that provide the client interfaces via: - SMTPd, smtp-auth, pop3d, send, IMAPd, anti-virus, anti-spam, webmail (apache + squirrelmail) I would advise using the local supervise scripts. They should change so little that running them from a mounted dir really isn't needed. In our case we wanted them local. For example, exec /usr/local/bin/softlimit -m 200 \ /usr/local/bin/tcpserver -v -P -R -h -l ecluster4.tls.net -x \ /var/qmail/control/tcp.smtp.cdb -c $MAXSMTPD \ -u $QMAILDUID -g $NOFILESGID 10.0.241.134 25 \ /usr/local/bin/fixcrio /var/qmail/bin/qmail-smtpd 21 Putting the host name and the IP in the run file will make your headers more informative. Most How-Tos don't show that. You could script a solution I'm sure if you choose to share run files. As far as smtp-auth IPs, we offer smtp to only the networks we own for outbound mail, we make everyone else us smtp-auth. Our IPs don't change often enough to warrant sharing tcp.cdb, though we configured it that way from the beginning. Using smtp-auth instead of relay IP solutions means we don't have to modify and rebuild cdb files all day. Keep in mind that changing a shared file will make all servers see the changes immediately, for better or for worse. It's a balancing act. Risk vs Convenience. - CHKUSER talking to the backend server CHKUSER doesn't care, there is nothing special to do. - Local /var/qmail/ (typical) install for queue, bin, supervise, etc... possibly taken from the central, backend server via nightly rsync where needed. Run a local queue, trust me on this. /var/qmail/control is really all you need to share, and actually you could get by without it. We found data in there changes so little it really isn't an advantage having it on NFS or scripting a solution via rsync. DAve - NFS client communication to the central backend server We use a large MySQL/NFS machine for this here. We have each front-end server (toaster/ecluster/whatever) connecting to a common MySQL DB. We also use a self authored management program to modify vpopmail DB entries. Currently we NFS mount a common directory on each front-end machine. That directory contains the following; domains, qmail-control, webmail. We then use symlinks to map the required directories on each front-end server. front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Make sure your NFS mount is up and operational before starting qmail. A single, large server provides the backend services to these machines for: - MySQL server (for smtp-auth tracking, squirrelmail prefs/abook/sigs, users, domains) - NFS Service providing Client-mounted folder(s) for the domains' email. Any special compile/configuration suggestions to support this that I wouldn't normally use on a single-box solution? Should the client machines be logging to their local drives, to an NFS mounted drive, or log over the network (like syslog-ng, even possible with multilog???) to any particular host? We use local logging, I would advise against NFS logging, it was iffy for us. Never had a need to investigate logging over the network. We only have three front-end machines so it is easy enough to log into the offending machines and tail/grep the logs. Headers will always tell you which machine to investigate. Any administrative issues that grow through this distributed model? I'm thinking about whether vqadmin or qmailadmin will continue to function correctly when run from any of the farm machines? Would I just allow one admin machine for vqadmin/qmailadmin to prevent issues? We use neither. Any risks of data collision/overlap or other issues that might surface with this multi-server model? Central MySQL should solve most of this, right? THANKS! Three years up and running, 50,000 delivered messages a day. No problems ever with lost mail or failures. Clients still scream you lost my message and I prove them wrong each time, but they still try. I hope that helps. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans?
Re: [vchkpw] A vpopmail farm/NFS framework?
On Jan 2, 2007, at 1:37 PM, DAve wrote: front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Don't forget /var/qmail/users as well. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] A vpopmail farm/NFS framework?
Tom Collins wrote: On Jan 2, 2007, at 1:37 PM, DAve wrote: front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Don't forget /var/qmail/users as well. -- Tom Collins - [EMAIL PROTECTED] Thank you, that is a big whoops on my part. I actually have the following qmail dirs mapped. alias - /shared/qmail-alias control - /shared/qmail-control users - /shared/qmail-users It has been that long since I had to log in and look at that directory ;^) DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: [vchkpw] A vpopmail farm/NFS framework?
Anyone aware of a particularly good discussion of building a farm of vpopmail compliant front-end machines for user access to a central file server via NFS on linux? I'm concerned that I haven't thought through issues in how to properly account for webmail/IMAP, MySQL for storing smtp-auth IPs for relay control, and a few other topics. Googling hasn't yielded much but a few threads from the *BSD folks. I was involved in setting up/administering a rather large cluster when I was consulting for a mid-sized college, which is probably bigger than you want to get into, but I'll share a few items: My tentative thinking is 2+ front end machines that draw from a common/identical configuration that provide the client interfaces via: - SMTPd, smtp-auth, pop3d, send, IMAPd, anti-virus, anti-spam, webmail (apache + squirrelmail) - CHKUSER talking to the backend server - Local /var/qmail/ (typical) install for queue, bin, supervise, etc... possibly taken from the central, backend server via nightly rsync where needed. - NFS client communication to the central backend server A single, large server provides the backend services to these machines for: - MySQL server (for smtp-auth tracking, squirrelmail prefs/abook/sigs, users, domains) - NFS Service providing Client-mounted folder(s) for the domains' email. We had local installs of qmail/vpopmail/etc. on all of the front-end servers, and then nfs-mounted certain shared things from the back-end instead of the local folders. Originally we nfs-mounted them directly, but network problems with nested NFS mounts led us to mount them in a separate tree and use symlinks - e.g. /var/qmail/control was symlinked /mnt/qmail-control, which in turn nfs-mounted backend:/export/qmail/control. We imported the following from the back-end server: /var/qmail/control /var/qmail/users /var/vpopmail/domains /var/vpopmail/domains/primary domain/hash dirs Let me explain the last bit - we hosted several domains on the cluster, but only the primary one was big, so we left the rest on a single centralized FS. We then created each hash dir (0-9,A-Z,a-z) as a separate FS and exported them individually - the speed of not having anywhere near as many emails on each FS made up for the NFS overhead. It originally was all one FS, then we went to multiple FSs on a single server, and eventually we migrated to 4 back-end servers each exporting a quarter of the hash dirs. We also installed vpopmail and POP/IMAP servers on the back end, and used perdition on the front ends to have the POP/IMAP connections go directly to the correct back-end server whenever possible. We kept one server with all the NFS mounts as a fallback for POP/IMAP, but it was rarely used. One other thing we did was a perl script with a DB back end indicating which NFS mount came from where - it allowed us to do some shuffling as needed, and also got around the problem of trying to mount the NFS shares before the network ports had come up, something that happens a lot with certain combinations of NICs and switches... For inbound mail we still needed the NFS mounts, although I was working on and eventually testing a method of doing distributed SMTP as well, using the front-end systems as a queue and figuring out how to send it to the correct back-end, also running qmail/vpopmail. As far as I know if never left testing after I moved on, but it worked AFAIK. For the SQL, we used one of the back-ends as a master and all of the other systems (front- and back-end) as slaves, then had vpopmail do all reads from the local system and write to the master, which then sent updates. IIRC there was a weekly script early sunday morning that tarred up the master DB and refreshed the slaves to clean up the binlogs as well. Other than webmail, every front-end system could do anything, and we routinely would change the DNS entries to have different servers provide different services so we could take systems offline for maintenance or clear out large queues. Webmail was only on a couple of systems, one live and one for testing. If you're going to use webmail, a caching IMAP proxy is a must - it boosts webmail performance by a ton. Oh, put your NFS traffic on a separate physical network from your public communications - we used a second interface running at gigabit speed on RFC1918 address space for the front-end to back-end communications, which helped a lot when the public connections were being stressed. Any special compile/configuration suggestions to support this that I wouldn't normally use on a single-box solution? Should the client machines be logging to their local drives, to an NFS mounted drive, or log over the network (like syslog-ng, even possible with multilog???) to any particular host? We logged locally - we were looking at a way to get everything aggregated as well, but never really found a good answer. In any case, I wrote a patch to qmail that adds the machine name to the received
Re: [vchkpw] A vpopmail farm/NFS framework?
DAve wrote: Tom Collins wrote: On Jan 2, 2007, at 1:37 PM, DAve wrote: front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Don't forget /var/qmail/users as well. -- Tom Collins - [EMAIL PROTECTED] Thank you, that is a big whoops on my part. I actually have the following qmail dirs mapped. alias - /shared/qmail-alias control - /shared/qmail-control users - /shared/qmail-users It has been that long since I had to log in and look at that directory ;^) DAve DAve, Tom, Joshua; You have my sincerest thanks for your thoughtful and VERY useful contributions! Thank you! Dave.
Re: [vchkpw] A vpopmail farm/NFS framework?
Dave Richardson wrote: DAve wrote: Tom Collins wrote: On Jan 2, 2007, at 1:37 PM, DAve wrote: front-end (target)- NFS (source) --- /home/vpopmail/domains - /shared/vdomains /var/qmail/control - /shared/qmail-control /usr/local/www - /shared/webmail /var/tmp - /shared/webmail-sessions Don't forget /var/qmail/users as well. -- Tom Collins - [EMAIL PROTECTED] Thank you, that is a big whoops on my part. I actually have the following qmail dirs mapped. alias - /shared/qmail-alias control - /shared/qmail-control users - /shared/qmail-users It has been that long since I had to log in and look at that directory ;^) DAve DAve, Tom, Joshua; You have my sincerest thanks for your thoughtful and VERY useful contributions! Thank you! Dave. use the onchange functionality in vpopmail 5.4.18 or (5.4.17+onchange patch) to push control file updates around...plus whatever other crap you want to tack onto certain api calls. check out README.onchange in the 5.4.18 source dist for notes on that. also refer to these pages: http://qmail.jms1.net/mailhub.shtml http://shupp.org/maps/ispcluster.html -- aichains
[vchkpw] unsubscribe vchkpw
unsubscribe Sent via the WebMail system at mail.norristechs.net
Re: [vchkpw] unsubscribe vchkpw
On Tue, 2007-01-02 at 19:06 -0700, Jeff Norris wrote: unsubscribe Next time, check the headers for the unsub address. Try these instead... List-Post: mailto:vchkpw@inter7.com List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED]
