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 TADDM 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 TADDM user ID that starts the TADDM server. In addition, if you are using a TADDM 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:
You see this error even though the sudo command works successfully for the2008-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
run_as
user from the command line. - Solution
- Complete the following steps:
- Type the OS command
visudo
to edit the /etc/sudoers file - Once the file opens, comment out the line
Defaults requiretty
. - Save and close the file.
- Type the OS command
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:
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.QETH_OPTIONS='fake_ll=1'
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:
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.OPTIONS='fake_ll=1'
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.
Need enhanced Stack Scan sensor debugging
- Problem
- Need to enable enhanced debugging of the Stack Scan sensor.
- Solution
- Complete the following steps:
- Check the local-anchor-<machine>.log file to see if Nmap was used by the sensor.
- 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 fails with a message: sudo: sorry, you must have a tty to run sudo
- Problem
- During a discovery, if the Discovery Management Console where the TADDM server was started is closed, the sensor fails. The message: sudo:sorry, you must have a tty to run sudo is displayed. If you start the Discovery Management Console and leave it open the sensor works.
- Solution
Comment out or delete the
Defaults requiretty
line from the /etc/sudoers configuration file on the TADDM server.
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 TADDM 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:
In the Nmap folder a core file is created during the discovery.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:/taddm/cmdb/dist/nmap/nmap-4. 76/nmap[25]: 708778 Segmentation fault(coredump)
- 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 valuenmap
. For example, the new value isnmap -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 TADDM database are not updated. Delete the computer systems manually and run discovery again.
Stack Scan sensor never updates CI objects already stored into TADDM 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 TADDM. Thus, the CI Computer systems that are already present in the TADDM database, are not updated by the StackScan sensor in case of any changes. Until now, the only possible action for TADDM 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 TADDM 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