• Loading...
This documentation refers to a previously released version of BMC Atrium Discovery (other versions).

Troubleshooting and Debugging Tips

Skip to end of metadata
Go to start of metadata
Space Search

Searching TWF 7.2

Table of Contents

This section is intended as a summary of how to troubleshoot and debug Tideway Foundation. It contains the following sections:

  • Log Locations
  • UI Tracebacks
  • External Slaves

Log Locations

When you are looking for logging output from Tideway Foundation the following locations may be helpful:

Debug Log Files

These log files should be the starting point for finding debugging information. They are produced by each running component of the system as well as some of the miscellaneous scripts and can be found in:
/usr/tideway/log
These logs are produced using the standard python logging module. An example of a line produced by one of the tideway components is shown below:
46912496181184: 2006-04-06 18:31:44,572: model.datastore.main: INFO: DataStore Main initialised
This line can be broken down into the following sub-components:

  • 46912496181184 – The thread ID of the thread that called the logging module.
  • 2006-04-06 18:31:44,572 – The timestamp of the message that was written to the log.
  • model.datastore.main – The python file where the logging call originated.
  • INFO – The log level associated with the message. This can be one of the following:
    • CRITICAL – Something unexpected has happened.
    • ERROR – Something expected has happened, but it was handled.
    • WARNING – Something sub-optimal has occurred.
    • INFO – This is just information.
    • USEFUL – Used to output the startup information to the log file.
    • DEBUG – This is a low-level debug message.
  • DataStore Main initialised – The actual logging message. 
    When you see a CRITICAL log message it normally indicates that there is a bug. A CRITICAL log message can be followed by a python stack trace. For example:
1220540768: 2006-01-28 00:06:12,707: discovery.device: CRITICAL: Host::getProcessList() for 169.24.189.103 -- UNEXPECTED EXCEPTION
Traceback (most recent call last):
File "./device.py", line 327, in getProcessList    return self.proxy_.getProcessList() 
File "./host.py", line 685, in getProcessList  
File "./host.py", line 1549, in queryProcessList  
File "./solaris.py", line 627, in parsePsOutput
KeyError: 'pid2'

The *.out Files

Each running component in the system captures anything that gets sent to stderr and sdtout and logs it to a file. These files are all of the form <bin script name>.out and are also stored in the following directory:
/usr/tideway/log
Any *.out file that has a non-zero file size is generally an indication that something has gone awry. However, there are some exceptions to this rule.
For example, the tw_appserver.out files are always non-zero, as the appserver sends certain Webware information to stdout. This means that you need to read the contents to check for any errors that may be in there.
Also, on shutdown any component may send a traceback to its .out file.

UI Tracebacks

Whenever the appserver component experiences a traceback you are presented with an error message. When this happens the UI is obscuring a detailed traceback page which may contain useful information that can assist you with troubleshooting and debugging activities.
The appserver saves the entire html page that is being hidden above as a self-contained *.html file that can be opened in a browser. These files are stored in the following location on the appliance:
/usr/tideway/python/ui/web/ErrorMsgs
You can manually delete these files from the Appliance command line.

Java UI Tracebacks

Where a traceback is produced by a Java component, the information contained is simply the Java exception that has been thrown. You can use this to search for the exception in the log for that component. The logs are:

  • Visualizations log – tw_deptree.log
  • Lifecycle Management UI log – tw_lifecyclemanagement_ui.log

External Slaves

If you have installed an external slave and it fails to connect, there are a number of checks that you should make before contacting Tideway Customer Support.

Check the SSL Keys

In order for the slave to communicate with the appliance both ends require the presence of a certificate authority file and an SSL (Secure Sockets Layer) key file.
The appliance needs the following:

  • ca_01.pem – The certificate authority.
  • appliance_key_01.pem – The key for the appliance.

The Slave needs the following:

  • ca_01.pem – The same certificate authority file as the appliance, copied to the slave.
  • slave_key_01.pem – The same key file as the appliance, renamed and copied to the slave.

Check the following:

  1. The files exist at both ends in the corresponding ~/etc directories.
  2. The files were present at the time that the process started.
  3. The certificate authority on both the appliance and the slave are the same.
Check the omniORB.cfg File

