How You Diagnose Connectivity Problems

Often, the most difficult task in problem solving is determining the origin of the problem. Sometimes the circumstances of the problem point to a particular cause. For example, if only one user on a node is experiencing an Ingres Net connection problem, that user's vnode entries are probably incorrect. Some problems, however, leave more ambiguous clues.

To determine the origin of a problem, follow these steps:

Examine the Ingres error file, errlog.log. Ingres logs DBMS error messages, Ingres Net error messages, and Communications Server startup and shutdown messages to this log.
The default location for the errlog.log file is:

Windows: %II_SYSTEM%\ingres\files\errlog.log

UNIX: $II_SYSTEM/ingres/files/errlog.log

VMS: II_SYSTEM:[INGRES.FILES]ERRLOG.LOG

Often the error message provides sufficient information to determine the origin of the problem.
Examine any of the optional logs or tracing facilities, if set up in your installation.
Perform the General Ingres Net Installation Check described next if examining the error messages does not pinpoint the origin of the problem.

If you are having password or other security or permission problems with Ingres Net, use the procedure in Security and Permission Errors (UNIX) to resolve them.

General Net Installation Check

The Ingres Net installation check is a diagnostic procedure that checks your installation to determine the following:

Whether the problem is Ingres Net-related
Whether the iigcn and iigcc processes are running
Whether the network protocol software is working

How You Check Net Installation on Windows

If you are experiencing a problem and cannot determine its source, use this diagnostic procedure as a starting point:

Verify that your network protocol is functioning.
1. Use the ping command to connect between machines to verify that basic TCP/IP networking is working.
2. On both the client and the server, verify that TCP/IP is properly installed and configured. Do this by attempting to connect to the default localhost (or loopback) listen address from each machine. Type one of the following commands to loop back to your own machine using the network:
  - ping localhost
  - ping 127.0.0.1
  - ping ::1 (if TCP/IP version 6 enabled)
    If either "a" or "b" fails, the problem is with the underlying network. Contact your network administrator.
If the remote node is a UNIX machine, verify that you can connect to the target database on the remote node when you are logged in directly to the remote node.
1. Use telnet to log in to the remote node from your local node.
2. Enter a command that connects you to the database. For example:
  sql database_name
  
  If you cannot connect to the database even when logged in directly to the remote node, the problem is something other than Ingres Net.
  
  If you can connect this way, but cannot connect when you are Using Net to log into the remote node and connect (through the syntax sql vnode_name::database_name), it is an Ingres Net problem. Proceed with Step 3.
Check that the iigcc process is registered with the Name Server:
1. Enter iinamu at the operating system prompt.
2. Type show comsvr.
  If you receive no output from the show comsvr command, this means that no Communications Server is registered with the Name Server.
Check that configuration parameters such as local_vnode and the Communications Server listen address are correctly set. These parameters can be viewed and, if necessary, changed using the Configuration Manager (vcbf) or Configuration-By-Forms (cbf) utility.
Check the II_GCNxx_PORT environment variable where xx is the installation ID. It must be visible only when using the ingprenv utility. It must never be visible when using the UNIX commands env or printenv. II_GCNxx_PORT must not be part of your local operating system environment. If it is set in the local environment, it overrides their proper settings in the Ingres symbol table.

You must be the installation owner (who by default has Ingres user privileges) to take corrective action.

How You Check Net Installation on Linux and UNIX

If you are experiencing a problem and cannot determine its source, use this diagnostic procedure as a starting point:

Verify that your network protocol is functioning.
1. Use the rlogin and/or telnet commands to connect between machines to verify that basic TCP/IP networking is working.
2. On both the client and the server, verify that TCP/IP is properly installed and configured. Do this by attempting to connect to the default localhost (or loopback) listen address from each machine. Type one of the following commands to loop back to your own machine using the network:
  - telnet localhost
  - telnet 127.0.0.1
  - ping ::1 (if TCP/IP version 6 enabled)
    The login messages that follow the command reveal whether you are connected to your own machine (the name of the machine can be embedded in the messages). If they do not, you can log in and issue the hostname command to display the name of the machine to which you are connected.
    
    If either "a" or "b" fails, the problem is with the underlying network. Contact your network administrator.
