Python is my favourite programming language. But then again, it’s also the only one I know. 🙂
I made a choice to go with python because, honestly, that’s what all the cool kids were doing at the time. But after spending the last year or so learning the basics of the language, I do find that it’s something that I can easily consume, and I’m starting to get better with all the different resources out there. BTW http://www.stackoverflow.com is your friend. you will learn to love it.
On with the show…
So in this post, I’m going to show how to use python to build a quick script that will allow you to issue the RealTimeLocate API to the HP IMC server. In theory, you can build this against any RESTful API, but I make no promises that it will work without some tinkering.
Planning the project.
I’ve written before how I’m a huge fan of OPML tools like Mind Node Pro. The first step for me was planning out the pieces I needed to make this:
- usable in the future
- actually work in the present
Auth Handler
Assuming that the RESTful service you’re trying to access will require you to authenticate, you will need an authentication handler to deal with the username/password stuff that a human being is usually required to enter. There are a few different options here. Python actually ships with URLLIB or some variant depending not the version of python you’re working with. For ease of use reasons, and because of a strong recommendation from one of my coding mentors, I chose to use the REQUESTS library. This is not shipped by default with the version of python you download over at http://www.python.org but it’s well worth the effort over PIP’ing it into your system.
The beautiful thing about REQUEST’s is that the documentation is pretty good and easily readable.
In looking through the HP IMC eAPI documentation and the Request library – I settled on the DigestAuth
So here’s how this looks for IMC.
Building the Authentication Info
>>>import requests #imports the requests library you may need to PIP this in if you don’t have it already
>>> from requests.auth import HTTPDigestAuth # this imports the HTTPDigestAuth method from the request library.
>>>
>>> imc_user = ”’admin”’ #The username used to auth against the HP IMC Server
>>> imc_pw = ”’admin”’ #The password of the account used to auth against the HP IMC Server.
>>>
auth = requests.auth.HTTPDigestAuth(imc_user,imc_pw) #This puts the username and password together and stores them as a variable called auth
We’ve now built the auth handler to use the username “admin” with the password “admin”. For a real environment, you’ll probably want to setup an Operator Group with only access to the eAPI functions and lock this down to a secret username and password. The eAPI is power, make sure you protect it.
Building the URL
So for this to work, I need to assign a value to the host_ip variable above so that the URL will complete with a valid response. The other thing to watch for are types. Python can be quite forgiving at times, but if you try to add to objects of the wrong type together… it mostly won’t work. So we need to make sure the host_ip is a string and the easiest way to do that is to put three quotes around the value.
In a “real” program, I would probably use the input function to allow this variable to be input as part of the flow of the program, but we’re not quite there yet.
>>> host_ip = ”’10.101.0.109”’ #variable that you can assign to a host you want to find on the network
>>> h_url = ”’http://”’ #prefix for building URLs use HTTP or HTTPS
>>> imc_server = ”’10.3.10.220:8080”’ #match port number of IMC server default 8080 or 8443
>>> url = h_url+imc_server #combines the h_url and the IP address of the IMC box as a base URL to use later
>>> find_ip_host_url = (”’/imcrs/res/access/realtimeLocate?type=2&value=”’+host_ip+”’&total=false”’) # This is the RealTimeLocate API URL with a variable set
>>>
Putting it all together.
This line takes puts the url that we’re going to send to the web server all together. You could ask “Hey man, why didn’t you just drop the whole string in one variable to begin with? “ That’s a great question. There’s a concept in programming called DRY. (Don’t Repeat Yourself). The idea is that when you write code, you should never write the same thing twice. Think in a modular fashion which would allow you to reuse pieces of code again and again.
In this example, I can easily write another f_url variable and assign to it another RESTful API that gets me something interesting from the HP IMC server. I don’t need to write the h_url portion or the server IP address portion of the header. Make sense?
>>> f_url = url + find_ip_host_url
>>> # This is a very simple mathematical operation that puts together the url and the f_url which will product the HTTP call.
Executing the code.
Now the last piece is where we actually execute the code. This will issue a get request, using the requests library. It will use the f_url as the actual URL it’s going to pass, and it will use the variable auth that we created in the Authentication Info step above to automatically populate the username and password.
The response will get returned in a variable called r.
>>> r = requests.get(f_url, auth=auth) # Using the requests library get method, we’re going to pass the f_url as the argument for the URL we’re going to access and pass auth as the auth argument to define how we authenticate Pretty simple actually .
>>>
The Results
So this is the coolest part. We can now see what’s in r. Did it work? Did we find out lost scared little host? Let’s take a look.
>>> r
<Response [200]>
Really? That’s it? .
The answer is “yes”. That’s what’s been assigned to the variable r. 200 OK may look familiar to you voice engineers who know SIP and it means mostly the same thing here. This is a response code to let you know that your request was successful – But not what we’re looking for. I want that content, right? If I do a type(r) which will tell me what python knows about what kind of object r is I will get the following.
>>> type(r)
<class ‘requests.models.Response’>
So this tells us that maybe we need to go back to the request documentation and look for info on the responses. Now we know to access the part of the response that I wanted to see, which is the reply to my request on where the host with ip address 10.101.0.111 is actually located on the network.
So let’s try out one of the options and see what we get
>>> r.content
b'<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?><list><realtimeLocation><locateIp>10.101.0.111</locateIp><deviceId>4</deviceId><deviceIp>10.10.3.5</deviceIp><ifDesc>GigabitEthernet1/0/16</ifDesc><ifIndex>16</ifIndex></realtimeLocation></list>’
How cool is that. We put in an IP address and we actually learned four new things about that IP address without touching a single GUI. And the awesome part of this? This works across any of the devices that HP IMC supports.
Where to from here?
So we’ve just started on our little journey here. Now that we have some hints to the identity of the network devices and specific interface that is currently harbouring this lost host, we need to use that data as hints to continue filling in the picture.
But that’s in the next blog…
Comments or Questions? Feel free to post below!
kontrolissues 