atom feed11 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: MYSQL_SELECT_...
FromSent OnAttachments
Lindsay HaisleyAug 30, 2004 9:14 am 
Sam VarshavchikAug 30, 2004 4:58 pm 
Lindsay HaisleyAug 31, 2004 12:40 pm 
Ben KennedyAug 31, 2004 1:06 pm 
Lindsay HaisleyAug 31, 2004 1:15 pm 
Keith WillisAug 31, 2004 2:06 pm 
Sam VarshavchikAug 31, 2004 3:37 pm 
Lindsay HaisleyAug 31, 2004 6:26 pm 
Sam VarshavchikSep 1, 2004 4:09 am 
Lindsay HaisleySep 1, 2004 9:24 am 
Sam VarshavchikSep 1, 2004 3:48 pm 
Subject:Re: [courier-users] Re: MYSQL_SELECT_CLAUSE again
From:Lindsay Haisley (fmou@fmp.com)
Date:Aug 31, 2004 6:26:38 pm
List:net.sourceforge.lists.courier-users

Thus spake Sam Varshavchik on Tue, Aug 31, 2004 at 05:37:33PM CDT

Lindsay Haisley writes:

Thus spake Sam Varshavchik on Mon, Aug 30, 2004 at 06:58:29PM CDT

Lindsay Haisley writes:

I have MYSQL_SELECT_CLAUSE working nicely with a non-standard query on courier-0.38.2 and authmysql. I'm trying to get courier with authmysql set up and working on a customer's mail system the same way, and it looks as if MYSQL_SELECT_CLAUSE isn't working at all in courier-0.46.

Nothing shows up in the mysql log so apparently no mysql query is being made by the mail server.

This indicates a connectivity problem. Check your login parameters:

MYSQL_SERVER MYSQL_USERNAME MYSQL_PASSWORD

These are OK. If I comment out MYSQL_SELECT_CLAUSE and let authmysql build its own query, then everything is hunky-dory, the query works, and shows up in the mysql log, so it's not connectivity.

That does indicate a bug.

Set DEBUG_LOGIN=2; this generates a few debugging messages in syslog.

Also try replacing $(localpart) with a constant string, 'foo'. Perhaps there's a bug in variable substitution getting triggered.

OK, apparently esmtpd doesn't support DEBUG_LOGIN=2 so I put it in pop3d, which does support it, and here's the output.

Aug 31 20:05:27 mail01 pop3d: Connection, ip=[::ffff:127.0.0.1] Aug 31 20:05:33 mail01 pop3d: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], command=USER Aug 31 20:05:41 mail01 pop3d: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], command=PASS Aug 31 20:05:41 mail01 pop3d: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], username=foo Aug 31 20:05:41 mail01 pop3d: LOGIN: DEBUG: ip=[::ffff:127.0.0.1],
password=g00ber Aug 31 20:05:41 mail01 pop3d: authdaemon: starting client module Aug 31 20:05:41 mail01 pop3d: authdaemon: TEMPFAIL - no more modules will be
tried Aug 31 20:05:46 mail01 pop3d: LOGIN FAILED, ip=[::ffff:127.0.0.1]

A POP connection just shows "login failed". authmysql is the only module enabled in authdaemond, and ps shows 6 instances of authdaemond.mysql running. Again, the mysql logs show that _no_ query was even tried, whether using pop3 or esmtp. Swapping out $(localpart) for an explicit username ('foo') makes no difference.

The MYSQL_SELECT query is now about as simple as it gets:

MYSQL_SELECT_CLAUSE select * from passwd where id = 'foo'

The fields in the db are in the right order, although it makes no difference since no query is performed. I had tried enumerating the fields by name in imitation of the query performed with no MYSQL_SELECT_CLAUSE, but it makes no difference either way.

-- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (Travis W. Redfish) | <http://www.fmp.com/pubkeys> http://www.fmp.com | ("The Roadie") |