Verify that you can connect to the target database on the remote node when you are logged in directly to the remote node.
1. Use telnet, rlogin, or your site's network server bridge software to log in to the remote node from your local node.
2. Enter a command that connects you to the database. For example:
  $ sql database_name
  
  If you cannot connect to the database even when logged in directly to the remote node, the problem is something other than Ingres Net.
  
  If you can connect this way, but cannot connect when you are Using Net to log into the remote node and connect (through the syntax sql vnode_name::database_name), it is an Ingres Net problem. Proceed with Step 3.
To verify that the Communications Server (iigcc) and Name Server (iigcn) processes are running on your local node, use the ps command. This command shows the status of all currently running processes. Also check the processes on the remote node.
Check that the iigcc process is registered with the Name Server:
1. Enter iinamu at the operating system prompt.
2. Type show comsvr.
  If you receive no output from the show comsvr command, this means that no Communications Server is registered with the Name Server.
Check that configuration parameters such as local_vnode and the Communications Server listen address are correctly set. These parameters can be viewed and, if necessary, changed using the Configuration Manager (vcbf) or Configuration-By-Forms (cbf) utility.
Check the II_GCNxx_PORT environment variable where xx is the installation ID. It must only be visible using the ingprenv utility. It must never be visible using the UNIX commands env or printenv. II_GCNxx_PORT must not be part of your local UNIX shell environment. If it is set in the local environment, it overrides their proper settings in the Ingres symbol table.
You must be the installation owner (who by default has Ingres user privileges) to take corrective action.

How You Check Installation on VMS

If you are experiencing a problem and cannot determine its source, use this diagnostic procedure as a starting point:

Verify that your network protocol is functioning.
You must be able to connect to another node on the network. If you cannot, your network software is not working. Contact your network administrator to correct the networking problem.
Verify that you can connect to the database on the remote node when you are logged in directly to the remote node.
1. Log directly into the remote node.
2. Enter a command that connects you to the database. For example:
  $ sql database_name
  
  If you cannot connect when logged in directly to the remote node, the problem is something other than Ingres Net.
  
  If you can connect this way, but cannot connect when you are Using Net to log into the remote node and make the connection (through the syntax sql vnode_name::database_name for example), it is an Ingres Net problem. Proceed with Step 3.
To verify that the iigcc and iigcn processes are running properly on your local node:
Check the error log (errlog.log) for any error messages indicating a startup failure on the part of either iigcc or iigcn. Check the iigcc process on the remote node also.

Alternatively, at the operating system prompt, type show system.

This command displays a list of the processes currently active. Check for the following processes:

II_GCC
II_GCN
II_DBMS
II_IUSV (dmfrcp)
DMFACP
Check that the iigcc process is registered with the Name Server:
1. Enter iinamu at the operating system prompt.
2. Type show comsvr.
  If you receive no output from the show comsvr command, this means that there is no Communications Server registered with the Name Server.
Check that configuration parameters such as local_vnode and the Communications Server listen address are correctly set. These parameters can be viewed and, if necessary, changed using the Configuration Manager (vcbf) or Configuration-By-Forms (cbf) utility.

Connection Errors

Connection errors can occur for a variety of reasons. For example, a failure in any of the internal connections described in How Connection Between the Application and DBMS Server Is Established results in a connection error.

How connection errors are reported depends on where the failure occurs. If failure occurs:

At the local instance, errors are reported directly to the user interface program or the application.
Between the local and remote instances, for example, when attempting to connect from the local Communications Server to the remote Communications Server, errors go to the local errlog.log file as well as to the application.
At the server installation, errors are reported to both the local and remote errlog.log file and to the application.

Local Connection Errors

Each Communications Server has a GCA and GCC listen address. The GCA listen address is the server's connection to local processes and is known only to the local Name Server (iigcn). The GCC listen address is the server's connection to the network and is known to all nodes in the network. These listen addresses are stored separately.

The GCA address is stored at runtime in an IICOMSVR file in the Name Server database. You can obtain this address using the iinamu utility. Do not attempt to view these files directly. For more information about iinamu, see the Command Reference Guide.

The GCC address is stored in the config.dat file when the installation is configured. To view or change the GCC address, use the Net Server Protocol Configuration screen in the Configuration-By-Forms (cbf) utility, or the Net Server Protocols page in Configuration Manager (vcbf).