Check the omniORB.cfg file for the correct serverTransportRules. The external Active Directory and Workgroup slaves do not register with the appliance NamingService. This is so that a single external slave can be used by more than one appliance. However, in order to ensure that only certain appliances can connect, CORBA serverTransportRules are used to restrict the permitted incoming calls.
These rules are added in the omniORB.cfg file which by default is created in C:\omniORB.cfg. By default, for Workgroup and Active Directory slaves this file will contain the following line:

serverTransportRule = localhost ssl

For external slaves this file contains the following line by default:

InitRef = NameService=corbaname::1.2@appliance_IP_address

This is designed to ensure that a clean install is secure and only tcp connection from the localhost is permitted. However, this does mean that no other connections will be permitted, so in order for the appliance to communicate with the slave you will have to do one of the following:

  • Delete the omniORB.cfg file or ensure that it does not contain any data. This means that any appliance can then use the slave.
    or
  • Add the correct serverTransportRule. Ensure that you delete the default one as they are evaluated in order.
Check the Corba EndPoints

When you run the slave on a host with more than one IP address, it has to select which address to listen on. By default it will choose the one that is listed first in ipconfig. However, this may not always be accessible from the appliance. To avoid this issue, ensure that you have set the following in the HKEY_LOCAL_MACHINE\SOFTWARE\Tideway\DISCOVERY\<slavetype>SLAVE\CommandLine value:
-ORBendPoint giop:ssl:<ipaddress>:<port>
Where the ipaddress is the IP address of the slave that is accessible from the appliance.

FAQ

What is the performance impact of running Tideway Foundation?

Running Foundation should minimally impact your environment – the discovery techniques used are non-intrusive, lightweight and agent-free.

What can Tideway Foundation discover in the network?

Tideway Foundation is IP-based and can discover any host system with an IP connection including servers, workstations, network nodes, printers, wireless access points – even mainframes that have an IP connection. It uses a wide range of discovery techniques to discover software running on these hosts and the network connections between that software.

What discovery techniques do you use?

Foundation uses a range of discovery techniques where appropriate. These include:

  • Network scanning (looking for services on well-known TCP and UDP ports on IP-reachable machines).
  • Remote command execution (looking at specific processes running on each node, querying package managers and querying established inter-process communications mechanisms).
  • SNMP (MIBs provide a rich source of management information).

Will any network security need to be disabled for the discovery process?

Obviously the Foundation appliance needs to be able to reach areas of the network in order to discover hosts. However various methods of providing secure access are possible without disabling firewalls and access control policies, including using VPN tunnels and using slave Foundation appliances. Some IDS systems may identify certain activities (such as port scans) as suspicious.

What is the impact of my applications running on platforms that are not supported by Tideway Foundation?

Our discovery process will identify endpoints on such computers if they are visible from other hosts. You will need to complete details of programs running on them manually, though it may also be possible to categorize some of the components of the applications running on the unsupported platform either by which port it, or its counterpart, is listening on.

Can the product introduce any risk into my network or application infrastructure?

In providing a clear picture of your total IT infrastructure, Tideway Foundation will actually reduce risk in your network by allowing you to weed out rogue elements that do not meet corporate policy, are out of date or provide potential security holes.
The Tideway Foundation discovery process uses standard techniques that should not de-stabilize elements of the infrastructure.
Since of course there are always risks with deploying new technology, Tideway's implementation plan involves analyzing areas of potential risk and achieving the right balance of risk and reward. Tideway's test plan is also aimed at minimizing risk – ideally including testing in the customer's test environment.

Do I need to install any software on other computers?

The Tideway ethos is agent-free management – we do not believe the logistical challenges associated with having an agent on every node is justifiable, so no Tideway-specific software needs to be installed on other computers. The Tideway Foundation user interface is entirely web-based.

Why is agent-free discovery so important?

Agent-based discovery relies upon a level of control of asset deployment that does not exist in most businesses. It also implies a significant cost overhead to maintain agents on each platform, including approving, testing and deploying the agents. Finally, agents may not be available for the range of target platforms that your organization uses. We use standard techniques that have individually been authorized and deployed.
If you have any other questions about Tideway Foundation, please contact Tideway Support.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.