A.1 Troubleshooting the Access Gateway Import

When you install the NetWare® Access Gateway or the Linux Access Gateway, it should automatically be imported into the Administration Console you specified during installation. If the Access Gateway does not appear in the server list, you need to repair the import.

If the repair option does not correct the problem, the following section explains what should happen and how you can discover what went wrong. This information can be used to accurately report the problem to Novell® Support.

A.1.1 Repairing an Import

If the Access Gateway does not appear in the Administration Console within ten minutes of installing an Access Gateway, complete the following steps:

  1. If a firewall separates the Administration Console and the Access Gateway, make sure the correct ports are opened. See When a Firewall Separates the Administration Console from a Component in the Novell Access Manager 3.0 SP4 Setup Guide.

  2. In the Administration Console, click Access Gateways.

  3. Wait a few minutes, then click Refresh.

  4. Look for a failed import message.

    If the device starts an import but fails to finish, a message similar to the following appears at the bottom of the table:

    Server gateway-<name> is currently importing. If it has been several minutes after installation, click repair import to fix it.

  5. Click repair import.

  6. If the device still does not appear or you do not receive a repair import message, continue with Section A.1.2, Triggering an Import Retry.

  7. If triggering an import retry does not solve the problem, reinstall the device.

  8. If reinstalling the device does not correct the problem, continue with Understanding the Import Process and report the problem to Novell Support.

A.1.2 Triggering an Import Retry

If the import process failed to start (see Step 3), you can manually trigger the import process. These steps explain how to set the IP address of the Administration Console to an incorrect address and then back to the correct address, which triggers the import process. Select the procedure that matches your Access Gateway platform.

For the NetWare Access Gateway

  1. Unlock the console (see Unlocking the NetWare Access Gateway Console).

  2. Press Ctrl+Escape and select the Novell Access Gateway Console screen.

    If you are in debug mode, first enter 0 to go to the next page and then enter 4.

  3. Verify that the Access Gateway can communicate with the Administration Console. From the Novell Access Gateway Console screen, enter a ping command with the IP address of the Administration Console.

    If the ping command successfully returns, continue with the following steps. If it is unsuccessful, fix the network communication problem before continuing.

  4. From the Novell Access Gateway Console screen, enter the following two commands:

    clear devicemanager serveraddress
apply

    These commands return you to the system console screen.

  5. Press Ctrl+Escape and select the Novell Access Gateway Console screen.

  6. To set the IP address, enter the following command:

    set devicemanager serveraddress=<AC_address>

    Replace <AC_address> with the address of the Administration Console.

  7. When prompted, enter the name of the admin user.

  8. Enter the password for the admin user and verify it.

  9. To trigger the import process, enter

    Apply

    The system retries to import the device.

  10. Wait 30 seconds, then log in to the Administration Console.

  11. If these steps do not work, reinstall the device.

For the Linux Access Gateway

If the Administration Console is up and the ping command successfully returns, continue with the following steps. If it is unsuccessful, fix the network communication problem before continuing.

  1. Verify if the Administration Console is up by logging into the Administration Console from a Web browser.

  2. Verify that you can communicate with the Administration Console. From the command line of the Access Gateway machine, enter a ping command with the IP address of the Administration Console.

  3. Log in as root.

  4. Enter the following command:

    /chroot/lag/opt/novell/bin/lagconfigure.sh

  5. Specify the IP address of the Administration server.

  6. Specify the username of the Access Manager administrator.

  7. Specify the password of the Access Manager administrator.

  8. Specify the password of the Access Manager again to reconfirm.

  9. You are prompted to specify if you want to retain the current configuration or return to the initial configuration.

    1. Press I if you want to restore the initial values configured during the installation.

    2. Press C if you want to restore the current configuration of Access Gateway.

  10. Wait 30 seconds, then log in to the Administration Console.

  11. If these steps do not work, reinstall the device.

NOTE:If you are re-importing the Access Gateway, you must also do the following:

A.1.3 Troubleshooting the Import Process

If a step in the import process does not complete successfully, the device does not show up in the Access Gateway list. The sections below describe the import process, where to find the log files, and how to use them to determine where the failure occurred so you can accurately report the problem.

Understanding the Import Process

The following operations are performed during the import process:

  1. A user specifies the IP address for the Administration Console during installation.

  2. A Java process called “JCC” (Java Communication Channel) detects that the Administration Console IP address/port has changed between its own configuration in SYS:\jcc\conf\settings.properties and the CLI-updated settings in SYS:\etc\proxy\ecc.cfg on NetWare or /opt/novell/devman/jcc/conf/settings.properties and /var/novell/cfgdb/.current/config.xml on Linux.

  3. An import message is sent to Administration Console notifying it of the IP, port, and ID of the Access Gateway device.

  4. The Administration Console then connects to the Access Gateway device, asking for its configuration and version information. The Access Gateway portion of the import process is now complete.

  5. As a separate asynchronous operation, the Access Gateway embedded service provider (ESP), running in Tomcat, connects and registers itself with the JCC.

  6. When the ESP connects to the JCC, a similar import message is sent to the Administration Console notifying it to import into the system.

  7. The Administration Console connects to the JCC, asking for the ESP configuration and version information. On the Administration Console, an LDIF (Lightweight Directory Interchange Format) file containing the default configuration for the ESP is applied on the local eDirectory™ configuration store.

  8. The Administration Console then makes a link between the ESP and its configuration.

  9. If the entire process completed properly, the Access Gateway device appears in the list of Access Gateways in the UI.