When the Communications Server starts up, it must be able to obtain the use of the network (GCC) listen address. If the Communications Server cannot use this listen address because the operating system has allocated the address to another process, the Communications Server cannot listen on that protocol. This problem can occasionally arise if the installation is not started from the machine boot file.

How You Resolve Remote Connection Errors

When you cannot establish a remote connection, use this procedure to diagnose the problem:

Check the errlog.log for error messages.
If that does not identify the problem, follow the procedure for your protocol in the General Net Installation Check section of this chapter. This procedure tells you if your network and protocol are working properly and if the Name Server (iigcn) and Communications Server (iigcc) processes are working properly.
If the problem remains unidentified after you have looked at the error messages and performed the installation check, use the following procedure to verify that your netutil connection data entry contains the correct listen address.
1. From the local instance, check the connection data for the remote instance. Note the listen address specified in the netutil Connection Data table.
2. From the remote instance, check to see which GCC listen address the remote instance's Communications Server is using. You can find this information in the Net Server Protocol Configuration screen in the Configuration-By-Forms (cbf) utility, or the Net Server Protocols page in Configuration Manager (vcbf).
3. If the listen address found Step a does not match the listen address found in Step b, correct the problem by re-registering the remote instance's GCC listen address. Do this from the local instance, using netutil to edit the incorrect entry. For procedures for adding, deleting, and changing a vnode definition, see the chapter "Establishing Communications."

How You Resolve Net Registration Problems

To resolve net registration problems, use this procedure:

Use the General Net Installation Check to verify that your installation is properly installed and working.
Check that your connection data entries and remote user authorizations are correct.
The utilities used to set up connection data and remote user authorizations (Network Utility, Visual DBA, or netutil) can test a connection, but you must explicitly choose the Test operation from a menu. If you did not test the connection after entering, adding, or editing connection data or remote user authorizations, the information can be incorrect.
Check that the required connection data and remote user authorizations for the target installation exist. If they are present, check the following:
- That all vnode names and user (account) names are spelled correctly
- That the proper network protocol has been specified
- That listen addresses and network addresses are correct
  Note: End users check their private entries. A user with the SECURITY privilege (typically a system administrator) checks another user's private entries by using the -u command flag in netutil to impersonate that user. Users can also perform this task using Network Utility and Visual DBA.
  
  Any user can check global entries, however if corrections are required, they must be made by a user with the GCA privilege NET_ADMIN (typically the system administrator).
If you are experiencing problems connecting to a distributed database, make sure that the connection data and remote user authorizations required by Ingres Star have been entered on the Star Server installation. For more information, see the Ingres Star User Guide.

Security and Permission Errors

Ingres Net encrypts the password entered in netutil and compares it with the encrypted password in "/etc/passwd" (or your machine's similar password file). If the two do not match, an error is returned.

How You Resolve Ingres Security Problems (UNIX)

If you are having password or other security/permission problems in Ingres Net, use the following procedure:

Verify that you can log in to the remote machine directly. If you cannot, you do not have the right password.
Using netutil, re-enter the remote user authorization.
If you are running NIS ("yellow pages"), the account's correct password will be in the yellow pages password file (/etc/yppasswd) rather than in /etc/passwd. Add the following string to the end of /etc/passwd file to tell Ingres Net to look in /etc/yppaswd for the encrypted password:
+::0:0:::
If you have additional security such as C2 security enabled on the target machine, you must verify that the ingvalidpw executable exists in $II_SYSTEM/ingres/bin by typing:
$ ls -l $II_SYSTEM/ingres/bin/ingvalidpw

This executable is required to make the password in the secure area readable by Ingres.

Note: Not all Ingres UNIX releases use ingvalidpw to enforce C2 security. If the ingvalidpw executable is required for your release, it will be documented in the Readme file for your platform.
If the ingvalidpw executable exists:
1. Verify that it is owned by root. If not, log in as root and issue the command:
  $ chown root ingvalidpw
2. Verify that it has the "set uid" bit set. If not, issue the command:
  $ chmod 4711 ingvalidpw
3. Verify that the Ingres variable II_SHADOW_PWD is set to the full path to the ingvalidpw executable. Type:
  $ ingprenv | grep II_SHADOW_PWD
  
  The ingprenv utility displays the II_SHADOW_PWD variable.
If the ingvalidpw executable is not installed, create it using the mkvalidpw script. For details, see Create Password Validation Program (UNIX).