ITNM 3.8 NMAPScan Agent

Recent updates to IBM Tivoli Network Manager 3.8 introduced a new discovery agent that utilizes Nmap (Network Mapper) to provide some extra details about devices without SNMP access or certain types of end nodes. The extra information includes operating system type based on nmap’s OS fingerprinting capability along with port and service information.

This sounds great, but there are some serious drawbacks…

A. It’s slow. It’s a typical ITNM perl based agent that handles parallelism by spawning more instances of nmap to scan individual hosts rather than utilizing the large volume scanning capabilities inherent to nmap.

B. The required version of nmap is 4.85 and most enterprise *nix platforms are still shipping 4.0-4.11 so chances are you will need to acquire a recent version from the Nmap project page (http://nmap.org).

C. You can’t just turn the agent on. After you get an appropriate version of nmap installed you have to edit $NCHOME/ precision/disco/agents/perlAgents/ NMAPScan.pl to uncomment and set the path to nmap :

my $nmapBinary = '/usr/bin/nmap';

D. Running ITNM as setuid root does not work with the default nmap arguments. If you do not want your ITNM processes running as root you will need to adjust the scan settings in NMAPScan.pl or chown root ncp_disco_perl_agent then chmod u+s ncp_disco_perl_agent and then modify root’s environment so that the ITNM perl is used rather than the system perl. Or you could just run as root.

E. The OS type value is really just a guess. Sometimes it is a little off. For example CentOS 5 indentified as Gentoo.

F. Did I mention that it is slow?

Here are some screen shots of examples of the information collected.

So what would be a good use of the NMAPScan agent? For starters it would help classifying NoSNMPAccess devices.

Consider this AOC file that defines the class Linux_NoSNMPAccess:

//*************************************************************

//

// File : Linux_NoSNMPAccess.aoc

//

//*************************************************************

active object 'Linux_NoSNMPAccess'

{

super_class = 'NoSNMPAccess';

instantiate_rule = "ExtraInfo->m_OSType LIKE '.*Linux.*'";

visual_icon = 'NoSNMPAccess';

};

With this solution it is possible to create buckets to dump your devices into to provide the ability to at a minimum do ping polling via a class filter without pinging stuff you could care less about.

Adding web pages to WebTop/TBSM/ITNM

You can add any web page you want to be protected by WebTop/TBSM by putting that file under the directory:


INSTALL_DIR/tip/profiles/TIPProfile/systemApps/isclite.ear/Webtop.war/

accessed via:

https://hostname:16316/ibm/console/webtop/filename

Now, where it gets pretty exciting is that WebTop 2.2 and above are hosted on WebSphere, a full-fledged app server, and it supports JSP pages (which basically let you write server-side Java code to do anything you want, PLUS output HTML). An example JSP file can be found here:

http://www.java2s.com/Code/Java/JSP/Printtherequestheadersandthesessionattributes.htm

Just put that file into the above directory and you'll see all of the session and request information available to your JSP.

Have fun.

Tivoli Common Reporting 1.3 - Framework Manager Installation

The latest and greatest TCR product, as previously noted, contains both BIRT and Cognos reporting engines and you are free to develop reports in either one of those formats.  To develop custom reports in BIRT, you need to use the Eclipse based report designer. How about Cognos?   For Cognos, you should be able to develop reports using the browser based Report Studio tool.  End users with right permissions should be able to modify the reports according to their needs.  However, there is one limitation.   The Report Studio tool can operate only on already published Cognos packages.  So, the question is, how do you publish new packages containing data model for your reports?   That is where the Framework Manager comes into picture.    Framework Manager lets you define your own data sources, Query Subjects, etc.  and package these definitions into a Cognos package, which will be published on the TCR server.

 

Prerequisites

 

Before installing Framework manager, you will need the following.

 

1.       A Windows box to install framework manager. IT is NOT supported on other operating systems.

2.       Necessary ODBC data sources or Database client software installed  on the Windows system.  You can't use JDBC type-4 drivers.  

 

Installation and Configuration

 

Installing Framework manager is pretty straight-forward. The installation media contains a separate folder named "CognosModeling". You basically run the issetup.exe from win32 subdirectory to install it.    However, you need to perform couple of easy post install configurations to get the product to work.   The steps are given below.

 

1.       Bring up the Cognos Configuration under Programs->IBM Cognos 8->IBM Cognos Configuration. Note: There is another "IBM Cognos Configuration" under Tivoli Common Reporting.  Do not make changes to it as it will break the TCR product.

2.       Select the Environment Group under Local Configuration.

3.       Change the Gateway URI property to https://<tcrserver>:16316/tarf/servlet/component

4.       Change the "Dispatcher URI for external applications" to http://<tcrserver>:16315/tarf/servlet/dispatch

5.       Again the above values for default TCR installation (assuming 16316 is HTTPS and 16315 is HTTP). You can double check by bringing up the "IBM Cognos Configuration" under Tivoli Common Reporting and comparing the property values for "Gateway URI" & "External dispatcher URI" with the above values. 

 

Once you configured these values, you should be able to bring up Framework Manager, create a new project and signin with your TIP id (e.g. tipadmin) to create your custom data model.

 

Hope this helps.

Getfile, Putfile, Executecommand - added in ITM 6.2.2 fp02

Enable this functionality (Check out Venkat’s earlier post)

GETFILE:

{-m|--system} SYSTEM
{-s|--source} REMOTE_FILE
{-d|--destination} LOCAL_FILE
[{-t|--type} Transfer MODE] - Either [text|bin]
[{-f|--force}] – Forces an overwrite of the file if it exists

Example:
tacmd getfile -m itmtest:LZ -s /tmp/itmtest.log -d /base_logs/itmtest_08272010.out -t text –f
--------------------------------------------------------------


PUTFILE:

{-m|--system} SYSTEM
{-s|--source} LOCAL_FILE
{-d|--destination} REMOTE_FILE
[{-t|--type} MODE] ] - Either [text|bin]
[{-f|--force}] – Forces an overwrite of the file if it exists

