Maintaining many collector versions from the All in One for many clients as a MSP

KarlH · ‎10-16-2024

We have Collectors at 6.2, 6.3, 6.5.0, 6.5.1 , 6.6, 6.7, 7.1 , 7.0, 7.1 and 7.2

Supervisor is 7.1.3

I have taken on a new role out of the versions 6.5 collector seems to a problem, as a Engineer I am the one who has to answer collectors going in the red for disk space capacity, cpu usage, and what ever else.

And now I'm told the supervisor image server is broken 7.1.3. How do we get that fixed?

Do I try to upgrade 6.5 ? can I see the upgradable paths somewhere for the above versions how do we get the supervisor image server fixed so it can be used and function correctly for them we need to improve our KPI.

Meanwhile the worst is that these clients repeatedly lose the credentials to LOG IN to the collector, not register, and this forces us to have to re-deploy the collector, what version do I give them that is the least problematice I haven't done that yet either... need some best practice advice and assist. All in one single collectors not cluster, need upgrade paths.

Thank you in advance

Karl Henning, Security Engineer, CISSP

KarlH · ‎10-24-2024

@Prem

So the way the image server can be "broken" is due to network or even more obscure issues

only by placing things in debug

su - admin
phtools --change-log ALL DEBUG
exit

Disable modsecurity

mv /etc/httpd/conf.d/mod_security.conf /tmp/

- Reload http service

# systemctl reload httpd

were we able to successfully upload a zip file, Second I am told we must hit the upload button a second time

what does this do there is not documentation for this gui functionality under

ADMIN -> SETTINGS - IMAGE SERVER

to help know how this feature works or what is supposed to happen I would be grateful for a clear step by step process for using this feature and knowing what is expected to occur during the process.

After getting the first step completed so the .zip file exists as expected in the

/opt/phoenix/CollectorUpgrade/

But the ImageS etup task was not completed:

https://community.fortinet.com/t5/FortiSIEM/Technical-Tip-How-to-upgrade-collectors-from-the-FortiSI...

the doc says to run

psql phoenixdb phoenix -c "SELECT type, progress from ph_task where type = 'ImageSetup';"

the result for me was

type | progress
------------+----------
ImageSetup | 0 What do I need to do to get the ImageSetup task to complete?

(1 row)

/opt/phoenix/CollectorUpgrade/ has a file in it in red--- FSM_Upgrade_All_7.1.3_build0165.zip

Finally does moving away from 7.1.3 to a much more recent version make this process more robust and less buggy, as I am told by support this feature is problematic, but it is a crucial tool for MSSP trying to support many clients with many versions of collector and in keeping with best practices of mantinaing equitable versions of supe4rvisor and collector.

Thank you

thank you in advance

Karl Henning, Security Engineer, CISSP

View solution in original post

KarlH · ‎10-28-2024

My specific problem is getting the thing to even copy to the supervisor. Should I not see the 3 GB file copied in in it's entirety to the /opt/phoenix/CollectorUpgrade they are looking at the logs now in Fortinet Support. But it appears that the network that the transfer is going through perhaps proxy issues is causing problems I have not found any best practices written up for moving a file from one place on up via the GUI to the supervisor.

I have a support ticket for this issue as we desperately need to have the image server feature working and by working I mean we need to be able to success fully upload the .zip file have FortiSIEM process the file and allow for its selection and push to a collector for upgrade. Presently it is indeed "broken".

Karl Henning, Security Engineer, CISSP

Maintaining many collector versions from the All in One for many clients as a MSP

Nominate a Forum Post for Knowledge Article Creation