Re: systemd integration not working
Can you try with latest git? We did some improvements on the systemd configure parts. Aki > On 26/04/2021 23:32 Joan Moreau wrote: > > > Looking at config.log, there is #define HAVE_LIBSYSTEMD 1 > But "Type=notify" does not appear > My systemd is version 248 > > > > On 2021-04-26 12:05, Joan Moreau wrote: > > I have > > # sudo systemctl status dovecot > > ● dovecot.service - Dovecot IMAP/POP3 email server > > Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor > > preset: disabled) > > Active: active (running) since Sun 2021-04-25 20:13:25 UTC; 14h ago > > Docs: man:dovecot(1) > > https://doc.dovecot.org/ > > Main PID: 2559364 (dovecot) > > Tasks: 28 (limit: 76912) > > Memory: 1.0G > > CPU: 7min 18.342s > > CGroup: /system.slice/dovecot.service > > ├─2559364 /usr/sbin/dovecot -F > > ├─2559366 dovecot/imap-login > > ├─2559367 dovecot/anvil [11 connections] > > ├─2559368 dovecot/log > > > > > > > > On 2021-04-26 08:32, Aki Tuomi wrote: > > > I don't know then. It works for me and I just tried it again. The only > > > reason it would fail would be that HAVE_LIBSYSTEMD is not defined, so it > > > would not be using libsystemd for notify support. > > > > > > $ sudo systemctl status dovecot > > > ● dovecot.service - Dovecot IMAP/POP3 email server > > > Loaded: loaded (/lib/systemd/system/dovecot.service; disabled; vendor > > > preset: enabled) > > > Active: active (running) since Mon 2021-04-26 10:30:02 EEST; 2s ago > > > Docs: man:dovecot(1) > > > https://doc.dovecot.org/ > > > Main PID: 30213 (dovecot) > > > Status: "v2.4.devel (98a1cca054) running" > > > Tasks: 4 (limit: 4701) > > > Memory: 3.3M > > > CGroup: /system.slice/dovecot.service > > > ├─30213 /home/cmouse/dovecot/sbin/dovecot -F > > > ├─30214 dovecot/anvil > > > ├─30215 dovecot/log > > > └─30216 dovecot/config > > > > > > You can tell from the "Status" line that it's using Type=notify. > > > > > > Aki > > > > > > > > > > On 26/04/2021 10:29 Joan Moreau wrote: > > > > > > > > > > > > Yes, I do run autogen.sh after every "git pull" > > > > > > > > > > > > On 2021-04-26 08:21, Aki Tuomi wrote: > > > > > The current autoconf code is bit buggy, but if you do indeed have > > > > > libsystemd-dev installed it should do the right thing and will work > > > > > with systemd even if you have Type=notify. > > > > > > > > > > This has been actually tested, so if it's not working, then something > > > > > else is wrong. > > > > > > > > > > Did you remember to run ./autogen.sh after pulling from git to make > > > > > sure you get new configure script? > > > > > > > > > > Aki > > > > > > > > > > > > > > > > > > > > > On 26/04/2021 10:11 Joan Moreau wrote: > > > > > > > > > > > > > > > > > > Yes systemd is installed (and the "dev" files as well) > > > > > > > > > > > > > > > > > > On 2021-04-26 06:23, Aki Tuomi wrote: > > > > > > > This is because you are not compiling with libsystemd-dev > > > > > > > installed. I guess we need to make some service template that use > > > > > > > type simple when you don't use libsystemd. > > > > > > > > > > > > > > Aki > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 25/04/2021 22:53 Joan Moreau wrote: > > > > > > > > > > > > > > > > > > > > > > > > Yes, it seems fixed with this patch :) > > > > > > > > > > > > > > > > Another bug with git, is the "type=" in systemd is switched > > > > > > > > from "simple" to "notify". The later does not work and > > > > > > > > reverting to "simple" does work > > > > > > > > > > > > > > > > > > > > > > > > On 2021-04-25 17:53, Aki Tuomi wrote: > > > > > > > > > > On 24/04/2021 21:56 Joan Moreau wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > chroot= does not resolve the issue > > > > > > > > > > I have "chroot = login" in my conf > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > The chroot was needed to get the core dump. > > > > > > > > > > > > > > > > > > Can you try if this does fix the crash? > > > > > > > > > > > > > > > > > > Aki > > > > > > > > > > > > > > > > > > From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 > > > > > > > > > 00:00:00 2001 > > > > > > > > > From: Timo Sirainen > > > > > > > > > Date: Fri, 23 Apr 2021 16:43:36 +0300 > > > > > > > > > Subject: [PATCH] login-common: Fix handling destroyed_clients > > > > > > > > > linked list > > > > > > > > > > > > > > > > > > The client needs to be removed from destroyed_clients linked > > > > > > > > > list before > > > > > > > > > it's added to client_fd_proxies linked list. > > > > > > > > > > > > > > > > > > Broken by 1c622cdbe08df2f642e28923c39894516143ae2a > > > > > > > > > --- > > > > > > > > > src/login-common/client-common.c | 11 +++ > > > > > > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/src/login-common/client-common.c > > > > > > > > >
Re: systemd integration not working
Looking at config.log, there is #define HAVE_LIBSYSTEMD 1 But "Type=notify" does not appear My systemd is version 248 On 2021-04-26 12:05, Joan Moreau wrote: I have # sudo systemctl status dovecot ● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2021-04-25 20:13:25 UTC; 14h ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 2559364 (dovecot) Tasks: 28 (limit: 76912) Memory: 1.0G CPU: 7min 18.342s CGroup: /system.slice/dovecot.service ├─2559364 /usr/sbin/dovecot -F ├─2559366 dovecot/imap-login ├─2559367 dovecot/anvil [11 connections] ├─2559368 dovecot/log On 2021-04-26 08:32, Aki Tuomi wrote: I don't know then. It works for me and I just tried it again. The only reason it would fail would be that HAVE_LIBSYSTEMD is not defined, so it would not be using libsystemd for notify support. $ sudo systemctl status dovecot ● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/lib/systemd/system/dovecot.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2021-04-26 10:30:02 EEST; 2s ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 30213 (dovecot) Status: "v2.4.devel (98a1cca054) running" Tasks: 4 (limit: 4701) Memory: 3.3M CGroup: /system.slice/dovecot.service ├─30213 /home/cmouse/dovecot/sbin/dovecot -F ├─30214 dovecot/anvil ├─30215 dovecot/log └─30216 dovecot/config You can tell from the "Status" line that it's using Type=notify. Aki On 26/04/2021 10:29 Joan Moreau wrote: Yes, I do run autogen.sh after every "git pull" On 2021-04-26 08:21, Aki Tuomi wrote: The current autoconf code is bit buggy, but if you do indeed have libsystemd-dev installed it should do the right thing and will work with systemd even if you have Type=notify. This has been actually tested, so if it's not working, then something else is wrong. Did you remember to run ./autogen.sh after pulling from git to make sure you get new configure script? Aki On 26/04/2021 10:11 Joan Moreau wrote: Yes systemd is installed (and the "dev" files as well) On 2021-04-26 06:23, Aki Tuomi wrote: This is because you are not compiling with libsystemd-dev installed. I guess we need to make some service template that use type simple when you don't use libsystemd. Aki On 25/04/2021 22:53 Joan Moreau wrote: Yes, it seems fixed with this patch :) Another bug with git, is the "type=" in systemd is switched from "simple" to "notify". The later does not work and reverting to "simple" does work On 2021-04-25 17:53, Aki Tuomi wrote: On 24/04/2021 21:56 Joan Moreau wrote: chroot= does not resolve the issue I have "chroot = login" in my conf Thanks! The chroot was needed to get the core dump. Can you try if this does fix the crash? Aki From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 2001 From: Timo Sirainen Date: Fri, 23 Apr 2021 16:43:36 +0300 Subject: [PATCH] login-common: Fix handling destroyed_clients linked list The client needs to be removed from destroyed_clients linked list before it's added to client_fd_proxies linked list. Broken by 1c622cdbe08df2f642e28923c39894516143ae2a --- src/login-common/client-common.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/login-common/client-common.c b/src/login-common/client-common.c index bdb6e9c798..1d264d9f75 100644 --- a/src/login-common/client-common.c +++ b/src/login-common/client-common.c @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, const char *reason, /* Login was successful. We may now be proxying the connection, so don't disconnect the client until client_unref(). */ if (client->iostream_fd_proxy != NULL) { + i_assert(!client->fd_proxying); client->fd_proxying = TRUE; - i_assert(client->prev == NULL && client->next == NULL); + DLLIST_REMOVE(_clients, client); DLLIST_PREPEND(_fd_proxies, client); client_fd_proxies_count++; } @@ -307,8 +308,9 @@ void client_destroy(struct client *client, const char *reason) if (last_client == client) last_client = client->prev; - /* remove from clients linked list before it's added to - client_fd_proxies. */ + /* move to destroyed_clients linked list before it's potentially + added to client_fd_proxies. */ + i_assert(!client->fd_proxying); DLLIST_REMOVE(, client); DLLIST_PREPEND(_clients, client); @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) DLLIST_REMOVE(_fd_proxies, client); i_assert(client_fd_proxies_count > 0); client_fd_proxies_count--; + } else { + DLLIST_REMOVE(_clients, client); } i_stream_unref(>input); o_stream_unref(>output); i_close_fd(>fd); event_unref(>event); - DLLIST_REMOVE(_clients, client); i_free(client->proxy_user); i_free(client->proxy_master_user); i_free(client->virtual_user);
Dovecot integration w/ FreeIPA expired password as well as if over quota login notice; local user can't login
As I continue to test freeipa-server-4.9.3-1, on Fedora 33 with dovecot-2.3.14-1 I've run into the following issues with web mail and Dovecot integration. 1. I followed https://www.freeipa.org/page/Dovecot_IMAPS_Integration_with_FreeIPA_using_Single_Sign_On but I couldn't get web mail to login until I used the suggestion from https://blog.delouw.ch/2017/02/19/integrate-dovecot-imap-with-freeipa-using-kerberos-sso/ and changed logins auth_mechanisms = plain gssapi login which allowed logins of FreeIPA Kerberos users. 2. even with auth_mechanisms = plain gssapi login, I could then no longer login to SquirrelMail webmail with any local Unix (non-Kerberized) users. The dovecot logs show: auth: Error: policy(localu...@ourdomain.edu,127.0.0.1,): Policy server HTTP error: connect(x.x.x.x:8084) failed: Connection refused auth: Debug: policy(localu...@ourdomain.edu,127.0.0.1,): Policy report action finished auth: Debug: http-client[1]: request [Req2: POST https://x.x.x.x:8084/?command=report]: Destroy (requests left=1) auth: Debug: http-client[1]: request [Req2: POST https://x.x.x.x:8084/?command=report]: Free (requests left=0) auth: Debug: http-client: conn x.x.x.x[2]: Connection close auth: Debug: http-client: conn x.x.x.x[2]: Connection disconnect auth: Debug: http-client: conn x.x.x.x[2]: Disconnected: connect() failed: Connection refused (fd=23) auth: Debug: http-client: conn x.x.x.x[2]: Detached peer auth: Debug: http-client: conn x.x.x.x[2]: Connection destroy auth: Debug: http-client: host x.x.x.x: Idle host timed out auth: Debug: http-client: host x.x.x.x: Host destroy auth: Debug: http-client: host x.x.x.x: Host session destroy auth: Debug: http-client[1]: queue https://x.x.x.x:8084: Destroy auth: Debug: client passdb out: FAIL1 user=localu...@ourdomain.edu original_user=localuser imap-login: Debug: Ignoring unknown passdb extra field: original_user imap-login: Info: Aborted login (auth failed, 1 attempts in 3 secs): user=< localu...@ourdomain.edu>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session= 3. If a user was over quota there was no way to tell on the webmail page that they were over quota but the dovecot logs show imap(ouruser): Error: mkdir(/path/to/ouruser/mail/.imap) failed: Disk quota exceeded. Would there be a security risk if the web page displayed a warning that could be generalized to inform the user to either check their quota or password reset being needed?
Re: Error and Panic (with coredump)
> On 26/04/2021 19:03 Thomas Knaute wrote: > > > Hi there, > > i'm pretty new to this stuff, just tell me if you need more information. > > Apr 26 17:15:43 dilia dovecot: > imap(u...@domain.de)<78561>: Error: > i_stream_seekable_write_failed: close((>fd)) @ > istream-seekable.c:246 failed (fd=21): Bad fi > le descriptor > Regards, Thomas Do you by change run out of disk space in /tmp or see any other errors? Aki
Error and Panic (with coredump)
Hi there, i'm pretty new to this stuff, just tell me if you need more information. Apr 26 17:15:43 dilia dovecot: imap(u...@domain.de)<78561>: Error: i_stream_seekable_write_failed: close((>fd)) @ istream-seekable.c:246 failed (fd=21): Bad fi le descriptor Apr 26 17:15:43 dilia dovecot: imap(u...@domain.de)<78561>: Panic: file istream-seekable.c: line 226 (read_from_buffer): assertion failed: (*ret_r >0) Apr 26 17:15:43 dilia dovecot: imap(u...@domain.de)<78561>: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xdb73b) [0x7f13aead973b] -> /usr/lib/dovecot/libdov ecot.so.0(+0xdb7d1) [0x7f13aead97d1] -> /usr/lib/dovecot/libdovecot.so.0(+0x4a199) [0x7f13aea48199] -> /usr/lib/dovecot/libdovecot.so.0(+0x4c7cf) [0x7f13aea4a7cf] -> /usr/lib/dovecot/libdove cot.so.0(+0xee6e2) [0x7f13aeaec6e2] -> /usr/lib/dovecot/libdovecot.so.0(+0xeeb46) [0x7f13aeaecb46] -> /usr/lib/dovecot/libdovecot.so.0(+0xe6cd9) [0x7f13aeae4cd9] -> /usr/lib/dovecot/libdovec ot.so.0(i_stream_get_size+0x2a) [0x7f13aeae5baa] -> /usr/lib/dovecot/modules/lib20_zlib_plugin.so(+0x417c) [0x7f13ae80817c] -> /usr/lib/dovecot/libdovecot-storage.so.0(index_mail_set_seq+0x2 5) [0x7f13aec57eb5] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xd19ce) [0x7f13aec5e9ce] -> /usr/lib/dovecot/libdovecot-storage.so.0(index_storage_search_next_nonblock+0x61) [0x7f13aec5f0e 1] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x28) [0x7f13aebe7e58] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](+0x2695f) [0x55740be9495f] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](imap_search_start+0xdc) [0x55740be9528c] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](cmd_sort+0x271) [0x55740be87b7 1] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](command_exec+0x70) [0x55740be8ddc0] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](+0x1e3f2) [0x55740be8c3f2] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](+0x1e494) [0x55740be8c494] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](client_handle_input+0x1b5) [0x55740be8c845] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](client_input+0x7e) [0x55740be8cd6e] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x6f) [0x7f13aeaefbef] -> /usr/lib/dovec ot/libdovecot.so.0(io_loop_handler_run_internal+0x136) [0x7f13aeaf11e6] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c) [0x7f13aeaefc8c] -> /usr/lib/dovecot/libdovecot.so.0(io_ loop_run+0x40) [0x7f13aeaefdf0] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f13aea70123] -> dovecot/imap [u...@domain.de 192.168.xxx.xxx UID SORT](main+0x325) [0x5574 0be7ebf5] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f13ae85709b] Apr 26 17:15:44 dilia dovecot: imap(u...@domain.de)<78561>: Fatal: master: service(imap): child 78561 killed with signal 6 (core dumped) # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.4 () # OS: Linux 4.19.0-9-amd64 x86_64 Debian 10.9 # Hostname: dilia.intern.domain.de auth_cache_size = 10 M auth_default_realm = domain.de auth_mechanisms = plain login default_vsz_limit = 1 G disable_plaintext_auth = no imapc_features = " fetch-headers" imapc_host = mail.intern.domain.de imapc_user = %u mail_location = maildir:~/Maildir mail_plugins = zlib acl mail_prefetch_count = 20 managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify envir onment mailbox date index ihave duplicate mime foreverypart extracttext namespace { hidden = no ignore_on_failure = no inbox = no list = children location = maildir:%%h/Maildir:INDEX=%h/shared/%%u:CONTROL=%h/shared/%%u prefix = shared/%%u/ separator = / subscriptions = yes type = shared } namespace inbox { hidden = no inbox = yes list = yes location = mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Junk { auto = subscribe special_use = \Junk } mailbox Sent { auto = subscribe special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { auto = subscribe special_use = \Trash } prefix = INBOX/ separator = / subscriptions = yes type = private } passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { acl = vfile acl_shared_dict = file:/var/lib/dovecot/db/shared-mailboxes.db mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size sieve = file:~/sieve;active=~/.dovecot.sieve zlib_save = gz zlib_save_level = 6 } protocols = " imap lmtp sieve" service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } unix_listener auth-userdb { group = vmail user = vmail } } service imap-login { process_min_avail = 12 service_count = 0 } service
Re: connection closes every 10 minutes
update on this: to make a long story short 1) I did run mutt with debug enabled , but could not recognize anything useful 2) I had the same problem with mutt from my laptop 3) a few days ago I received a new modem from my ISP, as part of their network upgrade operations 4) more or less in the same moment the problem I reported here disappeared. Now mutt stays connected even 24 hours without losing connection. I am NOT 100% sure that the problem disappeared AFTER the change of modem. That happened during a few chaotic days, both work- and family-wise, so I did not take notes. And modems may have nothing to do at all with the disconnections. But now the problem is not there anymore, I have no clue what may have happened, and if anybody can guess... thanks in advance. Il giorno lun 12 apr 2021 alle ore 16:47 Marco Fioretti ha scritto: > > Greetings, > > I use mutt on Ubuntu to access my IMAP mailboxes, on my Centos email > server that runs dovecot. Everything has worked without problems for > years. About one week ago, the connection between mutt and dovecot > became unstable. > > Before, I could leave mutt connected for days in a row, no problem. > Now, everything still works fine, except... I get every ten minutes I > get "connection timed out" in Mutt's status line, and hundreds of > messages like > > Apr 12 16:12:49 SERVERNAME dovecot: imap(ACCOUNTNAME): Logged out in=164 > out=757 > > what puzzles me is that I did not touch anything both on my server and > on my desktop, except an "apt-get update" some days before this > started. > > But cannot see how it would be related anyway, nor have I found > anything online like this. > > Any help to understand what happened and fix it is very welcome. > > Marco
Re: systemd integration not working (WAS: Latest git FATAL error)
I have # sudo systemctl status dovecot ● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2021-04-25 20:13:25 UTC; 14h ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 2559364 (dovecot) Tasks: 28 (limit: 76912) Memory: 1.0G CPU: 7min 18.342s CGroup: /system.slice/dovecot.service ├─2559364 /usr/sbin/dovecot -F ├─2559366 dovecot/imap-login ├─2559367 dovecot/anvil [11 connections] ├─2559368 dovecot/log On 2021-04-26 08:32, Aki Tuomi wrote: I don't know then. It works for me and I just tried it again. The only reason it would fail would be that HAVE_LIBSYSTEMD is not defined, so it would not be using libsystemd for notify support. $ sudo systemctl status dovecot ● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/lib/systemd/system/dovecot.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2021-04-26 10:30:02 EEST; 2s ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 30213 (dovecot) Status: "v2.4.devel (98a1cca054) running" Tasks: 4 (limit: 4701) Memory: 3.3M CGroup: /system.slice/dovecot.service ├─30213 /home/cmouse/dovecot/sbin/dovecot -F ├─30214 dovecot/anvil ├─30215 dovecot/log └─30216 dovecot/config You can tell from the "Status" line that it's using Type=notify. Aki On 26/04/2021 10:29 Joan Moreau wrote: Yes, I do run autogen.sh after every "git pull" On 2021-04-26 08:21, Aki Tuomi wrote: The current autoconf code is bit buggy, but if you do indeed have libsystemd-dev installed it should do the right thing and will work with systemd even if you have Type=notify. This has been actually tested, so if it's not working, then something else is wrong. Did you remember to run ./autogen.sh after pulling from git to make sure you get new configure script? Aki On 26/04/2021 10:11 Joan Moreau wrote: Yes systemd is installed (and the "dev" files as well) On 2021-04-26 06:23, Aki Tuomi wrote: This is because you are not compiling with libsystemd-dev installed. I guess we need to make some service template that use type simple when you don't use libsystemd. Aki On 25/04/2021 22:53 Joan Moreau wrote: Yes, it seems fixed with this patch :) Another bug with git, is the "type=" in systemd is switched from "simple" to "notify". The later does not work and reverting to "simple" does work On 2021-04-25 17:53, Aki Tuomi wrote: On 24/04/2021 21:56 Joan Moreau wrote: chroot= does not resolve the issue I have "chroot = login" in my conf Thanks! The chroot was needed to get the core dump. Can you try if this does fix the crash? Aki From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 2001 From: Timo Sirainen Date: Fri, 23 Apr 2021 16:43:36 +0300 Subject: [PATCH] login-common: Fix handling destroyed_clients linked list The client needs to be removed from destroyed_clients linked list before it's added to client_fd_proxies linked list. Broken by 1c622cdbe08df2f642e28923c39894516143ae2a --- src/login-common/client-common.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/login-common/client-common.c b/src/login-common/client-common.c index bdb6e9c798..1d264d9f75 100644 --- a/src/login-common/client-common.c +++ b/src/login-common/client-common.c @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, const char *reason, /* Login was successful. We may now be proxying the connection, so don't disconnect the client until client_unref(). */ if (client->iostream_fd_proxy != NULL) { + i_assert(!client->fd_proxying); client->fd_proxying = TRUE; - i_assert(client->prev == NULL && client->next == NULL); + DLLIST_REMOVE(_clients, client); DLLIST_PREPEND(_fd_proxies, client); client_fd_proxies_count++; } @@ -307,8 +308,9 @@ void client_destroy(struct client *client, const char *reason) if (last_client == client) last_client = client->prev; - /* remove from clients linked list before it's added to - client_fd_proxies. */ + /* move to destroyed_clients linked list before it's potentially + added to client_fd_proxies. */ + i_assert(!client->fd_proxying); DLLIST_REMOVE(, client); DLLIST_PREPEND(_clients, client); @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) DLLIST_REMOVE(_fd_proxies, client); i_assert(client_fd_proxies_count > 0); client_fd_proxies_count--; + } else { + DLLIST_REMOVE(_clients, client); } i_stream_unref(>input); o_stream_unref(>output); i_close_fd(>fd); event_unref(>event); - DLLIST_REMOVE(_clients, client); i_free(client->proxy_user); i_free(client->proxy_master_user); i_free(client->virtual_user);
Re: Live migrating index/control files
> On 26 Apr 2021, at 16:03, azu...@pobox.sk wrote: > > Btw, if your control files are OUTSIDE maildir and you are moving them back > INSIDE maildir, notice (for example in my script) that .INBOX directory > doesn't exists in maildir and control files for INBOX are placed directly in > maildir instead. This is probably why you are failing to prevent > resync/redownload. Oh, thanks! I was simply using rsync to synchronize the control/index directory tree into the maildir, incorrectly assuming the trees were the same in both configurations: rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ /mail/${user:0:1}/${user:0:2}/${user}/Maildir/; I see now, as you said, that the control and index files for INBOX should be placed directly in the maildir, and that they have been recreated for the users in question. I'll try modifying the sync part to also move the files from the .INBOX folder: rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ ~/Maildir/; mv -v ~/Maildir/.INBOX/* ~/Maildir/; rmdir -v ~/Maildir/.INBOX; Thanks again! Best regards, Eirik
Re: Live migrating index/control files
Citát Eirik Rye : On 26 Apr 2021, at 15:14, Eirik Rye wrote: Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now want to consolidate all files to the user's home directory instead. The end goal is to stop using NFS altogether. Some more background information: - Running 2.3.13 (89f716dc2) - The rsync is run from the user's current mapped backend (from `doveadm director status `), in hopes to reduce NFS-related issues - Kicking is done through one of the directors, to ensure all of the user's connections are kicked. Best regards, Eirik Btw, if your control files are OUTSIDE maildir and you are moving them back INSIDE maildir, notice (for example in my script) that .INBOX directory doesn't exists in maildir and control files for INBOX are placed directly in maildir instead. This is probably why you are failing to prevent resync/redownload.
How to Easily Set Up a Full-Featured Linux Mail Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0
Subject: How to Easily Set Up a Full-Featured Linux Mail Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0 Good day from Singapore, I followed linuxbabe.com's Xiao Guoan's guide and successfully setup a full featured Linux mail server on Ubuntu 18.04.5 LTS with IRedMail 1.4.0. Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 25 April 2021 Sunday Type of Publication: PDF Manual Document Version: 20210425.01 (1st release) ***IMPORTANT NOTICE*** Please note that Turritopsis Dohrnii Teo En Ming’s guide is based on Xiao Guoan’s guide at linuxbabe.com. Reference Guide Used by Teo En Ming: How to Easily Set Up a Full-Featured Mail Server on Ubuntu 18.04 with iRedMail Link: https://www.linuxbabe.com/mail-server/ubuntu-18-04-iredmail-email-server Original Author: Xiao Guoan The following is a list of open-source software that will be automatically installed and configured by iRedMail. • Postfix SMTP server • Dovecot IMAP server • Nginx web server to serve the admin panel and webmail • OpenLDAP, MySQL/MariaDB, or PostgreSQL for storing user information • Amavised-new for DKIM signing and verification • SpamAssassin for anti-spam • ClamAV for anti-virus • Roundcube webmail • SOGo groupware, providing webmail, calendar (CalDAV), contacts (CardDAV), tasks and ActiveSync services. • Fail2ban for protecting SSH • mlmmj mailing list manager • Netdata server monitoring • iRedAPD Postfix policy server for greylisting Redundant Download Links for Teo En Ming's PDF Manual: [1] https://drive.google.com/file/d/1un8sLLmNSMIt7V6blWCvJEgwGvxMbd4B/view?usp=sharing [2] https://drive.google.com/file/d/1i0vY7kfYkobu563qoI3_qCZg7G7BFoYR/view?usp=sharing [3] https://drive.google.com/file/d/1U9MFN1EklLbA8TMweLV5ntiSJuBBVkpQ/view?usp=sharing [4] https://www.docdroid.net/dW70KtS/iredmail-setup-1st-release-pdf [5] https://www.mediafire.com/file/evar7j28knqyoj6/IRedMail+Setup+1st+Release.pdf/file [6] https://www.scribd.com/document/504932780/IRedMail-Setup-1st-Release Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 26 April 2021, is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: Live migrating index/control files
> On 26 Apr 2021, at 15:14, Eirik Rye wrote: > > Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now > want to consolidate all files to the user's home directory instead. The end > goal is to stop using NFS altogether. Some more background information: - Running 2.3.13 (89f716dc2) - The rsync is run from the user's current mapped backend (from `doveadm director status `), in hopes to reduce NFS-related issues - Kicking is done through one of the directors, to ensure all of the user's connections are kicked. Best regards, Eirik
Re: Live migrating index/control files
Sorry, accidentaly sent the uncomplete message. Here is the mentioned script (see some configuration directives at the beginning of the script): https://pastebin.com/ArG8zspi Citát azu...@pobox.sk: Hi, i think you cannot do this without preventing users to log in. We were doing similar thing few years ago and i wrote a Python script for this purpose - you can use it if you find it usefull (script is copying only control files as indexes are transparently recreated): Citát Eirik Rye : Hello, We are running a director-based dovecot cluster where the user's maildir and the indexes/control files are, for legacy reasons, stored on separate NFS-backends, i.e.: mail_location = maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now want to consolidate all files to the user's home directory instead. The end goal is to stop using NFS altogether. I have devised a four step plan for gradually migrating the index/control files into the user's maildir, on a per-user basis: 1. Kick the user in an attempt to flush the user's index files: `doveadm director kick ` 2. Rsync the index/control files into the user's maildir: `rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ /mail/${user:0:1}/${user:0:2}/${user}/Maildir/;` 3. Update the (redis-based) userdb for the specific user to override mail_location to use the default CONTROL/INDEX locations: `{"mail": "maildir:~/Maildir"}` 4. Kick the user one last time so that they reconnect using the new settings. Unfortunately, after running this for a small batch of users, we recieved a couple reports that their clients had started to resynchronize and redownload their mailboxes, which is exactly what we're trying to avoid. There are no index related error messages related to the few users that reported these issues. From my understanding, clients become confused when the control files are changed or lost (`dovecot-uidlist` and `dovecot-uidvalidity`), so I suspect the kick + rsync + kick procedure is not robust enough for this. Does anyone have any experience with performing such a migration without taking systems offline for the duration? Any suggestions to make this process more transparent for our users, so as to not induce panic when their mailboxes abruptly appear empty? Best regards, Eirik
Re: Live migrating index/control files
Hi, i think you cannot do this without preventing users to log in. We were doing similar thing few years ago and i wrote a Python script for this purpose - you can use it if you find it usefull (script is copying only control files as indexes are transparently recreated): Citát Eirik Rye : Hello, We are running a director-based dovecot cluster where the user's maildir and the indexes/control files are, for legacy reasons, stored on separate NFS-backends, i.e.: mail_location = maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now want to consolidate all files to the user's home directory instead. The end goal is to stop using NFS altogether. I have devised a four step plan for gradually migrating the index/control files into the user's maildir, on a per-user basis: 1. Kick the user in an attempt to flush the user's index files: `doveadm director kick ` 2. Rsync the index/control files into the user's maildir: `rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ /mail/${user:0:1}/${user:0:2}/${user}/Maildir/;` 3. Update the (redis-based) userdb for the specific user to override mail_location to use the default CONTROL/INDEX locations: `{"mail": "maildir:~/Maildir"}` 4. Kick the user one last time so that they reconnect using the new settings. Unfortunately, after running this for a small batch of users, we recieved a couple reports that their clients had started to resynchronize and redownload their mailboxes, which is exactly what we're trying to avoid. There are no index related error messages related to the few users that reported these issues. From my understanding, clients become confused when the control files are changed or lost (`dovecot-uidlist` and `dovecot-uidvalidity`), so I suspect the kick + rsync + kick procedure is not robust enough for this. Does anyone have any experience with performing such a migration without taking systems offline for the duration? Any suggestions to make this process more transparent for our users, so as to not induce panic when their mailboxes abruptly appear empty? Best regards, Eirik
Live migrating index/control files
Hello, We are running a director-based dovecot cluster where the user's maildir and the indexes/control files are, for legacy reasons, stored on separate NFS-backends, i.e.: mail_location = maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now want to consolidate all files to the user's home directory instead. The end goal is to stop using NFS altogether. I have devised a four step plan for gradually migrating the index/control files into the user's maildir, on a per-user basis: 1. Kick the user in an attempt to flush the user's index files: `doveadm director kick ` 2. Rsync the index/control files into the user's maildir: `rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ /mail/${user:0:1}/${user:0:2}/${user}/Maildir/;` 3. Update the (redis-based) userdb for the specific user to override mail_location to use the default CONTROL/INDEX locations: `{"mail": "maildir:~/Maildir"}` 4. Kick the user one last time so that they reconnect using the new settings. Unfortunately, after running this for a small batch of users, we recieved a couple reports that their clients had started to resynchronize and redownload their mailboxes, which is exactly what we're trying to avoid. There are no index related error messages related to the few users that reported these issues. From my understanding, clients become confused when the control files are changed or lost (`dovecot-uidlist` and `dovecot-uidvalidity`), so I suspect the kick + rsync + kick procedure is not robust enough for this. Does anyone have any experience with performing such a migration without taking systems offline for the duration? Any suggestions to make this process more transparent for our users, so as to not induce panic when their mailboxes abruptly appear empty? Best regards, Eirik
Re: cannot see my mails
Le 26/04/2021 à 13:45, Aki Tuomi a écrit : On 26/04/2021 14:38 Jean-Max Reymond wrote: Le 26/04/2021 à 13:31, Aki Tuomi a écrit : On 26/04/2021 14:28 Jean-Max Reymond wrote: Le 26/04/2021 à 13:24, Yassine Chaouche a écrit : Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > After a change of server When you changed servers, did you copy the contents of (probably) /var/vmail/ from the old server to the new server ? this is usually where e-mails are stored. You can also use imap-sync from old to new server. This should automatically transfer your old mail there (if old server is still operationnal) yep, the 144 GB of mails are copied. The correct owner is mail:mail. Database posfixadmin is copied and authentification by sql works fine.dovecot does not report any issues, postfix works like a charm. I have deleted for only one mailbox, the dovecot files but no changes. -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com Does output of `doveadm user your-user-name` match with where you copied all your mails to? Aki # doveadm user jmreym...@normaal.fr field value uid 8 gid 8 home/home/Mails/jmreym...@normaal.fr/ mailmaildir:~/Maildir maildir jmreym...@normaal.fr/ # ls -ld /home/Mails/jmreym...@normaal.fr/* drwx-- 2 mail mail 4096 Mar 26 07:12 /home/Mails/jmreym...@normaal.fr/cur drwx-- 3 mail mail 4096 Nov 8 2014 /home/Mails/jmreym...@normaal.fr/mail drwx-- 8 mail mail 4096 Apr 26 13:24 /home/Mails/jmreym...@normaal.fr/Maildir drwx-- 2 mail mail 4096 Apr 26 11:12 /home/Mails/jmreym...@normaal.fr/new -rw--- 1 mail mail 18 Jun 10 2019 /home/Mails/jmreym...@normaal.fr/subscriptions drwx-- 2 mail mail 4096 Apr 26 11:12 /home/Mails/jmreym...@normaal.fr/tmp -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com home/home/Mails/jmreym...@normaal.fr/ mailmaildir:~/Maildir this is what matters, so dovecot expects to see your maildir structure under /home/Mails/jmreym...@normaal.fr/Maildir/ Aki YES, it works :-) thanks a lot, Aki and Yassine. -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
Re: cannot see my mails
> On 26/04/2021 14:38 Jean-Max Reymond wrote: > > > Le 26/04/2021 à 13:31, Aki Tuomi a écrit : > > > >> On 26/04/2021 14:28 Jean-Max Reymond wrote: > >> > >> > >> Le 26/04/2021 à 13:24, Yassine Chaouche a écrit : > >>> Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > >>> > After a change of server > >>> > >>> When you changed servers, did you copy the contents of (probably) > >>> /var/vmail/ from the old server to the new server ? this is usually > >>> where e-mails are stored. > >>> > >>> You can also use imap-sync from old to new server. This should > >>> automatically transfer your old mail there (if old server is still > >>> operationnal) > >> > >> yep, the 144 GB of mails are copied. The correct owner is mail:mail. > >> Database posfixadmin is copied and authentification by sql works > >> fine.dovecot does not report any issues, postfix works like a charm. I > >> have deleted for only one mailbox, the dovecot files but no changes. > >> > >> -- > >> Jean-Max Reymond > >> CKR Solutions Open Source https://www.ckr-solutions.com > > > > Does output of `doveadm user your-user-name` match with where you copied > > all your mails to? > > > > Aki > > > > # doveadm user jmreym...@normaal.fr > field value > uid 8 > gid 8 > home /home/Mails/jmreym...@normaal.fr/ > mail maildir:~/Maildir > maildir jmreym...@normaal.fr/ > > # ls -ld /home/Mails/jmreym...@normaal.fr/* > drwx-- 2 mail mail 4096 Mar 26 07:12 > /home/Mails/jmreym...@normaal.fr/cur > drwx-- 3 mail mail 4096 Nov 8 2014 > /home/Mails/jmreym...@normaal.fr/mail > drwx-- 8 mail mail 4096 Apr 26 13:24 > /home/Mails/jmreym...@normaal.fr/Maildir > drwx-- 2 mail mail 4096 Apr 26 11:12 > /home/Mails/jmreym...@normaal.fr/new > -rw--- 1 mail mail 18 Jun 10 2019 > /home/Mails/jmreym...@normaal.fr/subscriptions > drwx-- 2 mail mail 4096 Apr 26 11:12 > /home/Mails/jmreym...@normaal.fr/tmp > > > -- > Jean-Max Reymond > CKR Solutions Open Source https://www.ckr-solutions.com home/home/Mails/jmreym...@normaal.fr/ mailmaildir:~/Maildir this is what matters, so dovecot expects to see your maildir structure under /home/Mails/jmreym...@normaal.fr/Maildir/ Aki
Re: cannot see my mails
Le 26/04/2021 à 13:31, Aki Tuomi a écrit : On 26/04/2021 14:28 Jean-Max Reymond wrote: Le 26/04/2021 à 13:24, Yassine Chaouche a écrit : Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > After a change of server When you changed servers, did you copy the contents of (probably) /var/vmail/ from the old server to the new server ? this is usually where e-mails are stored. You can also use imap-sync from old to new server. This should automatically transfer your old mail there (if old server is still operationnal) yep, the 144 GB of mails are copied. The correct owner is mail:mail. Database posfixadmin is copied and authentification by sql works fine.dovecot does not report any issues, postfix works like a charm. I have deleted for only one mailbox, the dovecot files but no changes. -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com Does output of `doveadm user your-user-name` match with where you copied all your mails to? Aki # doveadm user jmreym...@normaal.fr field value uid 8 gid 8 home/home/Mails/jmreym...@normaal.fr/ mailmaildir:~/Maildir maildir jmreym...@normaal.fr/ # ls -ld /home/Mails/jmreym...@normaal.fr/* drwx-- 2 mail mail 4096 Mar 26 07:12 /home/Mails/jmreym...@normaal.fr/cur drwx-- 3 mail mail 4096 Nov 8 2014 /home/Mails/jmreym...@normaal.fr/mail drwx-- 8 mail mail 4096 Apr 26 13:24 /home/Mails/jmreym...@normaal.fr/Maildir drwx-- 2 mail mail 4096 Apr 26 11:12 /home/Mails/jmreym...@normaal.fr/new -rw--- 1 mail mail 18 Jun 10 2019 /home/Mails/jmreym...@normaal.fr/subscriptions drwx-- 2 mail mail 4096 Apr 26 11:12 /home/Mails/jmreym...@normaal.fr/tmp -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
Re: cannot see my mails
> On 26/04/2021 14:28 Jean-Max Reymond wrote: > > > Le 26/04/2021 à 13:24, Yassine Chaouche a écrit : > > Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > > > After a change of server > > > > When you changed servers, did you copy the contents of (probably) > > /var/vmail/ from the old server to the new server ? this is usually > > where e-mails are stored. > > > > You can also use imap-sync from old to new server. This should > > automatically transfer your old mail there (if old server is still > > operationnal) > > yep, the 144 GB of mails are copied. The correct owner is mail:mail. > Database posfixadmin is copied and authentification by sql works > fine.dovecot does not report any issues, postfix works like a charm. I > have deleted for only one mailbox, the dovecot files but no changes. > > -- > Jean-Max Reymond > CKR Solutions Open Source https://www.ckr-solutions.com Does output of `doveadm user your-user-name` match with where you copied all your mails to? Aki
Re: Latest git FATAL error
Yes, I do run autogen.sh after every "git pull" On 2021-04-26 08:21, Aki Tuomi wrote: The current autoconf code is bit buggy, but if you do indeed have libsystemd-dev installed it should do the right thing and will work with systemd even if you have Type=notify. This has been actually tested, so if it's not working, then something else is wrong. Did you remember to run ./autogen.sh after pulling from git to make sure you get new configure script? Aki On 26/04/2021 10:11 Joan Moreau wrote: Yes systemd is installed (and the "dev" files as well) On 2021-04-26 06:23, Aki Tuomi wrote: This is because you are not compiling with libsystemd-dev installed. I guess we need to make some service template that use type simple when you don't use libsystemd. Aki On 25/04/2021 22:53 Joan Moreau wrote: Yes, it seems fixed with this patch :) Another bug with git, is the "type=" in systemd is switched from "simple" to "notify". The later does not work and reverting to "simple" does work On 2021-04-25 17:53, Aki Tuomi wrote: On 24/04/2021 21:56 Joan Moreau wrote: chroot= does not resolve the issue I have "chroot = login" in my conf Thanks! The chroot was needed to get the core dump. Can you try if this does fix the crash? Aki From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 2001 From: Timo Sirainen Date: Fri, 23 Apr 2021 16:43:36 +0300 Subject: [PATCH] login-common: Fix handling destroyed_clients linked list The client needs to be removed from destroyed_clients linked list before it's added to client_fd_proxies linked list. Broken by 1c622cdbe08df2f642e28923c39894516143ae2a --- src/login-common/client-common.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/login-common/client-common.c b/src/login-common/client-common.c index bdb6e9c798..1d264d9f75 100644 --- a/src/login-common/client-common.c +++ b/src/login-common/client-common.c @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, const char *reason, /* Login was successful. We may now be proxying the connection, so don't disconnect the client until client_unref(). */ if (client->iostream_fd_proxy != NULL) { + i_assert(!client->fd_proxying); client->fd_proxying = TRUE; - i_assert(client->prev == NULL && client->next == NULL); + DLLIST_REMOVE(_clients, client); DLLIST_PREPEND(_fd_proxies, client); client_fd_proxies_count++; } @@ -307,8 +308,9 @@ void client_destroy(struct client *client, const char *reason) if (last_client == client) last_client = client->prev; - /* remove from clients linked list before it's added to - client_fd_proxies. */ + /* move to destroyed_clients linked list before it's potentially + added to client_fd_proxies. */ + i_assert(!client->fd_proxying); DLLIST_REMOVE(, client); DLLIST_PREPEND(_clients, client); @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) DLLIST_REMOVE(_fd_proxies, client); i_assert(client_fd_proxies_count > 0); client_fd_proxies_count--; + } else { + DLLIST_REMOVE(_clients, client); } i_stream_unref(>input); o_stream_unref(>output); i_close_fd(>fd); event_unref(>event); - DLLIST_REMOVE(_clients, client); i_free(client->proxy_user); i_free(client->proxy_master_user); i_free(client->virtual_user);
Re: cannot see my mails
Le 26/04/2021 à 13:24, Yassine Chaouche a écrit : Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > After a change of server When you changed servers, did you copy the contents of (probably) /var/vmail/ from the old server to the new server ? this is usually where e-mails are stored. You can also use imap-sync from old to new server. This should automatically transfer your old mail there (if old server is still operationnal) yep, the 144 GB of mails are copied. The correct owner is mail:mail. Database posfixadmin is copied and authentification by sql works fine.dovecot does not report any issues, postfix works like a charm. I have deleted for only one mailbox, the dovecot files but no changes. -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
Re: cannot see my mails
Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > After a change of server When you changed servers, did you copy the contents of (probably) /var/vmail/ from the old server to the new server ? this is usually where e-mails are stored. You can also use imap-sync from old to new server. This should automatically transfer your old mail there (if old server is still operationnal) -- Yassine
Re: cannot see my mails
Le 26/04/2021 à 13:13, Yassine Chaouche a écrit : Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > Hi, > After a change of server, I cannot see my mails. postfix is OK and I > receive emails. If I send emails, with roundcube or thunderbird, I > can seethese new sent emails. Access rights seems OK. Dovecot with > debug trace does not complain. Any tips ? Hello Jean-Max You see sent mails but not received mails ? You see new mails but not old mails ? as if your inbox has just been created ? -- Yassine not exactly. I cannot see any received mails, old or new and I am sure I received new emails. I can see new mails I sent. If I move an email from Sent to Inbox with roundcube or thunderbird, I can see these emails in Inbox. -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
Re: cannot see my mails
Le 4/26/21 à 10:22 AM, Jean-Max Reymond a écrit : > Hi, > After a change of server, I cannot see my mails. postfix is OK and I > receive emails. If I send emails, with roundcube or thunderbird, I > can seethese new sent emails. Access rights seems OK. Dovecot with > debug trace does not complain. Any tips ? Hello Jean-Max You see sent mails but not received mails ? You see new mails but not old mails ? as if your inbox has just been created ? -- Yassine
Re: Latest git FATAL error
Yes systemd is installed (and the "dev" files as well) On 2021-04-26 06:23, Aki Tuomi wrote: This is because you are not compiling with libsystemd-dev installed. I guess we need to make some service template that use type simple when you don't use libsystemd. Aki On 25/04/2021 22:53 Joan Moreau wrote: Yes, it seems fixed with this patch :) Another bug with git, is the "type=" in systemd is switched from "simple" to "notify". The later does not work and reverting to "simple" does work On 2021-04-25 17:53, Aki Tuomi wrote: On 24/04/2021 21:56 Joan Moreau wrote: chroot= does not resolve the issue I have "chroot = login" in my conf Thanks! The chroot was needed to get the core dump. Can you try if this does fix the crash? Aki From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 2001 From: Timo Sirainen Date: Fri, 23 Apr 2021 16:43:36 +0300 Subject: [PATCH] login-common: Fix handling destroyed_clients linked list The client needs to be removed from destroyed_clients linked list before it's added to client_fd_proxies linked list. Broken by 1c622cdbe08df2f642e28923c39894516143ae2a --- src/login-common/client-common.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/login-common/client-common.c b/src/login-common/client-common.c index bdb6e9c798..1d264d9f75 100644 --- a/src/login-common/client-common.c +++ b/src/login-common/client-common.c @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, const char *reason, /* Login was successful. We may now be proxying the connection, so don't disconnect the client until client_unref(). */ if (client->iostream_fd_proxy != NULL) { + i_assert(!client->fd_proxying); client->fd_proxying = TRUE; - i_assert(client->prev == NULL && client->next == NULL); + DLLIST_REMOVE(_clients, client); DLLIST_PREPEND(_fd_proxies, client); client_fd_proxies_count++; } @@ -307,8 +308,9 @@ void client_destroy(struct client *client, const char *reason) if (last_client == client) last_client = client->prev; - /* remove from clients linked list before it's added to - client_fd_proxies. */ + /* move to destroyed_clients linked list before it's potentially + added to client_fd_proxies. */ + i_assert(!client->fd_proxying); DLLIST_REMOVE(, client); DLLIST_PREPEND(_clients, client); @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) DLLIST_REMOVE(_fd_proxies, client); i_assert(client_fd_proxies_count > 0); client_fd_proxies_count--; + } else { + DLLIST_REMOVE(_clients, client); } i_stream_unref(>input); o_stream_unref(>output); i_close_fd(>fd); event_unref(>event); - DLLIST_REMOVE(_clients, client); i_free(client->proxy_user); i_free(client->proxy_master_user); i_free(client->virtual_user);
Re: cannot see my mails
Le 26/04/2021 à 11:22, Jean-Max Reymond a écrit : Hi, After a change of server, I cannot see my mails. postfix is OK and I receive emails. If I send emails, with roundcube or thunderbird, I can see these new sent emails. Access rights seems OK. Dovecot with debug trace does not complain. Any tips ? # dovecot -n # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.15.0-142-generic x86_64 Ubuntu 18.04.5 LTS auth_mechanisms = plain login first_valid_uid = 8 log_path = /var/log/dovecot.log mail_location = maildir:~/Maildir managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext passdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } protocols = imap service auth { unix_listener /var/spool/postfix/private/dovecot-auth { group = postfix mode = 0660 user = postfix } } ssl_cert = ssl_cipher_list = ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM ssl_client_ca_dir = /etc/ssl/certs ssl_key = # hidden, use -P to show it userdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } protocol imap { imap_client_workarounds = delay-newmail mail_max_userip_connections = 10 } protocol pop3 { mail_max_userip_connections = 10 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } protocol lda { deliver_log_format = msgid=%m: %$ mail_plugins = sieve postmaster_address = postmaster quota_full_tempfail = yes rejection_reason = Your message to <%t> was automatically rejected:%n%r } -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
cannot see my mails
Hi, After a change of server, I cannot see my mails. postfix is OK and I receive emails. If I send emails, with roundcube or thunderbird, I can see these new sent emails. Access rights seems OK. Dovecot with debug trace does not complain. Any tips ? append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes compatibility_level = 2 content_filter = smtp-amavis:[127.0.0.1]:10024 home_mailbox = Maildir/ local_recipient_maps = $virtual_mailbox_maps local_transport = virtual mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}" message_size_limit = 3072 milter_default_action = accept milter_protocol = 2 mydestination = localhost non_smtpd_milters = inet:localhost:12345 readme_directory = no slow_destination_concurrency_limit = 2 slow_destination_recipient_limit = 20 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_milters = inet:localhost:12345 smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = private/dovecot-auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = reject_unknown_sender_domain smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/dovecot/private/dovecot.pem smtpd_tls_key_file = /etc/dovecot/private/dovecot.key smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_tls_received_header = yes smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport vacation_destination_recipient_limit = 1 virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf virtual_gid_maps = static:8 virtual_mailbox_base = /home/Mails virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/virtual_domains_maps.cf virtual_mailbox_limit = 20480 virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf virtual_minimum_uid = 8 virtual_transport = virtual virtual_uid_maps = static:8 yahoo_destination_concurrency_limit = 4 yahoo_destination_rate_delay = 1s yahoo_destination_recipient_limit = 2 yahoo_initial_destination_concurrency = 1 -- Jean-Max Reymond CKR Solutions Open Source https://www.ckr-solutions.com
Re: systemd integration not working (WAS: Latest git FATAL error)
I don't know then. It works for me and I just tried it again. The only reason it would fail would be that HAVE_LIBSYSTEMD is not defined, so it would not be using libsystemd for notify support. $ sudo systemctl status dovecot ● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/lib/systemd/system/dovecot.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2021-04-26 10:30:02 EEST; 2s ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 30213 (dovecot) Status: "v2.4.devel (98a1cca054) running" Tasks: 4 (limit: 4701) Memory: 3.3M CGroup: /system.slice/dovecot.service ├─30213 /home/cmouse/dovecot/sbin/dovecot -F ├─30214 dovecot/anvil ├─30215 dovecot/log └─30216 dovecot/config You can tell from the "Status" line that it's using Type=notify. Aki > On 26/04/2021 10:29 Joan Moreau wrote: > > > Yes, I do run autogen.sh after every "git pull" > > > On 2021-04-26 08:21, Aki Tuomi wrote: > > The current autoconf code is bit buggy, but if you do indeed have > > libsystemd-dev installed it should do the right thing and will work with > > systemd even if you have Type=notify. > > > > This has been actually tested, so if it's not working, then something else > > is wrong. > > > > Did you remember to run ./autogen.sh after pulling from git to make sure > > you get new configure script? > > > > Aki > > > > > > > On 26/04/2021 10:11 Joan Moreau wrote: > > > > > > > > > Yes systemd is installed (and the "dev" files as well) > > > > > > > > > On 2021-04-26 06:23, Aki Tuomi wrote: > > > > This is because you are not compiling with libsystemd-dev installed. I > > > > guess we need to make some service template that use type simple when > > > > you don't use libsystemd. > > > > > > > > Aki > > > > > > > > > > > > > > > > > On 25/04/2021 22:53 Joan Moreau wrote: > > > > > > > > > > > > > > > Yes, it seems fixed with this patch :) > > > > > > > > > > Another bug with git, is the "type=" in systemd is switched from > > > > > "simple" to "notify". The later does not work and reverting to > > > > > "simple" does work > > > > > > > > > > > > > > > On 2021-04-25 17:53, Aki Tuomi wrote: > > > > > > > On 24/04/2021 21:56 Joan Moreau wrote: > > > > > > > > > > > > > > > > > > > > > chroot= does not resolve the issue > > > > > > > I have "chroot = login" in my conf > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > The chroot was needed to get the core dump. > > > > > > > > > > > > Can you try if this does fix the crash? > > > > > > > > > > > > Aki > > > > > > > > > > > > From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 > > > > > > 2001 > > > > > > From: Timo Sirainen > > > > > > Date: Fri, 23 Apr 2021 16:43:36 +0300 > > > > > > Subject: [PATCH] login-common: Fix handling destroyed_clients > > > > > > linked list > > > > > > > > > > > > The client needs to be removed from destroyed_clients linked list > > > > > > before > > > > > > it's added to client_fd_proxies linked list. > > > > > > > > > > > > Broken by 1c622cdbe08df2f642e28923c39894516143ae2a > > > > > > --- > > > > > > src/login-common/client-common.c | 11 +++ > > > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > > > > > > > diff --git a/src/login-common/client-common.c > > > > > > b/src/login-common/client-common.c > > > > > > index bdb6e9c798..1d264d9f75 100644 > > > > > > --- a/src/login-common/client-common.c > > > > > > +++ b/src/login-common/client-common.c > > > > > > @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, > > > > > > const char *reason, > > > > > > /* Login was successful. We may now be proxying the connection, > > > > > > so don't disconnect the client until client_unref(). */ > > > > > > if (client->iostream_fd_proxy != NULL) { > > > > > > + i_assert(!client->fd_proxying); > > > > > > client->fd_proxying = TRUE; > > > > > > - i_assert(client->prev == NULL && client->next == NULL); > > > > > > + DLLIST_REMOVE(_clients, client); > > > > > > DLLIST_PREPEND(_fd_proxies, client); > > > > > > client_fd_proxies_count++; > > > > > > } > > > > > > @@ -307,8 +308,9 @@ void client_destroy(struct client *client, > > > > > > const char *reason) > > > > > > > > > > > > if (last_client == client) > > > > > > last_client = client->prev; > > > > > > - /* remove from clients linked list before it's added to > > > > > > - client_fd_proxies. */ > > > > > > + /* move to destroyed_clients linked list before it's potentially > > > > > > + added to client_fd_proxies. */ > > > > > > + i_assert(!client->fd_proxying); > > > > > > DLLIST_REMOVE(, client); > > > > > > DLLIST_PREPEND(_clients, client); > > > > > > > > > > > > @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) > > > > > > DLLIST_REMOVE(_fd_proxies, client); > > > > > > i_assert(client_fd_proxies_count > 0); > > > > > >
Re: Latest git FATAL error
The current autoconf code is bit buggy, but if you do indeed have libsystemd-dev installed it should do the right thing and will work with systemd even if you have Type=notify. This has been actually tested, so if it's not working, then something else is wrong. Did you remember to run ./autogen.sh after pulling from git to make sure you get new configure script? Aki > On 26/04/2021 10:11 Joan Moreau wrote: > > > Yes systemd is installed (and the "dev" files as well) > > > On 2021-04-26 06:23, Aki Tuomi wrote: > > This is because you are not compiling with libsystemd-dev installed. I > > guess we need to make some service template that use type simple when you > > don't use libsystemd. > > > > Aki > > > > > > > On 25/04/2021 22:53 Joan Moreau wrote: > > > > > > > > > Yes, it seems fixed with this patch :) > > > > > > Another bug with git, is the "type=" in systemd is switched from "simple" > > > to "notify". The later does not work and reverting to "simple" does work > > > > > > > > > On 2021-04-25 17:53, Aki Tuomi wrote: > > > > > On 24/04/2021 21:56 Joan Moreau wrote: > > > > > > > > > > > > > > > chroot= does not resolve the issue > > > > > I have "chroot = login" in my conf > > > > > > > > > > > > > Thanks! > > > > > > > > The chroot was needed to get the core dump. > > > > > > > > Can you try if this does fix the crash? > > > > > > > > Aki > > > > > > > > From 1df4e02cbff710ce8938480b07a5690e37f661f6 Mon Sep 17 00:00:00 2001 > > > > From: Timo Sirainen > > > > Date: Fri, 23 Apr 2021 16:43:36 +0300 > > > > Subject: [PATCH] login-common: Fix handling destroyed_clients linked > > > > list > > > > > > > > The client needs to be removed from destroyed_clients linked list before > > > > it's added to client_fd_proxies linked list. > > > > > > > > Broken by 1c622cdbe08df2f642e28923c39894516143ae2a > > > > --- > > > > src/login-common/client-common.c | 11 +++ > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/src/login-common/client-common.c > > > > b/src/login-common/client-common.c > > > > index bdb6e9c798..1d264d9f75 100644 > > > > --- a/src/login-common/client-common.c > > > > +++ b/src/login-common/client-common.c > > > > @@ -289,8 +289,9 @@ void client_disconnect(struct client *client, const > > > > char *reason, > > > > /* Login was successful. We may now be proxying the connection, > > > > so don't disconnect the client until client_unref(). */ > > > > if (client->iostream_fd_proxy != NULL) { > > > > + i_assert(!client->fd_proxying); > > > > client->fd_proxying = TRUE; > > > > - i_assert(client->prev == NULL && client->next == NULL); > > > > + DLLIST_REMOVE(_clients, client); > > > > DLLIST_PREPEND(_fd_proxies, client); > > > > client_fd_proxies_count++; > > > > } > > > > @@ -307,8 +308,9 @@ void client_destroy(struct client *client, const > > > > char *reason) > > > > > > > > if (last_client == client) > > > > last_client = client->prev; > > > > - /* remove from clients linked list before it's added to > > > > - client_fd_proxies. */ > > > > + /* move to destroyed_clients linked list before it's potentially > > > > + added to client_fd_proxies. */ > > > > + i_assert(!client->fd_proxying); > > > > DLLIST_REMOVE(, client); > > > > DLLIST_PREPEND(_clients, client); > > > > > > > > @@ -409,13 +411,14 @@ bool client_unref(struct client **_client) > > > > DLLIST_REMOVE(_fd_proxies, client); > > > > i_assert(client_fd_proxies_count > 0); > > > > client_fd_proxies_count--; > > > > + } else { > > > > + DLLIST_REMOVE(_clients, client); > > > > } > > > > i_stream_unref(>input); > > > > o_stream_unref(>output); > > > > i_close_fd(>fd); > > > > event_unref(>event); > > > > > > > > - DLLIST_REMOVE(_clients, client); > > > > i_free(client->proxy_user); > > > > i_free(client->proxy_master_user); > > > > i_free(client->virtual_user);