Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #269312 > unrolled thread

Dovecot correct ownership for logs

Started byRichard <rrosner5@gmail.com>
First post2024-05-13 22:20 +0200
Last post2024-05-14 14:20 +0200
Articles 20 on this page of 80 — 28 participants

Back to article view | Back to linux.debian.user


Contents

  Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-13 22:20 +0200
    Re: Dovecot correct ownership for logs Geert Stappers <stappers@stappers.nl> - 2024-05-13 22:30 +0200
    Re: Dovecot correct ownership for logs Greg Wooledge <greg@wooledge.org> - 2024-05-13 22:30 +0200
      Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 13:20 +0200
    Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-14 00:50 +0200
      Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 13:20 +0200
        Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-14 13:40 +0200
          Re: Dovecot correct ownership for logs Greg Wooledge <greg@wooledge.org> - 2024-05-14 13:50 +0200
            Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-14 14:00 +0200
              Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 19:30 +0200
            Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 14:00 +0200
              Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 15:20 +0200
                Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 15:30 +0200
                OT: Top Posting (was: Dovecot correct ownership for logs) "Loris Bennett" <loris.bennett@fu-berlin.de> - 2024-05-14 16:00 +0200
                  Re: OT: Top Posting (was: Dovecot correct ownership for logs) Richard <rrosner5@gmail.com> - 2024-05-14 16:10 +0200
                    Re: OT: Top Posting gene heskett <gheskett@shentel.net> - 2024-05-14 17:00 +0200
                      Re: OT: Top Posting Richard <rrosner5@gmail.com> - 2024-05-14 17:10 +0200
                        Re: OT: Top Posting Jeffrey Walton <noloader@gmail.com> - 2024-05-14 21:00 +0200
                          Re: OT: Top Posting Larry Martell <larry.martell@gmail.com> - 2024-05-15 00:30 +0200
                      Re: OT: Top Posting fxkl47BF@protonmail.com - 2024-05-14 19:10 +0200
                        Re: OT: Top Posting Greg Wooledge <greg@wooledge.org> - 2024-05-14 19:50 +0200
                          Re: OT: Top Posting "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2024-05-14 20:00 +0200
                          Re: OT: Top Posting Nicolas George <george@nsup.org> - 2024-05-14 20:20 +0200
                            Re: OT: Top Posting Karen Lewellen <klewellen@shellworld.net> - 2024-05-14 20:40 +0200
                            Re: OT: Top Posting Greg Wooledge <greg@wooledge.org> - 2024-05-14 21:40 +0200
                              Markup in mail messages (was: Re: OT: Top Posting) Max Nikulin <manikulin@gmail.com> - 2024-05-15 04:20 +0200
                                Re: Markup in mail messages eben@gmx.us - 2024-05-15 05:40 +0200
                                Re: Markup in mail messages Darac Marjal <mailinglist@darac.org.uk> - 2024-05-15 17:00 +0200
                                  Re: Markup in mail messages David <curmudgeon@telaman.net.au> - 2024-05-15 20:50 +0200
                                  Re: Markup in mail messages Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-16 15:30 +0200
                                    Re: Markup in mail messages <tomas@tuxteam.de> - 2024-05-16 15:50 +0200
                                      Re: Markup in mail messages Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-16 16:00 +0200
                                        Re: Markup in mail messages Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-17 21:30 +0200
                                          Re: Markup in mail messages Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-17 23:20 +0200
                                          Re: Markup in mail messages Max Nikulin <manikulin@gmail.com> - 2024-05-18 05:40 +0200
                                          Re: Markup in mail messages <tomas@tuxteam.de> - 2024-05-18 07:50 +0200
                                      Re: Markup in mail messages Max Nikulin <manikulin@gmail.com> - 2024-05-16 19:00 +0200
                                      Re: Markup in mail messages Karl Vogel <vogelke@pobox.com> - 2024-05-17 05:50 +0200
                                        Re: Markup in mail messages Max Nikulin <manikulin@gmail.com> - 2024-05-17 07:50 +0200
                                          Re: Markup in mail messages Greg Wooledge <greg@wooledge.org> - 2024-05-17 13:20 +0200
                                            Re: Markup in mail messages Max Nikulin <manikulin@gmail.com> - 2024-05-18 15:30 +0200
                                              Re: Markup in mail messages Greg Wooledge <greg@wooledge.org> - 2024-05-18 15:50 +0200
                                    Re: Markup in mail messages Curt <curty@free.fr> - 2024-05-16 17:10 +0200
                          Re: OT: Top Posting debian-user@howorth.org.uk - 2024-05-14 21:40 +0200
                          Re: OT: Top Posting Cindy Sue Causey <butterflybytes@gmail.com> - 2024-05-15 16:40 +0200
                            Re: OT: Top Posting Nicolas George <george@nsup.org> - 2024-05-15 17:00 +0200
                              Re: OT: Top Posting gene heskett <gheskett@shentel.net> - 2024-05-15 20:10 +0200
                        Re: OT: Top Posting "Andrew M.A. Cater" <amacater@einval.com> - 2024-05-14 20:30 +0200
                        Re: OT: Top Posting Andy Smith <andy@strugglers.net> - 2024-05-14 23:20 +0200
                          Re: OT: Top Posting fxkl47BF@protonmail.com - 2024-05-14 23:40 +0200
                      Re: OT: Top Posting Cindy Sue Causey <butterflybytes@gmail.com> - 2024-05-15 15:50 +0200
                        Re: OT: Top Posting Nicolas George <george@nsup.org> - 2024-05-15 16:10 +0200
                          Re: OT: Top Posting gene heskett <gheskett@shentel.net> - 2024-05-15 16:50 +0200
                        Re: OT: Top Posting Greg Wooledge <greg@wooledge.org> - 2024-05-15 16:50 +0200
                          Re: OT: Top Posting Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-15 18:10 +0200
                        Re: OT: Top Posting "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2024-05-15 18:50 +0200
                    Re: OT: Top Posting (was: Dovecot correct ownership for logs) <tomas@tuxteam.de> - 2024-05-14 17:30 +0200
                Re: Dovecot correct ownership for logs Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-14 16:00 +0200
                  Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 20:50 +0200
                Re: Dovecot correct ownership for logs Alain D D Williams <addw@phcomp.co.uk> - 2024-05-14 17:40 +0200
                  Re: Dovecot correct ownership for logs Nicolas George <george@nsup.org> - 2024-05-14 17:50 +0200
          Re: Dovecot correct ownership for logs <tomas@tuxteam.de> - 2024-05-14 13:50 +0200
    Re: Dovecot correct ownership for logs <tomas@tuxteam.de> - 2024-05-14 06:40 +0200
      Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 13:40 +0200
        Re: Dovecot correct ownership for logs tomas@tuxteam.de - 2024-05-14 13:50 +0200
          Re: Dovecot correct ownership for logs Florent Rougon <f.rougon@free.fr> - 2024-05-14 14:10 +0200
          Re: Dovecot correct ownership for logs tomas@tuxteam.de - 2024-05-14 14:20 +0200
            Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-15 00:50 +0200
              Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-15 12:30 +0200
                Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-15 12:40 +0200
                  Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-15 13:00 +0200
                    Re: Dovecot correct ownership for logs jeremy ardley <jeremy.ardley@gmail.com> - 2024-05-15 13:00 +0200
                Re: Dovecot correct ownership for logs Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-15 14:00 +0200
                  Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-16 13:10 +0200
                    Re: Dovecot correct ownership for logs Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-16 14:40 +0200
                      Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-17 10:20 +0200
                        Re: Dovecot correct ownership for logs Greg Wooledge <greg@wooledge.org> - 2024-05-17 14:30 +0200
                        Re: Dovecot correct ownership for logs Henning Follmann <hfollmann@itcfollmann.com> - 2024-05-17 14:30 +0200
                          Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-18 15:20 +0200
          Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-14 14:20 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]


