Re: auth module logging
On Sat, Aug 03, 2019 at 11:27:24AM -0600, Michael Slusarz wrote: > > Errors hit the logs but I would appreciate seeing successful auths > > happen for the additional piece of mind. Cmouse and I couldn't > > find a way to do it on irc and it appears that the capability is > > missing. Successul /logins/ can be logged but auths, by themselves, > > cannot. > > > > I would appreciate if the ability was added. > > > > Dovecot 2.3.7.1 is in use. > > Events (using event exporter) is probably what you want, new in 2.3.7. > > https://doc.dovecot.org/admin_manual/list_of_events/ Hi, I've tried using this in various ways but I could never get any real success. I came close but the logging was always far too verbose. The info I wanted WAS there but so was a ton of other data I didn't want. I'd share the configs I tried but they came and went as I was experimenting. Would love to know how to configure the events logging such that I only get a successful auth line logged as that would, indeed, solve my issue. It's quite likely I didn't hit the right config as the docs are somewhat sparse. AP
segmentation fault in fs_list_get_path
Hi,
There seems to be a straightforward bug in
src/lib-storage/list/mailbox-list-fs.c:79. set->index_dir is unchecked
prior to dereferencing (unlike on line 126 in the same file, where it is
properly checked). This manifested on a FreeBSD server running dovecot
2.3.6 when clients tried to retrieve mail with subscriptions like
`~/bar/baz`. This caused the `imap` child to crash, e.g. (slightly
anonymized)
Core was generated by `imap: [foo w.x.y.z EXAMINE]'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x11593af4 in fs_list_get_path (_list=0x12444848,
name=0x12416880 "/home/foo/bar/baz", type=MAILBOX_LIST_PATH_TYPE_INDEX,
path_r=0x7fffe150) at mailbox-list-fs.c:79
79 *set->index_dir == '\0')
(gdb) bt
#0 0x11593af4 in fs_list_get_path (_list=0x12444848,
name=0x12416880 "/home/foo/bar/baz", type=MAILBOX_LIST_PATH_TYPE_INDEX,
path_r=0x7fffe150) at mailbox-list-fs.c:79
#1 0x11559dd0 in mbox_list_get_path (list=0x12444848,
name=0x124da410 "~/bar/baz", type=MAILBOX_LIST_PATH_TYPE_INDEX,
path_r=0x7fffe2c8) at mbox-storage.c:96
#2 0x1150ed0b in mailbox_list_get_path (list=0x12444848,
name=0x124da410 "~/bar/baz", type=MAILBOX_LIST_PATH_TYPE_INDEX,
path_r=0x7fffe2c8) at mailbox-list.c:1387
#3 0x114f8aaf in get_path_to (box=0x124da048,
type=MAILBOX_LIST_PATH_TYPE_INDEX, internal_path=0x124da250,
path_r=0x7fffe2c8) at mail-storage.c:2662
#4 0x114f89e9 in mailbox_get_path_to (box=0x124da048,
type=MAILBOX_LIST_PATH_TYPE_INDEX, path_r=0x7fffe2c8) at
mail-storage.c:2678
#5 0x114f928c in mailbox_create_missing_dir (box=0x124da048,
type=MAILBOX_LIST_PATH_TYPE_INDEX) at mail-storage.c:2826
#6 0x115cf049 in index_storage_mailbox_alloc_index
(box=0x124da048) at index-storage.c:243
#7 0x115cf43f in index_storage_mailbox_open (box=0x124da048,
move_to_memory=false) at index-storage.c:297
#8 0x1155a715 in mbox_mailbox_open_finish (mbox=0x124da048,
move_to_memory=false) at mbox-storage.c:413
#9 0x1155a94b in mbox_mailbox_open_existing (mbox=0x124da048)
at mbox-storage.c:452
#10 0x11559309 in mbox_mailbox_open (box=0x124da048) at
mbox-storage.c:489
#11 0x115a446e in mailbox_list_index_open_mailbox
(box=0x124da048) at mailbox-list-index.c:720
#12 0x114f43ed in mailbox_open_full (box=0x124da048, input=0x0)
at mail-storage.c:1294
#13 0x114f4117 in mailbox_open (box=0x124da048) at
mail-storage.c:1350
#14 0x0103d788 in select_open (ctx=0x12443228,
mailbox=0x12416810 "~/bar/baz", readonly=true) at cmd-select.c:287
#15 0x0103d307 in cmd_select_full (cmd=0x12443048,
readonly=true) at cmd-select.c:415
#16 0x01034afa in cmd_examine (cmd=0x12443048) at cmd-examine.c:8
#17 0x0104a520 in command_exec (cmd=0x12443048) at
imap-commands.c:201
#18 0x0104804e in client_command_input (cmd=0x12443048) at
imap-client.c:1164
#19 0x010483cf in client_command_input (cmd=0x12443048) at
imap-client.c:1227
#20 0x010469fc in client_handle_next_command (client=0x12442848,
remove_io_r=0x7fffe8c7) at imap-client.c:1269
#21 0x010463c0 in client_handle_input (client=0x12442848) at
imap-client.c:1283
#22 0x01044134 in client_input (client=0x12442848) at
imap-client.c:1329
#23 0x11b6bd1c in io_loop_call_io (io=0x1244f240) at ioloop.c:703
#24 0x11b6fc08 in io_loop_handler_run_internal
(ioloop=0x1242b0a0) at ioloop-kqueue.c:160
#25 0x11b6c37e in io_loop_handler_run (ioloop=0x1242b0a0) at
ioloop.c:755
#26 0x11b6c146 in io_loop_run (ioloop=0x1242b0a0) at ioloop.c:728
#27 0x11a87dcb in master_service_run (service=0x12436000,
callback=0x1060080 ) at master-service.c:781
#28 0x0105f870 in main (argc=1, argv=0x7fffeb20) at main.c:523
(gdb) p set->index_dir
$3 = 0x0
The following one-liner fixes the immediate problem (although I didn't
look closely to see what set->index_dir means in the context of
MAILBOX_LIST_PATH_TYPE_INDEX):
--- src/lib-storage/list/mailbox-list-fs.c~ 2019-04-30
06:25:06.0 -0600
+++ src/lib-storage/list/mailbox-list-fs.c2019-08-02
16:23:57.254087000 -0600
@@ -76,6 +76,7 @@
if (mailbox_list_try_get_absolute_path(_list, &name)) {
if (type == MAILBOX_LIST_PATH_TYPE_INDEX &&
+ set->index_dir != NULL &&
*set->index_dir == '\0')
return 0;
*path_r = name;
David
doveadm sis deduplicate problem
Hi all, I'm running dovecot 2.3.7.1, with mdbox and single instance storage. I use offline deduplication like this: mail_attachment_fs = sis-queue /mailboxes/%d/_attachments_/queue:posix Each week I run doveadm sis deduplicate to deduplicate the mail attachments. Everything was fine until I mistakenly run doveadm sis deduplicate twice, simultaneously. I ended up having some error messages like this: Error: unlink(/mailboxes/domain.com/_attachments_/queue/067518ec61f872420813727326dde0933c7449e4-11ae16131c3f445d7e032b0fbac2) failed: No such file or directory (in doveadm-sis.c:260) Also, the sis store has a suspicious temporary (leftover?) file (in the according _attachments_/06/75/ dir): -rw--- 4 vmail vmail 941197 Aug 2 15:48 temp.server-name.9633.77f5a7183d74f72b So the question is, shall I be nervous about this temp file? Does the error mean that the deduplication did not finish correctly? Is my mail store in a consistent state now? What shall I do with the temp file? I'd really appreciate some help... Regards, Peter
Re: auth module logging
> On August 2, 2019 9:35 PM AP via dovecot wrote: > > As per my discussion with cmouse on irc, I'm currently just using > dovecot for its auth mechanism, etc capabilities (alas, Exim does > not support argon directly). Tis a fun little side project. :) > > I have the config pared down as far as I think is reasonable (see > below) and all is working well except that dovecot is very silent. > > Errors hit the logs but I would appreciate seeing successful auths > happen for the additional piece of mind. Cmouse and I couldn't > find a way to do it on irc and it appears that the capability is > missing. Successul /logins/ can be logged but auths, by themselves, > cannot. > > I would appreciate if the ability was added. > > Dovecot 2.3.7.1 is in use. Events (using event exporter) is probably what you want, new in 2.3.7. https://doc.dovecot.org/admin_manual/list_of_events/ michael
Sieve redirect
What is the intended way to configure Sieve for the redirect command? Can I do it using in Dovecot (e.g. using the submission config) or does it have to be done in sendmail? I'm running Dovecot in a container and the MTA/MSA is in another container. Dovecot version: 2.3.2.1 (0719df592) - Björn
Re: auth-policy crashing
On 02/08/2019 11:45, James via dovecot wrote: My auth process is dumping core. This happens several times per day but dovecot can operate normally for hours between errors. The crash occurs in src/auth/auth-policy.c, line 356: t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address) Current function is auth_policy_parse_response 356 context->request->policy_refusal = FALSE; Further tracking shows this sets context->request to NULL: "src/lib/iostream.c" line 54 array_foreach(&stream->destroy_callbacks, dc) dc->callback(dc->context); Very occasionally I see: Aug 3 11:00:35 mailhost dovecot: [ID 702911 mail.crit] auth: Panic: file http-client-request.c: line 283 (http_client_request_unref): assertion failed: (req->refcount > 0) Swapping keep-alive on/off changes crashing from very approximately once per day to some per hour. I guess there is some fundamental thread clash or keep alive time out clean-up failure. James.
auth module logging
Hi,
As per my discussion with cmouse on irc, I'm currently just using
dovecot for its auth mechanism, etc capabilities (alas, Exim does
not support argon directly). Tis a fun little side project. :)
I have the config pared down as far as I think is reasonable (see
below) and all is working well except that dovecot is very silent.
Errors hit the logs but I would appreciate seeing successful auths
happen for the additional piece of mind. Cmouse and I couldn't
find a way to do it on irc and it appears that the capability is
missing. Successul /logins/ can be logged but auths, by themselves,
cannot.
I would appreciate if the ability was added.
Dovecot 2.3.7.1 is in use.
Thanks
# Pigeonhole version 0.5.7.1 (db5c74be)
# OS: Linux 5.2.4 x86_64 Debian 10.0
# Hostname: bob
auth_mechanisms = plain login
auth_verbose = yes
auth_verbose_passwords = sha1:16
log_timestamp = "%Y-%m-%d %H:%M:%S %z "
mail_log_prefix = "%{pid}<%{session}> %{service}(%{user}): "
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
service anvil {
unix_listener anvil-auth-penalty {
mode = 00
}
}
service auth-worker {
user = $default_internal_user
}
service auth {
unix_listener auth-client {
group = Debian-exim
mode = 0660
}
}
ssl = no
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
AP
