John Simpson wrote:

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.

My intent is to make it so adding a domain calls the script once, reporting that the domain was added. Adding a user calls the script once, reporting that the user was added. Modifying a user or domain calls the script once, reporting the modification. I agree we want to know when a modify command is executed by the user, we just don't need to know if it happened as part of adding a user or domain.

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.

Are you going to document that somewhere?  Its a cool idea.

I'm just going to write a script that tweaks the file structure, sends a pair of welcome messages and writes a log entry. Unless your structure is well documented and easy to find, I bet that's what most people end up doing.

It really doesn't matter to you if you get one or three calls when someone runs vadddomain. Right?

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.

That is exactly what I want to prevent. It feels like a support nightmare to me. Its not that hard to make vpopmail only make one call to the script per transaction.

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,

I see no problem with that.  You will get:

add-domain  - when they run vadddomain

add-user [EMAIL PROTECTED]  - when they run vadduser

mod-user [EMAIL PROTECTED]  - when they run vmoduser

del-user [EMAIL PROTECTED]  - when they run vdeluser

instead of

mod-user [EMAIL PROTECTED]  *
add-user [EMAIL PROTECTED]  * - when they run vadddomain

mod-user [EMAIL PROTECTED]  *
add-user [EMAIL PROTECTED]  - when they run vadduser

mod-user [EMAIL PROTECTED]  - when they run vmoduser

del-user [EMAIL PROTECTED]  - when they run vdeluser

Can you keep a straight face and tell me the * lines are anything but noise? :)

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.)

I understand the theory, but the you are supposed to have a postmaster account to receive administrative traffic. On the other hand I must admit mine only gets cleaned out every few months.

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.

Yes, but we shouldn't be making it too easy for people to violate the RFC's. The guys over on the qmail mailing list are mad enough at us over the way we use users/assign. I don't think you will find any developer support for not creating the postmaster user automatically.

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 don't see any problem at all. Add-domain means someone ran vadddomain, executed the add_domain command from the daemon, or called vadddomain() from a c program. No matter how it was executed it will create the domain and the postmaster account. I really don't see this changing any time soon. Any adds/mods/deletes they do after that will be reported as separate transactions.

(1) please include the URL 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.

The philosophy of vpopmail is supposed to be lean and mean. We prefer to recompile the program to make configuration changes rather than mucking around in the file system every time something gets run.

Reply via email to