#269350

FromNicolas George <george@nsup.org>
Date2024-05-14 17:50 +0200
Message-ID<IE2zD-djGA-9@gated-at.bofh.it>
In reply to#269349
Alain D D Williams (12024-05-14):
> PS: check the dictionary definition of "literally".

I think you should have checked first that it makes the point you want
to make and not the opposite:

2. (degree, figuratively, proscribed, contranym) Used non-literally as
   an intensifier for figurative statements: virtually, so to speak
   (often considered incorrect; see usage notes)
3. (colloquial) Used to intensify or dramatize non-figurative
   statements.
4. (colloquial) Used as a generic downtoner: just, merely.
<https://en.wiktionary.org/wiki/literally>

2. in effect : virtually—used in an exaggerated way to emphasize a
   statement or description that is not literally true or possible
<https://www.merriam-webster.com/dictionary/literally>

* used to emphasize what you are saying:
* simply or just:
<https://dictionary.cambridge.org/dictionary/english/literally>

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]


#269331

From<tomas@tuxteam.de>
Date2024-05-14 13:50 +0200
Message-ID<IDYPo-dhq7-7@gated-at.bofh.it>
In reply to#269327

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:

[...]

> Postfix is chrooted (usuallly) to /var/spool/postfix
> 
> If postfix complains about /var/log/dovecot it's actually complaining about
> /var/spool/postfix/var/log/dovecot

