Re: [vchkpw] vadddomain -u issues
Tom Collins wrote: On Apr 14, 2006, at 9:57 AM, Ken Jones wrote: kengheng wrote: When I add a domain using vadddomain -u , I have to change the permission of /var/qmail/vpopmail/etc/vpopmail.mysql to o+r ? Thanks. Yes. By default, and for security reasons, the ~vpopmail/etc/vpopmail.mysql file is only readable by the vpopmail user. If you add any domain under a different user, that user will need access to that file. You could either grant access to all users, or you could make sure the vchkpw group has access and include the new user in the vchkpw group. Note that making it world-readable opens up a dangerous security hole. If someone can get access to the server, they can learn the username and password for the entire vpopmail database. If that server just does email, and only admins have access/accounts, then it's less of a risk. Doing it on a server that does web hosting and allows users to upload their own cgi scripts would be very dangerous. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ I agree with Tom, it will lead to more threats available. I'm using vadddomain -u option is for system based quota control, if the -u is not suitable in this scenario, what else can be used to control the mail quota since the vpopmail is not plan to add the domain quota function. Thanks.
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? 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
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
[vchkpw] Re: ONCHANGE behavior
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. 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! 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] 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
[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
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.
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
[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 complet
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
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: 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
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.
[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
Rick Widmer wrote: > > I see no problem with that. You will get: > > add-domain example.com - when they run vadddomain > > add-user [EMAIL PROTECTED] - when they run vadduser > > mod-user [EMAIL PROTECTED] - when they run vmoduser > > del-user [EMAIL PROTECTED] - when they run vdeluser > > > instead of > > add-domain example.com > mod-user [EMAIL PROTECTED] * > add-user [EMAIL PROTECTED] * - when they run vadddomain > > mod-user [EMAIL PROTECTED] * > add-user [EMAIL PROTECTED] - when they run vadduser > > mod-user [EMAIL PROTECTED] - when they run vmoduser > > del-user [EMAIL PROTECTED] - when they run vdeluser > > > Can you keep a straight face and tell me the * lines are anything but > noise? :) 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 have less of a problem with supressing the mod-user call that triggers when add-user is called, but I really think that creating a domain should trigger an add-domain action and an add-user action. If this code was called for every delivery on an underpowered box receiving millions of deliveries per day then it might cause a problem, but it will only be called when domains/users/aliases are being managed, and that's hardly a synchronous task. It seems like premature optimisation to me. R.
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 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? 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.
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 th
