Creating TPM Signatures for Multi_sz registry entries

When creating some software signatures for Windows the use of registry entries to identify an application/operating system on a system. If you check out many of the existing Windows signatures, you will see that they use registry entries extensively.

One issue I came across was around the use of multi_sz type registry entries. This came up when scanning a Windows server, the operating system was not defined. In order to define the operating system the following keys were needed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName=Microsoft Windows Server 2003
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion=Service Pack 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductType=ServerNT

And the multi_sz
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductSuite=Blade Terminal Server

For this last key, the Blade and Terminal Server were on separate lines. After looking at other signatures that also used multi_sz, I could not see what was required to separate the lines, so I tried a space, \n and a couple others that never worked.

I then tried the dcmexport command and looked at other multi_sz definitions. They were useless as the character was not a normal ASCII character.

Then I found Windows signatures located in $TIO_HOME/eclipse/plugins/windows-operating-system/xml. In there I found the code & # 1 4 5 ; (remove the spaces) used in existing definitions. I then created the software signature, associated it with the Software Definition Windows Server 2003 Standard Edition SP1 (for lack of a better one for now), ran a scan and the operating system was recognized.

Hope this helps.

TCR Report Packages

Tivoli Common Reporting provides two ways to package your BIRT report design files viz. Report Design Format and Report Definition Format. Both have the same acronym, so we can't abbreviate them.  This article explains the two formats in detail.

Report Design Format

This is the simplest of the two formats. How do you create them?   Simply create a zip file of your BIRT project directory (note! you need to create the zip file of the PROJECT not the ReportDesign file).  That's it. In Windows, you can right click on the project directory and click Send To->Compressed (Zipped) Folder, there you're done!  Import the resulting zip file into TCR and it will import the files with .rptdesign extension as TCR reports. 

The Path to the report design files will be reflected in the TCR navigation tree.  For example, if your report design files are located in /GBSReports/Netcool directory, then the report designs in TCR will appear under GBSReports->Netcool in the TCR Navigation tree. 

Report Definition Format

TCR Documentation does not give good idea about Report Definition Format. Creating Report Definition Format involves creating an XML file that describes the report set structure. The advantage of this format is that you can create a well documented report set and it also provides the ability to share the same report design across multiple levels in the navigation tree.   Even though, this format helps to create a well-documented report set, ironically, TCR does not have a detailed documentation such as details about the XML Schema.   The OPAL ITM62 Report set uses the Report Definition Format and it should give you some idea, but that's all I have come across so far.

Overall, the Report Design Format should be good enough for most of our needs and it is much easier to change the Report set structure as well.  However, Report Definition Format gives more control over Report set organization and one hopes that more information about the format will be available in future releases.

And here's how to use extended attributes in TADDM

UPDATE: Since TADDM 7.1.2 is MUCH friendlier about extended attributes, I changed the title of this post. Details on reporting on extended attributes to come soon.

... you'll want to be able to populate them during discovery. And this requires the use of the SCRIPT: directive in your custom server template. The documentation on this is pretty sketchy, so that's why I'm including a full script here that will set the value of the "FrankCustom" custom attribute for a LinuxComputerSystem.

Prerequisites
1. You must create the extended attribute named FrankCustom for the LinuxUnitaryComputerSystem class (or any class in its inheritance chain).

2. You must enable the LinuxComputerSystemTemplate custom Computer System sensor. You can do this from the TADDM GUI, Discovery drawer, click on Computer Systems, and edit the LinuxComputerSystemTemplate to set it to "enabled".

3. You have to create a file named $COLLATION_HOME/etc/templates/commands/LinuxComputerSystemTemplate with the following line:

SCRIPT:/myscripts/myscript.py

If it's a Jython script you're calling (which it is in this case), the script filename MUST end with a ".py" extension. If you try to use ".jy", it will absolutely fail.

Now, you need to create the file /myscripts/myscript.py with the following contents:



import sys
import java
from java.lang import System

coll_home = System.getProperty("com.collation.home")
System.setProperty("jython.home",coll_home + "/external/jython-2.1")
System.setProperty("python.home",coll_home + "/external/jython-2.1")

jython_home = System.getProperty("jython.home")
sys.path.append(jython_home + "/Lib")
#sys.path.append(coll_home + "/lib/sensor-extensions")
sys.prefix = jython_home + "/Lib"

import traceback
import string
import re
import StringIO
import jarray

from java.lang import Class
from com.collation.platform.util import ModelFactory
from java.util import Properties
from java.util import HashMap
from java.io import FileInputStream
from java.io import ByteArrayOutputStream
from java.io import ObjectOutputStream