Example:

tacmd putfile -m itmtest:LZ -s /automationscripts/ testing.sh -d /tmp/testing.sh -t text –f

NOTE: When transferring the file, it sets the permissions of the file to “666”.

--------------------------------------------------------------


EXECUTECOMMAND:
tacmd executecommand

{-m|--system} SYSTEM
{-c|--commandstring} COMMAND_STRING
[{-w|--workingdir} REMOTE_WORKING_DIRECTORY}]
[{-o|--stdout}]
[{-e|--stderr}]
[{-r|--returncode}]
[{-l|--layout}]
[{-t|--timeout} TIMEOUT]
[{-d|--destination} LOCAL_STD_OUTPUT_ERROR_FILENAME]
[{-s|--remotedestination} REMOTE_STD_OUTPUT_ERROR_FILENAME]
[{-f|--force} FORCE_MODE}
[{-v|--view}]

Example:

tacmd executecommand -m itmtest:LZ -c "/tmp/testing.sh" -o -e -r -l –v


NOTE: You will need to parse the STDOUT from this command to get the local STDERR, STDOUT, Return Code etc…

Tivoli Common Reporting 1.3 Overview

The Tivoli Common Reporting product introduced about 3 years back now  fills in the reporting requirements for various Tivoli products. It is tightly integrated with various Tivoli products such as Tivoli monitoring, Maximo, Tivoli Provisioning manager and access manager. A new version of this product is available now called Tivoli Common Reporting for Asset and Performance Management 1.3.  

 

I personally think the version number increment is misleading. This product introduces a number of changes and features that should warrant a 2.x instead of 1.x.  Anyway, here are few notes about this TCR product.

 

Report Engine

 

The TCR 1.3 product uses two report engines for report generation. The BIRT engine (2.2.1) used by the older TCR product is continue to be available in the newer version as well.  The reports developed using TCR 1.1.x or 1.2 will work correctly.   However, this version of  TCR product also gives you additional choice to develop reports using Cognos.  There are some very cool features available in Cognos reporting such as on-the-fly report creation by end users,  browser based report studio to design reports, etc.  While the Cognos reporting is powerful, it also introduces own complexities such as separate data modeling phase and additional components for report  design and generation.

 

