On 2006-04-15, at 1756, Rick Widmer wrote:
Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.)
i noticed that in my testing... once is to add the domain itself, once to add the postmaster mailbox, and once to set the quota for the postmaster mailbox. (vauth_setquota calls vauth_setpw, and i wanted vauth_setpw to trigger the notify because i'm building an "auth.cdb" of mailbox names and passwords, and need to rebuild whenever a password changes.)
maybe vauth_setpw() could be modified to only call call_onchange() if the PASSWORD field was changed... but there may be future uses of the onchange mechanism where people may want to track quota changes as well, so i'm not convinced that's a good idea either. i'm thinking it would limit the future flexibility of the onchange mechanism if we remove this notification, and i'm all about maximum flexibility.
and if this means that adding a domain results in the onchange script being run three times, that tells me that the onchange script needs to do little more than send a signal somewhere, and some other process needs to do the real work so that whatever program called the vpopmail library functions can get back to doing its thing.
At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two.
honestly, what i'm doing with the "onchange" script is simple:
echo "$*" > /tmp/update-qmail
where /tmp/update-qmail is a named pipe. i have a daemontools service
which waits for input on this pipe, and "does its thing" (checks the
timestamps of various files and runs qmail-newu if needed, runs qmail-
newmrh if needed, sends a HUP to qmail-send if needed, rebuilds
validrcptto.cdb if needed, and now rebuilds auth.cdb if needed) after
a five second delay. this means that unless something is really slow
on the system, the first notification will cause the work to be done
after the third notification has been sent.
which means that whatever "smarts" are needed in order to prevent a certain piece of work from being done twice, would need to be done within the onchange script itself, or within whatever process the script sends its signal to. i'm currently doing this using the five- second delay before starting work, and then reading and ignoring any "pending" data on the pipe when that first work unit is done. however, i plan to teach the service to recognize the patterns, so that if it sees an "add_domain xyz", it will ignore any "add_user [EMAIL PROTECTED]" and "mod_user [EMAIL PROTECTED]" messages which arrive less than ten seconds later.
in any event, i think that the add_user notification for the postmaster mailbox itself needs to stay there.
i have seen some really strange situations... many times i've seen people delete postmaster mailboxes after using vusermod to give some other mailbox domain-admin rights, under the theory that by using a different name for the postmaster account, they are preventing a dictionary attack on the postmaster password from succeeding (which is the same idea as renaming the "Administrator" account on a windoze machine, and done for the same reasons, usually by windoze administrators who are learning about security through a trial by fire.)
and who knows, at some point in the future, the idea may catch on and we may want to allow a way to create domains with the first mailbox (which has domain-admin rights) having a name other than postmaster. writing onchange scripts which assume that every add_domain involves a mailbox named "postmaster" makes this kind of change harder to do. having two onchange calls, one for the domain and one for the mailbox, makes it possible to write this kind of change without having to worry about peoples' existing onchange scripts- just have the one for the domain ONLY do the activities needed to create a domain in whatever external system you are updating, and have the one for the mailbox ONLY do the activities needed for creating a new mailbox.
i'm all about maintaining as much flexibility as possible. my recommendation is to leave it the way it is.
Finally, is there anything I should add to the readme file? ... This is based on the onchange.2 patch by John Simpson. Rick Widmer changed ./configure.in so the onchange code is only compiled when specified at ./configure time.---------------------------------------------------------------------- -----Is there anything else I should do with 5.5 before I try to release it?
two minor points.(1) please include the URL http://qmail.jms1.net/patches/ vpopmail.shtml in the file, so that poeple can easily find the documentation i have written (and will be maintaining) for it. i'll be watching this mailing list for any problems which people may have with it, and if any problems seem to show up on a regular basis, i will write a FAQ for those problems, either on this page, or as a new page linked from this one.
(2) i hadn't thought of making it into a configure-time option, good call. my own idea was to turn the code on for everybody, and if anybody who didn't want to use an onchange script, they shouldn't create one.
-------------------------------------------------- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | -------------------------------------------------- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | --------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
