John Simpson wrote:
(re-arranging things so the sequence of my answers makes sense...)

On 2006-04-15, at 2237, Rick Widmer wrote:

John Simpson wrote:

I do think it is a good idea to name the parent domain if you delete an alias domain, even if I don't know how someone would use it today. If nothing else it will make my log entries look nicer.

If you've already got it worked out, go ahead and send me a patch. If not you've described it well enough, it will be easy enough to do.

ewww... the message which makes up the onchange command line arguments (other than the first command name) is a fixed-size buffer. what do you see the output looking like if you delete a physical domain with 50 alias domain names pointing to it? this would cause a buffer overflow unless we write in some kind of dynamic memory allocation function...

Don't worry about this one. There will never be more than the real domain and the alias domain.

>vadddomain password
ONCHANGE add_domain -

ONCHANGE add_alias_domain -

ONCHANGE add_alias_domain -

ONCHANGE del_domain - alias of

Warning: Alias domains exist:
   use -f to force delete of domain and all aliases

>vdeldomain -f
Warning: Alias domains deleted:
ONCHANGE del_domain -

That is the actual results on my system, using this PHP script:

#!/usr/local/bin/php -q

$Command = $argv[1];
$Target  = $argv[2];
$Parm    = $argv[3];

echo "ONCHANGE $Command - $Target $Parm\n";


not such a good job- you will notice that somebody reported a bug because my own testing procedure isn't as complete as it should be. there is now an "onchange.4" patch, any earlier versions should not be used.



any of these would be fairly major re-writes of the patch, although i can see where it probably needs to be done, and if i'm going to do it, now is certainly the time.


If you can find the right place to move call_onchange() to just do that.* (it may take one for an alias and another for the real domain) When the script is called (before the delete happens) it can just look at the domain data to see what is there. (If anyone really cares.) If you needed it in your program on the other side of the pipe, the source script will have to do the lookup because the domain may be gone before the receive side of the pipe gets around to looking. Other than that I think the results above are good enough. Its just supposed to be a trigger.

* I tried to move the call earlier, but it only was triggered when a real domain was removed. I was more worried about noise suppression at the time, so I put it back and went on.

It seems to me it is much easier to eliminate the noise at the source.

much easier to write an "onchange" script, yes... but less flexible.

Vadddomain, vadddomain() and add_domain are the smallest things that a vpopmail user can access. You don't get any choice on how they act. How is it helpful to expose internal operations you have no control over?

Vadduser, vadduser() and add_user are the same. The reason you see the mod_user call is because the original API did not support quotas when adding a user. Did the vauth_adduser() function change? No. Another function was added so existing programs did not have to change. Don't expect much support around here for changing anything that already exists. Backwards compatibility is king.

besides, if we decide in the future to allow users the option to use something other than "postmaster" for that function, then seperate messages will be necessary and it would not be proper to assume that an "add_domain" notification will always imply an "add_user [EMAIL PROTECTED]" notification.

Even in that case when you see the add_domain you can:

o run vuserinfo -D

o user_list

o look it up in the vpasswd file or database

On the other hand, if its your system and you are doing something wierd, you should already know what it is. Nobody says _your_ onchange script has to work on every system in the world.

i can see collapsing multiple messages into a single invocation of the "onchange" script if we follow that route, but i'm still not convinced that we should do away with the multiple messages entirely- not even with blocking the mod_user notification within add_user within add_domain, because somebody in the future may decide that they want to track quotas with the "onchange" mechanism for some reason.

They are going to have to do it in the vpopmail code. If they can get away with it. There is nothing you can do about the way vadddomain or vadduser work from outside of it.

It gets worse, the way a cdb file and a database handle the data are quite different and we need to add an order field to the database to make it able to store entries in a fixed order and add functions to the cdb back end to support the valias calls. someday...

yeah, i've been complaining about the "fixed order" stuff for about four years now.

If you agree to help with testing - if not coding, I'll find time to work that in as soon as I get pmailadmin usable. That's something that needs more than one brain to work out all the problems.

i hear ya. robin, or anybody else- any thoughts? i have no preference either way- if nobody cares, i'm just going to leave it the way it is right now.

After giving it some thought I think the best thing is to vpopmaild-ize all the names. The missing functions will probably get added once valias support gets fixed.

Reply via email to