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 one.com password
ONCHANGE add_domain - one.com
>vaddaliasdomain two.com one.com
ONCHANGE add_alias_domain - two.com
>vaddaliasdomain three.com one.com
ONCHANGE add_alias_domain - three.com
>vdeldomain three.com
ONCHANGE del_domain - three.com alias of five.com
>vdeldomain one.com
Warning: Alias domains exist:
two.com
use -f to force delete of domain and all aliases
>vdeldomain -f one.com
Warning: Alias domains deleted:
six.com
ONCHANGE del_domain - one.com
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.
Where?
<snip>
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.
thoughts?
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 example.com
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.
