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] ONCHANGE in CVS
John Simpson wrote: On 2006-04-16, at 0050, Rick Widmer wrote: I've just committed John Simpson's onchange patch. I've added the ability to enable it with --enable-onchange-script, and a file README.onchange. cool... except that i've updated the patch twice today, and i'm in the process of building another patch as i type this, and one of those patch updates was because of some very real bugs in my changes to vmysql.c and vpgsql.c. which version did you commit? Its based on 2. 3 doesn't matter to me because you never see add-user or mod-user in an add-domain, or mod-user in an add-user. I've also suppressed a few calls to the script that I considered redundant. which calls, specifically, did you remove? or did you add some kind of mechanism to suppress them, and if so which ones? The ones marked with *. vadddomain example.com ONCHANGE - add-domain example.com ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] * vadduser [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] vmoduser -a [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] vdeluser [EMAIL PROTECTED] ONCHANGE - del-user [EMAIL PROTECTED] Note that when you mod the user, you still get a mod-user call. Its only suppressed when it is part of add-domian or add-user. and when you did this, did you lock out the possibility of creating a domain with an initial mailbox whose name is not postmaster by forcing the user to assume that every add_domain should be considered to have an add_user [EMAIL PROTECTED] associated with it? Its no worse now than it was before. Still I wouldn't hold your breath on vadddomain changing how it works. I don't support it, and I don't think any of the primary developers will either. If you can get Ken and Tom to ok it, maybe I'll change my mind, but I won't be surprised when they revoke it if I did dare to make that change.
Re: [vchkpw] ONCHANGE in CVS
On 2006-04-16, at 0334, Rick Widmer wrote: John Simpson wrote: On 2006-04-16, at 0050, Rick Widmer wrote: I've just committed John Simpson's onchange patch. I've added the ability to enable it with --enable-onchange-script, and a file README.onchange. cool... except that i've updated the patch twice today, and i'm in the process of building another patch as i type this, and one of those patch updates was because of some very real bugs in my changes to vmysql.c and vpgsql.c. which version did you commit? Its based on 2. 3 doesn't matter to me because you never see add- user or mod-user in an add-domain, or mod-user in an add-user. anything lower than 4 won't compile if you're using mysql or pgsql... and 5 includes your suggestion of moving the del_domain and del_user notifications to BEFORE the damage is done, so that a final backup can be done. good idea, by the way. I've also suppressed a few calls to the script that I considered redundant. which calls, specifically, did you remove? or did you add some kind of mechanism to suppress them, and if so which ones? The ones marked with *. vadddomain example.com ONCHANGE - add-domain example.com ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] * vadduser [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] vmoduser -a [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] vdeluser [EMAIL PROTECTED] ONCHANGE - del-user [EMAIL PROTECTED] Note that when you mod the user, you still get a mod-user call. Its only suppressed when it is part of add-domian or add-user. how did you do the suppression? that sounds like something which needs to be part of the patch on my site. i know how i would have written it, but it might be handy to know how you did it, so that when people ask me about it (as they are already starting to, on the qmailrocks list) i have some idea of what's going on. and when you did this, did you lock out the possibility of creating a domain with an initial mailbox whose name is not postmaster by forcing the user to assume that every add_domain should be considered to have an add_user [EMAIL PROTECTED] associated with it? Its no worse now than it was before. Still I wouldn't hold your breath on vadddomain changing how it works. I don't support it, and I don't think any of the primary developers will either. If you can get Ken and Tom to ok it, maybe I'll change my mind, but I won't be surprised when they revoke it if I did dare to make that change. it's not about making any kind of change to the existing code- it's about NOT PREVENTING such a change from being made in the future. before the onchange patch, if they wanted to add the ability to create a domain with something other than postmaster as the first mailbox, they could. but with the onchange code modified to suppress these messages, they might not be able or willing to this so because somebody might already have an onchange script which assumes that a postmaster mailbox will be there, and adding such a feature would makes that assumption invalid. it doesn't affect anything right now, but it does prevent a potential feature from being added in the future. as i've said, i have two clients who have given domain admin rights to another mailbox and removed their postmaster mailbox altogether (replacing it with an alias pointing to their own mailbox) so that if somebody decides to try to break into the mailbox, they won't be able to because the mailbox doesn't exist. with microsoft preaching the benefits of renaming your administrator account to something else, i can see more domain administrators wanting to do this. this is exactly why i keep asking for other peoples' opinions about how this should be handled- i don't consider this issue to be decided one way or the other, and yet you have already committed a (buggy) version of it to the CVS server. you mentioned ken and tom, i would like to hear their opinion about this before it goes much further. obviously what's in the CVS right now needs to be updated to version 4 or later because of the bugs, but if ken and tom are in favour of suppressing the messages then i'll write a version 6 which includes the suppression code and we can commit that, so that the CVS version and the version on my web page will be the same (and i'll be able to properly answer questions about it, which is a major concern for me.) i would really rather leave the framework the way it is, instead of buffering a multi-line message while things are running and then dumping it all out at the end. it's do-able, and if the consensus is that it's a better way than what's out there right now, then i will write it... but i think that option is a lot more complicated than it really needs to be. i just had a thought- is there a vchkpw-devel
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] ONCHANGE in CVS
John Simpson wrote: On 2006-04-16, at 0334, Rick Widmer wrote: John Simpson wrote: On 2006-04-16, at 0050, Rick Widmer wrote: anything lower than 4 won't compile if you're using mysql or pgsql... and 5 includes your suggestion of moving the del_domain and del_user notifications to BEFORE the damage is done, so that a final backup can be done. good idea, by the way. I've got it updated to 5. I've got some testing to do before I put it into CVS. mysql compiles, but pgsql has errors that are not related to your patch. Unless you actually know someone who wants to use pgsql from CVS, its going to stay that way until cdb and mysql are done. how did you do the suppression? that sounds like something which needs to be part of the patch on my site. i know how i would have written it, but it might be handy to know how you did it, so that when people ask me about it (as they are already starting to, on the qmailrocks list) i have some idea of what's going on. I have sent a patch directly to you that should match your version 5, with my suppression code included. Search for the allow_onchange variable. It's pretty boring except in vpopmail.c. Watch closely, vadddomain() disables, and vadddomain() enables calling ONCHANGE. Its a little tricky in add_user which must blank its own sub calls and show its final call when initiated directly, but show nothing when called from vadddomian. I've also added: vmysql.c/vpgsql.c: valias_insert - add alias_line to the reported value. valias_remove - add alias_line to the reported value. valias_delete - add entire report valias_delete_domain - add entire report vpalias.c valias_insert - add alias_line to the reported value. this is exactly why i keep asking for other peoples' opinions about how this should be handled- i don't consider this issue to be decided one way or the other, and yet you have already committed a (buggy) version of it to the CVS server. What can I say... it worked with CDB, which is what I run. I'll test with MySQL and PostgreSQL after I have pmailadmin running as fully as I can until the alias functions are complete. Pmailadmin is my test platform for vpopmail so it comes up right after CDB. you mentioned ken and tom, i would like to hear their opinion about this before it goes much further. So would I. i would really rather leave the framework the way it is, instead of buffering a multi-line message while things are running and then I agree. Can the multi line message. i just had a thought- is there a vchkpw-devel mailing list that this conversation should be moved to? i suspect that most people on the list aren't interested in these kinds of low-level details- or maybe i'm wrong and people are interested? if so, speak up and let us know what you think. we won't bite unless you ask nicely. http://lists.sourceforge.net/lists/listinfo/vpopmail-devel I'm already subscribed... anyone who is interested in following this discussion is welcome there too. Rick
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] ONCHANGE in CVS
On 2006-04-16, at 0822, Rick Widmer wrote: John Simpson wrote: i just had a thought- is there a vchkpw-devel mailing list that this conversation should be moved to? i suspect that most people on the list aren't interested in these kinds of low-level details- or maybe i'm wrong and people are interested? if so, speak up and let us know what you think. we won't bite unless you ask nicely. http://lists.sourceforge.net/lists/listinfo/vpopmail-devel I'm already subscribed... anyone who is interested in following this discussion is welcome there too. joining as we speak... -- | 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 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
