Image via Wikipedia

Excel spreadsheets are used at almost every level of business.  As such spreadsheets are created by people with different goals and different levels of familiarity.  What many don’t realize is that excel is primarily a data processing and information storage tool.  Excel is much like a database and is most effective when data is stored as one would store information in a database.  The problem is that data in a database isn’t necessarily that presentable.  So many people input information into excel and attempt to format it for presentation.  Many people create groups and merge cells or insert multiple entries into a single cell and then apply special formatting.  The down side is when someone wants to use the graphing and report building features of excel the combined or grouped data isn’t accessible because it is either missing from cells due to cell merging or each entry isn’t accessible on its own because it has been entered into a single cell.  The best method is to treat the data as a database and ensure that each cell in a column has data in it relative to the cells in the row so that a complete record is available.  Then use the grouping and pivot table features to create reports that are presentable and much more functional because the data can be grouped and categorized in two dimensions.

But what do you do if you get  a spreadsheet in which data has been either entered into one cell but not in subsequent rows in some cases or has been merged through rows?  The first thing to do is to select the column with merged data and unmerge it. But then what now.  You can either go through manually massage the data adding rows and extracting the entries entered in a single cell and use a fill down copy where an entry was merged through rows.  But if you have hundreds of rows this can be time consuming.   I have run into this problem frequently enough that I have taken some time out to write a couple functions that spead up the process.

Text To Rows

If you have ever imported data into excel you may be familiar with the text to columns function under the data menu.  If you didn’t specify delimiters or missed one while importing you can select the column with multiple fields of data and tell it what to split the data on and it will automatically split the data across columns.  But what about rows.  The procedure below may be run on any column where multiple entries have been combined into single cells.  The default delimiter is a comma but this may be modified to meet your particular needs.

Fill Down Copy

If you have data in one cell which is either merged through rows or in a single cell with subsequent rows blank you will not be able to group by this column until each record has the corresponding data in each cell in the column.  You could page down and select each populated cell and then double click the little corner box to perform a fill down copy or you can execute a procedure.  The procedure below may be run to copy down data into unpopulated cells.

When disk capacity is released to a new application or service many times the projects do not consider how best to use the storage that has been provided. Essentially the approaches fall into one of two schools of thought. The first is to reduce upfront engineering into a couple design options and resolve issues when they arise. The second is to engineer several solution sets with variable parameters that will provide a broader pallet of solutions and policies from which an appropriate solution may be selected.

Reduced Simplified Engineering

• Apply one of a couple infrastructure designs to a project.
• This approach involves less work upfront, has a simpler execution and involves less work gathering requirements.
• Potentially more time and effort will be spent resolving issues when resources and design are insufficient.

Solution Engineering

• Develop several standard solution sets and models and document policies and procedures which will be used to fit applications/components into these models.
• This approach involves substantial requirements gathering and entails more work and complexity.
• The result is a more efficient use of resources and less time spent resolving issues because the design and resources should better fit the system needs.

Engineering Disk Performance

When it comes to disk performance the cost of not considering how to optimize the use of the storage infrastructure can be very significant. Consider the IO operation cycle time table. The order of magnitude difference between CPU operations, memory operations and that of device IO is significant. If cycle time is scaled up to a second the comparative difference is between seconds and that of device IO taking months to years to complete. Poorly orchestrated device use cases can result in significant impact. A memory miss will only cost a few hundred nanoseconds but a disk IO cycle miss could cost a couple dozen milliseconds. To put it in the perspective of scale we are talking about the difference between four minutes and eight months.

