Editing/changing a fixed address with curl

[#1]

I want to edit an *existing* fixed address and add a dhcp option.

I'm using this json for the creation:

{
  "name": "testhostname",
  "ipv4addr": "10.0.0.1",
  "mac":"00:11:22:33:44:55",
  "match_client":"MAC_ADDRESS",
  "options":[
  { "name": "host-name",
    "num": 12,
    "value": "testhostname",
    "vendor_class": "DHCP"}]
}

And it works with this curl call:

curl -u <user>:<password> -H 'Content-Type: application/json' -X POST https://infoblox/wapi/v2.0/fixedaddress -d @add_dhcp_hostname.json

But when I have created a fixed address without this option and want to later add the host-name option, I get an error:

{ "Error": "AdmConDataError: None (IBDataConflictError: IB.Data.Conflict:MAC address 00:11:22:33:44:55 is used in two fixed addresses 10.0.0.1 and 10.0.0.1, which are in the same network 10.0.0.0/24.)",
"code": "Client.Ibap.Data.Conflict",
"text": "MAC address 00:11:22:33:44:55 is used in two fixed addresses 10.0.0.1 and 10.0.0.1, which are in the same network 10.0.0.0/24."

It looks like this is the wrong way to edit/change a fixed address ... even though I want to add a previously not existing option in an existing fixed address.

What is the right way to do it?

[#2]

When you create or search for an object (including fixed addrs) one of the returned fields is the _ref.  This is the object reference.

To make changes to an existing object, use a PUT call against the reference, and give it the fields that are changing.

Something like this perhaps, with the complete list of options in the JSON file:

curl -u <user>:<password> -H 'Content-Type: application/json' -X PUT https://infoblox/wapi/v2.0/fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuMTAzLjMuMzMuMC4u:10.0.0.1/default -d @add_dhcp_hostname.json

Note that the DHCP options field is an array.  It cannot be modified in-place, when you update it you need to send the entire array of DHCP options.  So you may need to use a script to read the array, add new option/value pairs, adn then write the array.

[#3]

Thanks.

Do you have an example? A simple one on how to get the _ref for a fixed address?

Initially I wanted to do all this with Ansible, but the nios_fixed_address module has a bug (see my other post).

[#4]

A simple get will give you the list of all fixed addresses, including the _ref:

curl -k -u admin:infoblox -X GET https://192.168.1.2/wapi/v2.3/fixedaddress

You can also search for a specific one:

curl -k -u admin:infoblox -X GET https://192.168.1.2/wai/v2.3/fixedaddress?ipv4addr=192.168.1.26

returns:

[
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuOS4xNi4yNi4wLi4:192.168.1.26/default",
        "ipv4addr": "192.168.1.26",
        "network_view": "default"
    }
]

[#5]

Cool. One step closer. Thanks! I try to implement that.

I found that I need to add return_fields when I want to get more info than default.

I also want to get bootfile and nextserver. But adding those to returnfields, doesn't return anything.

Any hint on those?

[#6]

Thanks for this information. It is useful. Also this pokemon ruby roms is useful to get pokemon game.

[#7]

Are you sure bootfile and nextserver are configured directly on the fixedaddress?  They might be configured on the network or the grid instead, and inherited.

[#8]

Ehm, yes and no. I want to have a default nextserver but have the ability to override the default for each address, e.g. have the default bootserver Windows and be able to also boot from a Redhat Satellite or other OS install environment.

Following your answer, I suspect, that inherited entries are not displayed when I query a fixed address, correct?

Is there a way to show all effective settings for a certain entity, including the inherited? DHCP options also seem to be subject of inheritance, which makes things pretty hard... I mean, there can be more levels of inhertiance, one can't expect to follow the crumbs back to the initial configuration.

Is there a "better" best practice to boot different next servers than what we do?

[#9]

You are correct, the inherited values are not displayed, as they don't belong to this object but instead to the parent object.

There is an "_inheritance" flag however I haven't found it to work consistently.   It's giving me the lease time but not any other options inherited from the network.

curl -k -u admin:infoblox -X GET 'https://192.168.1.2/wapi/v2.3/fixedaddress' \
-d 'network=192.168.1.0/24' \
-d '_return_fields=options,bootfile,bootserver,nextserver' \
-d '_inheritance=true'

[#10]

I don't get your example to work. It works without -d '_inheritance=true' and displays all addresses with the requested options, but with the inheritance part I get

{ "Error": "AdmConProtoError: Unknown argument: _inheritance=true", 
  "code": "Client.Ibap.Proto", 
  "text": "Unknown argument: _inheritance=true"

Any idea?

I checked the May2019 API guide and I could not find any example that uses _inheritance. But there are other inheritance options... maybe a typo?

Speaking about consistency: When this is not the way it should work intentionaly, will you ask you collegues to fix this?

[#11]

Can I ask what version of NIOS you're running?  It looks like the _inheritance flag was introduced with NIOS 8.4 so it may not be available to you.

I'd recommend opening a support case, and discuss it with your account team, that's the best way to have it tracked.

[#12]

It's 8.4.3 (from the browser window title). Not sure whether or not this is the real one.

I'm not the admin... I'm just a user.

Is there a way to find out without having admin permission?

[#13]

The browser tab title should be accuerate.  You can also get the current version by asking about the grid upgrade stautus, via API:

curl -k1 -u admin:infoblox -X GET 'https://192.168.1.2/wapi/v2.8/upgradestatus?type=GRID&_return_fields=current_version_summary'

[#14]

This one is working fine.

It really is "current_version_summary": "8.4.3-383835".

It looks like there are no api elements like nextserver or bootfile. The gui is misleading here.

bootfile and nextserver are DHCP options and need to be requested with "options". Then it's option 66 (tftp-server-name) and 67 (bootfile-name).

It looks like one needs to check whether or not this option is actually used or inherited. According to the API reference then use_bootfile or use_nextboot are set to true for "set directly". When it's false, then the value is inherited from a higher level.

The API reference reads like this:

Somefields are associated with a corresponding boolean flag value that has the prefix use_. For example, ttlis associated with the flag use_ttl. In an object, the value of this field will only take effect when its use flag is true.Otherwise, the value will be inherited from a higher level setting.

I understand this like there would *always* be a value, but when the use_* value is true, it's set directly, and when it's false, it's inherited. But this is not the case. It seems that the use_* values are necessary for writing those values, but don't have an effect on reading them.

I still have no clue how to get the value when it's inherited from higher levels.

And I still can't find the _inheritance option in the api reference (https://www.infoblox.com/wp-content/uploads/infoblox-deployment-infoblox-rest-api.pdf)

[#15]

In the GUI, the bootfile, nextserver & bootserver fields (Boot File, Next Server, Boot Server, respectively) are in the BOOTP/PXE tab, and are only used by BOOTP and PXE clients.

DHCP clients will use the DHCP options 67 & 68 as you noted.

The appliance's online documentation for 8.4 does mention the "_inheritance" flag.  I usually use that documentaion instead as I find it to be more complete.  However as I mentioed before it doesn't seem to be fully implemented so I don't think it will suit your needs.

I'd recommend reaching out to your Infoblox account team if you think the current capabilites don't match your needs.

[#16]

I checked the ressources that are available from the appliances help menu.

I checked the API, the WAP and the NIOS online documentation.

None of the three have documentation about any _inheritance option (except 2 hits about record:host_ipv4addr.use_for_ea_inheritance )

What am I doing wrong? Can you point me to any online ressources that mention _inheritance?

A colleague of mine already tried to contact your customer support because of an Ansible problem (see my other posts), no result. They pointed me to the community forum. Some questions were solved, but now no answer anymore. I'm currently trying to work around this bug in your Ansible modules by using the WAPI. And again, I'm pointed to the customer support. Should I contact support again to be pointed back to the forum again?

I'm starting to get a little bit disappointed with the support experience of Infoblox...

[#17]

Hi,

The _inheritance flag is only supported from WAPI version 2.10.2 onwards.

Sample Code:
curl -k -u admin:infoblox "https://grid-master/wapi/v2.10.2/fixedaddress?_inheritance=True&_return_fields=options,bootfile,bootserver,nextserver"


Sample output:
[
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuMTAuMTAuMTQzLjAuLg:10.10.10.143/default",
        "bootfile": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "bootserver": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "nextserver": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "options": []
    },
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuMTAuMTAuMTAuMC4u:10.10.10.10/default",
        "bootfile": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "bootserver": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "nextserver": {
            "inherited": true,
            "multisource": false,
            "source": "NOT_DEFINED"
        },
        "options": [
            {
                "inherited": false,
                "source": "",
                "values": [
                    {
                        "name": "host-name",
                        "num": 12,
                        "value": "test_vm",
                        "vendor_class": "DHCP"
                    }
                ]
            }
        ]
    }
]

To check what the latest version of WAPI supported on your system is, you can run the _schema command

Sample API:
 curl -k -u admin:infoblox "https:/grid-master/wapi/v2.1/?_schema"             

Sample output:
{
    "requested_version": "2.1",
    "supported_objects": [
        "admingroup",
        "adminuser",
        "allrecords",
        "csvimporttask",
        "discovery",
        "discovery:device",
        "discovery:devicecomponent",
        "discovery:deviceinterface",
        "discovery:deviceneighbor",
        "discovery:status",
        "dtc",
        "dtc:certificate",
        "dtc:lbdn",
        "dtc:monitor",
        "dtc:monitor:http",
        "dtc:monitor:icmp",
        "dtc:monitor:pdp",
        "dtc:monitor:sip",
        "dtc:monitor:tcp",
        "dtc:object",
        "dtc:pool",
        "dtc:server",
        "dtc:topology",
        "dtc:topology:label",
        "dtc:topology:rule",
        "extensibleattributedef",
        "fileop",
        "fixedaddress",
        "grid",
        "grid:cloudapi",
        "grid:cloudapi:cloudstatistics",
        "grid:cloudapi:tenant",
        "grid:cloudapi:vmaddress",
        "grid:dhcpproperties",
        "grid:dns",
        "grid:maxminddbinfo",
        "grid:member:cloudapi",
        "grid:x509certificate",
        "ipv4address",
        "ipv6address",
        "ipv6fixedaddress",
        "ipv6network",
        "ipv6networkcontainer",
        "ipv6networktemplate",
        "ipv6range",
        "ipv6sharednetwork",
        "lease",
        "macfilteraddress",
        "member",
        "member:dhcpproperties",
        "member:dns",
        "msserver:adsites:domain",
        "msserver:adsites:site",
        "namedacl",
        "network",
        "networkcontainer",
        "networktemplate",
        "networkview",
        "nsgroup",
        "permission",
        "range",
        "record:a",
        "record:aaaa",
        "record:cname",
        "record:dtclbdn",
        "record:host",
        "record:host_ipv4addr",
        "record:host_ipv6addr",
        "record:mx",
        "record:naptr",
        "record:ptr",
        "record:srv",
        "record:txt",
        "request",
        "restartservicestatus",
        "roaminghost",
        "scheduledtask",
        "search",
        "sharednetwork",
        "sharedrecord:a",
        "sharedrecord:aaaa",
        "sharedrecord:mx",
        "sharedrecord:srv",
        "sharedrecord:txt",
        "snmpuser",
        "view",
        "zone_auth",
        "zone_auth_discrepancy",
        "zone_delegated",
        "zone_forward",
        "zone_stub"
    ],
    "supported_versions": [
        "1.0",
        "1.1",
        "1.2",
        "1.2.1",
        "1.3",
        "1.4",
        "1.4.1",
        "1.4.2",
        "1.5",
        "1.6",
        "1.6.1",
        "1.7",
        "1.7.1",
        "1.7.2",
        "1.7.3",
        "1.7.4",
        "1.7.5",
        "2.0",
        "2.1",
        "2.1.1",
        "2.1.2",
        "2.10",
        "2.10.1",
        "2.10.2",
        "2.10.3",
        "2.11",
        "2.2",
        "2.2.1",
        "2.2.2",
        "2.3",
        "2.3.1",
        "2.4",
        "2.5",
        "2.6",
        "2.6.1",
        "2.7",
        "2.7.1",
        "2.7.2",
        "2.7.3",
        "2.8",
        "2.9",
        "2.9.1",
        "2.9.5"
    ]
}

The _inheritance flag is covered under GET in the methods section of the official documentation which is avaliable off the box at https://<your grid ip>/wapidoc

Hope this is helpful,

Thanks and Regards,

Krishna Vasudevan

[#18]

Do you have an example? A simple one on how to get the _ref for a fixed address?

Sarkari Result Pnr Status 192.168.1.1

[#19]

Hi,

You can run a simple get request to get this, as below:

 WAPI call:
curl -k -u admin:infoblox "https://grid-master/wapi/v2.11/fixedaddress"

Sample output:
[
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuMTAuMTAuMTQzLjAuLg:10.10.10.143/default",
        "ipv4addr": "10.10.10.143",
        "network_view": "default"
    },
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTAuMTAuMTAuMTAuMC4u:10.10.10.10/default",
        "ipv4addr": "10.10.10.10",
        "network_view": "default"
    }
]

Hope this helps,

Thanks and Regards,

Krishna Vasudevan

[#20]

Hi,

Happy to find this undocumented use of PUT (at least in "Infoblox REST API, NIOS 8.6 pdf) to re-IP a fixedaddress to a different IP. 

However it seems to limit you to another IP in the same subnet:

     RuntimeError: {'Error': 'AdmConDataError: None (IBDataConflictError: IB.Data.Conflict:The IP '
     'address 10.102.91.177 is not valid for the network 10.102.80.0/21.)',
     'code': 'Client.Ibap.Data.Conflict',
     'text': 'The IP address 10.102.91.177 is not valid for the network '
     '10.102.80.0/21.'}

The fixedaddress' current IP is 10.102.80.23 (10.102.80.0/21) and am attempting to change the IP to 10.102.91.177 (10.102.88.0/22).

What would be the proper sequence of wapi call for my scenario in that case?

The current snippet for the error above is:

     URL = f'{GRID_MASTER}/{FixedAddrRef}'

     params = {"ipv4addr":f"{NextIP}","mac":f"{MAC}"}

     headers={"Content-Type": 'application/json'}

     resp = requests.put(URL, headers=headers, cookies=session.cookies, params=params, verify=False)

Where MAC is the MAC for the fixedaddress and NextIP is the next available IP in 10.102.88.0/22

Also if there if a more complete wapi document that shows the exitsing PUT tidbit please share that.

Thanks in advance!

Paul

[#21]

You need to tell it the new network too, since the old network is not correct anymore.

For example, suppose we start with a fixed address in the 192.168.1.0/24 network:

[
    {
        "_ref": "fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTkyLjE2OC4xLjIyLjAuLg:192.168.1.22/default", 
        "ipv4addr": "192.168.1.22", 
        "mac": "aa:bb:cc:dd:ee:ff", 
        "network": "192.168.1.0/24", 
        "network_view": "default"
    }
]

And we want to move it to the 192.168.255.0/24 network.  Here is a call that would make that change:

curl -k -u admin:infoblox -X PUT 'https://192.168.1.2/wapi/v2.11/fixedaddress/ZG5zLmZpeGVkX2FkZHJlc3MkMTkyLjE2OC4xLjIyLjAuLg:192.168.1.22/default' -d 'ipv4addr=192.168.255.22&network=192.168.255.0/24'