On 19 May 2024 11:11 -0400, from monn...@iro.umontreal.ca (Stefan Monnier):
>> If you have read permission on a directory but *not* execute permissions,
>> then the only thing you can do is read the contents of that directory --
>> the filenames and their inode numbers. You cannot stat() the
On Sun, May 19, 2024 at 05:15:40PM +0200, Richard wrote:
> Then where does the combination rwx come in here? With read the app knows
> the file is there, with write it writes to the file. Question is, where the
> necessity would be to know the owner of the file or even the kind. The
> logger is
Then where does the combination rwx come in here? With read the app knows
the file is there, with write it writes to the file. Question is, where the
necessity would be to know the owner of the file or even the kind. The
logger is supposed to just append text to a file. If it were trying to
append
> If you have read permission on a directory but *not* execute permissions,
> then the only thing you can do is read the contents of that directory --
> the filenames and their inode numbers. You cannot stat() the files,
> so you can't see who owns them or even what kind of files they are.
> Just
On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> Dovecot expects execution permissions on the directory it writes the logs
> to. Because "Standard POSIX permissions for a non-root process to enter a
> directory." How on earth is that even a thing?
That's how Unix permissions have always
So, I've just written to the Dovecot mailing list, the reality why Dovecot
is complaining is so much worse than anything I could have imagined. While
everything indicates Dovecot is able to write to the log files, it seems
Dovecot expects execution permissions on the directory it writes the logs
>
> 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
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
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
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
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
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 <
hfollm...@itcfollmann.com>:
> On Wed, May 15, 2024 at
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
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
:
On 15/5/24 18:23, Richard wrote:
> Interesting. That's not even configured in our main.cfg. We have
these
> concerning dovecot:
>
mailbox_transport isn't defined anywhere.
Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley <
jeremy.ard...@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
> >
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
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
On 14/5/24 20:17, to...@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.
Says the one refusing to stay on topic. What a sad hypocrite.
On Tue, May 14, 2024, 20:10 Henning Follmann
wrote:
> On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
> > "Top posting" (writing the answer above the text that's being replied to)
> > is literally industry standard behavior.
How exactly do I do that?
Am Di., 14. Mai 2024 um 18:40 Uhr schrieb jeremy ardley <
jeremy.ard...@gmail.com>:
>
> From what I can find out, the postfix local delivery agent is not
> chroot and it communicates with the main postfix processes via shared
> directories and pipes.
>
> To debug the
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
On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
>"Top posting" (writing the answer above the text that's being replied
>to) is literally industry standard behavior.
Many do top post, but many do not.
Places where it is often frowned on are technical mail lists such as this one.
On Tue, May 14, 2024 at 04:08:19PM +0200, Richard wrote:
> Just because something isn't an official ISO standard doesn't mean it's not
> standard behavior. And how it relates to this mailing list? It's called a
> setting.
Most people prefer inline quoting around here (I know I do). That's
because
Just because something isn't an official ISO standard doesn't mean it's not
standard behavior. And how it relates to this mailing list? It's called a
setting.
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett <
loris.benn...@fu-berlin.de>:
> Hi Richard,
>
> Richard writes:
>
> > "Top
Hi Richard,
Richard writes:
> "Top posting" (writing the answer above the text that's being replied
> to) is literally industry standard behavior.
Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this newsgroup?
[snip (51
On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
> "Top posting" (writing the answer above the text that's being replied to)
> is literally industry standard behavior.
>
Whatever.
It is not standard behavior in mailing lists.
And you think you're important enough to change that setting for a whole
mailing account? You're funny.
Am Di., 14. Mai 2024 um 15:16 Uhr schrieb Brad Rogers :
> On Tue, 14 May 2024 15:11:16 +0200
> Richard wrote:
>
> Hello Richard,
>
> >"Top posting" (writing the answer above the text that's
On Tue, 14 May 2024 15:11:16 +0200
Richard wrote:
Hello Richard,
>"Top posting" (writing the answer above the text that's being replied
>to) is literally industry standard behavior.
This 'literally' isn't industry.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/
"Top posting" (writing the answer above the text that's being replied to)
is literally industry standard behavior.
Also, I don't think you've really cleared out any confusion. Now, how
exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing
errors? Because it clearly is for 2 out
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
>
> 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
Le 14/05/2024, to...@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]: (...)
For us the situation is even a bit stranger. The inboxes are located in
neither location, but in /maildirs/username/ (no idea why it was set up
that way, but it's a dedicated mail server where the user's don't have
their own home directory). /var/mail is empty.
Am Di., 14. Mai 2024 um 13:45 Uhr
On 14/5/24 19:44, Greg Wooledge wrote:
On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
Postfix is chrooted (usuallly) to /var/spool/postfix
If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail
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
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
On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
> Postfix is chrooted (usuallly) to /var/spool/postfix
If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.
I could
On 14/5/24 19:17, Richard wrote:
But why should it cause issues? I set the logging in dovecot's conf.d,
so I'd expect dovecot to write these logs, not postfix as it has its
own settings.
Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley
:
On 14/5/24 04:16, Richard wrote:
>
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
AppArmor complaints would be shown in journalctl too. But dmseg doesn't
show anything either. Just switched dovecot back to these log files, waited
for the error message, yet dmesg doesn't have anything new since yesterday.
Systemd was also my guess as it was originally set to ProtectSystem=full
But why should it cause issues? I set the logging in dovecot's conf.d, so
I'd expect dovecot to write these logs, not postfix as it has its own
settings.
Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley <
jeremy.ard...@gmail.com>:
>
> On 14/5/24 04:16, Richard wrote:
> > Maybe someone
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
On 14/5/24 04:16, 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
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
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=,
> > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred
> > (temporary failure. Command output: lda(user): Error:
> >
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
46 matches
Mail list logo