How IO devices are use by systems can impact device performance in several ways. First, between the system and the device is usually a cache which attempts to predict what data will be needed and pre-stages it in faster memory in anticipation of any potential access requests. Traditional cache algorithms identify data that is accessed in ordered proximity on the IO device and then reads ahead to pre-fetch subsequent data. These pages are then left in cache until they are aged out due to subsequent access to other data on the device. The result is that sequential IOs will experience better performance because the data will be in cache. However random IOs and IOs that occur sporadically will require direct access to the slower storage device. Newer caching algorithms such as SARC have algorithms designed to improve anticipation of random IO but are no substitute for considering data layout on the devices. An example of incorrect data layout would be over aggressive server side striping using volume management which can cause sequential IOs on the system to appear as random on the storage device; in essence, circumventing caching. The second area of consideration is the storage device back-end performance. Back-end performance can be impacted by IO sizes and distributions across array boundaries. The most significant impact comes from conflicting IOs that request data from different portions of storage device media at the same time. The result is what is termed “thrashing” because the device access mechanism must be readdressed from one part of the media to another requiring increased times for continuous repositioning.

Optimizing the Layout of Information on Storage

Component Activity Diagram

With all these potential factors that can impact storage performance how can a method for optimizing how storage devices are used be formulated? Some of the decisions have to be made on the back-end by the Storage Analysts that configure and present the storage to hosts. Once storage is presented to a host how the storage is used in light of these factors needs to be considered. Back-end configuration considerations vary by storage device implementation but most storage sub-systems have facilities that automate redistribution of data to balance IOs across the device media. Directions on optimum logical device configuration on the storage system are available in architecture documentation and from field engineers. But once these configured devices are made available to a system a method of laying out data needs to be considered that will increase sequential IO and reduce IO conflict potential. To develop a standard method rather then create unique custom solutions for each application component is more advantageous to establish a more predictable, re-creatable and supportable environment. This method should consider three factors. It should consider what the component does, what the component stores and how large of an implementation the component is supporting.

Categorizing Component Functionality

Application Functional Categories

The first step is to determine what an application component does. Some applications are a single entity while other applications are non-monolithic and break the work they perform down into subsets of functionality performed by components. All applications or component functionality can be categorized into one or more of four possible categories. The first category is client servers which include; web servers, web portals, portal servers, SNA gateways, and Citrix servers. This category is mostly comprised of executables and static configurations or models with some temporary file requirements. The next category of functionality is utility servers. Utility servers provide peripheral or supporting functionality such as reporting, authentication and include; LDAP servers, Active Directory servers, messaging, certificate servers, file transfer servers, EDI and OLAP servers. This category has a broad constituency including executables along with configuration files, temporary file space and data space for certificates and directory structures. The IO profiles can range from sporadic to rather intense when dealing with OLAP servers. The next category is applications servers that provide framework for software development through distributed objects and APIs that provide business logic and business process functionality and include, IBM Websphere, GlassFish, DataStage TX, BEA Tuxedo, and AX Workflow manager. This category generally has executables, configuration files and uses some temporary space but interfaces with data servers for any major data functions. The final category of application components are data servers that manage access to structured, semi-structured and unstructured data. Data servers include databases such as Oracle and DB2 and document management applications such as Documentum. This category generally includes executables with configuration files and large data stores that are managed by a data engine and tend to perform the brunt of data manipulation. Categorizing components using these definitions should help to narrow down storage infrastructure performance requirements.

Categorizing Storage IO Activity

The next step is to determine what types of data is stored and how it is accessed by a component. The types of data that an application component stores and accesses fall into one of four categories based upon how the data is used and accessed, see the diagram below of the categories.

Types of Storage Access

