 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
9 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: MYSQL_SELECT_...| From | Sent On | Attachments |
|---|---|---|
| p dont think | Dec 17, 2004 1:30 pm | |
| Lindsay Haisley | Dec 17, 2004 4:35 pm | |
| p dont think | Dec 21, 2004 12:21 pm | |
| p dont think | Dec 22, 2004 1:46 pm | |
| p dont think | Dec 22, 2004 3:27 pm | |
| p dont think | Dec 22, 2004 4:39 pm | |
| Sam Varshavchik | Dec 22, 2004 5:02 pm | |
| p dont think | Dec 22, 2004 5:06 pm | |
| p dont think | Dec 22, 2004 5:09 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [courier-users] Re: MYSQL_SELECT_CLAUSE again | Actions... |
|---|---|---|
| From: | p dont think (pdon...@angrynerds.com) | |
| Date: | Dec 22, 2004 4:39:41 pm | |
| List: | net.sourceforge.lists.courier-users | |
One problem solved, one more problem identified. Sigh...
The problem here was that comment lines with a backslash on the end were being wrapped. I had such a comment line right above my MYSQL_SELECT_CLAUSE, so my real MYSQL_SELECT_CLAUSE was getting folded into a comment line. It looked similar to this:
#MYSQL_SELECT_CLAUSE SELECT id, crypt_pwd, clear_pwd, \ MYSQL_SELECT_CLAUSE SELECT id, crypt_pwd, '', \
I am not certain, but shouldn't such backslashes be ignored in comment lines? I'm sure I wouldn't be the only person surprised by this. Attached is a patch that fixes that.
However, now I see in my logs that $(service) is not giving what it promised. I am using $(service) with the hopes that it can tell me the difference between users hitting imapd-ssl and those using imapd. However, *both* are showing "imap" in my query logs. Pop3 has the same problem, pop3d-ssl connections have $(service) as merely pop3.
Can anyone please comment on why that would happen? Grumble grumble....
Cheers!
p dont think wrote:
bump.
is there any reason why MYSQL_SELECT_CLAUSE would be ignored?
If anyone is watching and can be of help, I just inserted a print of the MYSQL_SELECT_CLAUSE right after its value is read in authlib/authmysqllib.c on line 650, and its value is null. Er, what? I double checked that there isn't a typo in the name MYSQL_SELECT_CLAUSE and that it is not commented out, but it doesn't appear to be anything easy like that.
Before I dig further, can anyone comment why read_env() wouldn't read it or wouldn't find it?
select_clause=read_env("MYSQL_SELECT_CLAUSE");
Thanks,
Paul
Lindsay Haisley <fmouse-courier <at> fmp.com> writes:
This was a config error on my part. I corresponded with Sam off-list.
Hrm, that's not quite what I wanted to hear. ;)
Here's my post to him:
From fmouse <at> fmp.com Wed Sep 15 18:03:04 2004 Date: Wed, 15 Sep 2004 18:03:04 -0500 From: Lindsay Haisley <fmouse <at> fmp.com> To: Sam Varshavchik <mrsam <at> courier-mta.com> Subject: Re: Any progress with MYSQL_SELECT_CLAUSE ?? Organization: FMP Computer Services
It was my error. The box I'm working on doesn't have a domain name yet (I'm after the owners to give it one!) and I didn't have DEFAULT_DOMAIN set in authmysqlrc. This was causing MYSQL_SELECT_CLAUSE to fail because defdomain wasn't defined in parse_select_clause(). If I didn't use
Hrm. I don't have that defined, either, but never have, and never have had any problem as such. But for fun, I defined it and restarted the auth daemon. Watchin the SQL logs, this doesn't seem to change anything: I see zero errors, but the query being fed to MySQL is the one built out of the other fields in authmysqlrc.
The comments suggest that as long as you define MYSQL_SELECT_CLAUSE that the other query-related fields will be ignored. Is this inaccurate? Do I need to comment or otherwise remove any of them? If so, which ones?
Just to make sure I'm not going insane, I changed the value of some of those other fields just to make sure I'm using the right config file, and the change was immediately reflected in my MySQL logs.
So there is something that is not allowing the use of MYSQL_SELECT_CLAUSE, but I don't see what it would be. Can anyone shed some light?
If I have to poke in the code, I will (rather not...) -- can someone point me to the right place (files/fxns)?
Thanks,
Paul
MYSQL_SELECT_CLAUSE I could successfully run courier with authmysql using the IP address for the box.
Sorry for the fire drill!!
Thus spake Sam Varshavchik on Wed, Sep 15, 2004 at 05:33:40PM CDT
Lindsay Haisley writes:
I'm back to working on the customer system I mentioned previously using courier 0.46. Has any progress been made in the development version on the MYSQL_SELECT_CLAUSE problem I inquired about a couple of weeks ago? I'm going to work on debugging it, but don't want to reinvent the wheel if it's already been solved.
Sorry, haven't get around to it just yet. I'll let you know as soon as I have something. Although, someone on the mailing list did confirm that MYSQL_SELECT_CLAUSE works for them, so???
Thus spake p dont think on Fri, Dec 17, 2004 at 03:31:59PM CST
All,
Wondering if this has been looked at lately. I get slightly different side effects, wherein the select clause seems to simply be ignored, but nevertheless, it might be the same problem. I suppose I can take a look at the code, not that I have the time, but if someone wants to point me to the right place in the code maybe I'll make the time...
Thanks,
Paul
Original Message: =========================
From: Sam Varshavchik <mrsam <at> courier-mta.com> Subject: Re: MYSQL_SELECT_CLAUSE again Newsgroups: gmane.mail.imap.courier.general Date: Wed, 01 Sep 2004 18:48:04 -0400
Lindsay Haisley writes:
No help there, either. I added it to authdaemonrc, and also as an enviroment var in the authdaemond startup line in /etc/init.d/courier, but I don't get anything informative in syslog, only the usual ....
Sep 1 11:17:58 mail01 courieresmtpd: error,relay=::ffff:127.0.0.1,ident=root,from=<fmouse <at> bbadmin.com>,to=<foo <at> bbadmin.com>: 450 Service temporarily unavailable.
I suppose I'm going to have to hack some debugging code into authmysqllib.c in and around parse_select_clause() and calls to it. I don't really have time to mess with it right now, but maybe next week....
Presuming that the environment variable is properly set, the lack of any debugging output does narrow the culprit somewhat.
My time is also a bit tight, but I also intend to investigate it. Let's see who finds this bug first.
--- authlib/authmysqllib.c.orig 2004-12-22 16:03:21.000000000 -0800 +++ authlib/authmysqllib.c 2004-12-22 16:13:48.000000000 -0800 @@ -44,7 +44,8 @@ static size_t mysqlauth_size=0; size_t i; char *p=0; -int l=strlen(env); +int l=strlen(env), + is_comment=0;
if (!mysqlauth) { @@ -67,10 +68,18 @@ } mysqlauth[mysqlauth_size=buf.st_size]=0;
+ if (mysqlauth[0] == '#') + { + is_comment = 1; + } + else + { + is_comment = 0; + } for (i=0; i<mysqlauth_size; i++) if (mysqlauth[i] == '\n') { /* sie...@pld.org.pl */ - if (!i || mysqlauth[i-1] != '\\') + if (!i || is_comment || mysqlauth[i-1] != '\\') { mysqlauth[i]='\0'; } @@ -78,6 +87,15 @@ { mysqlauth[i]=mysqlauth[i-1]= ' '; } + + if (mysqlauth[i+1] == '#') + { + is_comment = 1; + } + else + { + is_comment = 0; + } } fclose(f); }