Re: Can’t authenticate any users after upgrade.

[Helmut K. C. Tessarek]

On 2018-04-05 22:14, Kevin Cummings wrote:
> OK, so I went this root, added the new file, stopped dovecot, did the
> daemon-reload, then started it up again.
> It did not work for me.  As I continued to read the other emails in this
> thread, I came to the conclusion that the Fedora configuration, as
> packaged by City-Fan.org  is what is broken. 
> Luckily for me, there was still a 2.2.35 version of dovecot in the
> repository, so I ended up doing the "dnf downgrade dovecot" and now I
> can read my emails again.  I'm assuming that the packager for Fedora
> will ensure that this gets fixed in the current releases.  I checked,
> and F26

Interesting, I'm still on an older Fedora release, but I used the
original Fedora spec file, which I adjusted a bit (so that it uses my
own openssl version instead of the system's, and a few other minor
tweaks), and created my own dovecot 2.3.1 package.

In any case, the changes I described fixed it for me.

I don't think the Fedora packager even knows about the PAM configuration
issue, otherwise he would have written a patch, but there's nothing in
git master of the dovecot package repo.

I've opend a bug with Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1564348

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: Can’t authenticate any users after upgrade.

[Kevin Cummings]

> On 04/05/18 02:34, B. Reino wrote:
>> On 2018-04-05 06:33, Helmut K. C. Tessarek wrote: 
>>> On 2018-04-04 23:10, Kevin Cummings wrote: 
>>> PAM audit_log_acct_message() failed: Operation not permitted 
>>> imap-login: Disconnected (AUTH failed, 2 attempts in 10 secs): 
>>> user=, method=PLAIN, rip=192.168.1.94 lip=192.168.1.94, TLS, 
>>> session= 
>> 
>> Please look at my pull request at: 
>> https://github.com/dovecot/core/pull/71 
>> 
>> Or, if it's any easier: 
>> 
>> 1) Stop dovecot 
>> 2) Replace /usr/lib/systemd/system/dovecot.service with the attached file 
> 
> I'd recommend to just override the necessary options by creating 
> /etc/systemd/system/dovecot.service.d/NoNewPrivileges.conf with the following 
> content: 
> 
> -<<-- 
> [Service] 
> NoNewPrivileges=false 
> -->>- 
> 
> This way the fix survives any updates and you don't have to mess with 
> package-provided files.   
> 
>> 3) systemctl daemon-reload 
>> 4) systemctl start dovecot 

OK, so I went this root, added the new file, stopped dovecot, did the 
daemon-reload, then started it up again.
It did not work for me.  As I continued to read the other emails in this 
thread, I came to the conclusion that the Fedora configuration, as packaged by 
City-Fan.org is what is broken.  Luckily for me, there was still a 2.2.35 
version of dovecot in the repository, so I ended up doing the "dnf downgrade 
dovecot" and now I can read my emails again.  I'm assuming that the packager 
for Fedora will ensure that this gets fixed in the current releases.  I 
checked, and F26 

Re: Can’t authenticate any users after upgrade.

[Helmut K. C. Tessarek]

On 2018-04-05 02:34, B. Reino wrote:
> This way the fix survives any updates and you don't have to mess with
> package-provided files.

You'd also have to add the following:

CapabilityBoundingSet=CAP_CHOWN CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_KILL
CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_CHROOT
CAP_SYS_RESOURCE CAP_AUDIT_WRITE

It won't work without CAP_AUDIT_WRITE, even, if NoNewPrivileges is set
to false, at least not on my server.

But as I've mentioned this _could_ be counterproductive if in the future
the systemd file that comes with dovecot is changed and you forget to
delete /etc/systemd/system/dovecot.service.d/NoNewPrivileges.conf again.


-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: Can’t authenticate any users after upgrade.

[Helmut K. C. Tessarek]

On 2018-04-05 03:01, Aki Tuomi wrote:
> Never replace /lib or /usr/lib systemd unit files, if you want to
> replace the whole unit file, please put it under /etc/systemd/system/
> directory. If unit file with same name is found under there, it is used
> instead.

Usually I'd agree, but let's assume you change something in the file
that comes with dovecot in the future, systemd will still use the one in
/etc/system.d/system and you'd never know that the original file has
ever even changed.

On the other side, if with the next version of dovecot this
NoNewPrivileges issue will not have been resolved, you just change the
file again.
If it has been fixed, all is good anyway.

Anyhow, both concepts are valid in this instance in my opinion.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: 2.3.1 Replication is throwing scary errors

[Remko Lodder]