The first category is static data which is comprised of executables, configuration files, models, static images, templates, style sheets, etc. This data usually gets loaded once when a process starts and much of what is needed is instantiated in the systems memory as a running process or cached frequently used templates and images files and therefore IO happens at start up and then less frequently there after. The next category is transient data which is comprised of temporary files, database transaction logs, database redo logs, spools, queues, temporary database tables etc. This data is usually only accessed a few times and then either purged or over-written in a cyclical file. The IO profile is more random and sporadic and in the case of data servers usually works in concert with access to retained active data. The next category is active data which includes RDBMS data, HDMS data, file shares, document or image stores, etc. This is the retained working data set used by an application component and typically involves heavier sequential IO operations. The final category is reference data and includes RDBMS indexes, HDMS directory data and meta data and is generally referenced in concert with access to retained active data to identify what active data needs to be accessed based upon criteria stored in the reference data. Categorizing the file systems/directories specified by a component into one of these categories will help to identify potential data structuring to achieve an isolation of IO to reduce contention and to consolidate similar IO patterns there by increasing sequential IO potential.

Determining a Size Model

Now that we know what the application component does and we know what types of data files it uses the next step is to determine how large of an implementation this component is supporting. The size should be made based upon the size of the file spaces and/or the estimated number of IOs. This model should then be used to determine if the file spaces need to be separated and to what extent based upon the storage activity category.

Using OS Storage Abstractions to Optimize Layout and Use

Finally, now that much has been learned about the component being implemented and a determination of file space and implementation size; what mechanism may be used to manage IOs? Most operating systems have facilities for creating logical abstractions of storage. The diagram of OS Storage Abstraction below depicts a typical volume management facility. This is true of HP LVM, AIX Volume Manager and Veritas Volume Manager and is even true of Solaris z-pools and zfs file systems.

OS Storage Abstraction Functionality

These abstraction structures provide the means to limit storage access in three ways. Device groups, Volume Groups or Windows labeled Disks provide a means of isolating IO. The logical partitions are distributed across the presented disks based upon several parameters but all their IO is limited to the devices within the group. The logical partitions and file systems limit data growth and directories provide a logical segregation of files into hierarchies for organizational purposes. Once an implementation size is determined a model may be assigned. In a small model all the storage activity categories may be handled by a single device group. In a medium model the reference and transient data should be placed in a device group and the static and active data placed in another device group. In a large model Static and reference data are placed in one device group, transient data into a second and active data into a third device group and file systems created per specifications. Finally if a component is determined to have a huge IO / Size requirement four or even more device groups should be considered including multiple partitioning of transaction, active and reference data.

Division of the volume groups may be tackled in several ways. One way would be to track all device group names and their purpose and add new device groups based upon the new application components the service or application they are supporting. This becomes more complex in shared service environments where one system may host several instances of a component. An easier way to accomplish this is through using a device group naming convention. With a naming scheme analysts don’t need to know what device groups already exist, at a glance how storage is used on a system can be seen from the device group names and it eliminates the creation of unnecessary volume groups since any new file systems that fall into pre-existing categories will end up being assigned to the appropriate pre-existing device group. Essentially the used device group names are self-tracking since the application of the naming process should result in the same name or a new name when applicable. The implementation of the naming scheme can be automated in a spreadsheet form using lookups based upon the models and categorizations of the file systems requested in the form. The naming scheme I have used has the following form:

• [app abbreviation up to 4 characters][00 Instance number][storage activity category(STAR)][Environment Code]
• example: Oracle People Soft Data Table Production = orps1ap
  Oracle People Soft Index Table Production = orps1rp

Conclusion

Exploring the structures that comprise an application component and then making informed judgments based upon the size of an implementation will result in better performance and a more efficient use of resources. The isolation of IOs by the type of data access will place like data together increasing sequential access potential and decreasing the potential for IO conflicts due to concerted access between active, transient and reference data types.

Bellow is a link to a worksheet which I had created a while ago to determine volume group names based upon data types.

VG Storage Layout Excel Worksheet

The first issue to be addressed is whether to report storage capacities as raw capacity or usable capacity. The simplest method is to report raw but since these numbers do not take into account protection and management overhead service delivery management is tempted to think that more storage is available then what is available in reality. If these overheads aren’t taken into account when projecting future demand the projected supply may be overstated. For this reason it is probably best to provide facilities for reporting both raw numbers which will be used more in the day to day support and usable numbers for planning and estimation purposes.

