What versions of NIOS does ibcli work with ?

I was just asked the question :

Given the various versions of ibcli.pl listed,
what is the recommended way to validate which
version of ibcli.pl 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.

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

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.

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 ?

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 sites.google.com (But it doesn't have RSS capability, go figure)