On 2025-07-11, Nicolas George wrote:
> hw (HE12025-07-11):
>> (S)FTP is still in use like for cameras, scanners (printers) and phones.
>
> Do you have a few examples of brand and models of cameras and phones
> that use FTP?
Some high-end cameras use it. Phones, not so much.
On Thu Jul 10, 2025 at 5:48 PM BST, hw wrote:
The Debian package doesn't seem to be managed well. It even still
uses an init.d script instead of a service file.
Agreed. The last two versions of it were non-maintainer uploads; the
last of those was 18 months ago; the last actual maintainer upl
hw (HE12025-07-11):
> (S)FTP is still in use like for cameras, scanners (printers) and phones.
Do you have a few examples of brand and models of cameras and phones
that use FTP?
--
Nicolas George
On Jul 11, 2025, hw wrote:
> On Thu, 2025-07-10 at 13:55 -0400, Jeffrey Walton wrote:
> > [...]
> > Nowadays it seems like scp and sftp are the norm, not ftp.
>
> (S)FTP is still in use like for cameras, scanners (printers) and phones.
> For local usages I don't want to do all the hassle the certi
On Thu, 2025-07-10 at 13:55 -0400, Jeffrey Walton wrote:
> On Thu, Jul 10, 2025 at 1:39 PM Charles Curley
> wrote:
> >
> > On Thu, 10 Jul 2025 18:58:03 +0200
> > hw wrote:
> >
> > > When running it on Debian, filezilla shows a password request for
> > > anonymous logins, and the login fails. T
On Thu, 2025-07-10 at 19:09 +0200, john doe wrote:
> On 7/10/25 18:58, hw wrote:
> > On Thu, 2025-07-10 at 16:28 +0100, Jonathan Dowland wrote:
> > > On Thu Jul 10, 2025 at 11:45 AM BST, hw wrote:
> > > >
> > > > Right. Anonymous logins are allowed and I have created a system account
> > > > 'ftp
On Thu, Jul 10, 2025 at 1:39 PM Charles Curley
wrote:
>
> On Thu, 10 Jul 2025 18:58:03 +0200
> hw wrote:
>
> > When running it on Debian, filezilla shows a password request for
> > anonymous logins, and the login fails. This is not what the man page
> > says. The ftp user doesn't have a passwor
On Thu, 10 Jul 2025 18:58:03 +0200
hw wrote:
> When running it on Debian, filezilla shows a password request for
> anonymous logins, and the login fails. This is not what the man page
> says. The ftp user doesn't have a password anyway. Apparently,
> Debians pure-ftpd version doesn't understan
On 7/10/25 18:58, hw wrote:
On Thu, 2025-07-10 at 16:28 +0100, Jonathan Dowland wrote:
On Thu Jul 10, 2025 at 11:45 AM BST, hw wrote:
Right. Anonymous logins are allowed and I have created a system account
'ftp', and it still doesn't work. It keeps asking for a password when
trying to log in
On Thu, 2025-07-10 at 16:28 +0100, Jonathan Dowland wrote:
> On Thu Jul 10, 2025 at 11:45 AM BST, hw wrote:
> >
> > Right. Anonymous logins are allowed and I have created a system account
> > 'ftp', and it still doesn't work. It keeps asking for a password when
> > trying to log in as 'anonymous'
On Thu, 2025-07-10 at 16:46 +0100, Jonathan Dowland wrote:
> On Thu Jul 10, 2025 at 3:25 PM BST, hw wrote:
> > So am I to assume that it's broken on Debian
>
> The problem could be the presence of /etc/pure-ftpd/conf/NoAnonymous,
> which causes the start-up wrapper to pass -E (= --noanonymous) t
On Thu Jul 10, 2025 at 3:25 PM BST, hw wrote:
So am I to assume that it's broken on Debian
The problem could be the presence of /etc/pure-ftpd/conf/NoAnonymous,
which causes the start-up wrapper to pass -E (= --noanonymous) to the
daemon. Try removing that file and restarting the daemon.
I
On Thu Jul 10, 2025 at 11:45 AM BST, hw wrote:
Right. Anonymous logins are allowed and I have created a system account
'ftp', and it still doesn't work. It keeps asking for a password when
trying to log in as 'anonymous' or 'ftp'.
Conventionally, when logging into an anonymous ftp server, as
On Thu, 2025-07-10 at 13:52 +0200, to...@tuxteam.de wrote:
> On Thu, Jul 10, 2025 at 01:41:51PM +0200, hw wrote:
> > On Thu, 2025-07-10 at 12:55 +0200, to...@tuxteam.de wrote:
>
> [...]
>
> > > I'd have a look at /var/log/auth.log, or however this is spelt in
> > > systemd-ese these days.
> >
>
On Thu, Jul 10, 2025 at 01:41:51PM +0200, hw wrote:
> On Thu, 2025-07-10 at 12:55 +0200, to...@tuxteam.de wrote:
[...]
> > I'd have a look at /var/log/auth.log, or however this is spelt in
> > systemd-ese these days.
>
> The log says nothing new:
>
>
> [...] pure-ftpd: pam_unix(pure-ftpd:auth)
On Thu, 2025-07-10 at 12:55 +0200, to...@tuxteam.de wrote:
> On Thu, Jul 10, 2025 at 12:45:22PM +0200, hw wrote:
> >
> > Right. Anonymous logins are allowed and I have created a system account
> > 'ftp', and it still doesn't work. It keeps asking for a password when
> > trying to log in as 'anony
On Thu, Jul 10, 2025 at 12:45:22PM +0200, hw wrote:
>
> Right. Anonymous logins are allowed and I have created a system account
> 'ftp', and it still doesn't work. It keeps asking for a password when
> trying to log in as 'anonymous' or 'ftp'.
>
> I have the same on Fedora, and there it does not
09 at 20:19 -0400, Greg Wooledge wrote:
> > > On Wed, Jul 09, 2025 at 23:08:05 +0200, hw wrote:
> > > > where does pure-ftpd store files when anonymous logs in?
> > > >
> > > > Even its man page is missing in Debian.
> > >
> > > Accord
On Thu, Jul 10, 2025 at 5:49 AM hw wrote:
>
> So I have created the ftp user with a home directory to use for files
> from the anonymous user. But still pure-ftpd is, contrary to the man
> page, asking for a password and the login fails.
>
> Why is this not working?
You probably missed a step so
On Thu Jul 10, 2025 at 7:41 AM BST, hw wrote:
And why is is so difficult and troublesome on Debian?
Possibly because running an anonymous ftpd in 2025 is quite a niche
interest.
Some of the other recent replies look to point in the right direction.
Last time I did this myself, I used vsftpd, a
On Thu, Jul 10, 2025 at 4:49 AM hw wrote:
>
> On Wed, 2025-07-09 at 20:19 -0400, Greg Wooledge wrote:
> > On Wed, Jul 09, 2025 at 23:08:05 +0200, hw wrote:
> > > where does pure-ftpd store files when anonymous logs in?
> > >
> > > Even its man page is
t all on Fedora.
On Thu, 2025-07-10 at 07:42 +0200, hw wrote:
> On Wed, 2025-07-09 at 20:19 -0400, Greg Wooledge wrote:
> > On Wed, Jul 09, 2025 at 23:08:05 +0200, hw wrote:
> > > where does pure-ftpd store files when anonymous logs in?
> > >
> > &g
On Wed, 2025-07-09 at 20:19 -0400, Greg Wooledge wrote:
> On Wed, Jul 09, 2025 at 23:08:05 +0200, hw wrote:
> > where does pure-ftpd store files when anonymous logs in?
> >
> > Even its man page is missing in Debian.
>
> According to packages.debian.org, the package &
On Wed, Jul 09, 2025 at 23:08:05 +0200, hw wrote:
> where does pure-ftpd store files when anonymous logs in?
>
> Even its man page is missing in Debian.
According to packages.debian.org, the package "pure-ftpd" depends on
the package "pure-ftpd-common", and the
Hi,
where does pure-ftpd store files when anonymous logs in?
Even its man page is missing in Debian. Are we supposed to create an
ftp user having a home directory to store such files in, or what's the
Debian way of specifying the directory for the files?
Hi,
Max Nikulin wrote:
> > > A bit off-topic question. In what wiki page you would expect to find
> > > suggestions to inspect ~/.xsession-errors file and journalctl output?
I wrote:
> > I pasted ".xsession-errors" into the "Search:" field at the upper right
> > corner of any Debian wiki page and
On 23/07/2024 19:20, Thomas Schmitt wrote:
A bit off-topic question. In what wiki page you would expect to find
suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki page and clicke
On Tue, Jul 23, 2024 at 14:20:43 +0200, Thomas Schmitt wrote:
> The only helpful match is
>
>
> https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text
>
> "What Does The Log Say?
>...
>If you're doing something with your window manage
Hi,
Max Nikulin wrote:
> A bit off-topic question. In what wiki page you would expect to find
> suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki page and clicked the "Text" butto
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 files
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 sup
hrieb Greg Wooledge :
> 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
> 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
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
>
> 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 y
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
#x27;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
> differ
nd 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, tha
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 deser
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 12:23:
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
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:
> smtpd_
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 a
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
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. I've
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 pr
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 stat
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.
T
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 posti
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 line
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.
https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guid
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 be
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 o
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,
>
> 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
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]: (...)
Regards
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 sc
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 o
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 o
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 ima
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, Ric
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 sam
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
fo
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 wr
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 fi
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 create
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 fi
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:
> > net_connect_unix(/run/dovecot/stats-w
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 to
ation
> to have selective copy of the journal in an alternative directory
Hi.
You know what? I think it is exactly the right answer.
I think the principle for this thing is: journald maintains the current
logs in a best-effort manner, but when it comes to archival, the needs
and manners are t
Max Nikulin writes:
> On 24/02/2024 21:09, Byunghee HWANG wrote:
>>> When I read the question I decided that syslog for auth facility is a
>>> kind of solution.
>> Really i would like to learn more. Can you show a more specific
>> example?
>> Also i'm using Debian (sid).
>
> Install rsyslog and l
On 24/02/2024 21:09, Byunghee HWANG wrote:
When I read the question I decided that syslog for auth facility is a
kind of solution.
Really i would like to learn more. Can you show a more specific example?
Also i'm using Debian (sid).
Install rsyslog and logrotate and read their configuration f
Hellow Max!
Max Nikulin writes:
> On 23/02/2024 17:15, Nicolas George wrote:
>> How do I tell systemd's logging system to keep authentication logs
>> for
>> one year and mail logs for one month?
>
> (...)
>
> P.S.
> When I read the question I decided tha
Dnia 2024-02-23, o godz. 15:05:52
Nicholas Geovanis napisał(a):
> On Fri, Feb 23, 2024, 2:57 PM Dan Ritter wrote:
>
> > Stefan Monnier wrote:
> > > Makes one wonder why they don't use naive append-only "plain
> > > text" logs (tho with appropriate
Dnia 2024-02-23, o godz. 12:34:34
Dan Ritter napisał(a):
> Stefan Monnier wrote:
> > Makes one wonder why they don't use naive append-only "plain text"
> > logs (tho with appropriate delimiters (maybe some kind of CSV) to
> > make searches more reliable
On Fri, Feb 23, 2024, 2:57 PM Dan Ritter wrote:
> Stefan Monnier wrote:
> > Makes one wonder why they don't use naive append-only "plain text" logs
> > (tho with appropriate delimiters (maybe some kind of CSV) to make
> > searches more reliable than with old-
Stefan Monnier wrote:
> Makes one wonder why they don't use naive append-only "plain text" logs
> (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
>
> What are the advantages of journ
thanks.
> Makes one wonder why they don't use naive append-only "plain text"
> logs (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
>
> What are the advantages of journald's represen
On 23/02/2024 17:15, Nicolas George wrote:
How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?
I am realizing that the following is not an answer to the asked
question. The thread is no more than useless arguing anyway.
Some
og/journal/
>
> (I've raised a bug 8 years ago about it
> https://github.com/systemd/systemd/issues/2460 )
Oh, that bug report is quite interesting, thanks.
Makes one wonder why they don't use naive append-only "plain text" logs
(tho with appropriate delimiters (mayb
Dnia 2024-02-23, o godz. 14:23:07
Nicolas George napisał(a):
> Mariusz Gronczewski (12024-02-23):
> > Like, really what kind of person gets angry when they get too much
> > details in instruction?
>
> What kind of person writes pages of angry mail when the details are
> not liked?
>
That wou
Mariusz Gronczewski (12024-02-23):
> Like, really what kind of person gets angry when they get too much
> details in instruction?
What kind of person writes pages of angry mail when the details are not
liked?
--
Nicolas George
Dnia 2024-02-23, o godz. 14:09:45
Nicolas George napisał(a):
> Greg Wooledge (12024-02-23):
> > Have you even *read* this mailing list? Most of the people who ask
> > for help here lack experience that you might consider "baby
> > sysadmin" level, and would greatly appreciate the explanations.
theoretical example of how one misbehaved
> > service could flush out the important logs of well-behaved
> > services.
>
> The selective blindness here is to look only at the bad things. The
> drawbacks mentioned exist, but they are in part there for reasons, in
> order to fix t
Greg Wooledge (12024-02-23):
> Have you even *read* this mailing list? Most of the people who ask
> for help here lack experience that you might consider "baby sysadmin"
> level, and would greatly appreciate the explanations.
It is usually quite easy to tell the difference by the phrasing and
acc
Dnia 2024-02-23, o godz. 13:48:35
Nicolas George napisał(a):
> Mariusz Gronczewski (12024-02-23):
> > So to say it short: It is horrid.
>
> Generic bashing of systemd in favor of a blind cult of the good old
> ways are not what I am looking for either, and the unbalanced tone of
> your reply m
On Fri, Feb 23, 2024 at 02:03:50PM +0100, Nicolas George wrote:
> When somebody spends one line answering the question and then pages
> “offering an alternative” by explaining things a baby sysadmin would
> already know, I deduce they are not much above the level of baby
> sysadmin themselves, and
Greg Wooledge (12024-02-23):
> What was "blind" about his anaylsis? It looked pretty well thought out
> to me. He showed actual examples of how space-inefficient it is, and
> provided a theoretical example of how one misbehaved service could
> flush out the importan
ne of your
> reply makes it look like precisely that.
What was "blind" about his anaylsis? It looked pretty well thought out
to me. He showed actual examples of how space-inefficient it is, and
provided a theoretical example of how one misbehaved service could
flush out the importan
Mariusz Gronczewski (12024-02-23):
> So to say it short: It is horrid.
Generic bashing of systemd in favor of a blind cult of the good old ways
are not what I am looking for either, and the unbalanced tone of your
reply makes it look like precisely that.
--
Nicolas George
e02e7
337M/var/log/journal/
(I've raised a bug 8 years ago about it
https://github.com/systemd/systemd/issues/2460 )
To summarize: the ~61MB of resulting text of logs takes around 337MB
on disk when saved by journald, ~80MB in sqlite (~103MB when I added
index for time and process). Use the
Mariusz Gronczewski (12024-02-23):
> That is not a feature systemd's logging have.
That is what it seems, but I would like second opinions.
> You'd have to make a
> rsyslogd rule to put it in one directory
Thanks, but my question was about systemd's
Dnia 2024-02-23, o godz. 11:15:29
Nicolas George napisał(a):
> Hi.
>
> It might be an obvious question, but I do not manage to find the
> obvious answer:
>
> How do I tell systemd's logging system to keep authentication logs for
> one year and mail logs for one month?
Hi.
It might be an obvious question, but I do not manage to find the obvious
answer:
How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?
Regards,
--
Nicolas George
1 - 100 of 643 matches
Mail list logo
