02-03-2016 09:44 AM
I want to be able to use the perl distribution module for my scripts. We do have some questions that we need to answer to before I can get my admin to install this module for me. Appreciate if you can provide us the answers.
1. After this Module is installed, how does it authenticate the user ? Is it possible to limit API access to a group of users?
2. How can the number of API calls/Jobs from all users be limited/controlled so that we don't overburden the NetMRI?
3. Is it possible to track all API request received/processed on a daily basis/report?
4. How much load does it create when a call to some API's such as discover_now() or a search by Index is executed? Does it cripple the box from its normal functioning?
5. If we run external perl scripts and connect to devices, how can the changed performed be tracked?
6. Are there any existing vulnerabilities that we should be aware of ?
These are some of the immediate concerns we have on our team.
Solved! Go to Solution.
02-03-2016 02:31 PM - edited 02-03-2016 02:35 PM
This Perl module is the same as what is installed in the sandbox for accessing the Perl API. This is just a Perl-based wrapper on top of the NetMRI RESTful API. It provides some convenience methods for working with the RESTful API, as well as allowing you to use Perl objects and classes rather than strictly hashes for the RESTful responses.
> 1. After this Module is installed, how does it authenticate the user ? Is it possible to limit API access to a group of users?
To authenticate, you either create a .netmri.yml file in your home directory with the connectivity information, or you can pass it into your script in some manner you choose and pass it during creation of the client. The client class will keep a cookie internally during that session (just like a browser), and use that rather than authenticating every request (which is slow if you have external authentication). This is exactly how the browser works.
You can find an HTML version of the Perl documentation in your NetMRI at https://yournetmri/netmri/share/api/perldoc/NetMRI__API.html or by clicking the "Perl API" link at the top of the /api/docs page. This describes it in some more detail.
> 2. How can the number of API calls/Jobs from all users be limited/controlled so that we don't overburden the NetMRI?
There is no rate limiting feature at this time. If you have a distributed architecture (OC/collector), then many of the API calls being run by Perl jobs will go to the collector API, not the OC. At least, any calls that are for directly interacting with the devices in the job. But that is just for jobs, not external scripts.
> 3. Is it possible to track all API request received/processed on a daily basis/report?
Just like with the UI, all significant operations done by the API are logged in the audit log. Read-only operations are not generally in the audit log, I don't think.
> 4. How much load does it create when a call to some API's such as discover_now() or a search by Index is executed? Does it cripple the box from its normal functioning?
Depends on the call. There are limits on the number of simultaneous discovery and poll operations that protect the device. So those aren't an issue. But as discussed in #2, you can overdo the number of other API calls so you have to be careful. (By the way use the "discover" - http://yournetmri/api/3/devices/docs#discover - method in the Device API instead of discovery_now(). The latter is really for the UI and not as nice for API work).
> 5. If we run external perl scripts and connect to devices, how can the changed performed be tracked?
This is trickier - when you initiate a device connection directly with an external script, it is not associated with any job within NetMRI. So it is not really tracked within NetMRI beyond what you get in the audit log. Depending on your needs, you may be able to create custom fields to track this.
One thing you can do is request a config just before the change (http://yournetmri/api/3/config_revisions/docs#get_configs), wait for it to complete (there is a get_configs_status call), perform the change, then request another config.
> 6. Are there any existing vulnerabilities that we should be aware of ?
No. As mentioned above, the Perl API is in fact just a wrapper (or "language binding") on top of the RESTful API - it has no special access beyond what you could do with a browser anyway.
Note there is also a lightweight Python language binding at https://github.com/infobloxopen/infoblox-netmri which functions similarly to this, except that it does not map the various data models to Python classes. It just uses dictionaries, so you have to be more explicit about managing the data from REST calls.
02-05-2016 10:15 AM
Thanks for your detailed answers to my questions. You are awesome.
I wish NetMRI had a rate-limiting feature for number of API calls. I will work with my admin to see what can be seen in the audit log. Our main concern is that if multiple users start running scripts, it may overwhelm the device. I guess we have to find another way to schedule script runs externally.