Distributed Installation

 

The new TCR product supports distributed installation meaning TCR components (especially Cognos related components) can be installed over multiple systems for better performance.  If you have an existing Cognos setup, TCR can be integrated with your Cognos BI setup to leverage the expertise you already have.

 

Cognos Components

 

In addition, the Cognos piece introduces quite a  few additional components such as Framework Manager for data modeling, Report and Query Studio for report and query design,  Cognos Admin page for administering Cognos report packages, etc.   Please stay tuned for an upcoming article on Cognos Reporting for more details on the Cognos BI Reporting terminology. 

 

Report Emailing and Scheduling

 

While Report Scheduling feature is available in TCR 1.2, the new version provides a report emailing feature as well. However, the feature is limited to ONLY Cognos reports. With Cognos, you can even schedule AND email the reports periodically, a very powerful and useful feature.  This feature is not available for BIRT reports but can be custom developed for BIRT reports using scripting. 

 

Please stay tuned for more articles related to TCR 1.3 and Cognos.

BIRT Tip: Dependent Parameters in your reports

In BIRT, using report parameters is the highly powerful (and easy!) way to customize the report according to the end user needs. Report parameters provides runtime values such as start and end dates for reports, specific item for which report needs to be run, etc based on the user input. While this is very useful, some of the reports may need multiple parameters that have dependent relationship among them. For example, if your report needs to list Customers in a specific state in a specific country, the "regular" report parameter will not meet your requirements because you will need to "dynamically" adjust the list of states available for selection based on the Country that the user chooses. How can you do this in BIRT? Read on.

In BIRT, you will need to use the "Cascading Parameters" to define the relationship between the parameters. Continuing the above example, let us take the CUSTOMERS table in BIRT CLASSICMODELS sample database.

1. Create a new dataset called COUNTRIES to select all unique Country information. e.g. A sample SQL is "SELECT distinct COUNTRY from CUSTOMERS".


2. Create a new dataset called StatesInCountry to select all unique State information for a given country. e.g. A Sample SQL is "SELECT distinct STATE from CUSTOMERS WHERE COUNTRY = ?". Leave the parameter binding for the first parameter (param_1) to NONE for now. We will change it later.


3. Create a new Cascading Parameter Group called "paramStates". Choose "Multiple Dataset" option as we will have to select information from two datasets created above.


4. Click on Add Button on the "New Cascading Parameter" dialog to add a new Cascading parameter. Enter the name for the cascading parameter as "paramCountries", choose COUNTIRES dataset created in Step1 as the dataset and select the "COUNTRY" fields for value and display text.


5. Click on Add button again to add the state cascading parameter. Enter the name for the cascading parameter as "paramStatesInCountry", choose the StatesInCountry dataset created in Step 2 as the dataset and select the "STATE" field for value and display text.


6. Click Ok to close "New Cascading Parameter" dialog. Please see the attached screenshot containing the Cascading Parameter Group information.
   
   


7. Now edit the StatesInCountry dataset created in step 2, goto Parameters section, edit the param_1 parameter binding and set the LinkedToReport Parameter value to the "paramCountries" cascading parameter created in step 4. Click ok to save the changes.

Now your reports are ready to use the cascading paramters. If you run the report now, whenever you change the COUNTRY in the parameter selection, the available STATE selection also changes accordingly. The attached screenshots show the State information for USA and Australia.

PS: It is easier to do these things in BIRT than telling how to do them. I have tried my best to describe the steps involved. If you have questions or need clarifications on the above steps, please feel free to write to me.

5 Things You Didn't Know About Java series from Developerworks

This is part 2, on Performance Monitoring. It's dealing with newer releases, so it won't be directly applicable to all environments, but I think it's very useful information:

http://www.ibm.com/developerworks/java/library/j-5things8.html?ca=drs-