From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: reversion of access.log commenting out in rootfile Date: Tue, 13 Aug 2024 13:04:51 +0200 Message-ID: <0a558cdd-3241-4ca1-a388-2b6d0024f108@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1978454935523213176==" List-Id: --===============1978454935523213176== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael & Arne, On 13/08/2024 11:57, Michael Tremer wrote: > Hello, >=20 > I am going to reply on Arne=E2=80=99s behalf... >=20 >> On 9 Aug 2024, at 16:25, Adolf Belka 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=3Dipfire-2.x.git;a=3Dcommit;h=3D97067db7862450bb= 40d4e9188627d6b5585bf931 >> >> I don't understand the meaning of >> >> "the file was created to be shipped with permissions >> so it is needed in the rootfile." >=20 > The file is created with other than default ownership than root or maybe ot= her 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=20 removed from the rootfile. >=20 > There is a follow-up commit which should exclude it from being overwritten: >=20 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D6f83ae4c95= 9045c866c08cc326f36ff645952ae4 I hadn't seen that commit. Looking at it, that should solve the issue. >=20 > 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=20 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=20 updated CU187 the day before the access logs would have been rotated so=20 nearly a week would have been lost. I can confirm that the access.log is fully present for the whole week=20 before CU187 was updated so the commit worked perfectly. Regards, Adolf. >=20 >> >> If it has to stay how do we ensure that users don't lose maybe up to a wee= ks 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 som= ething? >> >> Regards, >> >> Adolf. >> >=20 --=20 Sent from my laptop --===============1978454935523213176==--