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" 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.
-------------------------------------------------- | 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