> On 4 Apr 2018, at 01:34, Reuben Farrelly  wrote:
> 
> Hi,
> 
>> --
>> Message: 2
>> Date: Mon, 2 Apr 2018 22:06:07 +0200
>> From: Michael Grimm 
>> To: Dovecot Mailing List 
>> Subject: 2.3.1 Replication is throwing scary errors
>> Message-ID: <29998016-d62f-4348-93d1-613b13da9...@ellael.org>
>> Content-Type: text/plain;charset=utf-8
>> Hi
>> [This is Dovecot 2.3.1 at FreeBSD STABLE-11.1 running in two jails at 
>> distinct servers.]
>> I did upgrade from 2.2.35 to 2.3.1 today, and I do become pounded by error 
>> messages at server1 (and vice versa at server2) as follows:
>>  | Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
>> dsync(server2.lan): I/O has stalled, \
>>  no activity for 600 seconds (last sent=mail_change, last 
>> recv=mail_change (EOL))
>>  | Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
>> Timeout during state=sync_mails \
>>  (send=changes recv=mail_requests)
>>  [?]
>>  | Apr  2 18:59:03  server1.lan dovecot: doveadm: Error: 
>> dsync(server2.lan): I/O has stalled, \
>>  no activity for 600 seconds (last sent=mail, last recv=mail 
>> (EOL))
>>  | Apr  2 18:59:03  server1.lan dovecot: doveadm: Error: 
>> Timeout during state=sync_mails \
>>  (send=mails recv=recv_last_common)
>> I cannot see in my personal account any missing replications, *but* I 
>> haven't tested this thoroughly enough. I do have customers being serviced at 
>> these productive servers, *thus* I'm back to 2.2.35 until I do understand or 
>> have learned what is going on.
>> Any ideas/feedback?
>> FYI: I haven't seen such errors before. Replication has been working for 
>> years now, without any glitches at all.
>> Regards,
>> Michael
> 
> It's not just you.  This issue hit me recently, and it was impacting 
> replication noticeably.  I am following git master-2.3 .
> 
> 

I am seeing the same as Michael Grimm also on FreeBSD-11.
You’ll also notice in doveadm replicator status ‘*’ that the failed flag is 
raised for those users and that
there are processes just hanging forever when those logs start to appear:

   45949   0.0  0.047888  13276  -  I20:200:00.10 
doveadm-server: [ Verwijderde items send:mail_requests recv:changes] 
(doveadm-server)
 45964   0.0  0.049860  11608  -  I20:200:00.05 
doveadm-server: [IP6  INBOX import:1/3] (doveadm-server)
 45965   0.0  0.158256  19820  -  I20:200:00.11 
doveadm-server: [IP6  INBOX import:16/18] (doveadm-server)
 46480   0.0  0.053536  16288  -  I20:220:00.08 
doveadm-server: [IP6  INBOX import:4/6] (doveadm-server)
 46745   0.0  0.051496  14184  -  I20:220:00.07 
doveadm-server: [IP6  INBOX import:5/6] (doveadm-server)

I also reverted to 2.2.35 because I started to get complaints from my users 
that mail was missing.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP

issue with sieve forwarding after upgrade to 0.5.1

[Christos Chatzaras]

Finally I found a workaround to not depend on sendmail to forward messages 
using sieve:


In postfix main.cf I have:

authorized_submit_users = root, filter

(I want only root and filter to use sendmail and block other users to send 
e-mails from system accounts. Only allow users to send e-mails from virtual 
accounts and after smtp authentication. Username filter is used for bogofilter 
and needs access to sendmail)


And in dovecot.conf:

submission_host = 138.201.248.xxx


The same workaround maybe works for NoNewPrivileges too as the 
authorized_submit_users setting in postfix has similar result.

Re: GFS2 writes extremely slow

[Aki Tuomi]

On 05.04.2018 15:08, DurgaPrasad - DatasoftComnet wrote:
> Hello all,
> We are facing extremely slow GFS2 issues in Redhat 7 64 bit. Backend is 16 
> Gbps FC SAN so no issues there.
>
> I have scoured the entire (anyways most of the) Internet and arrived at the 
> following settings.
>
> mmap_disable = yes
This is ok
> mail_fsync = always
Try changing to never
> mail_nfs_storage = yes
> mail_nfs_index = yes
These you should not use.

> mmap_disable = yes

This is twice here.
> lock_method = fcntl
>
> Did a systemctl restart dovecot and did not find any major improvement.
> Can you please help.
>
> Regards
> Durga Prasad
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Aki

GFS2 writes extremely slow

[DurgaPrasad - DatasoftComnet]

Hello all,
We are facing extremely slow GFS2 issues in Redhat 7 64 bit. Backend is 16 Gbps 
FC SAN so no issues there.

I have scoured the entire (anyways most of the) Internet and arrived at the 
following settings.

mmap_disable = yes
mail_fsync = always
mail_nfs_storage = yes
mail_nfs_index = yes
mmap_disable = yes
lock_method = fcntl

Did a systemctl restart dovecot and did not find any major improvement.
Can you please help.

Regards
Durga Prasad


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Can’t authenticate any users after upgrade.

[Aki Tuomi]

On 05.04.2018 07:33, Helmut K. C. Tessarek wrote:
> On 2018-04-04 23:10, Kevin Cummings wrote:
>> PAM audit_log_acct_message() failed: Operation not permitted
>> imap-login: Disconnected (AUTH failed, 2 attempts in 10 secs):
>> user=, method=PLAIN, rip=192.168.1.94 lip=192.168.1.94, TLS,
>> session=
> Please look at my pull request at:
> https://github.com/dovecot/core/pull/71
>
> Or, if it's any easier:
>
> 1) Stop dovecot
> 2) Replace /usr/lib/systemd/system/dovecot.service with the attached file
> 3) systemctl daemon-reload
> 4) systemctl start dovecot
>
> Done.
>
> Cheers,
>  K. C.
>

Hi!

Never replace /lib or /usr/lib systemd unit files, if you want to
replace the whole unit file, please put it under /etc/systemd/system/
directory. If unit file with same name is found under there, it is used
instead.

Aki