reversion of access.log commenting out in rootfile

reversion of access.log commenting out in rootfile

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

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=97067db7862450bb40d4e9188627d6b5585bf931

I don't understand the meaning of

"the file was created to be shipped with permissions
so it is needed in the rootfile."

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.

Re: reversion of access.log commenting out in rootfile

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

Hello,

I am going to reply on Arne’s behalf...

> On 9 Aug 2024, at 16:25, Adolf Belka <adolf.belka(a)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=97067db7862450bb40d4e9188627d6b5585bf931
> 
> 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.

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=6f83ae4c959045c866c08cc326f36ff645952ae4

Can you confirm that this works, too?

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

Re: reversion of access.log commenting out in rootfile

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

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(a)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=97067db7862450bb40d4e9188627d6b5585bf931
>>
>> 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=6f83ae4c959045c866c08cc326f36ff645952ae4
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

Re: reversion of access.log commenting out in rootfile

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

Thank you for confirming this.

> On 13 Aug 2024, at 12:04, Adolf Belka <adolf.belka(a)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(a)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=97067db7862450bb40d4e9188627d6b5585bf931
>>> 
>>> 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=6f83ae4c959045c866c08cc326f36ff645952ae4
> 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