RFE: Install policy directly after currently running installation finishes

[Christian_Riede]

Hello,

currently, when a policy installation is running, no parallel second installation is possible.  While I of couse with that parallel installations would be possible, I do understand that there are technical limitation to do that. But: Currently, I as an administrator must activly wait for the running installation to finish until I can start my own installation. This is wasting my time.

Can you please implement an installation queue feature? I want to have my installation started automatically after the running installation finishes.

Thanks,

Christian Riede

[Daniel_Taney]

Policy Install Queues would be a fantastic feature!

[JozkoMrkvicka]

Option 1 (MDS R80.20):

Install Policy Presets

Option 2 (R77.30):

Pushing the Security Policy to Security Gateways

In order to perform installation of 3 different gateways, simply run the command:

fwm load <policy_package1> <gateway1>;fwm load <policy_package2> <gateway2>;fwm load <policy_package3> <gateway3>

 Note: In case of MDS R77.30, all 3 gateways must be part of the same CMA (mdsenv <cma_name>).

[PhoneBoy]

I could see this being a use case for the upcoming SmartTask.
After a policy installation, check some sort of external "queue" for pending policy pushes.
Then start the next one, rinse and repeat.

[Christian_Riede]

Let me clarify my use case:

A Smartcenter manages a large number of firewalls. Several admins work in parallel on the same R80.X smartcenter and implement changes.  At some point of time, one of the admins publishes his changes and installs a policy. A policy install runs for 5 min in our case.  When within these 5min the other admins of course can publish their changes, but they cannot install them as an installation is already running. So they have to actively wait until the running installation finishes (worst case 5min) and then click on install (and hope that not a different admin was again faster).

What is needed here is a feature to ask for an automatic install at earliest possible point of time. A queue where subsequent  install requestes are enqueued for completion.

This needs to be an integral feature of the SmartCenter/SmartConsole.

Not a solution:

• Provider 1
  • The firewalls share policy layers and must be within one CMA
• External scripts to run installations.
  • Why shoud I use external functional to for such a basic function? At the end, SmartConsole is the tool to make policy changes and install them. You dont need to know command line tools to install policy.
• SmartTask as presented in https://www.youtube.com/watch?v=steOVo6T2iY
  • At the time the first installation starts, it is unknown that a second installation is needed.

Thanks

Christian Riede

[Maik]

I understand the fact that you do not want to run "external" scripts for this case, but the mgmt_cli wouldn't be something like that. Sure you could call it a "script" but basically it would consist out of just a few commands. So for example, the "mgmt_cli install policy" command can be used to install the policy. This could be combined with either a timer, to e.g install the policy every hour during working ours or you write a small functionality that checks the last published sessions (show sessions). If a new publish is found the install command can be run again and so on.

But to be honest, I don't think that it's a good idea to install the policy after every publish operation (or every hour) without further checks. My best guess is that a "management policy" would make more sense in this scenario. So you could e.g. argue with your team to do 2 policy installs per day - one in the morning and during lunch time. This could be easily scripted or even scheduled via the Smart Console without the rise of new problems that could occur with 10-20 policy installs per day.

And regarding the question why it is not possible to install 2 or more policies at a time - this is related to the fact that Check Point pushed the whole policy once you click install. This policy (on a very basic level) gets translated into the INSPECT language and pushed to the related target(s). There is no "delta" installation, therefore only one at a time is possible. That's also the reason why the policy install can take a lot of time if you have thousand of rules and objects but just change one rule & install the change.

[PhoneBoy]

A SmartTask is the combination of a trigger and an action. Initially, the two triggers that will be supported are "before publish" and "after policy installation." 

I could totally see "before policy installation" be a trigger, where you could code whatever queuing logic you wish.

@Anat_Eytan-Davi @Dima_M 

[JozkoMrkvicka]

It is really true that you cannot have tasks in the queue ? Policy installation is a simple task. Once some task is running at the time I click on "Install Policy" my task should go to the queue. Once the running task is completed, next task in the queue will be issued (my Policy Installation) task.

[Christian_Riede]

Yes, that is true.

[JozkoMrkvicka]

So I have tested it and in fact, you can have multiple tasks in progress, but simply not 2 installations of policy...

This is what you will get once you try to install another policy if some other installation is in progress:

Tested on R80.20.

Good point for RFE.

@Tomer_Sole @Tal_Paz-Fridman @Vyacheslav_Dubr @Robert_Decker @Dutch_Arling 

[Daniel_Taney]

I agree that one work around to this problem is to use mgmt-cli scripts to handle your policy installs. I went this route for regularly scheduled policy installs and it works great!

That said, sometimes there are one-off occasions where I need to install multiple policies on a few GW's after a change and this would be a helpful feature to have. 

[Timothy_Hall]

The inability to have more than one policy installation running at the same time is probably a bit of a holdover from the R77.30 and earlier SMS.  In R80+ management, when a policy install is started the needed config data is dumped out of the postgres database back into files like objects_5_0.C, then the policy verification, symbol resolution, and compilation into INSPECT code proceeds more or less like it did in R77.30 (with some new optimizations).  I'm assuming that this "dumping" behavior is for the benefit of legacy SMS processes like fwm that are still actively involved in many management operations.  Until those legacy components go away (such as the HTTPS Inspection/MAB config still being in the old SmartDashboard via fwm), I just don't see how more than one policy installation can be running at a time on an SMS. 

The ability to queue policy install operations should be possible, but what about an administrator that queues three policy installs, then immediately makes some changes in a session and hasn't published/discarded yet, should the queued ones still be allowed to proceed?  What happens if multiple policy loads are queued then that same administrator makes changes and publishes them before the queued installations are all done?  I can see some rather confusing situations that could arise here.  An administrator with queued policy installations would almost have to stay locked in read-only mode until they are all done, but then what if some other administrator publishes new changes in the meantime...ugh

[Christian_Riede]

I'm not asking for parallel installs. That restriction does not bother me at all.

A queued install should always install the latest published policy, even if the policy was published after the enqueue request.

Of course, a dequeue of an enqueued install request should be possible.

The queue just removes the necessity to actively wait for the previous install(s) to finish. All conflicts that you describe are also possible if the install is triggered by a different admin rather than by the queue.

I can't see a problem with that behavior.