I'm sceptical about this -- the error would have been ENOENT, not EPERM
(because an intervening directory would be missing).

But of course, I might be wrong.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269317

From<tomas@tuxteam.de>
Date2024-05-14 06:40 +0200
Message-ID<IDS7f-ddsi-1@gated-at.bofh.it>
In reply to#269312

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated files. Therefore
> I've created the directory /var/log/dovecot and told dovecot in
> 10-logging.conf to log info, debug and error messages to separate files.
> But I get error messages from postfix (weird):

I think this Dovecot's LDA (the local delivery agent) [1], which is
invoked by the MTA (Postfix) and is, therefore, most probably running
as postfix.

[...]

> > (temporary failure. Command output: lda(user): Error:
> > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't
> > open log file /var/log/dovecot/error.log: Permission denied )

This message actually is an indicator against the chroot theory posed
elsewhere in this thread (in a chroot, you would get "no such file or
directory", I guess).
> 
> This is the content of /var/log/dovecot:
> -rw-r--r--  1 dovecot dovecot    0 13. Mai 20:50 debug.log
> -rw-r--r--  1 dovecot dovecot  880 13. Mai 21:21 error.log
> -rw-r--r--  1 dovecot dovecot  40K 13. Mai 21:20 info.log

Try to set the log file's group to mail (or whatever group Postfix is
running as) and make them group writable.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269328

FromRichard <rrosner5@gmail.com>
Date2024-05-14 13:40 +0200
Message-ID<IDYFH-dhmS-3@gated-at.bofh.it>
In reply to#269317

[Multipart message — attachments visible in raw view] — view raw

My guess is that postfix runs as postfix. At least processes like local,
smtpd, bounce etc run as that user. But beyond that I have no idea how to
find that out. At least there's nothing in the postfix.service or
postfix@.service
about that. So I've changed the files to dovecot:postfix 664, but same
error.

Am Di., 14. Mai 2024 um 06:34 Uhr schrieb <tomas@tuxteam.de>:

> On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> > Maybe someone here knows how the ownership of these files for Dovecot
> needs
> > to be in order to work, as various distributions of Dovecot packages seem
> > to use different users:
> > I'd like Dovecot not to log into syslog, but to dedicated files.
> Therefore
> > I've created the directory /var/log/dovecot and told dovecot in
> > 10-logging.conf to log info, debug and error messages to separate files.
> > But I get error messages from postfix (weird):
>
> I think this Dovecot's LDA (the local delivery agent) [1], which is
> invoked by the MTA (Postfix) and is, therefore, most probably running
> as postfix.
>
> [...]
>
> > > (temporary failure. Command output: lda(user): Error:
> > > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied
> Can't
> > > open log file /var/log/dovecot/error.log: Permission denied )
>
> This message actually is an indicator against the chroot theory posed
> elsewhere in this thread (in a chroot, you would get "no such file or
> directory", I guess).
> >
> > This is the content of /var/log/dovecot:
> > -rw-r--r--  1 dovecot dovecot    0 13. Mai 20:50 debug.log
> > -rw-r--r--  1 dovecot dovecot  880 13. Mai 21:21 error.log
> > -rw-r--r--  1 dovecot dovecot  40K 13. Mai 21:20 info.log
>
> Try to set the log file's group to mail (or whatever group Postfix is
> running as) and make them group writable.
>
> Cheers
> --
> t
>

