Portal logfiles not rotated

[Christian_Riede]

According to sk102527, in versions R75, R76, R76SP, R76SP.10, R76SP.10_VSLS, R76SP.20, R76SP.30, R76SP.40, R77, R77.10, R77.20, R77.30 the portal http server logs are not rotated. This sk originally is from 2014.

Well, we have 2019 (Yes, that's 5 years!) and R80.10 T142 here and this is still not solved. Fixing that is a totally low hangig fruit. Not fixing is means manual effort to find and fix that in all checkpoint installations worldwide. Proactive is different..

Checkpoint does not seem to be able to solve their quality problems finally.

[G_W_Albrecht]

According to sk102527, you can manually configure the Identity Awareness Gateway to rotate the Identity Awareness Captive Portal log files - and this is only needed when using IA Captive Portal.

I understand that manual changes are a pita and CP could have changed that already, but if all was perfect and no bugs anywhere, i fear i would not be able to make any money  !

[Christian_Riede]

Thanks, Adam, for taking this on your list for R80.30 GA.

[Christian_Riede]

According to sk113619, /opt/CPNacPortal/logs/error_log_autoauth is also missing in the list of files that are not rotated and need to be added to logrotate.conf. This file would need to be added to sk102527.

[PhoneBoy]

Make sure you leave feedback on the relevant SK so it gets addressed.

[Christian_Riede]

of course, already done some days ago.

[Patrik_Rapposch]

R80.30 T219 problem is still existent. 😒

If you see it too late, with this SK102527 and the usage of logrotate -f after the logrotate.conf update, you'd even force the system to write the disk 100% full ! happened at our site today!

the solution is then to throw away the existing log and then test with logrotate -f, if the config from SK102527 realy works.

[Expert@gatekeeper1-n1:0]# /usr/sbin/logrotate -f /etc/logrotate.conf
error: error writing to /opt/CPNacPortal/logs/access_log.1: No space left on device
error: error writing to /opt/CPNacPortal/logs/error_log.1: No such file or directory

deleting the existing log information helps out.

echo "0" /opt/CPNacPortal/logs/error_log
echo "0" /opt/CPNacPortal/logs/access_log


Check Point, really? Can't solve this simple issue in that huge amount of time and risking customers to fail with your product? 👌

[Royi_Priov]

Hi @Patrik_Rapposch ,

Thanks for bringing this issue into my attention.

I agree that we (Check Point) should be proactive here and avoid such issue in the first place, although there is a solution in sk102527.

I have added this issue into our roadmap plan and hopefully we will find a better way for this matter.

[Patrik_Rapposch]

Hi @Royi_Priov ,

great, thank you for responding and bringing this topic to your roadmap. Please note, that step 7 in SK102527 solution even could force the disk to become full, if you recognize it earlier then 100% disk usage, like we did.

If the disk is full, you anyway wouldn't be able to rotate logs, as the compressed logfile can't be written to a 100% full disk. In general I would recommend to move those logs to /var/log, which I expect is the real origin of this problem.

Thanks 

[Patrik_Rapposch]

6 months later, R80.30 Take 236, still not fixed.

[Licensing_Manag]

Well its October 2021 & R80.40 and its still not fixed - let me guess Check Point says we need to upgrade to R81

[JanVC]

2022 and still not fixed

in our instance, TAC admitted the sk102527 is even wrong

"After investigating this issue we saw that the problem is that the GW doesn't run the cronjob daily.
The fix for that is to manually create a cronjob to run this script using Gaia portal.

We will update the SK accordingly."

@Royi_Priov 

[_Val_]

@JanVC Please send me the TAC SR number via private message, please.