#Get the osobject and the result object
os_handle = targets.get("osobject")
result = targets.get("result")
system = targets.get("system")
# two more pieces of information available
#env = targets.get("environment")
#seed = targets.get("seed")

# Execute a command (it's best to give the full path to the command) and
# store its output in the variable named output
output = os_handle.executeCommand("/bin/ls -l /tmp")
s_output = StringIO.StringIO(output)
output_list = s_output.readlines()

# This loop just stores the last line of output from the above command in
# the variable named "output_line"
for line in output_list:
output_line = line
s_output.close()

#Get the AppServer ModelObject for the MsSql server
#app_server = result.getServer()

#Set up the HashMap for setting the extended attributes
jmap=HashMap()
jmap.put("FrankCustom",output_line)
bos=ByteArrayOutputStream()
oos=ObjectOutputStream(bos)
oos.writeObject(jmap)
oos.flush()
data=bos.toByteArray()
oos.close()
bos.close()

#Call setExtendedAttributes on the AppServer
system.setExtendedAttributes(data)


And there you have it. The examples you find in the documentation and on the TADDM wiki just won't lead you to any kind of success because they're missing some very key information.

Feel free to use extended attributes in TADDM

Update: TADDM 7.1.2 has massive improvements in data accessibility, so this post is no longer valid.


Don't let the documentation lead you astray - extended attributes in TADDM should be your LAST CHOICE for customization!

I realize that's a bold statement (especially since there's so much information about creating extended attributes in the documentation), but I'll explain why it's a valid statement:

1. You can't run any reports based on values stored in extended attributes! None. You can say, for example "give me all ComputerSystems where myCustomAttribute contains the string 'foo'". Just can't do it. The only call to get extended attribute values requires the GUID (or GUIDs) of the object(s) you're interested in. This is enough reason to stay away from extended attributes.

2. Extended attributes don't get imported into the CCMDB unless you do a LOT of customization to the TADDM integration adapter.

If you have custom data that you need to store in TADDM, what you need to do is become familiar with the CDM (Common Data Model) and the APIs available in TADDM. They are documented in three different archives that you have to extract (these all exist on your TADDM server):

CDMWebsite.zip - contains information about the CDM, including entity relationship diagrams.
model-javadoc.tar.gz - contains javadoc information for interacting with model objects.
oalapi-javadoc.tar.gz - contains javadoc information for accessing TADDM, from which you may just output XML, or you might obtain references to model objects, whose methods are defined in the above file.

If you're reading these files on your own workstation, make sure to grab a fresh copy from the TADDM server after each fixpack, as Tivoli does update this documentation.

By reading and understanding the documentation above, you can determine the appropriate object types to use to effectively store all of your data.

Getting the TADDM Discovery Client (aka TADDM GUI) to run when you have Java 1.5 and 1.6 installed

Getting the TADDM Discovery Client (aka TADDM GUI) to run when you have Java 1.5 and 1.6 installed

The TADDM GUI uses the Java Web Start technology (i.e. a JNLP file) to run. This allows the application to be launched as a full-screen application (rather than just an applet) over the web. If you ONLY have Java 5 installed , there shouldn’t be a problem. But if you have 1.5 AND 1.6 installed, you’ll probably get an error stating something similar to:

[SunJDK14ConditionalEventPump] Exception occurred during event dispatching:

java.lang.ClassCastException: java.lang.StringBuffer cannot be cast to java.lang.String

at com.collation.gui.client.GuiMain.setApplicationFont(GuiMain.java:511)

at com.collation.gui.client.GuiMain.doLogin(GuiMain.java:442)

at com.collation.gui.client.GuiMain.access$100(GuiMain.java:83)

The reason the problem occurs is that the .JNLP file states that it wants Java 1.5+, which means 1.5 or higher, so javaws will pick the highest one available, which is 1.6. But 1.6 isn't supported by the TADDM GUI. So here's how to fix it.

This file describes what has to be done to fix the problem. I apologize for the PDF link, but trying to get all of the screenshots uploaded was driving me crazy.

Java Info

Java versions are even more confusing than you think they are, so I wanted to clear up at least a little of it here.

Java 1.4.2 is also called Java 2 Platform Version 1.4.

Java 1.5 is also called Java 5

Java 1.6 is also called Java 6