To further complicate this problem most corporations have heterogeneous storage environments. Each vendor uses their own terminology for features and metrics. For example EMC uses the terms SRDF and TimeFinder for replicated storage and in EMC Control Center reports capacity used by these facilities as Local Replica Usable and Remote Replica Usable where as IBM terms replicated storage as Copy Services and storage allocated to Copy Services is reported as Remote Copy Usable and Local Copy Usable.

The third and final problem to overcome is one of perspective. For the most part storage technicians when talking about capacity are speaking from the stand point of the storage hardware and have in mind spindles and logical abstraction of this storage by disk subsystems for presentation to host systems. Where-as many service delivery analysts and IT system users look at storage from the stand point of how it has been further abstracted by host systems which have formatted the capacity into file systems. One group is thinking about file space and the other is thinking about drive space. I have seen this problem of perspective result in confusion when management looks at a new application that needs X amount of storage and they see free space on another system and erroneously assumed that the free space is just available to any other system. The truth is; free space within a file system may only be used from that file system, free space on a disk partially allocated may only be used by either a new file system or an existing file system. Free space on a disk assigned to a system but not yet allocated through logical formatting may be used by another system but requires additional work to remove it from that system and place it on another system. In other words there are degrees of freedom with regard to available capacity.

To resolve some of these problems the first step is to define a terminology which is vendor agnostic. Storage capacity terms must first start out at a high level defining terms that generically encompass functionality implemented by any storage vendor. To resolve the issue of degrees of available capacity the relationship of these terms to over-all capacity must be established.

Storage Capacity KPI Hierarchy

A generic set of terms is depicted in an hierarchy in the “Storage Capacity KPI Hierarchy” diagram. We will quickly review each term. Every storage solution has a potential capacity, the most amount of storage that can be installed in a storage sub-system. Drilling down into a storage sub system what ever capacity is already installed in a sub-system is termed the total capacity and anything left over related to the potential capacity would be called the expansion capacity. Within the total capacity some of that capacity is considered configured for use and whatever remains is considered unconfigured. Then within the the configured capacity some of that capacity may be reserved for maintenance, replication, protection (RAID sparing) or other over-head, some is assigned and what remains is unassigned capacity. Now assigned capacity may be available to be used by a system to which it is assigned but it is considered unallocated until it is logically formatted into a logical volume and/or file system. Capacity terminology shifts from being storage sub-system centric to being file space centric after being assigned to the host. Once allocated to a file system the space within the file system is either used by file data or free.

Once this terminology and these high level metrics are established the next undertaking is to determine how the vendor specific metrics may be used to calculate these metrics. After this is done then the reports using these metrics must be defined. It may also be useful to combine some of the metrics to simplify reporting. We will focus our metrics on usable capacities for reporting back to Service Delivery and users. Below are some examples of metrics and formulas which may be used to calculate them from EMC Control Center and HP EVA’s Virtual Controller Software.

