I have updated HEAD in cvs to include everything that has been changed in 5.4 as of last night. There wasn't very much, but there were bug fixes, and some improved documentation.
Ken Jones wrote:
That would be great if you could check it out.
I don't get a segfault here. I've tried with 8 existing domains; delete all domains, and clean out control files by hand; fresh install based on Bill Shupp's toaster. What is the state of your existing virtual domains and related qmail configuration? Specifically users/assign, control/morercpthosts, control/rcpthosts, control/virtualdomains, control/locals?
Send me a copy of those files and I'll see if I can get it to crash.
I'm wondering what the reason was behind redoing that code. Seems to work fine in the past.
When I tested the daemon against 1500 domains it took about 10 seconds to obtain and transfer the domain list... way too long. Since the daemon returned the domain list out of order I had to load all 1500 entries, sort them then display a page that only contains 20 of them.
So I made the daemon able to return any arbitrary single page of users or domains. You specify a page number, and the number of entries on the page. Now the daemon needs access to the lists in order. To add a new entry we are already reading the existing file, copying it to a new file and adding the new record at the end. Change that to insert the record before the first record that goes by with that is > and you have an insertion sort with almost no extra effort. If none are > then add it at the end of the file. This is handled by the function update_file().
Since vpopmail already used the same function to manage all the qmail control files, I continued that tradition. There is little other reason to maintain sort order on any control file except users/assign.
While update_file is copying the file it is also counting the number of entries in it, and checking the order of each entry pair. If it finds any records out of order it creates an array of string pointers sized to handle the number of records in the file; loads the new file into strings pointed to by the array; call qsort on them; then writes the data back to the new file. Whew... but that only happens the first time the new version sees a file from an older version, or if someone has changed the order of records in a control file by hand.
Finally it renames the new file over the old file, and unlocks it.
Function extract_domain takes the entry found in the input file and returns a normalized string for sorting. users/assign is a different format from the rest of the files in control, so you pass 1 in the last parm to change how the files are decoded.
Currently the sort order would result in this:
developersdesk.com developersdesk.net developersdesk.org rickwidmer.com mail.rickwidmer.com smtp.rickwidmer.com rickwidmer.net
The sort order is second level domain, top level domain, host name (if any). It tends to group customers together.
It was mentioned on the list that might not be the best for someone with mostly international domains, but no one ever told mw what would be better. I can change sort order fairly easily at the ./configure level.