Java 1.5 (aka Java 5) introduced a LARGE number of features that aren't available in version 1.4.2. And from what I've found, it's pretty difficult to have both Java 1.5 (or 1.6) and 1.4.2 installed on the same system. If you NEED to run some apps that require Java 1.4.2 (like the TEP desktop client, for example) and some apps that require Java 1.5, I would truly create a separate Windows virtual machine (using the virtual machine software of your choosing, though I would recommend VMWare) to run version 1.4.2.

After 1.4.2, however, it really appears (so far) that you can install the different versions on the same machine AND have them play well together. My next post will have some information about this.

If some piece of software states that it requires Java 1.5, that *should* mean that the JDK or JRE with a version number of 1.5.0_xx, where xx is the Update Number, will work; it's not guaranteed, but in my experience, it does NORMALLY work. Similar is true for Java 1.6 - version 1.6.0_xx *should* work.

What's the difference between the JDK and JRE

The JRE (Java Runtime Engine) is what most people need. It contains the java executable and all of the other executables that are needed to run Java clients, but it does NOT contain any of the executables needed to WRITE and package Java applications (i.e. javac and jar, among others).

The JDK (Java Developer Kit) contains all of the JRE, plus all of the developer tools needed to write and package Java applications.

What about SE and EE variants?

SE (Standard Edition) and EE (Enterprise Edition) are used to distinguish between types of developer environments.

SE is for creating client applications that will run inside a standalone JVM (Java Virtual Machine) on a user's local machine. Applets and Java Web Start applications, though they are accessed over the web, are examples of applications created using the SE developer kit.

EE contains all of the SE, PLUS it allows a developer to create applications that will run inside an application server, such as WebSphere, WebLogic, JBoss, Oracle App Server, and many others. These applications actually run on a JVM on a server. A user connects to that server to access the application, but the Java application itself is using CPU cycles on the server.

What's Java Web Start

Java Web Start (JavaWS) is a technology that allows application developers to create a web-launchable Java application directly from the browser. A Java Web Start application is defined in a .JNLP file (which is just a text file, so you can open one up to look at it), and is launched using the javaws executable. This is different than an applet in a few ways:

1. An applet generally runs inside the browser itself, or it can open a new window in which it runs *seemingly* outside of the browser. I say "seemingly" because if you close the browser, the applet will still die. Any windows opened by the applet are child windows of the browser and will automatically be closed when the browser is closed. A JavaWS application's control file (the JNLP file) is downloaded by the browser, but is then launched by the javaws executable. So if you close the browser, the application won't close.

2. A JavaWS application is a completely standalone application, which has full control over menus, windowing elements, look-and-feel, etc. of itself. An applet is constrained by the browser in several ways. (This difference is mainly interesting to developers, but I think it's useful for users to be aware of).

3. A JavaWS application can be launched outside of a browser; you can just double-click the javaws executable (or a .JNLP file, for that matter) to launch a JavaWS application. An applet MUST be launched in a browser.

Where to get Java

Sun Java:

ANY VERSION older than the current version: http://java.sun.com/products/archive/index.html

Current Update of 1.5: http://java.sun.com/javase/downloads/index_jdk5.jsp

Current Update of 1.6: http://java.sun.com/javase/downloads/index.jsp

IBM Java:
Links to different platforms and versions: http://www.ibm.com/developerworks/java/jdk/

Converting TDW Timestamps to DateTime in BIRT

We have previously published articles on how to convert TDW timestamps to "regular" timestamps in DB2. In BIRT, you may need to tackle the same problem again. The TDW timestamps can not be used for DateTime arithmetic and Charting functions in BIRT and has to be converted to regular DateTime. Though you can use the SQL to convert these timestamps to regular, in some cases, you may want to use the JavaScript integration of BIRT to convert them as well. Here is how to do it.

1. In your BIRT data set, ensure that you're selecting the TDW Timestamp that needs to be converted to the regular timestamp.
2. In the "Edit DataSet Window", click on Computed Columns and Click New button.
3. Give the column name for the new Computed Column, select the column data type as "Date Time".
4. In the expression field, click on the fX button and enter the following JavaScript code. Replace row["Timestamp"] with the appropriate Column name for the TDW Timestamp.

if (row["Timestamp"] == null)
{
null
}
else {
new Date(
(candleTime=row["Timestamp"],
(parseInt(1900) +
parseInt(candleTime.substr(0,3))) + "/" +
candleTime.substr(3,2)
+ "/" + candleTime.substr(5,2) + " " +
candleTime.substr(7,2) +
":" + candleTime.substr(9,2) + ":" +
candleTime.substr(11,2)
))
}

5. Goto the Preview Results and ensure that the newly Computed Column appears in the output.

This is the kind of method that ITM 6.2 built-in reports use and hope you find it useful.