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


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?

It gets worse, the way a cdb file and a database handle the data are quite different and we need to add an order field to the database to make it able to store entries in a fixed order and add functions to the cdb back end to support the valias calls. someday...

yeah, i've been complaining about the "fixed order" stuff for about four years now.

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.

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 nobody cares, i'm just going to leave it the way it is right now.

Rick   --  KD7VKZ

us ham radio guys, we turn up in the strangest places... and i think it's cool that you got your license five days after i did.

73 de KG4ZOW

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

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to