[toc] | [prev] | [next] | [standalone]


#269329

Fromtomas@tuxteam.de
Date2024-05-14 13:50 +0200
Message-ID<IDYPn-dhq7-1@gated-at.bofh.it>
In reply to#269328

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 14, 2024 at 01:29:17PM +0200, Richard wrote:
> My guess is that postfix runs as postfix.

That would be my guess too (or perhaps as some special "Debian-+postfix".

> At least processes like local,
> smtpd, bounce etc run as that user. But beyond that I have no idea how to
> find that out. At least there's nothing in the postfix.service or
> postfix@.service
> about that. So I've changed the files to dovecot:postfix 664, but same
> error.

You might try

  ps -eo pid,user,group,comm | grep postfix

or similar. Or have a look at Posrfix's log file ownerships.

You might try making the log files in question world writable just
to see whether the problem disappears or this approach is a blind
alley (don't forget to revert that: leaving them world-writable
seems like asking for trouble).

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269334

FromFlorent Rougon <f.rougon@free.fr>
Date2024-05-14 14:10 +0200
Message-ID<IDZ8K-dhMU-19@gated-at.bofh.it>
In reply to#269329
Le 14/05/2024, tomas@tuxteam.de a écrit:

> You might try
>
>   ps -eo pid,user,group,comm | grep postfix
>
> or similar.

Yep, and beware that the original message mentions a postfix program
named 'local' (/usr/lib/postfix/sbin/local).

> May 13 20:55:37 mail postfix/local[2824184]: (...)

Regards

-- 
Florent

[toc] | [prev] | [next] | [standalone]


#269335

Fromtomas@tuxteam.de
Date2024-05-14 14:20 +0200
Message-ID<IDZip-dhQd-3@gated-at.bofh.it>
In reply to#269329

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 14, 2024 at 02:11:53PM +0200, Richard wrote:

[...]

> Setting the permissions in /var/log/dovecot to 666 actually didn't
> solve the problem [...]

This seems to prove (or, at least, strongly suggest) that I was barking
up the wrong tree. I've currently run out of trees and at $DAYJOB, so
tight on resources. Good luck :)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269366

Fromjeremy ardley <jeremy.ardley@gmail.com>
Date2024-05-15 00:50 +0200
Message-ID<IE985-doby-1@gated-at.bofh.it>
In reply to#269335
On 14/5/24 20:17, tomas@tuxteam.de wrote:
> On Tue, May 14, 2024 at 02:11:53PM +0200, Richard wrote:
>
> [...]
>
>> Setting the permissions in /var/log/dovecot to 666 actually didn't
>> solve the problem [...]
> This seems to prove (or, at least, strongly suggest) that I was barking
> up the wrong tree. I've currently run out of trees and at $DAYJOB, so
> tight on resources. Good luck :)

Clarifying my understanding of the issues I have discovered that postfix runs a non chroot service 'local' that has the initial responsibility to deliver mail locally.

local runs as root and has the ability to deliver mail to local files

local also has the ability to delegate the delivery to dovecot and other agents. This can be configured in postfix main.conf as

virtual_transport  =  lmtp:unix:private/dovecot-lmtp or mailbox_transport  =  lmtp:unix:private/dovecot-lmtp

 From the postfix howto guide

