Thank you for confirming this.
On 13 Aug 2024, at 12:04, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael & Arne,
On 13/08/2024 11:57, Michael Tremer wrote:
Hello, I am going to reply on Arne’s behalf...
On 9 Aug 2024, at 16:25, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Arne,
I saw that my patch for commenting out the access.log in the rootfile had been reverted.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=97067db7862450bb40d4e918...
I don't understand the meaning of
"the file was created to be shipped with permissions so it is needed in the rootfile."
The file is created with other than default ownership than root or maybe other permissions than 644.
I will need to have a sit-down and think further on understanding this.
However, I believe it when you say that it causes a problem if it is removed from the rootfile.
There is a follow-up commit which should exclude it from being overwritten: https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=6f83ae4c959045c866c0...
I hadn't seen that commit. Looking at it, that should solve the issue.
Can you confirm that this works, too?
I was able to test this.
I looked in my Proxy Logs via the WUI for when I ran the CU186 update and the four days before that date my proxy log was empty.
I then looked in the proxy logs for the days before CU187 was run. I updated CU187 the day before the access logs would have been rotated so nearly a week would have been lost.
I can confirm that the access.log is fully present for the whole week before CU187 was updated so the commit worked perfectly.
Regards, Adolf.
If it has to stay how do we ensure that users don't lose maybe up to a weeks worth of the access.log file if an update is done on the day before access.log would be rotated to access.log.1 .gz
Although this has always been the case, it doesn't seem right to overwrite the existing access.log file if squid is updated or have I misunderstood something?
Regards,
Adolf.
-- Sent from my laptop