Re: thinking journal retention timelimits

2021-04-07 Thread Chris Murphy
Hi, Workstation working group discussed this at a recent meeting, and reached no decision. There's general agreement that a time based limitation should apply rather than disk usage limit, to make the retention more predictable. I think this can work by default for all Fedora editions and spins.

Re: thinking journal retention timelimits

2021-01-23 Thread Michael Catanzaro
On Sat, Jan 23, 2021 at 3:39 pm, Matthew Miller wrote: Sure, it should be easy to change, but that doesn't mean we shouldn't also look at defaults. Again, particularly on desktops where having years of logs probably more of a problem than a benefit. One year sounds like a good default to

Re: thinking journal retention timelimits

2021-01-23 Thread Matthew Miller
On Sat, Jan 23, 2021 at 02:32:15PM -0600, Chris Adams wrote: > Log rotation is something that can have vastly different requirements > for different environments - I don't think it is up to a distribution to > try to determine that and match them. Stick with one more or less sane > default and

Re: thinking journal retention timelimits

2021-01-23 Thread Chris Adams
Once upon a time, Sérgio Basto said: > I use 52 weeks in my machines or even 104 weeks if they are important, > because specially on security issues , we need dig for more than 2 or > 3 months and for statistic like watch disk usage , etc > Like logrotate, I'd like have journal retention for

Re: thinking journal retention timelimits

2021-01-23 Thread Matthew Miller
On Sat, Jan 23, 2021 at 07:02:17PM +, Sérgio Basto wrote: > I use 52 weeks in my machines or even 104 weeks if they are important, > because specially on security issues , we need dig for more than 2 or > 3 months and for statistic like watch disk usage , etc > Like logrotate, I'd like have

Re: thinking journal retention timelimits

2021-01-23 Thread Sérgio Basto
On Fri, 2021-01-01 at 12:15 -0500, Matthew Miller wrote: > As we start a new year, I'm thinking about data retention in general. > :) > > In my experience, it's pretty rare on an end-user laptop or desktop > system for > logs from much more than the previous boot to be interesting. Maybe I >

Re: thinking journal retention timelimits

2021-01-05 Thread Robbie Harwood
Matthew Miller writes: > Logs can accidentally contain sensitive data, and it's just plain > faster to work with them when there's less. I propose we set this to > something like six months by default. If there are non-negligible speed impacts from large logs, this seems like a problem with

Re: thinking journal retention timelimits

2021-01-02 Thread Dan Čermák
Matthew Miller writes: > As we start a new year, I'm thinking about data retention in general. :) > > In my experience, it's pretty rare on an end-user laptop or desktop system for > logs from much more than the previous boot to be interesting. Maybe I > occasionally want to look back a little

Re: thinking journal retention timelimits

2021-01-01 Thread Chris Adams
Once upon a time, Chris Murphy said: > On Fri, Jan 1, 2021 at 4:54 PM Kevin Kofler via devel > wrote: > > I don't think we should be destroying data by default. There should be no > > expiry by default. > > Indirectly they already expire by default. It's just a different > expiration date for

Re: thinking journal retention timelimits

2021-01-01 Thread Chris Murphy
On Fri, Jan 1, 2021 at 4:54 PM Kevin Kofler via devel wrote: > > Matthew Miller wrote: > > Right now, we don't set MaxRetentionSec, so journal expiry on Workstation > > is entirely based on disk usage. > > > > Logs can accidentally contain sensitive data, and it's just plain faster > > to work

Re: thinking journal retention timelimits

2021-01-01 Thread Nico Kadel-Garcia
On Fri, Jan 1, 2021 at 7:02 PM Matthew Miller wrote: > > On Sat, Jan 02, 2021 at 12:53:52AM +0100, Kevin Kofler via devel wrote: > > > Logs can accidentally contain sensitive data, and it's just plain faster > > > to work with them when there's less. I propose we set this to something > > > like

Re: thinking journal retention timelimits

2021-01-01 Thread Matthew Miller
On Sat, Jan 02, 2021 at 12:53:52AM +0100, Kevin Kofler via devel wrote: > > Logs can accidentally contain sensitive data, and it's just plain faster > > to work with them when there's less. I propose we set this to something > > like six months by default. > > I don't think we should be

Re: thinking journal retention timelimits

2021-01-01 Thread Kevin Kofler via devel
Matthew Miller wrote: > Right now, we don't set MaxRetentionSec, so journal expiry on Workstation > is entirely based on disk usage. > > Logs can accidentally contain sensitive data, and it's just plain faster > to work with them when there's less. I propose we set this to something > like six

thinking journal retention timelimits

2021-01-01 Thread Matthew Miller
As we start a new year, I'm thinking about data retention in general. :) In my experience, it's pretty rare on an end-user laptop or desktop system for logs from much more than the previous boot to be interesting. Maybe I occasionally want to look back a little while to see if a problem just