mailbox_transport_maps (default: empty)

     Optional lookup tables with per-recipient message delivery transports to use for local(8) mailbox delivery, whether or not the recipients are found in the UNIX passwd database.

     The precedence of local(8) delivery features from high to low is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, mailbox_command_maps,
     mailbox_command, home_mailbox, mail_spool_directory, fallback_transport_maps, fallback_transport and luser_relay.

https://www.postfix.org/local.8.html

https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/

[toc] | [prev] | [next] | [standalone]


#269372

FromRichard <rrosner5@gmail.com>
Date2024-05-15 12:30 +0200
Message-ID<IEk3v-duZo-3@gated-at.bofh.it>
In reply to#269366

[Multipart message — attachments visible in raw view] — view raw

Interesting. That's not even configured in our main.cfg. We have these
concerning dovecot:
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER

But that's still not that helpful for the main issue. Why on earth is
postfix throwing issues about the log files, even when they are
world-readable and -writable? It's not that dovecot doesn't log to them,
but it's also not the case that it's an error message that can just be
ignored, as it brings mail delivery to a halt.

Am Mi., 15. Mai 2024 um 05:00 Uhr schrieb jeremy ardley <
jeremy.ardley@gmail.com>:


> This can be configured in postfix main.conf as
>
> virtual_transport  =  lmtp:unix:private/dovecot-lmtp or mailbox_transport
> =  lmtp:unix:private/dovecot-lmtp
>
>  From the postfix howto guide
>
> mailbox_transport_maps (default: empty)
>
>      Optional lookup tables with per-recipient message delivery transports
> to use for local(8) mailbox delivery, whether or not the recipients are
> found in the UNIX passwd database.
>
>      The precedence of local(8) delivery features from high to low is:
> aliases, .forward files, mailbox_transport_maps, mailbox_transport,
> mailbox_command_maps,
>      mailbox_command, home_mailbox, mail_spool_directory,
> fallback_transport_maps, fallback_transport and luser_relay.
>
> https://www.postfix.org/local.8.html
>
> https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/
>
>

[toc] | [prev] | [next] | [standalone]


#269373

Fromjeremy ardley <jeremy.ardley@gmail.com>
Date2024-05-15 12:40 +0200
Message-ID<IEkdb-dv2z-9@gated-at.bofh.it>
In reply to#269372
On 15/5/24 18:23, Richard wrote:
> Interesting. That's not even configured in our main.cfg. We have these 
> concerning dovecot:
> smtpd_sasl_type = dovecot
> mailbox_command = /usr/lib/dovecot/deliver -d $USER

The sasl line is not relevant

The mailbox_command is unusual. It means whatever process actually 
execute the mailbox_command runs as (some) postfix user to run the 
deliver application. This may well cause permission issues.

The usual case is dovecot listens for commands on a unix socket or maybe 
an IP socket. In any case it has an entirely separate user ID from postfix.

You may want to look at using the mailbox_transport option instead of 
the mailbox_command option

mailbox_transport  =  lmtp:unix:private/dovecot-lmtp

[toc] | [prev] | [next] | [standalone]


#269374

FromRichard <rrosner5@gmail.com>
Date2024-05-15 13:00 +0200
Message-ID<IEkwy-dv9n-7@gated-at.bofh.it>
In reply to#269373

[Multipart message — attachments visible in raw view] — view raw

mailbox_transport isn't defined anywhere.


Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley <
jeremy.ardley@gmail.com>:

>
> On 15/5/24 18:23, Richard wrote:
> > Interesting. That's not even configured in our main.cfg. We have these
> > concerning dovecot:
> > smtpd_sasl_type = dovecot
> > mailbox_command = /usr/lib/dovecot/deliver -d $USER
>
> The sasl line is not relevant
>
> The mailbox_command is unusual. It means whatever process actually
> execute the mailbox_command runs as (some) postfix user to run the
> deliver application. This may well cause permission issues.
>
> The usual case is dovecot listens for commands on a unix socket or maybe
> an IP socket. In any case it has an entirely separate user ID from postfix.
>
> You may want to look at using the mailbox_transport option instead of
> the mailbox_command option
>
> mailbox_transport  =  lmtp:unix:private/dovecot-lmtp
>
>

