All probes released after OMNIBus 7.3 GA are in 7.3 format. Those probes can be installed onto 7.3 via $NCHOME/omnibus/install/nco_install_integration tool. if you want to use the same package to install the probe on 7.2 you need to do:

1. unzip the package.2.find the full path that contains the patch3. install the patch,using $NCHOME/omnibus/install/nco_patch

There are three server component in
OMNIBus that can be configured to use PAM authentication, Process
Agent, Objectserver and Gateways.information about how to configure
PAM authentication for Process Agent (nco_pad) and Objectserver
(nco_objserv) are very well documented in OMNIBus Administration
Guide, however, if you follow the Gateway documentation and try to
configure PAM for Gateways, you will end up with no success.

The general configuration steps for
this task are:

1. Configure Gateway to use PAM
authentication.

2. Create PAM module for Gateway.

The first step is documented in the
Gateway and Probe Guide. What you need to do is to configure
following two properties in gateway propsfile:

The second step is not mentioned by
Objectserver Gateway Guide(pre 7.3), or with wrong information(7.3).

Common sense applies here, as we know
from PA and Objectserver need to have their PAM module configured, we
must need similar thing for Gateway. the PAM module for PA and
Objectserver are 'netcool' and 'nco_objserv' respectfully, but what's
the PAM module for gateways?

OMNIBus 7.3 Gateway and Probe Guide
says it uses module 'netcool', that means no extra configuration is
needed as this module should already be configured when we configure
PA. However, when we try to login into gateway using nco_sql we get
an authentication failure.

To find out which PAM module does a
gateway use, we can use strace on linux(or truss on
Solaris/AIX).

following are steps I used on linux in
order to find the exact module name used by a particular gateway:

1. Configure the gateway to use PAM
authentication, start the gateway as normal, find the PID of the
gateway.

The trace file looks very complicated
unless you are a programmer, however we don't need to understand
every bit of it to do some basic trouble shooting. In this case we
know that we are trouble shooting a pam issue and on linux the pam
configuration files are in /etc/pam.d/ directory.

we can see that the bi-directional
gateway tried to open file /etc/pam.d/nco_g_objserv_bi and failed
with error message "-1 ENOENT (No such file or directory)",
from this we can guess that the PAM module for the bi-directional objectserver gateway is nco_g_objserv_bi, which is different with documentation.

This technique can be used on any
Netcool Gateways, for example I find the PAM module for EIF gateway
is called nco_g_tivoli_eif using exactly the same technique.so far we can guess that the PAM module name is same as the gateway binary name.

6. once we find the exact name of the
PAM module for the gateway, we can just create the module by copying
passwd module, make sure the netcool user can read this file:

Most of Netcool product installer now come with Prerequisite Scanner, which analyzes system environments before the installation or upgrade of a Tivoli product or IBM solution... it is a great tool however it may reports empty result as below:

It is recommended to review the Prerequisite checking results before proceeding... With empty output there is no way you can find if the check is successful.

The most common reason is because 'ksh' is not installed... Prerequisite checking tool use ksh as the default script and by default ksh is not installed on most OS except AIX.

To fix this please install ksh before starting the installation process... Ideally ksh should be listed as required package in product installation guide.

I had some trouble recently connecting nco_p_alcatel_sam_5620_v8 to a SAM instance in a controlled environment . although the probe connect to SOAP port fine and get can existing alarms, it fails to connect to the JMS port, which is for sub-sequential alarms. the same probe with same setting works fine if the probe and SAM is in one LAN. so this must be a firewall issue.

I used tcpdump to capture all traffics on the good probe, and found all the ports that the probe has send a SYN on, they are:

8443 or 8080 depending on if HTTPS or HTTP is used.109910981097109680938094

If you use default settings, ITNM 4.1 will install OMNIBus , ITNM core, TIP and DB2 configure auto-start for those components... Auto-start works for all components except DB2, which result in ncp_model and a number of key components fail to start:

To fix this issue, if the operating system is Redhat 5, the latest fixpack for DB2 10.1 should be applied..At the time of writing, the latest fixpack for 10.1 is FP3... Download links can be found below:

The out-of-box tool 'ping from server' doesn't work on Redhat Linux. If you have this problem you need to do following:

1. the default tool is configured to use /opt/IBM/tivoli/netcool/omnibus_webgui/etc/cgi-bin/nco_ping.cgi , which is for UNIX system other than linux, so the first thing you need to do is to replace the nco_ping.cgi file with nco_ping_linux.cgi.

2. the nco_ping_linux.cgi uses /usr/sbin/ping, which doesn't exist on Redhat V6. find where is 'ping' program located then put the fullpath in the cgi script. line 86.