A.6 Troubleshooting the Access Gateway Import

When you install the 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 sections explain 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.6.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.1 SP2 Setup Guide.

  2. In the Administration Console, click Devices > 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.6.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.6.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.

Reimporting the Linux Access Gateway Appliance

  1. Verify that 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.

    If the ping command is unsuccessful, fix the network communication problem before continuing.

  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 Console.

  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.

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

  9. Type I if you want to restore the initial values configured during the installation.

    or

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

  10. Press Enter.

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

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

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

Reimporting the Access Gateway Service

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

  2. Verify that you have a configured Identity Server.

    Reimport fails in Access Manager 3.1 SP2 if you do not have a configured Identity Server.

  3. 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.

    If the ping command is unsuccessful, fix the network communication problem before continuing.

  4. In the Administration Console, delete the Access Gateway Service.

  5. On the Access Gateway machine, change to the jcc directory.

    Linux: /opt/novell/devman/jcc

    Windows: \Program Files\Novell\devman\jcc

  6. Run the reimport script for jcc:

    Linux: ./conf/reimport_ags.sh jcc

    Windows: conf\reimport_ags.bat jcc

  7. Run the reimport script for the Access Gateway:

    Linux: ./conf/reimport_ags.sh agm

    Windows: conf\reimport_ags.bat agm <admin>

    Replace <admin> with the name of your administrator for the Administration Console.

  8. 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.6.3 Fixing Potential Configuration Errors on the Access Gateway Appliance

Auto-import fails when the hostname is not configured properly or is not resolvable. To fix these potential problems, see the following sections:

Hostname Is Not Configured Properly

If you have not configured the hostname properly, the following error messages are displayed:

  • Hostname is not set. Please set the hostname in nash and run /chroot/lag/opt/novell/bin/lagconfigure.sh to trigger the configuration steps again.

  • Default Hostname set. Please set the hostname in nash and run /chroot/lag/opt/novell/bin/lagconfigure.sh to trigger the configuration steps again.

To resolve the problem, manually configure the hostname. See Section A.3.6, Manually Configuring the Hostname, Domain Name, and DNS Server.

Hostname Is Not Resolvable

When hostname is not resolvable, the following error message is displayed:

Hostname cannot be resolved. Please set host entry in nash and run /chroot/lag/opt/novell/bin/lagconfigure.sh to trigger the configuration steps again.

To resolve the problem, manually configure the hostname. See Section A.3.6, Manually Configuring the Hostname, Domain Name, and DNS Server.

A.6.4 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 and the CLI-updated settings.

  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 Embedded Service Provider (ESP) of the Access Gateway 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 Administration Console.

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:

    Linux: /opt/novell/devman/share/logs/app_sc.0.log

    Windows Server 2003: \Program Files\Novell\log\app_sc.0.log

    Windows Server 2008: \Program Files (x86)\Novell\log\app_sc.0.log

  • Tomcat Log on the Administration Console:

    Linux: /var/opt/novell/tomcat5/logs/catalina.out

    Windows Server 2003: \Program Files\Novell\Tomcat\logs\stdout.log

    Windows Server 2008: \Program Files (x86)\Novell\Tomcat\logs\stdout.log

  • JCC log on the Access Gateway:

    Linux Appliance or Service: /opt/novell/devman/jcc/logs/

    Windows Service: \Program Files\Novell\devman\jcc\logs

Determining Where the Error Occurred on the Access Gateway Appliance

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:

    1. Log in as root.

    2. Start nash.

    3. Enter the following command:

      show deviceManager

    4. Verify that the bind-address field is set to a bound address on the server.

    5. 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:

    1. Verify that the /var/novell/cfgdb/.current/config.xml file contains the correct information set from the CLI.

    2. 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, 2010 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, 2010 3:19:34 PM com.novell.jcc.server.ClientRegistry
   register
INFO: registering ag-AEF62A32 in client registry
Jan 30, 2010 3:19:34 PM com.novell.jcc.server.JCCServerImpl
   processRegisterAlerts
INFO: Sending new device alert to Device Manager for ag-AEF62A32
Jan 30, 2010 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.6.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, 2010 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   handleRequest
INFO: This is a request from Device Manager.
Jan 30, 2010 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, 2010 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, 2010 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, 2010 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: Response code: 200 OK
Jan 30, 2010 3:21:34 PM com.novell.jcc.handler.ProxyHandler
   proxyHttpURLConnection
INFO: response body size: 5958 bytes
Jan 30, 2010 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, 2010 1:54:46 PM com.novell.jcc.client.JCCClientImpl <init>
INFO: Starting client esp-AEF62A32 of type idp
Jan 30, 2010 1:54:46 PM com.novell.jcc.sockets.CipherSocketUtils
   getKey
INFO: loading the secret key from /jcc/conf/jcc.keystore
Jan 30, 2010 1:54:47 PM com.novell.jcc.client.JCCClientImpl$
   ServerConnectionThread run
INFO: server connection thread started
Jan 30, 2010 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, 2010 3:19:37 PM com.novell.jcc.server.ClientRegistry
   register
INFO: registering idp-esp-AEF62A32 in client registry
Jan 30, 2010 3:19:37 PM com.novell.jcc.server.JCCServerImpl
   processRegisterAlerts
INFO: Sending new device alert to Device Manager for 
   idp-esp-AEF62A32
Jan 30, 2010 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, 2010 3:21:34 PM com.novell.jcc.client.AlertDispatcher
   $AlertQueueThread sendAlert
INFO: alert sent successfully
Jan 30, 2010 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, 2010 3:21:34 PM com.novell.jcc.servlet.DispatchServlet
   dispatchHandler
INFO: looking up handler: Config
Jan 30, 2010 3:21:34 PM com.novell.jcc.handler.HandlerUtils
   verifyCredentials
INFO: login successful
Jan 30, 2010 3:21:34 PM com.novell.jcc.handler.ConfigHandler
   handleRequest
INFO: <romaIDPConfiguration/>
Jan 30, 2010 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 2010(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 2010(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 2010(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 2010(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 2010(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 2010(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 2010(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 2010(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 2010(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