On 2006-04-15, at 1917, Rick Widmer wrote:
Robin Bowes wrote:I must admit I've not actually looked at John's code. However, my thoughts (based on your comments) are as follows: add_user should be called as well as add_domain when a new domain iscreated - these are separate actions that happen to both occur when youfirst create a domain.I can see that, on the other hand you already know when you write your response to an add_domain that the postmaster user was created. Do you really need to exec the script a second time to handle the postmaster as a separate operation? There is quite a bit of overhead with PHP and Perl starting up the script. (I'll be using PHP.)
for now, you know that a postmaster mailbox was created. this may change in the future, if the idea of using a name other than "postmaster" catches on (as it is starting to, especially among windoze admins who are just learning that it's a good idea to change their "Administrator" accounts to have some other name.)
i think it makes sense for the add_user notification to be separate from the add_domain notification.
I don't really have a problem with both mod_user and add_user triggering in an add_user operation. What happens to cause mod_user to trigger aswell as add_user?I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database.
i just walked the code- after vadduser() actually creates the mailbox, it sets a quota, which calls vauth_setquota(), which calls vauth_setpw() to re-write the vauth entry with the "shell" field (which contains the quota) changed.
they're showing up "out of order" because i'm calling call_onchange() at the very end of vadduser(), when it should probably happen right after the call to vauth_adduser() and before the call to vauth_setquota(). rick, i've just updated the patch so that it happens in the correct order. there is now an "onchange.3" patch, and for your use, there is an "onchange.2-3" patch which just moves the code. the direct URL for the upgrade patch is...
http://qmail.jms1.net/patches/vpopmail-5.4.15-onchange.2-3.patch
Why do you want to change this?Because it seems wasteful to me to call the script three times just to add a domain, or twice to add a user. In the case of the user the mod_user comes before the add_user, so the user data is not completely updated when the script is called for mod_user. By the time the script is called for add_user the mod_user data is available so you can look it up and act accordingly. Specifically when the initial mod_user exec happens the quota, sqwebmail_pass file, and last_auth processing has not been done yet. (Possibly more, I did not trace out the vauth_adduser() call that actually does the work.)
i can understand this. however, since the call_onchange() function waits for the script to complete, it is up to you as the author of an onchange script to make it run as quickly as possible. as i explained before, my "onchange" script sends its command line arguments to a named pipe and exits, and the service which is listening to the other end of that pipe does all of the work.
for me, the trick is dealing with the fact that input may arrive on the pipe at any time- including three notifications within the space of a second. i know that (for my purposes) if an "add_domain xyz" message arrives, for example, that i can wait 10 seconds before doing anything (to give the vpopmail program time to finish and send any other messages), and that any "add_mailbox [EMAIL PROTECTED]" or "mod_user [EMAIL PROTECTED]" messages which arrive less than 5 seconds after i'm done can be safely ignored.
What is the problem you are trying to solve?No real problem, just something I consider wasteful of resources. For example, if all you are doing is rebuilding a validrcptto database currently you are doing it three times every time you add a domain. Two of them are instantly thrown away as soon as they finish.
actually, i'm not- but you do have a point. whoever writes an "onchange" script does need to worry about this issue- but i don't think it's right to give up the flexibility in order to not have to write proper "onchange" scripts.
Does there need to be a "del_alias_domin" hook? How about a mod_domain,add_domain domain del_domain add_alias_domainor mod_alias_domain (not sure if these two would be necessary)?Delete of an alias is done with del_domain, naming the alias. Mod_domain might be valuable. There may be a problem here since you can't tell from the script if it is an alias or a whole domain. Maybe it should name the parent domain if an alias was deleted, or name the aliases if the parent is deleted.
or name both the alias and the real domains if an alias is deleted, as opposed to naming just the real domain if a real domain is deleted. basically, the first word after "del_domain" is what the user actually requested, and IF that domain name was an alias domain, then add the real domain as another term after it.
if the "onchange" script needs to know whether the user's request affected a real or alias domain, simply look to see if there IS another domain listed afterward- if so, the first one was an alias and the second one is the real domain that the alias pointed to.
is this something that needs to be in there? if so, i'll write it in.
Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ?I don't know. John?
the idea was that the names were are all the same as vpopmaild commands. however, these functions don't exist in vpopmaild, so i used the names of the actual functions within the vpopmail source code.
would it be better to use the vpopmail function names for all of the notifications, so that they are all consistent? if so, now is the time to make the decision, since nobody (as far as i know) has written any onchange scripts which would look for specific strings.
-------------------------------------------------- | 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
