Best practices to perform version UPGRADE

[Matlu]

Hello, team.

I am looking for a recommendation, regarding the "correct" way to perform a version UPGRADE for my GAIA R80.30 which is "working" on an OPEN SERVER, in the STANDALONE architecture (SMS+SG).
The intention is to take it to the R81.10 version.

These are the data of my operating system:

Product version Check Point Gaia R80.30
OS build 200
OS kernel version 2.6.18-92cpx86_64

Is it better to perform the UPGRADE process, using the CPUSE package?
Or is it better to do a FRESH INSTALL to perform the UPGRADE?

Which of both methods is the most advisable to do it in production?

Thanks for your comments and contributions.

Best regards.

[PhoneBoy]

In this specific case, I recommend using the “advanced upgrade” approach, which includes a fresh install booting from a USB ISO.
This is necessary to leverage the XFS file system, which will improve performance in a standalone configuration.

Of course, with a standalone system, any upgrade involves unavoidable downtime.
A fresh install always takes longer than an in-place upgrade.

[Matlu]

Thank you for your contribution, @PhoneBoy 

Could you comment me, in which cases nowadays, do you use the CPUSE package to do version upgrade?

Because I have seen in many videos and some documentation, that this method is also being "put" in practice a lot.

Thanks for your help.

[PhoneBoy · Accepted solution]

Generally, using CPUSE is fine to do the upgrade.
The only time I don't suggest using CPUSE (personally) is to benefit from changes that cannot be implemented through an in-place upgrade:

• In R80.40, we adopted the XFS filesystem as the default.
• In R81.20, the new installer changes how disks are partitioned https://community.checkpoint.com/t5/General-Topics/Gaia-partition-misalignment/m-p/160677#M26928 

In both cases, a fresh install from USB/ISO is the only way to implement these changes.
Management benefits greatly from these changes.
Gateways also benefit from these changes, albeit to a lesser degreee.

[Matlu]

@PhoneBoy 

Your explanation is clear, but I have a problem "interpreting" a part of your comment.

The part of the comment is this:

"...to benefit from changes that cannot be implemented through an in-place upgrade:"

What do you mean by this?
Could you maybe give me an "example" of what would be these "changes" you are referring to, to give me an idea?

Thanks for your support.

[PhoneBoy]

There are two reasons I am aware of you can’t do an in-place upgrade:

• You’re upgrading the hardware
• You need to change something that about the underlying filesystem and/or disk partitioning (i.e. the two specific examples I provided)

Like I said, you are welcome—and it is supported—to upgrade from R80.30 to a newer release with CPUSE.
You will just not obtain the benefits of the newer filesystem/partitioning unless a clean install of the relevant release is performed as part of the upgrade. 

[Matlu]

The explanation is clearer to me. 

However, I still have a doubt, if I perform the UPGRADE with the FRESH INSTALL mechanism with the USB/ISO, to take it from version R80.30 to R81.10, do I have to "convert" the "policy package" of my FW that are in "Standalone (SMS+SG)" mode to work without problems in the new version, R81.10?  For example, I understand that when you need to work an UPGRADE for an SMS with the FRESH INSTALL, you have to convert the "policy package" in such a way that it is compatible with the new version. Is this correct? 

Greetings.

[PhoneBoy]

If you follow the procedure documented in R81.10 Install and Upgrade Guide, yes, it will convert the policy configuration to the new version.
See: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui... 

[the_rock]

I had done this few times and from my experience, its BEST to use whats called "blink package" for upgrades, if its available. Those are much faster, but be prepared to give it some time, as even if thats uses on mgmt server upgrade, depending on the HDD size and database, it can take some time after reboot of the box.

[Matlu]

Hello, my friend.

This method you just mentioned is totally new to me.
I had not heard of it until now.

Is this method very different from the other method, in which you only work with the CPUSE package?

What I want is to try to minimize the risks of affecting the box I have (Standalone, R80.30), and try to "make" the task more practical.

Do you recommend using the "Blink Package" method, over the method of just using the "CPUSE" package?

Thanks for your comment

[the_rock]

I personally recommend "blink" package, always had success with it, except it may take longer for mgmt server, depending on how large database is. For gateways, always worked fine.

[Tsahi_Etziony]

Blink is a type of package (for fast installation of a version + Jumbo and sometimes private HFs). CPUSE is an installer, which supports "regular" packages as well as Blink packages. 

Blink packages are specific to the machine role, and unfortunately Blink upgrade for Standalone are not available. 

[Matlu]

Hello,

Thank you for your reply.

Does it mean that doing an UPGRADE with the "methodology" of "BLINK UPGRADE" is only possible in a distributed environment (SMS and SG separately)?

This methodology can be done in solutions that "run" on OPEN SERVER? Or can it only be done on Checkpoint Appliances?

Greetings.

[Tsahi_Etziony]

Indeed - only distributed. 

the methodology, just like any CPUSE package, can be used also on open servers, as long as they have a GAiA OS installed. 

[Matlu]

I understand.

In a Standalone environment, it is a criterion of the administrator, to know which methodology to use to make an UPGRADE to his solution, right?

I understand that the methodology would be between choosing to use a CPUSE package to upgrade the equipment, or in any case use the "ADVANCED UPGRADE", is this correct?

In your opinion, do you have any recommendation based on your experience?

Regards.

[Tsahi_Etziony]

My team develops CPUSE and other tools, and I have complete faith in those. As for a recommendation based on experience - this is exactly what we have this community for, so let's see what others answer. 

[PhoneBoy]

Regardless of the deployment, you should have some understanding of what upgrade method to use in your specific circumstances.
In general, either method will work, obviously, but the choice of which tool(s) you use will depend on:

• Source/target versions involved (for example, if upgrading R77.30 to R81.10, this will require a multi-stage upgrade)
• Hardware changes (if you are changing from one appliance to another)
• You need to leverage (or make) low-level changes that can't be implemented through an in-place upgrade (the filesystem/disk partitioning issues I mentioned previously)

I've explained why I recommend using the Advanced Upgrade process for your specific situation.
However, you can do an in-place upgrade, but will miss out on some of the performance benefits by doing that. (The filesystem changes improve performance)