Expansion: Usable* GB expandability based upon the number of free slots in the array that may be used to expand capacity multiplied by standard spindle sizes (min(disk size))
ECC: =(Total Slots for indicated model – “# Disks”) * (min(spindle_size)/2)
VCS: =Max Capacity – Current Capacity

Total Capacity: All usable* storage in the array including unconfigured, unallocated, reserved free, and used storage.
ECC: =(“Configured – Usable (GB)” + (“Unconfigured – Total (GB)”/2) or on SP1 of ECC “Configured – Usable” may not be accurate use: =(“Local Replica Usable”+“Remote Replica Usable”+”Primary Usable”) + (“Unconfigured – Total (GB)”/2)
VCS: Current Capacity

Unassigned: Unconfigured usable* storage within the array and configured usable* storage not presented to any host or reserved for any application including COD.
ECC: =“Unallocated – Unmapped – Usable – Total (GB)”
VCS: =Current Capacity – (Allocated Storage + Lost to Overhead)

Reserved : Usable* GB of Configured storage which is either reserved for a specific application or reserved through presentation to a specific host or front end adapter which is not being physically used or is not under volume management on a host.
ECC: =“Accessible – Free – No Vol Grps (GB)” + “Unallocated – Mapped – Usable (GB)”
VCS: Lost to Overhead = Current Capacity * 0.25

Assigned: Configured usable* storage presented to a host and in use, including free space within the file system and LVM structures.
ECC:= Total Storage – (Unallocated + reserved storage)
VCS: Allocated Storage

These metrics may be extracted and reported on in many ways including reporting tools like Birt or Crystal Reports, php and others . ECC provides an oracle API which creates an ODBC connection and other solutions either provide database connectivity or the information could be scraped from web pages if necessary. (The reports below were generated using an access database with table links through ODBC to a couple ECC implementations and data access pages. I will work on a follow up article on how to do this.)

Now that we have defined the formulas for extracting some metrics from our storage platforms the next step is to define some reports. The first report should present an overall picture of capacity. A pie chart is best suited for presenting an over-all picture of the percentage of capacity utilization. The chart below is an example of a Storage Capacity Pie Chart.

Storage Capacity Pie Chart

The next report should drill down into the capacity to further break it out by location and storage array. A percentage bar chart will normalize the data to a percentile and then the actual capacities may be inserted as labels. This will allow analysts to quickly assess where resources are running low.

Storage Capacity Bar Chart

The next task would be to further drill down by expanding the categorization of the storage resources by tier. This assumes that a tiered approach has been applied to storage resources. Most large corporations have categorized storage array platforms into tiers or classes of storage based upon architecture, performance and resiliency. This classification of storage has become more complicated in the past five years with the advent of unified storage, cloud storage and storage visualization. These technologies have introduced the ability to provide varied classifications of storage within the same storage subsystem. Since these technologies have complicated tiered storage capacity reporting the topic is somewhat beyond the scope of this article and will be handled in future articles.

Posted in Capacity Planning Tagged: Capacity, KPI, Storage, Storage Reporting ]]> http://dcawired.com/2010/01/22/storage-capacity-kpis/feed/ 0 Devin C. Adint Storage Capacity KPI Hierarchy Storage Capacity Pie Chart Storage Capacity Bar Chart http://dcawired.com/2010/01/21/pushing-your-profile-and-ssh-keys/ http://dcawired.com/2010/01/21/pushing-your-profile-and-ssh-keys/#comments Thu, 21 Jan 2010 22:58:48 +0000 Devin Adint http://dcawired.com/?p=419 ]]> When ever you start supporting a new environment especially in a large corporation usually you are confronted with many systems.  Security will take care of setting up your access across whatever platforms there may be.  But generally you are left holding the bag with setting up your ssh keys and any profile customizations not to mention distribution of any scripts or tools you have come to rely upon.  Of course before you put any tools on a system there are several things to consider.  You definitely want to consider the environments you are first performing the distributions on and it is always good to start with development or lab environments and move out from there.  Also you will need to consider the corporate policies related to the environment which might limit your ability to even have your own set of tools and scripts.  You may be limited down to simple .profile changes and ssh keys.  Implementing a script to push these keys and profiles out may need to go through various degrees of red tape.  Whatever policies and requirements exist in your organization are your responsibility to know and to determine how or if the tools discussed here may be used.

First you should have run ssh-keygen to create your keys and you should have created an .ssh/authorized_keys file in which you have placed your public key.  The next order of business is to create a script that may be copied to any other system to retrieve your profiles from a designated home or administrative system.  This script may be easily created using korn shell.  An example getprof script is inserted below.  The script uses ssh and file handles to stream tar through a ssh connection.  The reason for this is that I have run into organizations that have disabled scp as well as incompatibilities between the versions of ssh on various platforms.  Streaming tar through ssh has been the most effective means of distribution.

