[Dovecot] Dovecot Authentication Problem - Help pls!
Hello List,
This is dovecot 1.0.0 on FreeBSD 4.11-STABLE. I did not provide this
information before:-)
I am back again and I think I am edging closer to getting a solution.
I have done some modifications and now dovecot gives me a different
error message than before....
Here is what I have for the password_query and user_query
password_query = SELECT popbox.cleartext AS password FROM popbox, domain \
WHERE popbox.local_part = 'eddie' AND popbox.domain_name = 'demo.wananchi.com' \
AND popbox.domain_name = domain.domain_name;
+----------+
| password |
+----------+
| boeing8 |
+----------+
user_query = SELECT CONCAT(domain.path, '/', popbox.mbox_name) as home, \
69 as uid, 6 as gid FROM popbox, domain WHERE popbox.local_part = 'eddie' \
AND popbox.domain_name = 'demo.wananchi.com' AND \
popbox.domain_name = domain.domain_name;
+--------------------------------------------+-----+-----+
| home | uid | gid |
+--------------------------------------------+-----+-----+
| /var/spool/virtual/demo.wananchi.com/eddie | 69 | 6 |
+--------------------------------------------+-----+-----+
When I test to connect to the pop3 daemon, this is what happens now:
root@ns2]#telnet 0 7173
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
+OK Welcome. Dovecot is Ready to serve your emails.
user eddie@demo.wananchi.com
+OK
pass boeing8
-ERR [IN-USE] Internal login failure. Refer to server log for more information.
Connection closed by foreign host.
...and this is what dovecot writes to the log:
[root@ns2]#less /var/log/dovecot.log
dovecot: May 30 12:00:04 Info: auth(default): client in: AUTH 1 PLAIN service=POP3 secured lip=62.8.64.4 rip=62.8.64.4 resp=AGVkZGllQGRlbW8ud2FuYW5jaGkuY29tAGJvZWluZzg=
dovecot: May 30 12:00:04 Info: auth-worker(default): mysql: Connected to localhost (virtualemail)
dovecot: May 30 12:00:04 Info: auth-worker(default): sql(eddie@demo.wananchi.com,62.8.64.4): query: SELECT popbox.cleartext AS password FROM popbox, domain WHERE popbox.local_part = 'eddie' AND popbox.domain_name = 'demo.wananchi.com' AND popbox.domain_name = domain.domain_name
dovecot: May 30 12:00:04 Info: auth(default): client out: OK 1 user=eddie@demo.wananchi.com
dovecot: May 30 12:00:04 Info: auth(default): master in: REQUEST 2 36772 1
dovecot: May 30 12:00:04 Info: auth-worker(default): sql(eddie@demo.wananchi.com,62.8.64.4): SELECT CONCAT(domain.path, '/', popbox.mbox_name) as home, 69 as uid, 6 as gid FROM popbox, domain WHERE popbox.local_part = 'eddie' AND popbox.domain_name = 'demo.wananchi.com' AND popbox.domain_name = domain.domain_name
dovecot: May 30 12:00:05 Error: child 39853 (auth-worker) killed with signal 11
dovecot: May 30 12:00:05 Info: auth(default): master out: FAIL 2
dovecot: May 30 12:00:05 Info: pop3-login: Internal login failure: user=
On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote:
Here is a backtrace of the dovecot-auth crash:
Two problems with it:
#0 0x805dc00 in userdb_blocking_lookup ()
Debugging symbols were stripped. Could you try building it without removing them, at least from dovecot-auth binary? I guess "make install" does the stripping, so maybe copying the file manually would preserve it. You can anyway check this with "file dovecot-auth" to see if it says "stripped" or "not stripped".
(gdb) bt #0 0x805dc00 in userdb_blocking_lookup () #1 0x805dd50 in userdb_blocking_lookup () #2 0x806175a in sql_drivers_register_all () #3 0x8060d1c in sql_query () #4 0x805de62 in userdb_blocking_lookup () #5 0x8055724 in auth_stream_is_empty () #6 0x80557f4 in auth_stream_is_empty () #7 0x8055894 in auth_stream_is_empty () #8 0x80668ac in io_loop_handler_run () #9 0x80662a1 in io_loop_run () #10 0x805770f in main () #11 0x804fd52 in _start ()
Also this backtrace is corrupted for some reason. One (pretty) sure way to get a non-corrupted backtrace is to attach gdb to dovecot-auth while it's still running:
gdb attach
* On 04/06/07 02:59 +0300, Timo Sirainen wrote:
| On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote:
| > Here is a backtrace of the dovecot-auth crash:
|
| Two problems with it:
|
| > #0 0x805dc00 in userdb_blocking_lookup ()
|
| Debugging symbols were stripped. Could you try building it without
| removing them, at least from dovecot-auth binary? I guess "make install"
| does the stripping, so maybe copying the file manually would preserve
| it. You can anyway check this with "file dovecot-auth" to see if it says
| "stripped" or "not stripped".
|
| > (gdb) bt
| > #0 0x805dc00 in userdb_blocking_lookup ()
| > #1 0x805dd50 in userdb_blocking_lookup ()
| > #2 0x806175a in sql_drivers_register_all ()
| > #3 0x8060d1c in sql_query ()
| > #4 0x805de62 in userdb_blocking_lookup ()
| > #5 0x8055724 in auth_stream_is_empty ()
| > #6 0x80557f4 in auth_stream_is_empty ()
| > #7 0x8055894 in auth_stream_is_empty ()
| > #8 0x80668ac in io_loop_handler_run ()
| > #9 0x80662a1 in io_loop_run ()
| > #10 0x805770f in main ()
| > #11 0x804fd52 in _start ()
|
| Also this backtrace is corrupted for some reason. One (pretty) sure way
| to get a non-corrupted backtrace is to attach gdb to dovecot-auth while
| it's still running:
|
| gdb attach
On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote:
I have built and manually copied dovecot-auth to the install destination and now it id not stripped. Now this is the result of the debug: .. #0 0x805d848 in sql_query_get_result () (gdb) bt
Now this backtrace looks correct, but it's still stripped. Otherwise it would have shown parameters inside the ().
Did you build manually from the tarball or using ports? Building it with -g and without -O2 would be the best way to debug this properly. I don't know about ports, but using tarball you're able to do this with:
CFLAGS=-g ./configure
Once you do get the sql_query_get_result() to show a bit more information, type also these:
p i p fields_count p name p value p *auth_result
While trying the other method you have detailed, I just don't seem to get it right:
[root@ns2]#ps ax | grep dove 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot 11447 ?? S 0:00.02 dovecot-auth 17279 p2 RV 0:00.00 grep dove (csh)
[root@ns2]#gdb attach 11447 -w process
I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth -w" process. Apparently it hasn't been started yet. You could do a login with invalid user/pass to make sure it's created but without getting it to crash. But this isn't really needed since you managed to get a noncorrupted backtrace anyway using the core.
* On 04/06/07 15:16 +0300, Timo Sirainen wrote:
| On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote:
| > I have built and manually copied dovecot-auth to the install destination
| > and now it id not stripped. Now this is the result of the debug:
| ..
| > #0 0x805d848 in sql_query_get_result ()
| > (gdb) bt
|
| Now this backtrace looks correct, but it's still stripped. Otherwise it
| would have shown parameters inside the ().
Oh, so do I need to build everything unstripped? That would be difficult
when using the ports.
| Did you build manually from the tarball or using ports?
From the ports!
| Building it with -g and without -O2 would be the best way to
| debug this properly. I don't know about ports, but using
| tarball you're able to do this with:
|
| CFLAGS=-g ./configure
|
| Once you do get the sql_query_get_result() to show a bit more
| information, type also these:
|
| p i
| p fields_count
| p name
| p value
| p *auth_result
I do believe this problem is something to do with the OS version on
which it is happening, and perhaps might be so difficult to get round
to solving. All this is happening on FreeBSD 4.11, with MySQL-4.0.27.
This system could be "dirty" - some stale libscould be lying around!
I have simulated a similar setup on FreeBSD 5.5 and 6.2 both using
MySQL-4.1.22, and FreeBSD 7.x using MySQL-5.0.41 and there is no
crash at all. I create a file hierarchy for the mail_location and
everything seems to work perfectly.
The only problem I am facing is that the actual mail_store that I
need to move to another server via imapsync does live on the
FreeBSD 4.11 box!
It would be nice to get to solve this problem, as that would make
life easy for me, but now I am beginning to think that I could as
well rsync the data onto another machine and access it from there.
NFS-mounting the mail store would be another option but I hate to
deal with NFS-related problems too:-)
| > While trying the other method you have detailed, I just don't seem to get it right:
| >
| > [root@ns2]#ps ax | grep dove
| > 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot
| > 11447 ?? S 0:00.02 dovecot-auth
| > 17279 p2 RV 0:00.00 grep dove (csh)
| >
| > [root@ns2]#gdb attach 11447 -w process
|
| I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth
| -w" process. Apparently it hasn't been started yet. You could do a login
| with invalid user/pass to make sure it's created but without getting it
| to crash. But this isn't really needed since you managed to get a
| noncorrupted backtrace anyway using the core.
Ok. Allow me to understand this, even if just for another day..
-bash-2.05b$ sudo su
Password:
[root@ns2]#ps ax | grep dove
43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot
43803 ?? S 0:00.05 dovecot-auth
[root@ns2]#gdb attach 43803
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
attach: No such file or directory.
/mailstore/home/wash/43803: No such file or directory.
Attaching to process 43803
0x2812bc50 in ?? ()
(gdb) cont
Continuing.
# At this point, I go to another shell where I attempt pop3 login.
The login fails with an error, of course.
Now, what am I supposed to type/do on the gdb shell?
As you can see, it has the word "Continuing"... anything I need to type
to get it our of that so that it again accepts my commands?
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+======================================================================+
|\ _,,,---,,_ | Odhiambo Washington
* On 04/06/07 16:27 +0300, Wash wrote:
| * On 04/06/07 15:16 +0300, Timo Sirainen wrote:
| | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote:
| | > I have built and manually copied dovecot-auth to the install destination
| | > and now it id not stripped. Now this is the result of the debug:
| | ..
| | > #0 0x805d848 in sql_query_get_result ()
| | > (gdb) bt
| |
| | Now this backtrace looks correct, but it's still stripped. Otherwise it
| | would have shown parameters inside the ().
|
| Oh, so do I need to build everything unstripped? That would be difficult
| when using the ports.
|
|
| | Did you build manually from the tarball or using ports?
|
| From the ports!
|
|
| | Building it with -g and without -O2 would be the best way to
| | debug this properly. I don't know about ports, but using
| | tarball you're able to do this with:
| |
| | CFLAGS=-g ./configure
| |
| | Once you do get the sql_query_get_result() to show a bit more
| | information, type also these:
| |
| | p i
| | p fields_count
| | p name
| | p value
| | p *auth_result
|
|
| I do believe this problem is something to do with the OS version on
| which it is happening, and perhaps might be so difficult to get round
| to solving. All this is happening on FreeBSD 4.11, with MySQL-4.0.27.
| This system could be "dirty" - some stale libscould be lying around!
|
| I have simulated a similar setup on FreeBSD 5.5 and 6.2 both using
| MySQL-4.1.22, and FreeBSD 7.x using MySQL-5.0.41 and there is no
| crash at all. I create a file hierarchy for the mail_location and
| everything seems to work perfectly.
|
| The only problem I am facing is that the actual mail_store that I
| need to move to another server via imapsync does live on the
| FreeBSD 4.11 box!
|
| It would be nice to get to solve this problem, as that would make
| life easy for me, but now I am beginning to think that I could as
| well rsync the data onto another machine and access it from there.
| NFS-mounting the mail store would be another option but I hate to
| deal with NFS-related problems too:-)
|
|
| | > While trying the other method you have detailed, I just don't seem to get it right:
| | >
| | > [root@ns2]#ps ax | grep dove
| | > 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot
| | > 11447 ?? S 0:00.02 dovecot-auth
| | > 17279 p2 RV 0:00.00 grep dove (csh)
| | >
| | > [root@ns2]#gdb attach 11447 -w process
| |
| | I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth
| | -w" process. Apparently it hasn't been started yet. You could do a login
| | with invalid user/pass to make sure it's created but without getting it
| | to crash. But this isn't really needed since you managed to get a
| | noncorrupted backtrace anyway using the core.
|
| Ok. Allow me to understand this, even if just for another day..
|
| -bash-2.05b$ sudo su
| Password:
| [root@ns2]#ps ax | grep dove
| 43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot
| 43803 ?? S 0:00.05 dovecot-auth
| [root@ns2]#gdb attach 43803
| GNU gdb 4.18 (FreeBSD)
| Copyright 1998 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you are
| welcome to change it and/or distribute copies of it under certain conditions.
| Type "show copying" to see the conditions.
| There is absolutely no warranty for GDB. Type "show warranty" for details.
| This GDB was configured as "i386-unknown-freebsd"...
|
| attach: No such file or directory.
|
|
| /mailstore/home/wash/43803: No such file or directory.
| Attaching to process 43803
| 0x2812bc50 in ?? ()
| (gdb) cont
| Continuing.
|
| # At this point, I go to another shell where I attempt pop3 login.
| The login fails with an error, of course.
|
| Now, what am I supposed to type/do on the gdb shell?
| As you can see, it has the word "Continuing"... anything I need to type
| to get it our of that so that it again accepts my commands?
While still waiting for clarification so that I get to have ideas how
developers debug crashes, I got round to solving this problem on FreeBSD
4.11.
It turns out that dovecot-auth was linking against an old library of
libmysqlclient that was lying somewhere in /usr/local/lib/compat/pkg.
I am not sure what created that libs container, but all I had to do
was to make a symlink to the correct library inside this container,
rebuild dovecot from the ports and voila! No more dovecot-auth crashes.
Thanks, Timo, for your time on trying to help me with this. I am
awaiting your answers to the questions above - on gdb.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+======================================================================+
|\ _,,,---,,_ | Odhiambo Washington
Odhiambo WASHINGTON wrote:
- On 04/06/07 16:27 +0300, Wash wrote: | * On 04/06/07 15:16 +0300, Timo Sirainen wrote: | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: | | > I have built and manually copied dovecot-auth to the install destination | | > and now it id not stripped. Now this is the result of the debug: | | .. | | > #0 0x805d848 in sql_query_get_result () | | > (gdb) bt | | | | Now this backtrace looks correct, but it's still stripped. Otherwise it | | would have shown parameters inside the (). | | Oh, so do I need to build everything unstripped? That would be difficult | when using the ports. |
Let me help you then! :-)
cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install
Will install an unstripped Dovecot. If you use portupgrade you can set these are MAKE_ARGS in pkgtools.conf if you want to always have one available.
Dominic
* On 05/06/07 15:51 +0100, Dominic Marks wrote:
| Odhiambo WASHINGTON wrote:
| > * On 04/06/07 16:27 +0300, Wash wrote:
| > | * On 04/06/07 15:16 +0300, Timo Sirainen wrote:
| > | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote:
| > | | > I have built and manually copied dovecot-auth to the install
| > destination
| > | | > and now it id not stripped. Now this is the result of the debug:
| > | | ..
| > | | > #0 0x805d848 in sql_query_get_result ()
| > | | > (gdb) bt
| > | |
| > | | Now this backtrace looks correct, but it's still stripped. Otherwise
| > it
| > | | would have shown parameters inside the ().
| > |
| > | Oh, so do I need to build everything unstripped? That would be difficult
| > | when using the ports.
| > |
|
| Let me help you then! :-)
|
| cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install
|
| Will install an unstripped Dovecot. If you use portupgrade you can set
| these are MAKE_ARGS in pkgtools.conf if you want to always have one
| available.
Wow!
Thanks for that tip! Kept for future reference.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+======================================================================+
|\ _,,,---,,_ | Odhiambo Washington
On Tuesday June 05, 2007 at 10:51:04 (AM) Dominic Marks wrote:
Odhiambo WASHINGTON wrote:
- On 04/06/07 16:27 +0300, Wash wrote: | * On 04/06/07 15:16 +0300, Timo Sirainen wrote: | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: | | > I have built and manually copied dovecot-auth to the install destination | | > and now it id not stripped. Now this is the result of the debug: | | .. | | > #0 0x805d848 in sql_query_get_result () | | > (gdb) bt | | | | Now this backtrace looks correct, but it's still stripped. Otherwise it | | would have shown parameters inside the (). | | Oh, so do I need to build everything unstripped? That would be difficult | when using the ports. |
Let me help you then! :-)
cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install
Will install an unstripped Dovecot. If you use portupgrade you can set these are MAKE_ARGS in pkgtools.conf if you want to always have one available.
You could also go this route.
Look at /usr/ports/Mk/bsd.port.mk in this section:
.if defined(WITH_DEBUG) && !defined(WITHOUT_DEBUG) STRIP= #none STRIP_CMD= ${TRUE} DEBUG_FLAGS?= -g CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} .endif
As you can see, if WITH_DEBUG is defined, then $STRIP will be a empty, DEBUG_FLAGS and CFLAGS changes too.
Simply set 'WITH_DEBUG=yes' in the environment on on the command line. I also set 'DEBUG_FLAGS=-ggdb3' which supplies slightly more output. That is of course your call. It is important to realize that the default is "CFLAGS=-O2 -fno-strict-aliasing -pipe". You need to change the '02' to '0' or to insure that proper debug information is available at run time. Using the 'WITH_DEBUG=yes' accomplishes that objective.
HTH
-- Gerard
DISCLAIMER
If you find a posting or message from me
offensive, inappropriate, or disruptive,
please ignore it. If you don't know how to
ignore a posting, complain to me and I will
be only too happy to demonstrate... ;-)On Mon, 2007-06-04 at 16:27 +0300, Odhiambo WASHINGTON wrote:
-bash-2.05b$ sudo su Password: [root@ns2]#ps ax | grep dove 43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot 43803 ?? S 0:00.05 dovecot-auth [root@ns2]#gdb attach 43803 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...
attach: No such file or directory.
Oh, so BSD needs to have the path specified. I knew the "attach" wasn't really correct or meaningful, but I've been using it anyway. So the correct way would be
gdb /usr/local/libexec/dovecot/dovecot-auth 43803
# At this point, I go to another shell where I attempt pop3 login. The login fails with an error, of course.
Now, what am I supposed to type/do on the gdb shell? As you can see, it has the word "Continuing"... anything I need to type to get it our of that so that it again accepts my commands?
dovecot-auth process should have crashed and gdb dropped back to accepting commands.
* On 04/06/07 02:59 +0300, Timo Sirainen wrote:
| On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote:
| > Here is a backtrace of the dovecot-auth crash:
|
| Two problems with it:
|
| > #0 0x805dc00 in userdb_blocking_lookup ()
|
| Debugging symbols were stripped. Could you try building it without
| removing them, at least from dovecot-auth binary? I guess "make install"
| does the stripping, so maybe copying the file manually would preserve
| it. You can anyway check this with "file dovecot-auth" to see if it says
| "stripped" or "not stripped".
|
| > (gdb) bt
| > #0 0x805dc00 in userdb_blocking_lookup ()
| > #1 0x805dd50 in userdb_blocking_lookup ()
| > #2 0x806175a in sql_drivers_register_all ()
| > #3 0x8060d1c in sql_query ()
| > #4 0x805de62 in userdb_blocking_lookup ()
| > #5 0x8055724 in auth_stream_is_empty ()
| > #6 0x80557f4 in auth_stream_is_empty ()
| > #7 0x8055894 in auth_stream_is_empty ()
| > #8 0x80668ac in io_loop_handler_run ()
| > #9 0x80662a1 in io_loop_run ()
| > #10 0x805770f in main ()
| > #11 0x804fd52 in _start ()
|
| Also this backtrace is corrupted for some reason. One (pretty) sure way
| to get a non-corrupted backtrace is to attach gdb to dovecot-auth while
| it's still running:
|
| gdb attach
participants (4)
-
Dominic Marks
-
Gerard
-
Odhiambo WASHINGTON
-
Timo Sirainen