Re: [vchkpw] Re: ONCHANGE behavior
On Apr 16, 2006, at 10:41 PM, Rick Widmer wrote: Robin Bowes wrote: Rick Widmer wrote: I would still argue that the hooks should match the calls in the vopmail api, and not an arbitrary subset of the operations within them. Why? Why not make the hooks reflect the useful operations rather than just what goes in internal to vpopmail? I think you have it backward. Returning only add-domain when someone runs vadddomain tells you exactly what happened. Throwing in add-user and mod-user is arbitrarily picking _some_ of the internal functionality of the add-domain operation. If you want them why don't we throw in: I think I agree with Robin on this. If I've written on onchange script that needs to apply to every user on the system, I don't want to have to special-case the new-domain condition with a hack to run my script for postmaster. Tom Collins Tom Logic LLC PO Box 5717 Napa, CA 94581 (707) 265-6622 (707) 265-6646 fax [EMAIL PROTECTED]
[vchkpw] Re: ONCHANGE behavior
Tom Collins wrote: On Apr 16, 2006, at 10:41 PM, Rick Widmer wrote: Throwing in add-user and mod-user is arbitrarily picking _some_ of the internal functionality of the add-domain operation. If you want them why don't we throw in: I think I agree with Robin on this. If I've written on onchange script that needs to apply to every user on the system, I don't want to have to special-case the new-domain condition with a hack to run my script for postmaster. Tom, That's pretty much exactly why I think we should not supress OnChange calls, but I never managed to articulate it very clearly! R.
Re: [vchkpw] Re: ONCHANGE behavior
(re-arranging things so the sequence of my answers makes sense...) On 2006-04-15, at 2237, Rick Widmer wrote: John Simpson wrote: 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. I don't see any value in reporting a delete operation after the fact, other than to log it. On the other hand it might be a good idea to move the script before the delete. That would give you a chance to take a snapshot of the resource usage right before delete, or maybe make a backup. good point, i hadn't thought of that. coming soon to a web server near me, onchange.5... 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... 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. I'd rather wait on the entire process to finish so I know there were no errors in the operation before I report the job done. Oh well, it works just fine both ways. Good job! 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. thinking about this... one way to handle it would be to have a dynamically sized buffer where messages would be accumulated, a function add_onchange() which adds a line to this buffer, and call_onchange() would be called once to send the buffer contents and then clear the buffer when the operation is done- at the end of a vpopmail command line program, at the end of a vpopmaild command executing, at the end of a qmailadmin request, etc. in theory the buffer could be grown byte by byte as needed, but in practice i would have it allocate 16KB to start with, and if it grows bigger than that, add 16KB blocks as needed. the code would be a little messy (having to dynamically allocate memory when the message gets too big) but it would make it easier to report when alias domains are deleted. with that done, we could add a del_domain line for each alias domain involved, with the last del_domain line being the physical domain name. and then for add_domain, we would have the existing three messages all delivered at once. of course then we run the risk of bumping into the limit of how long a command line can be... i know in linux the limit is 128KB for (command line plus environment). if we're doing a del_domain on a physical domain which has hundreds of alias domain names, this could be an issue... here's another possibility, which makes the 128K command line limit a non-issue: instead of passing information on the command line (which is fairly easy), we can set up a pipe. the child process manipulates its handles so that its stdin is the output end of the pipe, and the parent process sends the contents of the buffer through the pipe. of course then the script becomes more complex, because it has to read and parse stdin to figure out what's going on, and it has to be able to deal with multiple messages in the same invocation. and while i'm in there re-writing things, i think i might move all of the calls which generate onchange messages into the back-end code, just so it's consistent. and i would probably move call_onchange() and add_onchange() to a new source file called onchange.c, with an onchange.h to provide the function prototypes to the other source files... 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? 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
Re: [vchkpw] Re: ONCHANGE behavior
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
[vchkpw] Re: ONCHANGE behavior
Rick Widmer wrote: Robin Bowes wrote: 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. But what problem does this cause? This only happens when managing domains/users/aliases, etc. and does need to be particularly fast. The extra calls won't cause any real problems and add clarity. valias_insert[EMAIL PROTECTED] valias_remove valias_delete What's the difference between valias_remove and valias_delete ? Assume an alias [EMAIL PROTECTED] that forwards to [EMAIL PROTECTED] and [EMAIL PROTECTED] valias_remove [EMAIL PROTECTED] would indicate that the alias no longer forwards to [EMAIL PROTECTED] valias_delete [EMAIL PROTECTED] would indicate the alias was removed entirely. What is [EMAIL PROTECTED] also forwards to [EMAIL PROTECTED] How does valias_remove [EMAIL PROTECTED] know which alias to remove? R.
[vchkpw] Re: ONCHANGE behavior
John Simpson wrote: On 2006-04-15, at 1917, Rick Widmer wrote: Robin Bowes wrote: 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. I agree with John. 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. I don't relaly care, as long as they're consistent, i.e. either add_user or user_add. R.
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: I really don't think the multiple calls cause any problem at all and add clarity, i.e. they reflect what's actually happening rather than requiring the sysadmin to make assumptions about what's going on behind the scenes. For example, assuming that a postmaster user is created when a domain is added. I don't understand why you want to look at adding a domain and creating the associated postmaster user as separate operations. They are not. You run the vadddomain program, call the vadddomain() function or use the add_domain function from the daemon. It creates a domain and the postmaster user. you don't have any choice about it other than the password that gets assigned. The oncall results reflect the reality of the vpopmail api. I don't expect to see that change any time soon. If it does, then you will probably have to add your own desired user after you create the domain. No matter, I'll worry about adding the the add_user call then. Rick,
[vchkpw] Re: ONCHANGE behavior
Rick Widmer wrote:
I don't see any value in reporting a delete operation after the fact,
other than to log it. On the other hand it might be a good idea to move
the script before the delete. That would give you a chance to take a
snapshot of the resource usage right before delete, or maybe make a backup.
If you look at qpsmtpd (which is where I believe the idea of onchange
hooks came from), it is moving to the idea of pre- and post- hooks for
all actions.
It also calls different scripts for each hook rather than having one
monolithic something's changed script. Would that be a better approach
for vpopmail?
It could work something like this [warning: pseudo-code alert]:
if (defined $user_add_pre) {
if ( exists $user_add_pre ) {
$hook_return = execute $user_add_pre;
if $hook_return = failure {
warning/error user_add pre-hook execution failed (error here)
# bail out here?
}
} else {
warning/error user_add pre-hook defined but not found
# bail out here?
}
}
# Now, add the user
if $hook_return = OK {
user_add;
}
if (defined $user_add_post) {
if ( exists $user_add_post ) {
$hook_return = execute $user_add_post;
if $hook_return = failure {
warning/error user_add post-hook execution failed (error here)
# bail out here?
}
} else {
warning/error user_add post-hook defined but not found
# bail out here?
}
}
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.
I don't really care. Robin - what do you think the names should be?
As far as I'm concerned, all I need is a complete list in front of me
when I sit down to write the script.
I don't really care either, but they should be consistent - add_user or
user_add, but not a mix.
R.
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: What is [EMAIL PROTECTED] also forwards to [EMAIL PROTECTED] How does valias_remove [EMAIL PROTECTED] know which alias to remove? valias_remove( alias, domain, alias_line ); You would call: valias_remove( 'foobar', 'example.com', '[EMAIL PROTECTED]' ); or to eliminate the entire foobar alias: valias_delete( 'foobar', 'example.com' );
[vchkpw] Re: ONCHANGE behavior
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: 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. 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. and while it may seem like noise to a human being, to a computer it's just a sequence of messages. and unless the server itself is already overloaded, the extra CPU load involved is minimal. 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. i don't feel right giving up that flexibility. the flexibility is why i wrote the onchange patch to run a script- my first idea was to have it write to a named pipe, since that's what i'm actually doing on my own server. i figured if i wrote it to call a shell script, and then had that script write the data to the pipe, the fact that there's a shell script in the middle would make it a lot easier for other people to write their own onchange handlers (or to combine two of them if needed.) 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. i don't think it's right to arbitrarily lock them out of such a possibility, especially when it's easy enough to write the onchange script so that it's not an issue. robin? anybody else? thoughts about this? I agree with John. Removing the multiple messages is a premature optimisation. Having thought about this some more, I think that a better approach would be to have both pre- and post- hooks for each action and to call a separate script for each hook. The benefit to this is that you would only call the hook if the script exists. So, by default, there would be no scripts so no hooks would be called. To create a hook, admin simply drops a script in VPOPMAILHOME/hooks/ (e.g. add_user_pre). yeah, i've been complaining about the fixed order stuff for about four years now. for those who don't know what we're talking about- if you think of a .qmail file, it may have multiple lines in it. the first line might run spamassassin, the second line might use condredirect to store the message somewhere (or simply not deliver it) based on the score, and then the third line would order everything else delivered to the normal inbox folder. when aliases are stored in a SQL database, there is no field in the database to hold what order the entries should be executed in. doing a SELECT * FROM valias query might return these same three items in any random order, because there is no ORDER BY clause in the query, because there is no field by which to order the results. and if it happens to return the steps in the wrong order, your filtering doesn't work. what needs to happen is that some kind of sequence field needs to be added to the table(s), and the alias-related functions need to be re-written to properly work with these fields, as well as deal with existing databases where there is no sequence value. we probably also need a utility to retroactively fix any existing databases- for single-item aliases, put an explicit 0 in the sequence field so it's no longer NULL. for multi-item aliases, print out the alias and the lines, so that the administrator can manually fill in the sequence field on each record. Why not just store the whole .qmail as a multi-line text object? 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. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. i hear ya. robin, or anybody else- any thoughts? i have no preference either way- if
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: Having thought about this some more, I think that a better approach would be to have both pre- and post- hooks for each action and to call a separate script for each hook. This has some possibilities. There would be an advantage if most of the hooks were empty, and a liability if there was a lot of duplicate code. It would require several identical files to support John's existing setup. I'm happy with a single script and a switch() on the command that was executed. I would still argue that the hooks should match the calls in the vopmail api, and not an arbitrary subset of the operations within them. Why not just store the whole .qmail as a multi-line text object? The biggest problem, it would break every program that currently updates valias entries. The other minor detail, can every back end support it? I don't know. I use CDB, test mysql and pgsql, and can't even list all the other back ends off the top of my head. I have no idea how you would implement valias in them, and I don't believe any of them have it yet. There is very little interest in keeping them current with the big three. They usually get updated just enough to scratch the itch of the person who contributes a patch... unless you want it bad enough to pay. Inter7 and Tom Collins will both do sponsored work that usually finds its way back into the distribution.
[vchkpw] Re: ONCHANGE behavior
Rick Widmer wrote: Robin Bowes wrote: Having thought about this some more, I think that a better approach would be to have both pre- and post- hooks for each action and to call a separate script for each hook. This has some possibilities. There would be an advantage if most of the hooks were empty, and a liability if there was a lot of duplicate code. It would require several identical files to support John's existing setup. I'm happy with a single script and a switch() on the command that was executed. If you have duplicate code you would just symlink a single script containing your switch() statement - best of both worlds! I would still argue that the hooks should match the calls in the vopmail api, and not an arbitrary subset of the operations within them. Why? Why not make the hooks reflect the useful operations rather than just what goes in internal to vpopmail? Why not just store the whole .qmail as a multi-line text object? The biggest problem, it would break every program that currently updates valias entries. The other minor detail, can every back end support it? I don't know. I use CDB, test mysql and pgsql, and can't even list all the other back ends off the top of my head. I have no idea how you would implement valias in them, and I don't believe any of them have it yet. There is very little interest in keeping them current with the big three. They usually get updated just enough to scratch the itch of the person who contributes a patch... unless you want it bad enough to pay. Inter7 and Tom Collins will both do sponsored work that usually finds its way back into the distribution. It was just an idea - I don't know the details of the code. R.
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-16, at 0639, Robin Bowes wrote: If you look at qpsmtpd (which is where I believe the idea of onchange hooks came from) not really... it's something i've wished that vpopmail had for several years, but never had the time to write. It also calls different scripts for each hook rather than having one monolithic something's changed script. Would that be a better approach for vpopmail? i don't think so. if you want to use this kind of approach, you can create an onchange script which looks like this: #!/bin/sh if [ -e ~vpopmail/etc/$1 ] then exec ~vpopmail/etc/$* fi logger -t onchange ignoring command $* exit 0 and then create scripts in ~vpopmail/etc with names matching the cmd parameter sent to the onchange script. 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. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. I don't really care either, but they should be consistent - add_user or user_add, but not a mix. since nobody really cares, i'm just going to leave them the way they are. -- | 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
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-16, at 1649, Robin Bowes wrote: John Simpson wrote: On 2006-04-16, at 0639, Robin Bowes wrote: It also calls different scripts for each hook rather than having one monolithic something's changed script. Would that be a better approach for vpopmail? i don't think so. if you want to use this kind of approach, you can create an onchange script which looks like this: #!/bin/sh if [ -e ~vpopmail/etc/$1 ] then exec ~vpopmail/etc/$* fi logger -t onchange ignoring command $* exit 0 and then create scripts in ~vpopmail/etc with names matching the cmd parameter sent to the onchange script. That will still exec the script for every OnChange event. exactly. the original concept was to modify vpopmail itself as little as possible, and any customizations would be done by the scripts, outside of vpopmail. besides, i don't really want to hard-code 15 different script names into the source code, and deal with the resulting confusion. 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. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. I don't really care either, but they should be consistent - add_user or user_add, but not a mix. since nobody really cares, i'm just going to leave them the way they are. Ahem, I said I didn't care as long as they were consistent! okay... you seem to be the only person with strong feelings about it. cool by me. i'm not doing anything with the messages yet (and for my needs i don't really need to), the onchange script on my server is very simple: #!/bin/sh PATH=/usr/bin:/bin logger -t onchange $* echo $* /tmp/update-qmail the list of messages and parameters is on the web. send your changes to me on the vpopmail-devel mailing list and i'll update the code. http://qmail.jms1.net/patches/vpopmail-onchange.txt -- | 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
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: Rick Widmer wrote: I would still argue that the hooks should match the calls in the vopmail api, and not an arbitrary subset of the operations within them. Why? Why not make the hooks reflect the useful operations rather than just what goes in internal to vpopmail? I think you have it backward. Returning only add-domain when someone runs vadddomain tells you exactly what happened. Throwing in add-user and mod-user is arbitrarily picking _some_ of the internal functionality of the add-domain operation. If you want them why don't we throw in: create-domain-directory set-domain-limits add-user create-user-directory create-user-entry set-quota create-sqwebmail-stuff That's off the top of my head, there may be more. The point is, you don't need notification of the internal operations. Vadddomain is not going to change the way it works any time soon. You can count on that, just like the rest of the existing vpopmail users are. We can end discussion of this topic here. Unless you can get a majority of the vpopmail admins to tell me I have to do it differently, the official version will return the modified name of the vpopmail operation that was initiated by the user and none of the internal operations. It will also call a single script named ~vpopmail/etc/onchange passing just enough information to identify what the user requested. It will have to be enabled in ./configure. Pretty much the way it works now. Unless you can show me a working application this will break, that is what future users need to get used to. Next topic. What names? Where possible the names will match the daemon, since I expect that is the way most people will develop their own code. Where a name doesn't exist as a command in the daemon, we will name it. (Then add it to the daemon that way.) I know the daemon is incomplete. The problem is vpopmail valias support is also incomplete across the various back ends. The back ends (like cdb) need full valias support before the daemon gets it. These are the names I think we should use: add_user del_user mod_user add_domain del_domain add_alias_domain insert_alias remove_alias delete_alias delete_all_alias Note that is is insert_alias rather than add_alias because insert_alias may or may not create a new alias, but will always insert a single line into an alias. There is no way to create an alias with no entries. Objections? snip It was just an idea - I don't know the details of the code. If you haven't yet, you might want to read through README.vpopmaild from one of the latest builds. It is pretty close to the complete set of functions available to a user of vpopmail, and their parameters. If you have questions, fire away... I can't think of a better way to expand the README file. Anyway, that is the API we have to work with. This will be the last message I post on this list related to vpopmail and John's patches on this list. Please join us on vpopmail-devel: http://lists.sourceforge.net/lists/listinfo/vpopmail-devel
[vchkpw] Re: ONCHANGE behavior
Rick Widmer wrote: John Simpson Robin Bowes 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.) At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. Rick, 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 is created - these are separate actions that happen to both occur when you first create a domain. 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 as well as add_user? I guess the user is added and then modified - the password is set, perhaps? BUt I would need to look at the code to see what actually happens. Bottom line; If the user is being added and then modified then it makes sense to have both hooks triggered. Why do you want to change this? What is the problem you are trying to solve? README.onchange --- If --enable-onchange-script is added to the ./configure command many vpopmail commands, and calls into the library will call the script ~vpopmail/etc/onchange when they have completed execution. When the script is called, it will be passed the following values on the command line to indicate what was changed. add_user[EMAIL PROTECTED] del_user mod_user add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or mod_alias_domain (not sure if these two would be necessary)? valias_insert[EMAIL PROTECTED] valias_remove valias_delete What's the difference between valias_remove and valias_delete ? Does there need to be a valias_mod? Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ? R.
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: Rick Widmer wrote: John Simpson Robin Bowes 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.) At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. Rick, 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 is created - these are separate actions that happen to both occur when you first 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.) 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 as well as add_user? I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. I guess the user is added and then modified - the password is set, perhaps? BUt I would need to look at the code to see what actually happens. Bottom line; If the user is being added and then modified then it makes sense to have both hooks triggered. Actually according to the calls of the script the user was modded before it was added. 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.) 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. add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or 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. valias_insert[EMAIL PROTECTED] valias_remove valias_delete What's the difference between valias_remove and valias_delete ? Assume an alias [EMAIL PROTECTED] that forwards to [EMAIL PROTECTED] and [EMAIL PROTECTED] valias_remove [EMAIL PROTECTED] would indicate that the alias no longer forwards to [EMAIL PROTECTED] valias_delete [EMAIL PROTECTED] would indicate the alias was removed entirely. Does there need to be a valias_mod? There is no such thing, just combinations of the above. Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ? I don't know. John? Rick
Re: [vchkpw] Re: ONCHANGE behavior
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 is created - these are separate actions that happen to both occur when you first 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 as well 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. add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or 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
Re: [vchkpw] Re: ONCHANGE behavior
John Simpson wrote: 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. I'd rather wait on the entire process to finish so I know there were no errors in the operation before I report the job done. Oh well, it works just fine both ways. Good job! 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. It seems to me it is much easier to eliminate the noise at the source. 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. I don't see any value in reporting a delete operation after the fact, other than to log it. On the other hand it might be a good idea to move the script before the delete. That would give you a chance to take a snapshot of the resource usage right before delete, or maybe make a backup. 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. 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. Sounds reasonable to me. I believe the reason they don't appear in the daemon yet is because the cdb back end doesn't support them. 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... 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. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. Rick -- KD7VKZ
Re: [vchkpw] Re: ONCHANGE behavior
On Apr 15, 2006, at 4:17 PM, Rick Widmer wrote: I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. My recollection is that it calls moduser to set the quota. The original adduser() API in the backends didn't allow for setting a quota when added. It should be possible to rectify this by adding a new API to each backend to add a user with a quota. Initially, it could just be a stub that does adduser(); moduser();. We would want to fix it to add the user in one shot, but that would require code customized to each back end. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