Locating the Log Files

Various Access Manager components produce log files. You use the following logs on either the Administration Console or the Access Gateway.

  • Administration Console Log: /opt/novell/devman/share/logs/app_sc.0.log

  • Tomcat Log on the Administration Console: /var/opt/novell/tomcat4/logs/catalina.out

  • JCC Log on the Access Gateway: For the NetWare Access Gateway, the JCC events are logged to the SYS:\jcc\logs\jcc-0.log.0 file. They are also logged to the NetWare Logger Screen (screen #3).

    For the Linux Access Gateway, the messages are logged in the /opt/novell/devman/jcc/logs/jcc-0.log.0 file.

Determining Where the Error Occurred

If the device does not show up in the list of Access Gateways in the UI after about 30 seconds, you can look for the following entries, determine which ones are not successful, and put the unsuccessful event messages in any bugs submitted.

  1. From the Access Gateway console, verify the IP addresses.

    • On NetWare, unlock the console (see Section A.1.4, Unlocking the NetWare Access Gateway Console). Enter get devicemanager. Verify that the bindaddress field is set to a bound address on the server. Verify that the serveraddress field is set to the correct address of the Administration Console.

    • On Linux, log in as root, start nash, and enter show deviceManager. Verify that the bind-address field is set to a bound address on the server. Verify that the server-address field is set to the correct address of the Administration Console.

  2. Verify that the configuration file contains the correct information:.

    • On NetWare, verify that the SYS:\etc\proxy\ecc.cfg file contains the correct information set from the CLI. Open the SYS:\jcc\conf\settings.properties file and verify that the information matches that in ecc.cfg file:

    • On Linux, verify that the /var/novell/cfgdb/.current/config.xml file contains the correct information set from the CLI. Open the /opt/novell/devman/jcc/conf/lag-settings.properties file and verify that the information matches that in the config.xml file.

  3. In the JCC log, an entry for a successful Access Gateway import should look similar to the following:

    Jan 30, 2006 3:19:34 PM com.novell.jcc.server.JCCServerImpl
   register
INFO: Registering Proxy client "ag-AEF62A32"
   com.novell.jcc.proxy.AGProxy$AGJCCClient@19113f8
Jan 30, 2006 3:19:34 PM com.novell.jcc.server.ClientRegistry
   register
INFO: registering ag-AEF62A32 in client registry
Jan 30, 2006 3:19:34 PM com.novell.jcc.server.JCCServerImpl
   processRegisterAlerts
INFO: Sending new device alert to Device Manager for ag-AEF62A32
Jan 30, 2006 3:19:34 PM com.novell.jcc.client.AlertDispatcher
   sendAlert
INFO: alerts in send queue: 1
INFO: alert sent successfully

    Look for an error message such as sendAlert: IOException connection timed out. This means the Access Gateway device could not connect to the Admin server. The operation will retry until it is successful. To trigger a retry, see Section A.1.2, Triggering an Import Retry.

  4. In the JCC log, an entry for a successful Access Gateway configuration import should look similar to the following:

    Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   handleRequest
INFO: This is a request from Device Manager.
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: Setting request method: GET for http://127.0.0.1:101
   /Ex?Config:/appliance?Config:/appliance
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: Adding request headers:
X-Roma-Username: config.ics.ics_tree
X-Roma-Password:
X-Roma-Frequency: 0
X-Roma-Schedule-Id: 248237e8e9bc131da1bf7b23a1091ce91d43aa7c4a
X-Roma-Appliance-Id: ag-AEF62A32
Host: 10.155.164.14
X-Roma-Xml-Length: 0
Content-Length: 0
Pragma: no-cache
Cache-Control: max-age=0
X-Roma-Version: 1.0
User-Agent: Java1.3.0
Accept: text/html, text/plain, image/*, */*
Content-Type: text/plain
Connection: close
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: Connecting to http://127.0.0.1:101/Ex?Config:/appliance
   method GET
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: Response code: 200 OK
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: response body size: 5958 bytes
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: disconnecting client.

  5. In the JCC log, a log entry for a successful ESP connection to the ESP should look similar to the following:

    Jan 30, 2006 1:54:46 PM com.novell.jcc.client.JCCClientImpl <init>
INFO: Starting client esp-AEF62A32 of type idp
Jan 30, 2006 1:54:46 PM com.novell.jcc.sockets.CipherSocketUtils
   getKey
INFO: loading the secret key from /jcc/conf/jcc.keystore
Jan 30, 2006 1:54:47 PM com.novell.jcc.client.JCCClientImpl$
   ServerConnectionThread run
INFO: server connection thread started
Jan 30, 2006 1:54:47 PM com.novell.jcc.client.JCCClientImpl$
   ServerConnectionThread establishServerConnection
INFO: attempting to contact RMI server on 127.0.0.1:1197
INFO: Registering RMI client "idp-esp-AEF62A32" com.novell.jcc.
   client.JCCClientImpl$JCCRMIClient_Stub[RemoteStub [ref:
   [endpoint:[10.155.164.14:1029,com.novell.jcc.sockets.
   CipherSocketFactory@6a3960]remote),objID:[134ce4a:1091d189f37
   :-8000, 1]]]]
