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 example.com - 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
add-domain example.com
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 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.
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.
