Gaia portal 404 after expanding logs volume

[yukaia]

I'm running into a strange issue on a standalone gateway in my lab, whenever I try to expand the logs volume on the device the Gaia web portal as well as web smartconsole both start intermittently throwing 404's. This problem happens to me on both R82 and R82.10 installs, this is all on a Quantum 7000 appliance. Has anyone else encountered this problem?

[the_rock]

Are you using custom port or default 443?

[yukaia]

I'm using the default 443. httpd is up and listening on that port, what's odd is smartview loads perfectly fine, and occasionally the Gaia portal will load for a few times before going back to a 404.

[Lesley]

Do I understand correctly you want to increase disk space size for the LOG dir?

This should be done via lvm_manager in maintenance mode. 

https://support.checkpoint.com/results/sk/sk95566

[the_rock]

Yep, definitely needs console for that too.

[yukaia]

Yeah, I already went through the maint mode/lvm_manager process to expand the vg_splat-lv_log volume. When I do that the Gaia platform portal and web smartconsole return a 404 not found error. If I change the platform portal to an alternative port like 4434, then Gaia and web smartconsole both work.

Edit: as a note, the volume expansion works flawlessly, I managed to expand the volume from 200gb to 1TB of space.

[the_rock]

Here is example from my lab, what does line apache gaia port show? Also what does fw stat show?

[Expert@CP-MANAGEMENT:0]# api status

API Settings:
---------------------
Accessibility: Require all granted
Automatic Start: Enabled

Processes:

Name State PID More Information
-------------------------------------------------
API Started 10298
CPM Started 10298 Check Point Security Management Server is running and ready
FWM Started 9823
APACHE Started 8496

Port Details:
-------------------
JETTY Internal Port: 61964
JETTY Documentation Internal Port: 59128
APACHE Gaia Port: 443

Profile:
-------------------
Machine profile: Large SMC env resources profile without SME
CPM heap size: 16384m

Apache port retrieved from: dbget http:ssl_port

--------------------------------------------
Overall API Status: Started
--------------------------------------------

API readiness test SUCCESSFUL. The server is up and ready to receive connections

Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'

[Expert@CP-MANAGEMENT:0]#

[yukaia]

This is the output of my api status command, and this is a standalone gateway configuration, so no dedicated management/logging server.

[Expert@pap-7000:0]# api status

API Settings:
---------------------
Accessibility:                      Require local
Automatic Start:                    Enabled

Processes:

Name      State     PID       More Information
-------------------------------------------------
API       Started   46945
CPM       Started   46945     Check Point Security Management Server is running and ready
FWM       Started   46213
APACHE    Started   208359

Port Details:
-------------------
JETTY Internal Port:               58614
JETTY Documentation Internal Port: 63114
APACHE Gaia Port:                  443

Profile:
-------------------
Machine profile:                   Large SMC env resources profile without SME
CPM heap size:                     2304m

                          Apache port retrieved from: dbget http:ssl_port


--------------------------------------------
Overall API Status: Started
--------------------------------------------

API readiness test SUCCESSFUL. The server is up and ready to receive connections

Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'

[the_rock]

That looks right. What about fw stat?

[yukaia]

Here's fw stat, I've also attached some images of what I'm actually seeing.

[Expert@pap-7000:0]# fw stat
HOST      POLICY           DATE
localhost Standard          6Nov2025 13:43:07 :  [>eth1-01] [<eth1-01] [>eth1-04] [<eth1-04]

[Lesley]

https://support.checkpoint.com/results/sk/sk91380

[yukaia]

Yeah, I looked through that before posting and couldn't really figure it out. I did just barely come across https://support.checkpoint.com/results/sk/sk180829 which is somewhat similar, but not quite. I haven't been able to try copying a clean template file from a known good install over, but I did run the "tellpm process:httpd2 ; tellpm process:httpd2 t" command and it brought gaia and web smartconsole back up for a few minutes before it finally goes back to giving me a 404 error.

Edit: what still confuses me is changing the platform portal to a nonstandard port fixes the issue entirely.

[the_rock]

Does reboot help if you tried it?

[yukaia]

It does not

[the_rock]

I recommend TAC case then.

[yukaia]

Yeah, I was thinking that, but it's an R82.10 install in my lab so I'd have to level it and drop R82, duplicate the issue and then open the case.

[the_rock]

Understood.

[kamilazat]

We have encountered weird issues with Gaia Portal with a customer and we were able to resolve it using the logic on sk127792. 

What we did was basically killing the httpd2 process manually with the command tellpm process:httpd2, and then restarting it in the foreground. 

/opt/CPshrd-R81.20/web/Apache/2.2.0/bin/httpd2 -k start -f /web/conf/httpd2

This told us where to look and what to look for. Sometimes low level changes during updates or volume operations mess with specific files. 

I also attached a httpd-ssl.conf.templ file (with an added .txt extension to be able to attach here, you'll need to remove that before importing) from a freshly installed R81.20 gateway. We also initially thought sk180829 was the most similar, but after it didn't help (there were no differences between the existing and the original files anyway in our case), we managed to resolve it with sk127792. 

Let us know how it goes.

Cheers!

[the_rock]

I recall customer using that sk to solve the issue once, but error was exactly the same. Not sure here thats the case, but definitely worth trying.

[kamilazat]

The symptoms weren't the same for us either. But starting httpd2 in the foreground gave us useful information as to where to dig further. So I hope it will provide some insights.

@yukaia Please do share when you have more insights 🙂

[the_rock]

Super valid point @kamilazat 

I truly hope it helps!

[yukaia]

Thanks a bunch for pointing me in this direction, when I get some time (this is my personal lab, not $DAYJOB) I'll go ahead and try this.