Troubleshooting the sensor

This topic describes common problems that occur with the Stack Scan sensor and presents solutions for those problems.

The Stack Scan sensor completes successfully, but no Computer Systems are stored

Problem
Doing a Level 1 discovery, the Stack Scan sensor finishes without errors, but it does not store any computer system information. In the services/DiscoveryManager.log, you see the following message: 
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]  
WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM   invocation failed: 
sudo: sorry, you must have a tty to run sudo  
From the ASM server command line you can successfully do an 	
su - <run as user>
and then
sudo "nmap -0 10.1.2.3
Solution

For non-windows platforms, give root authority for all commands to the Agile Service Manager user ID that starts the Agile Service Manager server. In addition, if you are using a Agile Service Manager anchor server, give root authority to the discovery service account on the anchor server. See Configuring Nmap for details.

The Stack Scan sensor does not discover Computer Systems on a Linux system

Problem
On a Linux® server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored.
In the services/DiscoveryManager.log, the following message can be seen: 
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]  
WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM   invocation failed: sudo: sorry, 
you must have a tty to run sudo
You see this error even though the sudo command works successfully for the run_as user from the command line.
Solution
Complete the following steps:
  1. Type the OS command visudo to edit the /etc/sudoers file
  2. Once the file opens, comment out the line Defaults requiretty.
  3. Save and close the file.

The network configuration on Linux for System z systems does not create packets that Nmap can read

Linux for System z® supports both OSA and VSWICH network interfaces operating in Layer 3 (Network Layer) or Layer 2 (Link Layer) mode. If operating in Layer 2 mode, TCP packets contain a valid ethernet Link Layer header required by Nmap. However, systems using OSA or VSWITCH operating in Layer 3 mode require adding the QETH_OPTIONS='fake_ll=1' to the hardware configuration file for the interface. The following section describes how to modify the hardware configuration file enabling Nmap to operate with Layer 3 network interfaces.

For more information about OSA and VSWITCH and their operating modes, see Chapter 7 qeth device driver for OSA-Express (QDIO) and HiperSockets in the Linux on System z Device Drivers, Features, and Commands at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf.

Problem
The network configuration on Linux for System z systems does not create packets that Nmap can read.

The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery. If Nmap is not working properly, the Stack Scan sensor does not store any computer systems.

Although the sensor runs without errors, the Linux for System z system that is running the Stack Scan sensor returns the following message: 
stored - 0 ComputerSystems in the database
If you type the nmap <hostname> command for any system other than the local host, the following message is displayed: 
Note: Host seems down. If it is really up,
but blocking our ping probes, try -P0...
Solution
Depending on your operating system, perform the following actions:
On SUSE Linux for System z systems
The network must run with the following option: 
QETH_OPTIONS='fake_ll=1'
Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses.

The configuration file must be in the /etc/sysconfig/hardware directory. The file name might be hwcfg-qeth-bus-ccw-0.0.5000.

On RedHat Linux for System z systems
The network must run with the following option: 
OPTIONS='fake_ll=1'
Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses.

The configuration file must be in the /etc/sysconfig/network-scripts directory. The file name might be ifcfg-eth0.

Verify that the alias in the /etc/modprobe.conf file includes the following information:
alias eth0 qeth

Computer system displays in the incorrect category

Problem
The computer system displays under the OtherComputerSystem category.
Solution
Check the OS type. If it is correct, check the confidence. If the confidence is below the confidence threshold value (the default is 40), then what you are seeing is expected.
You can change the confidence threshold to have the computer system appear under the correct category. The threshold is configured 0 - 100. The threshold can be set using the sensor configuration attribute: confidenceThreshold.

Need enhanced Stack Scan sensor debugging

Problem
Need to enable enhanced debugging of the Stack Scan sensor.
Solution
Complete the following steps:
  1. Check the local-anchor-<machine>.log file to see if Nmap was used by the sensor.
  2. Enable further debugging by doing the following:

    In the collation.properties file, set one of the following:

    • com.collation.log.level.StackScanSensor=TRACE
    • com.collation.log.StackScanSensor=TRACE
    • com.collation.log.level=TRACE

    This method produces a verbose trace of what the sensor is doing, the results, the configurations used, and more.

Stack Scan sensor is unable to run the sudo nmap command

Problem
The Stack Scan sensor fails with the following error message: "Sorry, sudo has been configured to not allow root to run it." However, you can successfully run sudo nmap at a command line.
Solution
This problem occurs when the system is configured not to allow the root user to run the sudo command. To fix the problem, edit the collation.properties file and set the com.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor property to true. Then restart the Agile Service Manager server.

The Stack Scan sensor does not discover Computer Systems on an AIX system

Problem
On an AIX® server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored.
In the services/DiscoveryManager.log, the following message can be seen: 
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]  
 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223]
)]  DEBUG stackscan.ExecCmd - standard err:/asm/cmdb/dist/nmap/nmap-4.
76/nmap[25]: 708778 Segmentation fault(coredump)
In the Nmap folder a core file is created during the discovery.
Solution
Create a discovery profile or edit an existing profile for the Stack Scan sensor. In the Configuration section of the Create Configuration window, click nmapExec. Then double-click the Value field in the row, and append -d to the value nmap. For example, the new value is nmap -d.

After you enable winscanner some of the discovered ComputerSystems have the signature with no MAC address.

Problem
A custom Level 1 discovery is run with only the nmap scanner enabled. Then, another discovery is run on the same scope with both nmap and winscanner enabled. Discovered computer systems have signatures with no MAC addresses.
Solution
The Stack Scan sensor stores information only about those target systems that are not discovered yet. Computer systems that are already present in the Agile Service Manager database are not updated. Delete the computer systems manually and run discovery again.

Stack Scan sensor never updates CI objects already stored into Agile Service Manager DB during Level 1 discovery

Problem
During a Level 1 discovery, the Stack Scan sensor stores information exclusively (bold) for those new IP objects systems that are not discovered yet and this is as per the way the Level 1 Discovery is designed in Agile Service Manager. Thus, the CI Computer systems that are already present in the Agile Service Manager database, are not updated by the StackScan sensor in case of any changes. Until now, the only possible action for Agile Service Manager to be able to update the stored CI objects, that were discovered and stored as fake "shallow" objects initially during first time Level 1 discovery is to delete the computer systems manually and then run the discovery again, or even run a Level 3 discovery.
Solution
A new feature has been introduced into FP4 to avoid the Agile Service Manager creation of fake "shallow" objects that usually occurs when you got pingable IP addresses without a corresponding system (creation of low OS confidence shallow ComputerSystems).
com.ibm.idd.stackscanner.confidence.skip=default 0