Re: [logwatch:git] Merge request: rhel 8 patches, 7.5.x branch (7.5.1)

> -----Original Message-----
> From: Bjorn via Logwatch-devel
> Sent: Sunday, January 13, 2019 4:58 PM
> 
> My additional comments are interspersed:
> 
> 
> On 1/13/19 12:47 PM, Jason Pyeron wrote:
> 
> >> #217226
> >> 	logwatch-vsftpd.patch
> >> 	Not sure if this is still applicable, and fix was applied
> >> 	incorrectly.  Each script has its own configuration file,
> >> 	and that's were the change, if needed, should occur.  The
> >> 	vsftpd configuration does call the applystddate script.
> >
> >
> > I will take a stab at making 217226 better (more aligned to the logwatch
> > way) and opening a new ticket on Bugzilla.redhat.com.
> 
> If it needs changing, let us know in what way it is broken.  The patch
> applied an apparently old copy of the applystddate script by patching
> the logwatch.pl executable, which is the wrong way and place to do that.
>  The command to execute applystddate should go in the appropriate
> configuration file, and it appears to be already there.
> 
> The logs produced by vsftpd appear to be analyzed correctly on my
> system, so not clear what the issue was to begin with.

I'll see if there are logs files that can be processed by RH's but not
master. Either way, I will look to minimizing this patch.

> 
> 
> >> #230974
> >> 	logwatch-oldfiles.patch
> >> 	Seems to me that the warning message was not interpreted
> >> 	correctly.  The proper solution was to delete the
> >> 	directories mentioned.
> >>
> >
> > With regards to bug 230974, the tmpdir is cleared on reboot for some
> > systems. This option makes sense for those platforms.
> 
> That may be the case, but I am arguing that the "fix" is unnecessary.
> It is not clear that the submitter ever attempted to remove the
> temporary logwatch files, which is what the warning suggested.  The
> submitter posited that it was a race between logwatch and tmpwatch,
> which is very unlikely, unless an unreasonable parameter for tmpwatch's
> time was used.  But I don't think that was the issue either, because the
> warning was from logwatch indicating it found previous instances of
> logwatch, and not a warning from tmpwatch.

The solution is more general than the initial bug. I can say with absolute
certainty that this option is being used in the wild, and may be worthwhile
from that point alone.

Also, I am a big fan of not making noise when noise is not needed.

> 
> In summary, if you want to preserve the old temporary logwatch files,
> they can be moved to another directory, renamed, or you ignore the
> warning.  [It only looks for directories of the format
> ^logwatch\.\w{8}$.]  The only reason I can think for keeping these
> temporary directories is if you are actively debugging logwatch.
> 
> I will also note that the submitter had changed the location of the
> temporary logwatch directory to /tmp, which may be why it clears upon
> reboot.  And why the submitter thought it was interacting with tmpwatch.