#!/bin/ksh
HST=${HST:-AdminHost}
USR=${USR:-UserName}
RCP=${RCP:-”scp -p”}
RSH=${RSH:-”ssh -l”}
SRC=${SRC:-”$USR@$HST”}
## Get Tools
mkdir -p ~/tools/bin
mkdir -p ~/tools/sbin
mkdir -p ~/tools/rbin
mkdir -p ~/tools/dba
mkdir -p ~/tools/etc
mkdir -p ~/tools/man
mkdir -p ~/tools/source
mkdir -p ~/tools/depot
mkdir -p ~/.ssh
## Get ALL
exec 3>all.tar
${RSH} ${USR} ${HST} ‘tar cf – ./.ssh ./.ssh2 .profile .kshrc .hosts .exrc .screenrc tools/bin tools/sbin tools/etc tools/dba tools/man tools/rbin’ >&3
exec 3>&- ; tar xvf all.tar && rm all.tar

But this is only half the battle.  The next problem is to get this script distributed to all the systems you support and to execute it so that your profile is retrieved from a central system to all the systems you will need to support.  To manually do this you would have to login to each system and scp this script to that system, then execute it and answer all the ssh prompts.  A better way is to use a perl script and the Expect.pm module from the central system to automate the login, copy and execution of this script.  You will first need to go to www.cpan.org and get the Expect and IO-Tty perl modules and install them on your systems as most native OS perl distributions do not have these modules.  Instructions for perl module installation may also be found on cpan.

Start your perl script out with a good header for documentation and load your modules. Also setup any global variables in this section.