[toc] | [prev] | [next] | [standalone]


#269375

Fromjeremy ardley <jeremy.ardley@gmail.com>
Date2024-05-15 13:00 +0200
Message-ID<IEkwy-dv9n-9@gated-at.bofh.it>
In reply to#269374
On 15/5/24 18:52, Richard wrote:
> mailbox_transport isn't defined anywhere.
>
>
> Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley 
> <jeremy.ardley@gmail.com>:
>
>
>     On 15/5/24 18:23, Richard wrote:
>     > Interesting. That's not even configured in our main.cfg. We have
>     these
>     > concerning dovecot:
>     > smtpd_sasl_type = dovecot
>     > mailbox_command = /usr/lib/dovecot/deliver -d $USER
>
>     The sasl line is not relevant
>
>     The mailbox_command is unusual. It means whatever process actually
>     execute the mailbox_command runs as (some) postfix user to run the
>     deliver application. This may well cause permission issues.
>
>     The usual case is dovecot listens for commands on a unix socket or
>     maybe
>     an IP socket. In any case it has an entirely separate user ID from
>     postfix.
>
>     You may want to look at using the mailbox_transport option instead of
>     the mailbox_command option
>
>     mailbox_transport =  lmtp:unix:private/dovecot-lmtp
>

Then you may want to look at the manuals and find out how to add a 
mailbox_transport entry and comment out the mailbox_command entry.

There are many other options of course, but mailbox_transport is a very 
common configuration and usually avoids most permission issues.

[toc] | [prev] | [next] | [standalone]


#269377

FromHenning Follmann <hfollmann@itcfollmann.com>
Date2024-05-15 14:00 +0200
Message-ID<IElsB-dvI1-3@gated-at.bofh.it>
In reply to#269372
On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote:
>
[...]
 
> But that's still not that helpful for the main issue. Why on earth is
> postfix throwing issues about the log files, even when they are
> world-readable and -writable? It's not that dovecot doesn't log to them,
> but it's also not the case that it's an error message that can just be
> ignored, as it brings mail delivery to a halt.
> 

Maybe because you write directly to the logfile. One process trying to write
t it while a different already holds a lock to it.

-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]


#269395

FromRichard <rrosner5@gmail.com>
Date2024-05-16 13:10 +0200
Message-ID<IEH9L-dIVt-3@gated-at.bofh.it>
In reply to#269377

[Multipart message — attachments visible in raw view] — view raw

But why is postfix even holding a lock on it? And how do I prevent that? I
never asked it to.
At least, I don't think there should be a different process holding a lock
on it.

Am Mi., 15. Mai 2024 um 18:45 Uhr schrieb Henning Follmann <
hfollmann@itcfollmann.com>:

> On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote:
> >
> [...]
>
> > But that's still not that helpful for the main issue. Why on earth is
> > postfix throwing issues about the log files, even when they are
> > world-readable and -writable? It's not that dovecot doesn't log to them,
> > but it's also not the case that it's an error message that can just be
> > ignored, as it brings mail delivery to a halt.
> >
>
> Maybe because you write directly to the logfile. One process trying to
> write
> t it while a different already holds a lock to it.
>
> -H
>
> --
> Henning Follmann           | hfollmann@itcfollmann.com
>
>

[toc] | [prev] | [next] | [standalone]


#269397

FromHenning Follmann <hfollmann@itcfollmann.com>
Date2024-05-16 14:40 +0200
Message-ID<IEIyR-dJCE-1@gated-at.bofh.it>
In reply to#269395
On Thu, May 16, 2024 at 01:00:19PM +0200, Richard wrote:
> But why is postfix even holding a lock on it? And how do I prevent that? I
> never asked it to.
> At least, I don't think there should be a different process holding a lock
> on it.
> 

I told you where to look, which is more than you deserve after how you
behave. 
Configure the literal industry standard syslog or journald to use a
facility to your liking and the problem should resolve itself.

