Blogging Techstacks

iControl Perl get_member_v2 Example

This first fairly useful iControl example using Perl and SOAP::Lite solves a fairly time-consuming problem if you want to print all the pools and pool members from one of your BigIP LTM's and you're not really sure how to do it with the tmsh commands (or tmsh scripting). If you have a large number of pools and are using a web browser, you could spend hours clicking on a pool, then clicking the Members tab, then clicking on Pools, then selecting the next pool, then the Members tab for *that* pool, etc. Very time consuming.

This example uses the get_member_v2() method. It first grabs all the pools on that ltm using the get_list() method, then loops through each one and prints the pool followed by the pool members using get_member_v2().

There are other examples of this script out there but this one is the first version of the one I wrote for my own job. Some values have been sanitized and replaced with placeholders, ($host, $uid, and $pwd in my script). If you were to copy and paste this script verbatim into your new Perl script, it won't work until you replace those values.

#!/usr/bin/env perl

use Modern::Perl;
use Mozilla::CA;
use SOAP::Lite;
#use SOAP::Lite +trace => [ qw (all -transport) ];

# Pick one or the other. If the former doesn't work
# try the latter
use iControlTypeCast; # Same directory as your script
# --OR--
#use lib '[/path/to/your/icontrol/modules/directory/]';

$ENV{HTTPS_CA_FILE} = Mozilla::CA::SSL_ca_file();

# IMPORTANT - Values in ALL_CAPS are placeholders
# Swap out the values with your own values

my $host = "IP_ADDRESS_OR_HOSTNAME_OF_YOUR_BIGIP";
my $port = "443"; # Usually...

# Replace with your userid and password
# An account with Operator rights is all that is required here
my $uid = "YOUR_ICONTROL_USERID";
my $pwd = "YOUR_ICONTROL_PASSWORD";

sub SOAP::Transport::HTTP::Client::get_basic_credentials {
    return "$uid" => "$pwd";
    }

# This is the base request
my $req = SOAP::Lite
    -> uri('urn:iControl:LocalLB/Pool')
    -> proxy("https://$host:$port/iControl/iControlPortal.cgi");

# Add authorization header; Otherwise the
# initial request will fail
    eval { $req->transport->http_request->header (
        'Authorization' => 'Basic ' . MIME::Base64::encode("$uid:$pwd", '')); };

# Grab a list of all pools on this BigIP
my $pools = $req->get_list();
my @list = @{$pools->result};
say "BigIP LTM: $host";

# Iterate through the list of pools and get the pool members.
foreach my $pool (@list) {
    say "    $pool";
    my $poolmember = $req->get_member_v2(
        SOAP::Data->name(pool_names => [$pool])
    );

    my @memberListAofA = @{$poolmember->result};
    my @memberListA = @{$memberListAofA[0]};

    foreach my $member_def (@memberListA) {
        my $address = $member_def->{"address"};
        my $port = $member_def->{"port"};
        say "        $address:$port";
    }
}

iControl Perl - Authentication

Another thing that each of these iControl Perl scripts is going to need to do is to authenticate with the BigIP ltm. Since you are connecting using https, you are going to be using Basic Authentication. Below are a couple of options for setting authentication up.

The first method, which seems to be the most popular, is to insert the userid and password into SOAP::Lite's get_basic_credentials method, which would get set prior to creating your soap request. For example:

my $host = "the_bigip_hostname_or_ipaddr"
my $port = "443";
my $uid = "some_user_id";
my $pwd = "some_password";

sub SOAP::Transport::HTTP::Client::get_basic_credentials {
    return "$uid" => "$pwd";
    }

# This is the base request
my $req = SOAP::Lite
    -> uri('urn:iControl:LocalLB/Pool')
    -> proxy("https://$host:$port/iControl/iControlPortal.cgi");

Using this method, the request will get sent to your bigip, the bigip will respond with a 401 Unauthorized status code, and then the request will be retried with the UserID and password. If you want to skip the initial authentication failure, add the following code after the code which creates the request. This will add an Authorization header with your encoded userid and password on every request:

# Add authorization header; Otherwise the
# initial request will fail
    eval { $req->transport->http_request->header (
        'Authorization' => 'Basic ' . MIME::Base64::encode("$uid:$pwd", '')); };

The second method employs a similar technique to what you would employ if you were setting an ftp_proxy environment variable in your .bashrc—insert the userid and password separated by a colon and then separate the password from the URL with an @ symbol. For example:

export ftp_proxy=$USERID:[email protected]

With iControl, you would modify the proxy parameter in your request to use the same syntax:

my $host = "the_bigip_hostname_or_ipaddr"
my $port = "443";
my $uid = "some_user_id";
my $pwd = "some_password";
my $req = SOAP::Lite
    -> uri('urn:iControl:LocalLB/Pool')
    -> proxy("https://$uid:$pwd@$host:$port/iControl/iControlPortal.cgi");

---

Other Posts in This Series

<< Previous iControl Perl - User Accounts

iControl Perl - User Accounts

Figuring out what kind of user account your iControl script is going to require is about as simple as figuring out what rights a regular user is going to need. If your script is simply echoing back statistics or pools or pool member stats or virtual server configurations, you don't need a user account that is going to have Administrative rights to your BigIP. You can get away with "Auditor" rights for these types of scripts. They also will not require any special terminal rights since they are going to be executed remotely.

If your script is going to enable or disable nodes or pool members, "Operator" rights should be sufficient. The "Application Editor" role will give your script the ability to modify pools like setting weights, adding or deleting pool members, or modifying nodes and pools to attach monitors.

Operationally, it is tempting to just create an Administrative user that can do whatever it wants but I'd discourage that practice when you consider the security ramifications. You might, at some future point, want to distribute your scripts to junior members of your team but if you're embedding an Administrative account in your script, you may inadvertently be providing folks with the access that they shouldn't have so I encourage people to use an account that has the lowest privileges available to get the task done.

---

Other Posts in This Series

iControl Perl - Getting Started << Previous | Next >> iControl Perl - Authentication