Hi, I am one of the people taking over our new suse.de email setup (consisting of dovecot+rspamd+postfix) and wanted to report some issues we experience: 1. we use dovecot-director to distribute users between 2 backend servers that share an NFS mount. We found that it proxies lmtp to a different backend than imap of the same user and that caused NFS stale-filehandle errors on the dovecot-uidlist. It then proceeds to re-generate the dovecot-uidlist with new UIDs that creates trouble for users. a) shouldn't dovecot use locks (fcntl or flock) to protect such files from concurrent updates? b) could it generate uidlist in a way that re-generating it, assigns the same UIDs again? E.g. via hash over file content c) how to get dovecot-director to send all traffic for a user to one backend? 2. We have 2 backends so that we can do maintenance on one of them while users can still access their emails through the other backend. However, we found that stopping dovecot on one backend left users unable to access their mails. Maybe this is related to how user auth works? How to get this HA setup right, so that we don't have a single point of failure? grep PRETTY /etc/os-release PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3" rpm -q dovecot23 dovecot23-2.3.15 https://www.zq1.de/~bernhard/temp/dovecot/ has some sysreports. Ciao Bernhard M.
> On 10/09/2021 12:19 Bernhard M. Wiedemann <bwiedemann at suse.de> wrote: > > > Hi, > > I am one of the people taking over our new suse.de email setup > (consisting of dovecot+rspamd+postfix) > and wanted to report some issues we experience: > > > 1. > we use dovecot-director to distribute users between 2 backend servers > that share an NFS mount. > We found that it proxies lmtp to a different backend than imap of the > same user and that caused NFS stale-filehandle errors on the > dovecot-uidlist. > It then proceeds to re-generate the dovecot-uidlist with new UIDs that > creates trouble for users. > > a) shouldn't dovecot use locks (fcntl or flock) to protect such files > from concurrent updates? > > b) could it generate uidlist in a way that re-generating it, assigns the > same UIDs again? E.g. via hash over file content > > c) how to get dovecot-director to send all traffic for a user to one > backend? > > > 2. > We have 2 backends so that we can do maintenance on one of them while > users can still access their emails through the other backend. > However, we found that stopping dovecot on one backend left users unable > to access their mails. > Maybe this is related to how user auth works? > How to get this HA setup right, so that we don't have a single point of > failure? > > > grep PRETTY /etc/os-release > PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3" > > rpm -q dovecot23 > dovecot23-2.3.15 > > https://www.zq1.de/~bernhard/temp/dovecot/ has some sysreports. > > Ciao > Bernhard M.Can you post your `doveconf -n`? LMTP should not end up in different backend. Aki
Bernhard M. Wiedemann schreef op 2021-09-10 11:19:> Hi, > > I am one of the people taking over our new suse.de email setup > (consisting of dovecot+rspamd+postfix) > and wanted to report some issues we experience: > > > 1. > we use dovecot-director to distribute users between 2 backend servers > that share an NFS mount. > We found that it proxies lmtp to a different backend than imap of the > same user and that caused NFS stale-filehandle errors on the > dovecot-uidlist. > It then proceeds to re-generate the dovecot-uidlist with new UIDs that > creates trouble for users. > > a) shouldn't dovecot use locks (fcntl or flock) to protect such files > from concurrent updates? > > b) could it generate uidlist in a way that re-generating it, assigns > the > same UIDs again? E.g. via hash over file content > > c) how to get dovecot-director to send all traffic for a user to one > backend? > > > 2. > We have 2 backends so that we can do maintenance on one of them while > users can still access their emails through the other backend. > However, we found that stopping dovecot on one backend left users > unable > to access their mails.Director doesn't do health checks.> Maybe this is related to how user auth works? > How to get this HA setup right, so that we don't have a single point of > failure? > > > grep PRETTY /etc/os-release > PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3" > > rpm -q dovecot23 > dovecot23-2.3.15 > > https://www.zq1.de/~bernhard/temp/dovecot/ has some sysreports. > > Ciao > Bernhard M.-- With kind regards, William Edwards
> On 10/09/2021 12:19 Bernhard M. Wiedemann <bwiedemann at suse.de> wrote: > > > Hi, > > I am one of the people taking over our new suse.de email setup > (consisting of dovecot+rspamd+postfix) > and wanted to report some issues we experience: > > > 1. > we use dovecot-director to distribute users between 2 backend servers > that share an NFS mount. > We found that it proxies lmtp to a different backend than imap of the > same user and that caused NFS stale-filehandle errors on the > dovecot-uidlist. > It then proceeds to re-generate the dovecot-uidlist with new UIDs that > creates trouble for users. > > a) shouldn't dovecot use locks (fcntl or flock) to protect such files > from concurrent updates? > > b) could it generate uidlist in a way that re-generating it, assigns the > same UIDs again? E.g. via hash over file content > > c) how to get dovecot-director to send all traffic for a user to one > backend? > > > 2. > We have 2 backends so that we can do maintenance on one of them while > users can still access their emails through the other backend. > However, we found that stopping dovecot on one backend left users unable > to access their mails. > Maybe this is related to how user auth works? > How to get this HA setup right, so that we don't have a single point of > failure? > > > grep PRETTY /etc/os-release > PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3" > > rpm -q dovecot23 > dovecot23-2.3.15 > > https://www.zq1.de/~bernhard/temp/dovecot/ has some sysreports. > > Ciao > Bernhard M.It seems you are normalizing SQL usernames by doing SELECT username, but you are not doing it for LDAP. See if the problem goes away with pass_attrs = uid=username Aki
You can setup the nfs users with NIS over idmapd. Then setup the dovecot server with NIS logins, so the the user login from any server over nis will get uid, gid, userhome etc, It mean it can read the nis users passwd and shadow. On Fri, 10 Sep, 2021, 2:49 pm Bernhard M. Wiedemann, <bwiedemann at suse.de> wrote:> Hi, > > I am one of the people taking over our new suse.de email setup > (consisting of dovecot+rspamd+postfix) > and wanted to report some issues we experience: > > > 1. > we use dovecot-director to distribute users between 2 backend servers > that share an NFS mount. > We found that it proxies lmtp to a different backend than imap of the > same user and that caused NFS stale-filehandle errors on the > dovecot-uidlist. > It then proceeds to re-generate the dovecot-uidlist with new UIDs that > creates trouble for users. > > a) shouldn't dovecot use locks (fcntl or flock) to protect such files > from concurrent updates? > > b) could it generate uidlist in a way that re-generating it, assigns the > same UIDs again? E.g. via hash over file content > > c) how to get dovecot-director to send all traffic for a user to one > backend? > > > 2. > We have 2 backends so that we can do maintenance on one of them while > users can still access their emails through the other backend. > However, we found that stopping dovecot on one backend left users unable > to access their mails. > Maybe this is related to how user auth works? > How to get this HA setup right, so that we don't have a single point of > failure? > > > grep PRETTY /etc/os-release > PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3" > > rpm -q dovecot23 > dovecot23-2.3.15 > > https://www.zq1.de/~bernhard/temp/dovecot/ has some sysreports. > > Ciao > Bernhard M. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20210910/01a49030/attachment.html>