Guest post by Eric Nothen, a Red Hat Certified Engineer (RHCE) who is a part of the Red Hat customer reference program and the Red Hat Innovation Advocates.
http://www.redhat.com/summit/2013/speakers/session.html#enothen
https://twitter.com/ericnothen

If you have any type of Dell assets registered to a Spacewalk or Satellite server, like desktops, laptops, or servers, then there’s a very easy way you can get all of your assets hardware support information saved at Spacewalk or Red Hat Satellite. In case you didn’t know, Dell provides a web service that you can use to query support information, by just providing the service tag of an asset. This valuable information includes shipping date, region, model, plus start and end dates of expired and active contracts. Read more about the web service.

Your Spacewalk or Red Hat Satellite already has the hardware information of each of your assets, so then the only thing you need to do is to take that information out, query Dell’s web service and then save the output. This is a very simple thing to do using Spacewalk or Red Hat Satellite APIs, which you can use through Perl or Python scripts, for example.
I’m going to be doing this through a Perl script. In order to make all this work, I will use the Frontier client module to connect to Spacewalk or Red Hat Satellite, and the SOAP Lite module to use Dell’s web service:

 #!/usr/bin/perl –w
 use strict;
 use warnings;
 use Frontier::Client;
 use SOAP::Lite;

The second thing you want to do is to login at Spacewalk or Red Hat Satellite using the “auth.login” API and get a valid session handler. Your server provides documentation and sample scripts that show you how to do that, (check out Documentation > API > Sample scripts) and it basically goes back to these two lines:

 my $client = new Frontier::Client(url => "http:///rpc/api");
 my $session = $client->call('auth.login', '', '');

The next thing will be to get a list of all machines registered to Spacewalk or Red Hat Satellite, and filter those that have “Dell” as the vendor. You do that by combining the “system.listUserSystems” and “system.getDmi” APIs:

 my $systems = $client->call('system.listUserSystems', $session);
 foreach (@$systems) {
 my $systemId = $_->{'id'};
 my $hwInfo = $client->call('system.getDmi', $session, $systemId);
 next unless ($hwInfo->{'vendor'} =~ /Dell/);

Now that you know you have Dell hardware on your hands, extract and validate the service tag:

 my ($ServiceTag) = $hwInfo->{'asset'} =~ /system: (\w+)\)/;
 next if ( !defined($ServiceTag) or $ServiceTag !~ m/^\w{7}$/ );

Here’s where the things get more interesting. With the service tag at hand, now you create a SOAP envelope that will be sent to Dell’s web service:

 my $envelope = SOAP::Lite
 -> uri('http://support.dell.com/WebServices/')
 -> on_action( sub { join '', @_ } )
 -> proxy('http://xserv.dell.com/services/assetservice.asmx');
 my $method = SOAP::Data->name('GetAssetInformation')
 ->attr({xmlns => 'http://support.dell.com/WebServices/'});
 my @params = (
 SOAP::Data->name(guid => '11111111-1111-1111-1111-111111111111'),
 SOAP::Data->name(applicationName => 'dellAssetInformation'),
 SOAP::Data->name(serviceTags => $ServiceTag) );
 my $results = $envelope->call($method => @params)->result;

If you want to have more detailed information on this last block of code, read this article.

You’ve created a SOAP envelope with your machine’s service tag and sent it to Dell. Now you want to extract the information from results, which is grouped in two types of data: the AssetHeaderData and the EntitlementsData. The first one contains static information that shouldn’t change as time goes by, such as the machine model name, shipping date, region, and the service tag itself. The later, on the other hand, contains information related to each of the support contracts as you renewed them, such as when they started, finished, and whether they are expired or active. More information about this.

So, get your asset and entitlements data saved:

 my $assetInfo = $results->{Asset}{AssetHeaderData};
 my $assetSupp = $results->{Asset}{Entitlements}{EntitlementData};

Something I learnt by using this tool with machines shipped worldwide is that the SystemType and SystemModel fields are not always defined, so to avoid errors, better come up with one single model string, like this:

 my $model = "";
 $model .= $assetInfo->{SystemType}." " if defined $assetInfo->{SystemType};
 $model .= $assetInfo->{SystemModel} if defined $assetInfo->{SystemModel};

To make the note look good at Spacewalk or Red Hat Satellite, I defined format strings, so that columns show up aligned, and then started populating a table. First goes the asset information:

 my $fmt = "%-15s%-15s%-11s%-20s\n";
 my $table = sprintf ($fmt, "Service Tag:", $assetInfo->{ServiceTag}, "Model: ", $model);
 $table .= sprintf ($fmt, "Shipping Date:", (split ("T", $assetInfo->{SystemShipDate}))[0], "Region:", $assetInfo->{Region}."\n");

Now print a header, and then go through the support contracts, printing a new line for each of them:

 $fmt = "%-15s%-15s%-11s%-10s%10s\n";
 $table .= sprintf ($fmt, "Support Start", "Support End", "Status", "Provider", "Days Left");
 foreach (@$assetSupp) {
 next unless defined;
 my $status = $_->{EntitlementType};
 my $start = (split ("T", $_->{StartDate}))[0];
 my $end = (split ("T", $_->{EndDate}))[0];
 my $days = $_->{DaysLeft};
 my $prov = $_->{Provider};
 $table .= sprintf ($fmt, $start, $end, $status, $prov, $days);
 }

So far so good, but before saving “table” as a note on this specific server, make sure you run through the existing system notes and remove any that has the same subject. This is to avoid duplicates when you cron this script weekly, or so. Then go ahead and add a new note:

 my $subject = "Dell Support Information";
 my $notes = $client->call('system.listNotes', $session, $systemId);
 foreach my $note (@$notes) {
 next unless ( $note->{'subject'} eq $subject );
 $client->call('system.deleteNote', $session, $systemId, $note->{'id'});
 }
 $client->call('system.addNote', $session, $_->{'id'}, $subject, $table);

To finalize the script, just close the loop that ran through all systems, and use the “auth.logout” API to expire the session handler. That’s all.

When you go back to your Spacewalk or Red Hat Satellite web interface, check on one of the assets, and the note will look like this:

picture 1 blog post

There are many things you can do with this information, like running reports to get assets with no active support contract. Another way to use this information is, if you have servers that are not allowed to connect to the internet, you can write a client script that can pull this note from Spacewalk or Red Hat Satellite, and show its own support information, right on the command line, like this:

picture 2 blog postAs you can see, the APIs are one of the most powerful features of Spacewalk and Red Hat Satellite. If you use them in depth, they will allow you to take automation to a whole different level, saving a great deal of time on the way. If you also combine them with the ability to save almost any type of information, you could make Spacewalk or Red Hat Satellite the central source of asset’s information.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.