The Ibcli is a simple command line tool that lets you do some (mostly) powerful things. It leverages the Infoblox api, but provides a wrapper to the more complex (and detailed) API calls with a simple command line syntax.

It also lets you create batch scripts so you can configure an Infoblox SDB without writing any scary perl.


Do not call Infoblox support expecting help, do not hassle them because this cli doesn't work. I wrote this tool in my spare time because I wanted the functionality. If you have questions or bug fixes, email me : 'horne-ibcli (at)

Tuesday, December 29, 2009

What versions of NIOS does ibcli work with ?

I was just asked the question :

Given the various versions of listed,
what is the recommended way to validate which
version of should be used - based on
the version of NIOS that's on the GM that ibcli
will be interacting with ?

The answer is : "Use the latest version of ibcli, always".

Wherever possible I've tried to make ibcli backwards compatible, including working around known bugs, and inserting multiple versions of code (such as support for extensible attributes or IPAM fields).

If you use an old version of ibcli you won't have access to some of the commands. If you use a new version of ibcli against an old version of NIOS, some commands just won't do anything ( type 'set debug 1' to see the failures )

And, as usual, if you find a bug, let me know.

Thursday, September 24, 2009

Version 3.44 is now available

New in version 3.44

Get the Code
Get the Release Notes
Get the User Guide

More support for permissions
Network Views
and other stuff

Monday, July 27, 2009

Version 3.43 is now available

New in version 3.43

Get the Code
Get the Release Notes
Get the User Guide

You can modify views and fixed addreses
Provisional support for roaming hosts
Showing and adding extensible attributes
Showing and adding permissions to objects

I still haven't coded the 'update' feature yet, but no-one has been screaming for it.

Monday, March 9, 2009

For the next releae

For the next release I'm working on 2 new features. One is adding Extensible attributes to networks and other 'non-host' objects. The second one is more tricky, it has to do with modifying hosts. The command(s) I'm proposing are something like :

conf zone insert host ...
conf zone update host ...

If you go to modify a host and it isn't already there, you will get an 'object not found' error. This happens a lot if you are going back later and trying to import a pile of IPAM data on top of a pile of DNS data (it is never a 1-1 match).

So you have to do 2 passes :
  • Modify the existing hosts
  • Walk the error log and add hosts that didn't exist.

So I'm proposing a comand that will first try to MODIFY the host, and if there is an error, then try to ADD the host.

But, and here is the problem. Which is more efficient ? MODIFY then ADD, or ADD then MODIFY (or do we need both)

What are your thoughts ?

Monday, January 19, 2009

Version 3.40 is now out

Get the Code
Get the Release Notes
Get the User Guide

New in Version 3.40 :

Changes to TAB completion and other commands
Extended attributes
Support for more zone types
A Records and others can now be added to different views
Networks can now be added WITHOUT a default member
Move Networks to different members
Configure Member DNS settings
Configure Member DHCP settings

We now have RSS

I moved the website to blogger to get RSS feeds and announcements. The Code and files are hosted on (But it doesn't have RSS capability, go figure)