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);