-H 


-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]


#269419

FromRichard <rrosner5@gmail.com>
Date2024-05-17 10:20 +0200
Message-ID<IF0YN-dUZV-1@gated-at.bofh.it>
In reply to#269397

[Multipart message — attachments visible in raw view] — view raw

So now that you don't know any further, you just start lying? Now that's
rich.

> I told you where to look, which is more than you deserve after how you
behave.

You didn't though.

> Configure the literal industry standard syslog or journald to use a facility
to your liking and the problem should resolve itself.
The point is, Dovecot has an option to write certain types of logs to
different files. While it's doing that great, postfix is upset about that
capability. It shouldn't even try to access these files. So the issue is
not being able to log to files, that's already solved, but postfix running
crazy when using a very simple setting.

Am Do., 16. Mai 2024 um 18:55 Uhr schrieb Henning Follmann <
hfollmann@itcfollmann.com>:

> On Thu, May 16, 2024 at 01:00:19PM +0200, Richard wrote:
> > But why is postfix even holding a lock on it? And how do I prevent that?
> I
> > never asked it to.
> > At least, I don't think there should be a different process holding a
> lock
> > on it.
> >
>
> I told you where to look, which is more than you deserve after how you
> behave.
> Configure the literal industry standard syslog or journald to use a
> facility to your liking and the problem should resolve itself.
>
> -H
>
>
> --
> Henning Follmann           | hfollmann@itcfollmann.com
>
>

[toc] | [prev] | [next] | [standalone]


#269424

FromGreg Wooledge <greg@wooledge.org>
Date2024-05-17 14:30 +0200
Message-ID<IF4SJ-dXqC-1@gated-at.bofh.it>
In reply to#269419
On Fri, May 17, 2024 at 08:20:17AM -0400, Henning Follmann wrote:
> No the point is, you are not setting a file path, you are configure dovecot
> to directly write to these files.
> And dovecot is not just one process, there are multiple running as
> different users all trying t write into one file. Race conditions are
> to be expected. Because these options exist does not mean it is  a good
> decision to use them.

This is speculation.  When writing to log files, one normally opens the
file in append mode.  Multiple processes opening a single log file in
append mode, and using atomic write() calls, will not have any locking
or concurrency issues.  It'll just work.

Now, the question is whether Dovecot and Postfix both work this way.  I
don't use those two programs, so I don't know the answer to that.

It has become apparent that nobody on this mailing list has the intimate
technical knowledge of Dovecot and/or Postfix required to assist the OP
with setting up this nonstandard logging configuration.  I would suggest
that the OP should try on a Dovecot or Postfix support list instead.

[toc] | [prev] | [next] | [standalone]


#269425

FromHenning Follmann <hfollmann@itcfollmann.com>
Date2024-05-17 14:30 +0200
Message-ID<IF4SJ-dXqC-3@gated-at.bofh.it>
In reply to#269419
On Fri, May 17, 2024 at 10:12:03AM +0200, Richard wrote:
> So now that you don't know any further, you just start lying? Now that's
> rich.
> 
> > I told you where to look, which is more than you deserve after how you
> behave.
> 
> You didn't though.

Don't call me a liar, you are just too dumb to understand.

> 
> > Configure the literal industry standard syslog or journald to use a facility
> to your liking and the problem should resolve itself.
> The point is, Dovecot has an option to write certain types of logs to
> different files. While it's doing that great, postfix is upset about that
> capability. It shouldn't even try to access these files. So the issue is
> not being able to log to files, that's already solved, but postfix running
> crazy when using a very simple setting.
>

No the point is, you are not setting a file path, you are configure dovecot
to directly write to these files.
And dovecot is not just one process, there are multiple running as
different users all trying t write into one file. Race conditions are
to be expected. Because these options exist does not mean it is  a good
decision to use them.
And because you clearly don't understand what you are doing, do as being told.
Configure syslog or rsyslog to use that file path.


-H


-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]


#269447

