Generic API, List Index

[Christian_Riede]

Hello,

in dbedit, according to the documentation, you can edit elements of a list in the following way:

dbedit> modify network_objects My_FW interfaces:3:ipaddr IP_ADDRESS

This changes the attribute ipaddr of the 3rd interface.

How is this achieved which the gerneic api? How does one change attributes of a object in a list. Note that I am not asking how to change an ip address via api. My question is about general API syntax.

My use case is to go into a firewall object, navigate to the realmsForBlades section and change the userloginattr.

Something like

set generic-object uid="something'" realmsForBlades.1.directory.userloginattr SAMACOUNTNAME

, but that specific syntax does not work.

Probably, it's something like

set generic-object uid="something'" realmsForBlades.set .... ,but I cannot find the correct syntax anywhere.

Can anyone help?

Thanks

Christian Riede

[PhoneBoy]

Someone else ran into a similar situation trying to edit the platform portal URL, which requires a similar sort of change.
My understanding (confirmed by R&D) is the generic-object API doesn't provide a way to edit these sorts of attributes.
See: https://community.checkpoint.com/t5/CloudGuard-IaaS/Azure-VMSS-Gaia-Certificates/m-p/80948#M1745
You can still use dbedit, however.

[Christian_Riede]

Well.  "generic"... ok.

[Christian_Riede]

on dbedit:

# dbedit
Enter Server name (ENTER for 'localhost'):

Please enter a command, -h for help or -q to quit:
dbedit> modify network_objects <name-of-firewall> realmsForBlades:0:directory:userloginattr SAMACCOUNTNAME
failed to get field realmsForBlades

Reason: in objects_5.0.C, it's realms_for_blades, not realmsForBlades. And it's not SAMACCOUNTNAME, but sAMAccountName

the following works:

modify network_objects <name-of-firewall> realms_for_blades:0:directory:UserLoginAttr sAMAccountName

Now please Checkpoint, can we get rid of dbedit soon?

[PhoneBoy]

That's the ultimate plan, yes.

[Christian_Riede]

Adding support for indexes like in dbedit to the generic API seems to be a low hanging fruit and would solve the problem in a general way.

Having a specific API for all the objects is probably the long term solution.

[PhoneBoy]

The ultimate goal is to eliminate the need for the generic-object API entirely, which means having proper, supported API endpoints for everything.

[Christian_Riede]

So the question is: What happens first - get rid of dbedit by making the generic api functional or get rid of dbedit and generic api at the same time once the specific api is available? 😂

[PhoneBoy]

Remember that the generic-object API largely exists to deal with things that need to be automated in a RESTful way but don't have formal API support yet.
Once there is formal API support for something, there's no need to have support for it via generic-object, which was never meant to be a formally supported API to begin with.
Which means: the second option is most likely.