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

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.


>> #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.

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.