R80.20.M1 Management Release

[PhoneBoy]

R80.20.M1 Management Release is now available.
To be clear, this is for Management only (including Provider-1/Multi-Domain) and does not support installation as a gateway (with or without management).

I would encourage you to check out the FAQ in the SK, which answers many questions related to this release.
https://supportcenter.checkpoint.com...ionid=sk123473

[Bob_Zimmerman]

Is this one expected to be upgradable to future versions like a normal release? The letters and the longer-than-normal version number make me nervous after R55P, R60A, R65.2.100, and others.

[tomersole']

I'm going to lurk in this thread for questions...
What's New In SmartConsole: https://sc1.checkpoint.com/documents.../WhatsNew.html

Is this one expected to be upgradable to future versions like a normal release? The letters and the longer-than-normal version number make me nervous after R55P, R60A, R65.2.100, and others.

We are introducing a new release strategy. Management-only releases will be safely upgradable between one another. Users can still use the usual "no M suffix" model which includes Management and Gateway. The SK has the differences between the Management Feature Releases and the usual releases. Motivation is: you don't need to wait for a gateway version if the Management is already ready to be in GA for user experience enhancements and new API commands. Also, we already have engines that have faster release cycles - Sandblast Engine Updates and CloudGuard IaaS controller, and with this cycle we are bringing main-train Management supportability for these engines.

[Bob_Zimmerman]

I see now in the New Release Methodology section, "When the next Major release is available (such as R80.20), you can upgrade to it from the Management Feature Release." That is good to know.

So it sounds to me like there will be a rapid-release M branch which is periodically merged back into the GA trunk. In general, M versions can be upgraded to subsequent M versions or to GA versions released after the given M version. Is that accurate?

[PhoneBoy]

So it sounds to me like there will be a rapid-release M branch which is periodically merged back into the GA trunk. In general, M versions can be upgraded to subsequent M versions or to GA versions released after the given M version. Is that accurate?

Correct.

[tomersole']

I see now in the New Release Methodology section, "When the next Major release is available (such as R80.20), you can upgrade to it from the Management Feature Release." That is good to know.

So it sounds to me like there will be a rapid-release M branch which is periodically merged back into the GA trunk. In general, M versions can be upgraded to subsequent M versions or to GA versions released after the given M version. Is that accurate?

Merged Back is not the correct term. We cut the R80.20 branch at a specific point and after good EA score, stabilize it (both in the R80.20 branch and in the M branch) and make it GA after it passes the usual criteria's of QA and good score from the EA program. You will never find a feature that is contained in an "M" release and not in a future Management-And-Gateway release. Actually one of its benefits is to greatly reduce the "customer hotfix" solutions and just deliver everything to everyone.

[jflemingeds]

iotop.. nice. I helped a customer out with a large p1 install. Everyone was complaining about how slow policy installs were but no one noticed %100 iowait. Took a little trouble shooting to figure out what was causing it. iotop would have cleared that up.

[ShadowPeak.com]

iotop.. nice. I helped a customer out with a large p1 install. Everyone was complaining about how slow policy installs were but no one noticed %100 iowait. Took a little trouble shooting to figure out what was causing it. iotop would have cleared that up.

Yep there will be a raft of new native Linux tools available due to the kernel update to 3.5.

[Bob_Zimmerman]

Yep there will be raft of new native Linux tools available due to the kernel update to 3.5.

Hopefully these new tools don't include the tire-fire that is systemd.

[PhoneBoy]

Hopefully these new tools don't include the tire-fire that is systemd.

Nope, we're not using systemd.
We actually use our own process manager (pm).

[Bob_Zimmerman]

Nope, we're not using systemd.
We actually use our own process manager (pm).

Ah! Thus the 'tellpm' commands in the script to manually update the installer agent. Good to know.

[jflemingeds]

Yep there will be a raft of new native Linux tools available due to the kernel update to 3.5.

You sure about that version? :)

[jflemingeds]

Ah! Thus the 'tellpm' commands in the script to manually update the installer agent. Good to know.

technically init is still pid 1.

[jflemingeds]

hmm looks like network namespaces are now supported. I wonder if that means a big vsx update is on the way.

[peter42]

Hopefully these new tools don't include the tire-fire that is systemd.

The original idea of sytemd from svc from Solaris is great, the implementation is in Linux is a shame.

[Bob_Zimmerman]

The original idea of sytemd from svc from Solaris is great, the implementation is in Linux is a shame.

There was no real reason not to use Solaris SMF, BSD launchd, runit, or openrc. All of them predate systemd and all of them have enormously more mindful developers working to a much higher standard of quality.

This is why I specifically commented on systemd. At this point, it is an unacceptable liability on any system which needs to be predictable and available.

[peter42]

There was no real reason not to use Solaris SMF, BSD launchd, runit, or openrc. All of them predate systemd and all of them have enormously more mindful developers working to a much higher standard of quality.

This is why I specifically commented on systemd. At this point, it is an unacceptable liability on any system which needs to be predictable and available.

I fully agree - especially as the maintainer does not accept error reports, if they do not fit in his mindset...

[PhoneBoy]

hmm looks like network namespaces are now supported. I wonder if that means a big vsx update is on the way.

It's safe to say we'll be leveraging new kernel infrastructure for a lot of things in the gateway (including VSX).

[jflemingeds]

yeah i'm poking around and finding interesting things.

TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |
bridge | bond | ipoib | ip6tnl | ipip | sit | vxlan |
gre | gretap | ip6gre | ip6gretap | vti | nlmon |

vxlan support?... hmmmm

[Expert@gw-:0]# modprobe vxlan
[Expert@gw-:0]# lsmod | grep vxlan
vxlan 47359 0
udp_tunnel 12737 1 vxlan
ip6_udp_tunnel 12399 1 vxlan
[Expert@gw-:0]#