Re: [vchkpw] Re: vpopmail FHS compliance
On Sat, March 14, 2009 10:30 am, aledr wrote:
On Sat, Mar 14, 2009 at 2:03 PM, Matt Brookings m...@inter7.com wrote:
*snip*
We've had the same sort of concerns regarding FHS compliance (and
eas-of-package-building) for some time, and have had a set of patches
within our RPM that have proved effective for us. I have not tested them
with 5.4.28, however... I'd be grateful to anyone who could do (especially
in isolation from our other patches).
They might be useful for others on the list as well. Details below.
Regards,
Japheth Cleaver
# Instead of vpopmail's home directory, use standard FHS locations:
# bindir, localstatedir, and sysconfdir for files (patches configure.in
and code)
Patch1: vpopmail.use-std-locations.5.4.19.patch
# Modify makefile to deal with our above changes (patches Makefile.am)
Patch2: vpopmail.use-std-locations-makefile.patch
# Documentation changes for patches 1 and 2
Patch3: vpopmail.use-std-locations-documentation.patch
# Make vpopmail's configure rpmbuild-friendly
vpopmail.no-root-needed.patch
# Don't verify that the qmail binaries are actually installed
# at configure time
vpopmail.configure-no-qmail-needed.patch
# Same goes for tcpserver/tcprules
vpopmail.configure-no-tcprules-needed.patch
# Look in /usr/{s}bin before /usr/local or {qmailHome}/bin when finding
# tcprules and qmail binaries
vpopmail.configure-search-paths.patch
# Ensure that all checks for libs are compatible with x86_64 (/usr/lib64)
Patch11: vpopmail.x86_64libs.patch
# Why are mysql libs being checked using the same variable as libdir?
Patch12: vpopmail.sanemysqllibs.patch
!DSPAM:49c00f8e32685742672204!
vpopmail.use-std-locations.5.4.19.patch
Description: Binary data
vpopmail.use-std-locations-makefile.patch
Description: Binary data
vpopmail.use-std-locations-documentation.patch
Description: Binary data
vpopmail.no-root-needed.patch
Description: Binary data
vpopmail.configure-no-qmail-needed.patch
Description: Binary data
vpopmail.configure-no-tcprules-needed.patch
Description: Binary data
vpopmail.configure-search-paths.patch
Description: Binary data
vpopmail.x86_64libs.patch
Description: Binary data
vpopmail.sanemysqllibs.patch
Description: Binary data
[vchkpw] vdeluser isCatchall mysql segfault (was Re: [vchkpw] Decided to make the plunge today on late version of vpopmail)
Hi Steve,
i think the problem is related to something i posted some days ago but
without any answer.
Look at the post :
Re: [vchkpw] vdeluser segfault posted on 19/08/2007 be my answering
to a previous post.
Let me know if it is the case.
Bye,
Marcello
Steve Cole wrote:
On two (low volume) machines with vpopmail interfaced with mysql as the
data
store, it seemed to work successfully. I updated the database schema
with no
issues. This is with v5.4.21
However, when I do a vdeluser on either machine, the program
segfaults. On
both systems.
I tried various things like making sure my LDFLAGS= and CFLAGS=-O
only to
be sure it wasn't a compiler issue, without luck.
So, to be clear, this is on two Debian Etch machines with GCC 4.1.1-15
and
MySQL 5.0.32-7etch1 installed.
Going back to 5.4.17 seemed to be no issue at all and of course, it
works as
expected.
I would concur. From a cursory look at the logic, I don't see how this
really works when using MySQL aliases. I commented out the entire catchall
check when moving to 5.4.19 simply to keep things working.
Regards,
-jc
--- vpopmail.c.orig 2007-08-23 16:46:31.0 -0700
+++ vpopmail.c 2007-08-23 17:03:51.0 -0700
@@ -1733,9 +1733,9 @@
}
/* Make sure we are not the email address of the catchall account */
- if ( isCatchall( user, domain, Dir )) {
-return(VA_CANNOT_DELETE_CATCHALL);
-}
+ // if ( isCatchall( user, domain, Dir )) {
+ // return(VA_CANNOT_DELETE_CATCHALL);
+ // }
#ifdef ONCHANGE_SCRIPT
/* tell other programs that data has changed */
Re: [vchkpw] Vpopmail with Clamd
At 08:57 AM 8/25/2004, Juan Enciso Condeña wrote: Is there a software able of use .qmail-default file for scanning viruses using clamd? I don't want use qmail-scanner. I only saw that spamc work with vpopmail. I couldn't find any, and so wrote my own that does something similar to that :) Solution we used: 1) Patch vdelivermail to, upon finding a BLAH environment variable, leave the message in Maildir/tmp and run an external program specified in BLAH a la the QMQ patch. (We call this vrecordmail). Several arguments are given to BLAH: the user, domain, msg size, and the full path to the message. - Program BLAH stores a record of the message in a MySQL DB (a queue) and flags it in the queue for processing. - Program BLAH exits cleanly to vdelivermail, which exits with success to qmail-local. 2) Replace ~vpopmail/bin/vdelivermail with a simple ash script that sets the BLAH environment variable to the program, and then exec's the original vdelivermail with the arguments it was given. (Just like the QMQ patch, it can be selectively enabled.) 3) A separate process (we call vprocessmail) runs via supervise and queries for entries from the queue DB that need to be processed. We read each entry, checking for race conditions at each step along the way, and: a) Punt if over a specific size, b) Use ripmime to expand the message to tempdir on a RAM disk c) Clamdscan the tempdir d) If dirty, replace the body with a warning message including the virus found, time spent, and boilerplate; otherwise perform spam scanning (Mail::SpamAssassin, dspam) and other other message tweaking/rewriting per user prefs. e) Add headers with info about d) f) Update the queue DB with the same info g) If message is being deleted, delete message, and move on to the next msg. h) Otherwise write the re-written message back out as Maildir/tmp/.tmp.(origfilename) i) rename to Maildir/tmp/origfilename j) rename to Maildir/new/origfilename k) Record success and move onto the next message. l) If last message has been reached, sleep 7-12 seconds (randomly), query the queue again, and repeat. It works great for us, and also has the benefit of not spending any processing power on messages that aren't being delivered locally (ie, the final delivery). For scanning mail on a server used primarily for outgoing mail (or forwarding messages), a qmail-queue-based solution might work better. Having the queue DB based makes for really easy reporting and forensics too, and it's all written in Perl, so the sky's the limit in terms of functionality. YMMV... but let me know if you want any more info on the setup, or code :) Regards, Japheth Cleaver [EMAIL PROTECTED] [EMAIL PROTECTED]
[vchkpw] poppassd (in perl) for vpopmail+mysql
Hello all, I've written a small poppassd service (port 106) that is usable with vpopmail when using a MySQL back-end. I specifically wrote it to use with the SquirrelMail change password plugin (http://www.squirrelmail.org/plugin_view.php?id=21) when I had problems getting the poppassd they recommend for courier to work. This daemon can be used by any client, though. It includes some code to reject easy-to-guess passwords, IP restrictions (must have already logged in from that IP), and a small tarpit. Requires xinetd, DBI, and Socket, and is most efficient with SpeedyCGI. If anyone's interested, it's at http://www-rohan.sdsu.edu/~cleaver/software/qmail/. I'd be interested in any feedback anyone has. :) -jc
[vchkpw] Delays in vdelivermail to large default domain
Hi there,
I had a big giant email planned here, but as I was writing it I narrowed
down the scope of the problem we're having to a recursive stat call (I
think) in vdelivermail.c
First, some background on the setup:
I'm in the process of migrating a 12 G, ~5000 user
sendmail/aliases/virtualuser system to a qmail/vpopmail one, using MySQL as
the backend and am having a single problem holding me up.
We've got a cluster of 3 delivery machines, with a /vpopmail parition
shared over NFS. The NFS server is also the MySQL DB server where the
backend is done. /vpopmail is a 3Ware RAID 10 running ReiserFS. (We've
tried both the defaults and noatime/notail.)
All the 800 or so virtual domains are empty (save for the postmaster
account) and filled with .qmail-vuser files that forward to
[EMAIL PROTECTED] When a vpopmail user is made at one of those
domains, delivery happens instantaneously. Delivering to any vpopmail user
at the default domain results in vdelivermail hanging for 2-10 minutes
before finally delivering the message.
vuserinfo -d [EMAIL PROTECTED] works fine, which led me to
believe it was not a MySQL table problem (we're not using many_domains).
The vdelivery hang occurs whether delivering directly ON the NFS server, or
delivering on one of the cluster servers (though the time of the delay
varies unpredictably), which leads me to think that it's not an NFS
problem. Standard NFS read/writes are fine.
Additionally, copying files into and out of user's Maildirs manually works
fine, and squirrelmail and courier-imap are handling the situation fine as
well.
Attempted delivery to non-existant addresses gives a failure message
immediately.
Manual testing was done with a line like below, to verify it wasn't
anything else in qmail:
cat /vpopmail/testing/samplemail.txt | env EXT=cleaver
HOST=defaultdomain.com vdelivermail '' bounce-no-mailbox
Okay, as I was writing the above message, I decided to strace the running
vdelivermail process and discovered that vdelivermail was looping here:
stat64(/etc/vpopmail/domains/defaultdomain.com/5/charlenes/Maildir//new/1078418383.M015727P2293.haku.defaultdomain.com,
{st_mode=S_IFREG|0644, st_size=11180, ...}) = 0
stat64(/etc/vpopmail/domains/defaultdomain.com/5/charlenes/Maildir//new/1078418397.M208677P5866.haku.defaultdomain.com,
{st_mode=S_IFREG|0644, st_size=2123, ...}) = 0
stat64(/etc/vpopmail/domains/defaultdomain.com/5/charlenes/Maildir//new/1078418401.M185492P7109.haku.defaultdomain.com,
{st_m
[later]
stat64(/etc/vpopmail/domains/defaultdomain.com/E/gary/Maildir//new/1078419549.M564758P6609.haku.defaultdomain.com,
{st_mode=S_IFREG|0644, st_size=2744, ...}) = 0
stat64(/etc/vpopmail/domains/defaultdomain.com/E/gary/Maildir//new/1078419549.M438602P6573.haku.defaultdomain.com,
{st_mode=S
It appears to be stating every single message in every user underneath the
default domain's directory(!). Given that there is about 12 GB of mail
that's being transferred over in the test systems (before we go live), that
would explain the long delay. As it gets cached by NFS or the local disk
array, the time the stats take vary.
Any ideas on why it might be doing this? I'm looking over count_dir in
vdelivermail.c right now and not seeing it. =(
Sincerely,
Japheth J.C. Cleaver
Re: [vchkpw] Delays in vdelivermail to large default domain
D'oh! That makes total sense, and I hadn't considered it all. I've recompiled with --disable-domainquotas and things are delivering fine. It might be worth putting a warning in the migration FAQ about long delivery times for people who move everything over to a single domain like this... Thanks again! -jc At 12:55 PM 3/4/2004, you wrote: On Mar 4, 2004, at 1:36 PM, Japheth Cleaver wrote: It appears to be stating every single message in every user underneath the default domain's directory(!). Given that there is about 12 GB of mail that's being transferred over in the test systems (before we go live), that would explain the long delay. As it gets cached by NFS or the local disk array, the time the stats take vary. Maybe domain quotas were turned on, and it's trying to see how much space is used? -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] spam assassin enable/disable per domain flag
I'm actually doing something like this already. We've patched vdelivermail to leave files in the user's Maildir/tmp if an environment variable is set. That variable is the name of a program to run with a set of arguments detailing the user, domain, size, and filename that we've stored. Said program runs persistently and inserts that data into a MySQL database. Asynchronously, another program reads from that database, determines the preferences associated with that user/domain (stored in the vpopmail db), and runs over the file sitting in Maildir/tmp with things as needed (spamassassin, Clam, etc...) (If the program fails or is unexecutable, we tempfail back.) If the file passes (tagged or not) we move it to the user's Maildir/new directory, otherwise send it to .Trash, delete, or whatever else, and update the SQL db as needed with the resolution. It works pretty well (or will, once we finish tweaking our DB schema for this latest revision). -JC At 11:40 AM 1/13/2004, you wrote: At 11:06 AM 1/13/2004, Ken Jones wrote: The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. What I'd like to see with this is the ability to have either domain wide spam assassin settings or user specific spam assassin settings for the domain. I'm planning to host multiple virtual domains with Spam Assassin (mySQL Backend for configs) as an option, and having spamc called with the user name equal to the domain name would be great. I know some people would like a lower level approach so having vdelivermail have the option of passing no user name, the domain name as the user name, and the full email address as the user name would be helpful.
Re: [vchkpw] configure --enable-mysql=y error : help a noob please?
I believe the proper values are something like: --enable-incdir=/usr/include/mysql --enable-libdir=/usr/lib/mysql At least, those are where things are and what works on a RH9 + mysql.com rpms system Japheth Cleaver [EMAIL PROTECTED] At 12:19 AM 8/6/2003 +, jon kutassy wrote: Im trying to set up vpopmail +mysql + qmail on redhat 9 I believe I've read the relevent docs, and searched the web : when i run ./configure --enable-mysql=y I get this error: configure: error: unable to find your inc dir, specify --enable-incdir Now I'd love to be able to do this, but Im not sure what one is... Regards Jon