Jan 30, 2006 3:19:37 PM com.novell.jcc.server.ClientRegistry
   register
INFO: registering idp-esp-AEF62A32 in client registry
Jan 30, 2006 3:19:37 PM com.novell.jcc.server.JCCServerImpl
   processRegisterAlerts
INFO: Sending new device alert to Device Manager for 
   idp-esp-AEF62A32
Jan 30, 2006 3:21:34 PM com.novell.jcc.client.AlertDispatcher$
   AlertQueueThreads
endAlert
INFO: alert sent successfully

  6. In the JCC log, a successful logging of events for the ESP import should look similar to the following:

    INFO: Sending new device alert to Device Manager for 
   idp-esp-AEF62A32
Jan 30, 2006 3:21:34 PM com.novell.jcc.client.AlertDispatcher
   $AlertQueueThread sendAlert
INFO: alert sent successfully
Jan 30, 2006 3:21:34 PM com.novell.jcc.client.AlertDispatcher
   sendAlert
INFO: alerts in send queue: 2INFO: Received GET: /Ex?Config:
   /appliance from 10.155.165.108:33812
Jan 30, 2006 3:21:34 PM com.novell.jcc.servlet.DispatchServlet
   dispatchHandler
INFO: looking up handler: Config
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.HandlerUtils
   verifyCredentials
INFO: login successful
Jan 30, 2006 3:21:34 PM com.novell.jcc.handler.ConfigHandler
   handleRequest
INFO: <romaIDPConfiguration/>
Jan 30, 2006 3:21:34 PM com.novell.jcc.server.ClientRegistry
   setClientImported
INFO: setting client idp-esp-AEF62A32 as imported: true

  7. When the LDIF file is successfully imported, the app_sc.0.log file contains an entry similar to the following. The example below contains an add entry for one schema definition; the ellipsis (...) indicates that the other definitions have not been included. 

    528(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler$
   CommandThread(M)importDevice(Msg)Creating matching IDP server
   object for idp-esp-AEF62A32
529(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler$
   CommandThread(M)importDevice(Msg)Successfully created 
   cn=idp-esp-AEF62A32,cn=server,cn=nids,
   ou=accessManagerContainer,o=novell
530(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   $CommandThread(M)importDevice(Msg)
   dn: cn=SCCAEF62A32, cn=cluster, cn=nids,
   ou=accessManagerContainer,o=novell
   changetype: add
   nidsSignAuthnRequests: TRUE
   nidsIsConsumer: TRUE
   nidsSessionTimeout: 900
   nidsServerType: 3
   objectClass: nidsServerClusterConfiguration
   objectClass: Top
   nidsDisplayName: 10.155.164.14
   nidsServerConfigModified: FALSE
   nidsBaseURL: http://10.155.164.14/nidp
   nidsAssertionTimeToLive: 0
   cn: SCCAEF62A32
   nidsIsProvider: TRUE

[...]

531(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   (M)execute(Msg)Executing opt/novell/eDirectory/bin/ice
532(D)Mon Jan 30 15:21:37 MST 2006(L)System Controller(T)33
   (C)com.volera.vcdn.application.sc.core.DeviceManager
   (M)setHealthCheck(Msg)Setting the health attributes for nids 
    to: 1
533(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   (M)execute(Msg)Success, return code: 0

  8. In the app_sc.0.log file, the record of a successful linking of the LDIF configuration to the ESP looks similar to the following:

    534(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   $CommandThread(M)importDevice(Msg)S Searching for AEF62A32 in
   cn=cluster,cn=nids,ou=accessManagerContainer,o=novell
535(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43(
   C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   $CommandThread(M)importDevice(Msg)Checking configuration:
   cn=SCCAEF62A32,cn=cluster,cn=nids,
   ou=accessManagerContainer,o=novell with AEF62A32
536(D)Mon Jan 30 15:21:37 MST 2006(L)application.sc.alert(T)43
   (C)com.volera.vcdn.application.sc.alert.AlertCommandHandler
   $CommandThread(M)importDevice(Msg)Linking esp config to
   cn=SCCAEF62A32,cn=cluster,cn=nids,
   ou=accessManagerContainer,o=novell

A.1.4 Unlocking the NetWare Access Gateway Console

Before you can enter NetWare commands or view the logger screen, you must unlock the Novell Access Gateway Console.

  1. To unlock the console, enter

    unlock

  2. When prompted for a password, press Enter.

    The console is now unlocked and the active screen is the Access Gateway screen. From this screen you can enter device manager commands.

  3. To switch to the logger screen or other NetWare screens, enter 

    debug

  4. When prompted for a password, enter 

    proxydebug

  5. To switch from the device manager screen, press Ctrl+Escape and enter the screen number.