FromRichard <rrosner5@gmail.com>
Date2024-05-18 15:20 +0200
Message-ID<IFs8F-ecaR-1@gated-at.bofh.it>
In reply to#269425

[Multipart message — attachments visible in raw view] — view raw

>
> Don't call me a liar, you are just too dumb to understand.

It's sad to see that you need to make it this blatantly obvious that even I
clearly understand more than you do. And you're the one trying to scold me
about sticking to the mailing list rules when you so obviously don't care
for them yourself.

No the point is, you are not setting a file path, you are configure dovecot
> to directly write to these files.


I'm configuring dovecot the way it wants to be configured if you want to
deviate from default settings. What doesn't want to get to your brain is
that dovecot isn't the issue. Without postfix interfering everything would
be fine. It's postfix causing issues, not dovecot. Very simple logic would
have told you that, but you are way too focused on hatred and on knowing
everything better without actually doing so. I'm sorry but if you don't
have any clue of what you are talking about, just don't reply. Also you may
want to refrain from further replies - or attacks in your case - before you
write something you can't take back.

[toc] | [prev] | [next] | [standalone]


#269336

FromRichard <rrosner5@gmail.com>
Date2024-05-14 14:20 +0200
Message-ID<IDZip-dhQd-1@gated-at.bofh.it>
In reply to#269329

[Multipart message — attachments visible in raw view] — view raw

>
> ps -eo pid,user,group,comm | grep postfix
> 2886706 postfix  postfix  pickup
> 2886707 postfix  postfix  qmgr
> 2886764 postfix  postfix  tlsmgr

Also as far as I know, postfix logs to syslog too. At least there is no
dedicated file or folder for it in /var/log.

Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem, which just opens a whole other bunch of questions. So in
case that for some odd reason AppArmor logs aren't logged to syslog (and
also it doesn't have a dedicated file), these are the rules for dovecot and
postfix I could find:
postfix has an apparmor (in abstractions) file that doesn't say anything
about /var/log. It only has these rules for things in /var:

/var/spool/postfix/etc/*        r,
/var/spool/postfix/lib/lib*.so* mr,
/var/spool/postfix/lib/@{multiarch}/lib*.so* mr,

Dovecot has two files. In tunables you can find this:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories
# where dovecot is allowed to store and read mails
#
# The default value is quite broad to avoid breaking existing setups.
# Please change @{DOVECOT_MAILSTORE} to (only) contain the directory
# you use, and remove everything else.

@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/
/var/vmail/ /var/mail/ /var/spool/mail

Which doesn't seem to be relevant for this. No idea how dovecot can put the
mail into /maildirs/username, but since that's working I'm not complaining.
The file in abstractions only contains this:
# used with dovecot/*

  abi <abi/3.0>,

  capability setgid,

  deny capability block_suspend,

  # dovecot's master can send us signals
  signal receive peer=dovecot,

  owner @{run}/dovecot/config rw,

  # Include additions to the abstraction
  include if exists <abstractions/dovecot-common.d>

Am Di., 14. Mai 2024 um 13:45 Uhr schrieb <tomas@tuxteam.de>:

> On Tue, May 14, 2024 at 01:29:17PM +0200, Richard wrote:
> > My guess is that postfix runs as postfix.
>
> That would be my guess too (or perhaps as some special "Debian-+postfix".
>
> > At least processes like local,
> > smtpd, bounce etc run as that user. But beyond that I have no idea how to
> > find that out. At least there's nothing in the postfix.service or
> > postfix@.service
> > about that. So I've changed the files to dovecot:postfix 664, but same
> > error.
>
> You might try
>
>   ps -eo pid,user,group,comm | grep postfix
>
> or similar. Or have a look at Posrfix's log file ownerships.
>
> You might try making the log files in question world writable just
> to see whether the problem disappears or this approach is a blind
> alley (don't forget to revert that: leaving them world-writable
> seems like asking for trouble).
>
> Cheers
> --
> t
>

[toc] | [prev] | [standalone]


Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | linux.debian.user


csiph-web