Re: [SOLVED] Permissions for dovecot logging
On 30 December 2022 22:25:09 CET, James Moe wrote: >On 2022-12-27 16:19, James Moe wrote: > >> I changed logging to use a path rather than syslog. Doing so makes it >> easier >> to work with fail2ban. >> Dovecot fails to start with the error: >> Can't open log file /data01/var/log/dovecot.log: Permission denied >> > Yes, it was apparmor. It has been enabled for a couple of months. Dovecot is >the first app that I've added that has a apparmor profile. After adding the >necessary entry to the profile, logging proceeded as expected. > >In I added: > owner /data01/var/log/dovecot/* a, > > Hi, When an application is denied access by AppArmor, you can see the logs in syslog. Anyway, if that helps, have s look here: https://github.com/progmaticltd/homebox/tree/main/roles/dovecot/templates/apparmor.d André.
Permissions issue with doveadm mailbox command
I have been exploring dovecot and came across this:
$ sudo doveadm mailbox list
doveadm(root): Error: Mail access for users with UID 303 not permitted (see
first_valid_uid in config file, uid from mail_uid setting).
Hmm. After setting "first_valid_uid = 300":
$ sudo doveadm mailbox list
doveadm(root)<4380><4VP8EENer2McEQAAvbJltg>: Error: chdir(/root/) failed:
Permission denied (euid=303(vmail) egid=303(vmail) missing +x perm: /root, dir
owned by 0:0 mode=0700)
INBOX
I do not understand the error message.
The current configuration. (Note I have changed first_valid_uid to its
original value.)
$ postconf -n
# 2.3.15 (0503334ab1): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.15 (e6a84e31)
# OS: Linux 5.14.21-150400.24.33-default x86_64 btrfs
# Hostname: sma-server3.sma.com
auth_mechanisms = plain login
base_dir = /var/run/dovecot/
debug_log_path = /data01/var/log/dovecot/dovecot-debug.log
disable_plaintext_auth = no
first_valid_uid = 1001
info_log_path = /data01/var/log/dovecot/dovecot-info.log
log_path = /data01/var/log/dovecot/dovecot.log
log_timestamp = %Y-%m-%dT%H:%M:%S
mail_gid = vmail
mail_location = maildir:/var/mail/vmail/%u/
mail_uid = vmail
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
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service log {
group = users
user = dovecot
}
ssl = no
ssl_cipher_list =
ALL:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
ssl_options = no_compression
ssl_prefer_server_ciphers = yes
userdb {
driver = passwd
}
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
--
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.
doveadm proxy list has strange entries
Hi!
I am using dovecot from the latest docker image: Version 2:2.3.20-3+debian11
When getting the proxy list I get the following entries.
# doveadm -f flow proxy list
username=u...@example.com proto=imap src ip=10.254.0.13 dest
ip=172.23.6.194 port=143
username=username proto=service src ip=src-ip dest ip=dest-ip port=dest-port
username=us...@example.com proto=imap src ip=10.254.0.13 dest
ip=172.23.6.194 port=143
username=username proto=service src ip=src-ip dest ip=dest-ip port=dest-port
username=us...@example.com proto=imap src ip=10.254.0.13 dest
ip=172.23.6.194 port=143
username=username proto=service src ip=src-ip dest ip=dest-ip port=dest-port
...
These correspond to the http API's response:
# curl -H "Authorization: X-Dovecot-API $(echo -n MY_API_KEY|base64
-w0)" http://localhost:8080/doveadm/v1 -H "Content-Type:
application/json" -d '[["proxyList",{},"tag1"]]' | jq
[
[
"doveadmResponse",
[
{
"username": "u...@example.com",
"service": "imap",
"src-ip": "10.254.0.13",
"dest-ip": "172.23.6.194",
"dest-port": "143"
},
{
"username": "username",
"service": "service",
"src-ip": "src-ip",
"dest-ip": "dest-ip",
"dest-port": "dest-port"
},
...
],
"tag1"
]
]
This does not look right.
Cheers,
Tobias Florek
Re: [SOLVED] Permissions for dovecot logging
On 2022-12-27 16:19, James Moe wrote: > I changed logging to use a path rather than syslog. Doing so makes it easier > to work with fail2ban. > Dovecot fails to start with the error: > Can't open log file /data01/var/log/dovecot.log: Permission denied > Yes, it was apparmor. It has been enabled for a couple of months. Dovecot is the first app that I've added that has a apparmor profile. After adding the necessary entry to the profile, logging proceeded as expected. In I added: owner /data01/var/log/dovecot/* a, -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 Think.
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
Hi, Yes, it works perfectly! Jorge Concha C. Área de Sistemas - CEC U. de Chile On 30-12-22 05:19, Peter wrote: On 30/12/22 13:17, Peter wrote: On 30/12/22 07:40, Jorge Concha C. wrote: Hi... rpcgen it's required only at compiling time. Not for execution. The RPM package at https://mirror.ghettoforge.org/distributions/gf/el/9/testing/x86_64/ requiere rpcgen and this is not necesary. I wasn't sure and what I could find seemed to indicate it was required at runtime as well. Can you verify that it works, though? I'll remove the runtime requirement. Feel free to try the packages in gf-testing now, I believe they should work for what you need. I'll move them out to gf-plus once you've confirmed. Peter
doveadm sync - I/O has stalled
Hi All, We are using dovecot 2.3.19.1 We created a account with more than 1000 mail folders in Maildir format to reproduce the issue. After weeks of testing, we have found a logic that may cause dsync to encounter the error - no activity for 900 seconds The function, dsync_ibc_stream_input, is the callback function after some data are ready for be read. This is part of what it does. o_stream_cork(ibc->output); ibc->ibc.io_callback(ibc->ibc.io_context); o_stream_uncork(ibc->output); Normally, ibc->ibc.io_callback(ibc->ibc.io_context) reads some data and then processes it. But when dsync connects over tcps, it uses function implementations in lib-ssl-iostream to send and receive data. And this simplified call stack would result in some data are read when calling o_stream_uncork o_stream_uncork => o_stream_flush => o_stream_ssl_flush_buffer => openssl_iostream_bio_sync => openssl_iostream_bio_input If some data arrive after ibc->ibc.io_callback(ibc->ibc.io_context) and before o_stre am_uncork, o_stream_uncork would read the data and then return. After o_stream_uncork returns, dsync then waits for new data to be read or written. But because the data had been read in o_stream_uncork, and there may be no new data to be read, dsync may then wait until timeout is met. It may happen, but it is hard to reproduce. If you also encounter this situation, you may try to use dsync over tcp connection. It does not read data when calling o_stream_uncork. As a result, it may not stuck. Back to the error itself, Maybe openssl-stream should not read data when doing uncork(flush)? Song-Lin Yang
Re: Permissions for dovecot logging
On Thursday, December 29, 2022 10:17:08 PM AKST Aki Tuomi wrote:
> > On 30/12/2022 05:25 EET James Moe wrote:
> > Permission is still denied.
> > Where do I find information about "status=80/n/a"?
> >
> > I did not include all two of the syslog entries in the previous message:
> > 2022-12-29T20:17:56-0700 sma-server3 dovecot[12102]: Can't open log file
> > /data01/var/log/dovecot.log: Permission denied
> > 2022-12-29T20:17:56-0700 sma-server3 systemd[1]: dovecot.service: Main
> > process exited, code=exited, status=80/n/a
>
> Maybe you have selinux or apparmor involved? On rhel based systems, selinux
> logs into /var/log/audit/audit.log, dmesg -T is another good thing to
> check.
>
Status=80 I assume is the exit code dovecot threw when it couldn't open the
log file. Whatever "int main()" is programmed to return.
On Tuesday, December 27, 2022 2:19:39 PM AKST James Moe wrote:
> Dovecot fails to start with the error:
> Can't open log file /data01/var/log/dovecot.log: Permission denied
That error message is typical of a simple unix permission issue, nothing to do
with selinux etc.
On Tuesday, December 27, 2022 2:19:39 PM AKST James Moe wrote:
> Permissions:
> drwxrwxr-x 1 root users 104 Feb 25 2018 /data01/
> drwxrwxr-x 1 sma-user3x users 102 Dec 17 14:50 /data01/var/
> drwxrwxr-x 1 sma-user3x users 146 Dec 27 15:37 /data01/var/log/
> drwxrwxr-x 1 dovecotusers 22 Dec 27 15:47 /data01/var/log/dovecot/
>
> "dovecot" is a member of "users".
>
> What "permission" am I missing?
If the process isn't running with an effective group id of "users", then it
cannot access that directory simply by virtue of being a member of that group.
The main program has to call setegid() with the proper group id before
attempting to access those files.
On Tuesday, December 27, 2022 10:27:31 PM AKST Aki Tuomi wrote:
> If you want to run log as `dovecot`, you can do so with
>
> service log {
> user = dovecot
> }
Maybe try something like this:
service log {
user = dovecot
group = users
}
Otherwise you might not have the process running with the right effective group
id to access the log file location by unix group permissions.
--
https://justina.abeja.colmena.biz/
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
> On 30/12/2022 10:47 EET Peter wrote: > > > On 28/12/22 03:31, Jorge Concha C. wrote: > > Finally, I found the problem. > > At build time, I had not installed the 'rpcgen' (RPM) package. > > Initially, I installed the original RPM of the Rocky-Linux distribution, > > having the same problem. > > I gather that the Rocky-Linux community is also creating the dovecot's > > rpm without 'rpcgen' installed. > > A little bit of background on this since I've been looking into it. > > Up through RHEL 7 the rpcgen binary was included in the glibc-common > package, which is part of the standard build deps that are installed for > all builds. As of RHEL 8 this binary was moved to it's own package and > was not installed automatically as it was previously. > > This means that rquota (quota on NFS) worked fine up through EL7, but > was broken for all builds starting with EL8. Since dovecot builds fine > without rquota support it appears that the issue never came up before, > or at least it never got the notice of Red Hat. > > The solution, as you point out is simple. rpcgen simply needs to be > added as a BuildRequires line in the dovecot.spec file and the package > will once again be built with rquota support as it was before. > > I filed a bug in Red Hat bugzilla, let's see if anything comes of it: > > https://bugzilla.redhat.com/show_bug.cgi?id=2157045 > > > Peter Thanks Peter, we'll also take a note of the rpcgen change. Aki
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 28/12/22 03:31, Jorge Concha C. wrote: Finally, I found the problem. At build time, I had not installed the 'rpcgen' (RPM) package. Initially, I installed the original RPM of the Rocky-Linux distribution, having the same problem. I gather that the Rocky-Linux community is also creating the dovecot's rpm without 'rpcgen' installed. A little bit of background on this since I've been looking into it. Up through RHEL 7 the rpcgen binary was included in the glibc-common package, which is part of the standard build deps that are installed for all builds. As of RHEL 8 this binary was moved to it's own package and was not installed automatically as it was previously. This means that rquota (quota on NFS) worked fine up through EL7, but was broken for all builds starting with EL8. Since dovecot builds fine without rquota support it appears that the issue never came up before, or at least it never got the notice of Red Hat. The solution, as you point out is simple. rpcgen simply needs to be added as a BuildRequires line in the dovecot.spec file and the package will once again be built with rquota support as it was before. I filed a bug in Red Hat bugzilla, let's see if anything comes of it: https://bugzilla.redhat.com/show_bug.cgi?id=2157045 Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 30/12/22 13:17, Peter wrote: On 30/12/22 07:40, Jorge Concha C. wrote: Hi... rpcgen it's required only at compiling time. Not for execution. The RPM package at https://mirror.ghettoforge.org/distributions/gf/el/9/testing/x86_64/ requiere rpcgen and this is not necesary. I wasn't sure and what I could find seemed to indicate it was required at runtime as well. Can you verify that it works, though? I'll remove the runtime requirement. Feel free to try the packages in gf-testing now, I believe they should work for what you need. I'll move them out to gf-plus once you've confirmed. Peter