#!/usr/bin/perl
#
# Header Name: ~/pushprof.pl
#
# Purpose:
#
# Expected Paramters:
#
# Variables:
#
# Tech/Func Leads:
#
# Target Dependencies:
#
# SH Version: $Header$
#
# History:
# 07/11/00 {Your Name} – Script created, Func: None
#
#—————————————————————–
# ————————————-
#| Use/Include Modules |
# ————————————-
use File::Basename;
use Sys::Hostname;
use Shell qw(uname);
use Expect;
use Net::Ping;
# ————————————-
#| Define Header Global Variables |
# ————————————-
## Determine Current Hosts Name and OS
$THISHOST = hostname() ;
$THISOS = uname(“-s”) ;
chomp $THISOS ;
$OS = lc(substr($THISOS,0, 2)) ; ## lower case first two chars
### Global Variables
use vars qw/ %opt /;
$shell_prompt = qr/[\$\#>][>:\s]*\r?$/;

### Local Variables
my ($rc) ;

## Other Script Variables

Then create a section for functions and procedures and it is good practice to have a cleanup procedure and command line processing procedures.  This will give you a good foundation for any other perl scripts you may write in a future and is a template that I have found very useful.

# ————————————-
#| Define Script Functions/Procedures |
# ————————————-
#
# Trap signals and clean up
$Interrupted = 0; # to ensure it has a value
sub CleanUp()
{
syswrite(STDERR, “ouch\n”, 5);
die “\n”;
}
$SIG{INT} = \&CleanUp;
$SIG{TERM} = \&CleanUp;
$SIG{QUIT} = \&CleanUp;
#$SIG{EXIT} = \&CleanUp;
#
# Command line options processing
#
sub Init()
{
my $opt_string = ‘hs:u:’;
use Getopt::Std;
getopts( “$opt_string”, \%opt ) or Usage();
Usage() if $opt{h};
if ( $opt{s} ) {
$host = $opt{s} ;
} else {
Usage();
};

if ( $opt{u} ) {
$username= $opt{u} ;
} else {
Usage();
};

}
sub Usage()
{
print STDERR “
Syntax: $0 [-h] | [-s {host}] ( -u {username} )
-h Help
-s {hostname} Hostname
-u {username} User Name
” ;
exit;
}

We will also need a special subroutine to handle any login prompts that may be encountered.  The expect object, timeout, passphrase and password will have to be passed to this subroutine so that it can reference the expect methods.

sub LoginHandler
{
my $exp = shift;
my $timeout = shift;
my $passphrase = shift;
my $password = shift;
$spawn_ok = 0;
$exp->expect($timeout*2,
[
qr'(yes\/no)',
sub {
$spawn_ok = 1;
my $fh = shift;
$fh->send("yes\n");
exp_continue_timeout;
}
],
[
'-re', qr'(login: $)',
sub {
$spawn_ok = 1;
my $fh = shift;
$fh->send("$username\n");
exp_continue_timeout;
}
],
[
qr/try again/i,
sub {
$spawn_ok = 1;
my $fh = shift;
print $fh "^[\n";
print STDERR "\nSent Break...\n"; ## don't continue to avoid lock out
die "ERROR: password not accepted exiting to avoid lockout!\n";
}
],
[
qr/password.*:\s*\r?$/i,
sub {
$spawn_ok = 1;
my $fh = shift;
print $fh "$password\n";
exp_continue_timeout;
}
],
[
qr/passphrase/i,
sub {
$spawn_ok = 1;
my $fh = shift;
print $fh "$passphrase\n";
exp_continue_timeout;
}
],
[
'-re', qr/\#\s*\#\s*\#\s*\r?$/i, ## match banner and just continue
sub {
exp_continue_timeout;
}
],
[
eof =>
sub {
if ($spawn_ok) {
die "ERROR: premature EOF in login.\n";
} else {
die "ERROR: could not spawn telnet.\n";
}
}
],
‘-re’, $shell_prompt, #’ wait for shell prompt, then exit expect
); ## First expect handle login steps
}

The next step is to code the main subroutine.  I create a main subroutine not because one has to but because I first learned coding in ansi C and I am used to having a main function/subroutine.  I feel that it is also adds a certain level of neatness and form to the code.

# ——————————–
#| Define Main Routine |
# ——————————–
sub Main()
{
# Get Command Line Options
Init();

# Local Variables
my ($rc ); $rc=0;
my $RT=0;

my $password = ‘Password‘;
my $passphrase = ‘PhasePhrase‘;
my $username = ‘UserName‘ if (defined($username));
my $adminhost = ‘AdminHost‘;
my $homedir = “\/export\/home\/$username”;
my $shell_prompt = qr/[\$\#]\s*$/;
my $login = “ssh $username\@$host”;
my $timeout = 120 ;

print STDERR “$login\n” ;

## Test if the host can be ping’d
my $p = Net::Ping->new();
if ( $p->ping($host) ) {
print “Deploying profile to $host \n”;
} else {
print “Seems $host is not reachable \n”;
}
$p->close();

## Start Expect instance and open ssh
my $exp = Expect->spawn($login)
or die “Can’t login to $HOST as $USER:$!\n”;
$exp->log_file(“./pushprof.log”);

## Handle login prompts
LoginHandler($exp, $timeout, $passphrase, $password);

## scp getprof from AdminHost
$exp->send(“scp $username\@$adminhost:$homedir/getprof .\n”);
LoginHandler($exp, $timeout, $passphrase, $password);

## execute getprof
$exp->send(“sh getprof \n”);
LoginHandler($exp, $timeout, $passphrase, $password);

$exp->send(“exit\n”);
$exp->soft_close();
$exp->log_file(undef);

return $rc
} ;

# ——————————–
#| End of Main Routine |
# ——————————–
$rc = Main();
exit $rc

Now we have a script which we can call to push our profile out to any system.  If you want to pass the profile out to more than one system simply put the list into a .hosts file and then use a fore loop calling the pushprof.pl. eg:

for host in `cat .hosts`
do
./pushprof.pl –s $host –u YourUserName
done