From: John P. <jpe...@ro...> - 2005-01-03 20:04:03
|
I downloaded 1.2.6 for testing (since I was formerly running 1.2.2). If I log in as an ordinary user and attempt to set the Vacation message, I get an error in the Apache log: Premature end of script headers but if I resubmit exactly the same page, it works. What I've discovered is that if I check the virtual user directory after the failure but before the second submit, the .qmail file has been created, but it is empty. After the second submit, the .qmail file is populated and the vacation directory exists. This is 100% repeatable. Any clues? John p.s. anyone want a couple of my local patches: 1) suppress Forward/Deleted status for non-admin users 2) enable to use of CRACKLIB for strong password support -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
From: Tom C. <to...@to...> - 2005-01-03 20:29:58
|
On Jan 3, 2005, at 12:04 PM, John Peacock wrote: > but if I resubmit exactly the same page, it works. What I've > discovered is that if I check the virtual user directory after the > failure but before the second submit, the .qmail file has been > created, but it is empty. After the second submit, the .qmail file is > populated and the vacation directory exists. > > This is 100% repeatable. > > Any clues? Yes. I was so focused on making sure I was copying unrecognized lines from the old .qmail file, that I didn't fully test the code on accounts without a .qmail file! Here's the patch. The block of 8 lines removed in the second section are actually just indented. This will go into CVS shortly, and will be in the next release. Thanks for catching it. --- user.c 23 Dec 2004 18:39:48 -0000 1.11.2.9 +++ user.c 3 Jan 2005 20:25:33 -0000 @@ -904,9 +904,6 @@ } } } - if (olddotqmail == NULL) { - olddotqmail = ""; - } fs = fopen (dotqmailfn, "w"); @@ -914,18 +911,20 @@ * lines to the new .qmail file. */ emptydotqmail = 1; - dotqmailline = strtok (olddotqmail, "\n"); - while (dotqmailline) { - if ( (*dotqmailline == '|') && - (strstr (dotqmailline, "/true delete") == NULL) && - (strstr (dotqmailline, "/autorespond ") == NULL) && - (strstr (dotqmailline, SPAM_COMMAND) == NULL) ) { - fprintf (fs, "%s\n", dotqmailline); - emptydotqmail = 0; + if (olddotqmail != NULL) { + dotqmailline = strtok (olddotqmail, "\n"); + while (dotqmailline) { + if ( (*dotqmailline == '|') && + (strstr (dotqmailline, "/true delete") == NULL) && + (strstr (dotqmailline, "/autorespond ") == NULL) && + (strstr (dotqmailline, SPAM_COMMAND) == NULL) ) { + fprintf (fs, "%s\n", dotqmailline); + emptydotqmail = 0; + } + dotqmailline = strtok (NULL, "\n"); } - dotqmailline = strtok (NULL, "\n"); + free (olddotqmail); } - if (olddotqmail != NULL) free (olddotqmail); /* Decide on what to write to the new .qmail file after any old program * delivery lines are written. > p.s. anyone want a couple of my local patches: > > 1) suppress Forward/Deleted status for non-admin users Others are interested in having this, and if you've built it as a compile-time option, I'd love to see it. Does it preserve the fields as hidden for non-admins? > 2) enable to use of CRACKLIB for strong password support Yes, I'd be interested in that as well. -- Tom Collins - to...@to... QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/ |
From: John P. <jpe...@ro...> - 2005-01-03 21:00:08
Attachments:
mod_user.diff
cracklib.diff
|
Tom Collins wrote: > Here's the patch. The block of 8 lines removed in the second section > are actually just indented. This will go into CVS shortly, and will be > in the next release. Thanks for catching it. Cool. I couldn't quite get patch to apply that (probably due to cut and paste from the e-mail), but I did it manually and it tests fine. >> 1) suppress Forward/Deleted status for non-admin users > > > Others are interested in having this, and if you've built it as a > compile-time option, I'd love to see it. Does it preserve the fields as > hidden for non-admins? Nah, I just suppressed the appropriate bits with ##ta ##tt blocks. I suppose I can see if I can configure-ify it, but I find configure to be an unholy mess in general and I have to pound on (with much swearing) until it submits. I've attached the trivial patch as mod_user.diff. > >> 2) enable to use of CRACKLIB for strong password support > > > Yes, I'd be interested in that as well. Also attached (cracklib.diff). Obviously, you have to autoconf/automake to regenerate configure... Share and enjoy! John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
From: Rick W. <vc...@de...> - 2005-01-04 00:36:56
|
John Peacock wrote: > Tom Collins wrote: >> Others are interested in having this, and if you've built it as a >> compile-time option, I'd love to see it. Does it preserve the fields >> as hidden for non-admins? > > > Nah, I just suppressed the appropriate bits with ##ta ##tt blocks. I > suppose I can see if I can configure-ify it, but I find configure to be > an unholy mess in general and I have to pound on (with much swearing) > until it submits. I've attached the trivial patch as mod_user.diff. Make you changes based on a #define WHATEVER in config.h. Remember, config.h will be rebuilt each time you run ./configure. Just add your define by hand when you want the feature active. Post the patch here, tell me the name(s) of the define(s) and what you want the --enable-whatever to look like. I'll handle the build system. Rick |
From: John P. <jpe...@ro...> - 2005-01-04 00:54:29
|
Rick Widmer wrote: > Make you changes based on a #define WHATEVER in config.h. Remember, > config.h will be rebuilt each time you run ./configure. Just add your > define by hand when you want the feature active. Yes, but the changes are all in the html files, not in C files, so it is a little more complicated than that. It's probably just as easy to provide two copies of mod_user.html and just copy the correct one into place based on the configure option. Patches welcome... ;) In my mind, I cannot see any reason to allow an ordinary user the ability to disable their own e-mail account (it encourages carbon-based errors), so I have applied the patch on a site-wide basis. Being a BOFH in a corporate environment has its benefits! ;) John |
From: Tom C. <to...@to...> - 2005-01-04 02:00:30
|
On Jan 3, 2005, at 4:53 PM, John Peacock wrote: > Yes, but the changes are all in the html files, not in C files, so it > is a little more complicated than that. It's probably just as easy to > provide two copies of mod_user.html and just copy the correct one into > place based on the configure option. Patches welcome... ;) > > In my mind, I cannot see any reason to allow an ordinary user the > ability to disable their own e-mail account (it encourages > carbon-based errors), so I have applied the patch on a site-wide > basis. Being a BOFH in a corporate environment has its benefits! ;) I think that ultimately what we'll want are flags to enable/disable the blackhole and forward features on the modify-user page. Maybe something for the .qmailadmin-limits file? No access, admin-only or user access to each? Include vacation in that? I think we could accomplish it with lots of ##t tags and some more code (e.g., only show this section if the user is allowed to enable forward). My only concern is that we make sure .qmail files aren't hosed up due to the rendered page not matching the actual file (e.g., if the user has forwarding enabled, but can't modify it themselves, what happens if they edit their config? When I get around to releasing the simple change-password interface, it should simplify things a bit. -- Tom Collins - to...@to... QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/ |