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.
