30.2 Troubleshooting Access Gateway

30.2.1 Useful Troubleshooting Files

Access Gateway Service consists of two main modules, a Gateway Manager module that runs on top of Tomcat and a Proxy Service module that runs on top of Apache. Figure 30-1 illustrates these modules and the communication paths that Access Gateway Service has with other devices.

Figure 30-1 Access Gateway Service Modules

Proxy Service: This component runs as an instance of Apache and is responsible for controlling access to the configured protected resources on web servers. Low-level errors are reported in the Apache logs. Some higher-level errors are also reported to the files in the amlogging/logs directory.

ESP: The Embedded Service Provider is responsible for handling all communications with Identity Server and is responsible for the communication that verifies the authentication credentials of users. Log entries for this communication process, including errors, are logged in the catalina.out file and the stdout.log file.

ActiveMQ: This module is used for real-time communication between Administration Console and the Proxy Service. Errors generated from the Gateway Manager to the ActiveMQ module are logged to the Tomcat logs. Errors generated from the Proxy Service to the ActiveMQ module are logged to the Apache error logs.

JCC: The Java Communication Controller is the interface to Administration Console. It handles health, statistics, configuration updates, and purge cache requests from Administration Console. It is also responsible for certificate management. Errors generated between the JCC module and the Gateway Manager are logged to the ags_error.log file. Errors generated between Administration Console and the JCC module are logged to the jcc-0.log.x file

Gateway Manager: This module is responsible for handling communication from JCC to the Proxy Service. It also writes the configuration commands to the Apache configuration files and the Proxy Service configuration file on disk. Errors generated while performing these tasks are logged to the ags_error.log file.

For more information about these various log files, see the following:

Apache Logging Options for Gateway Service

The Proxy Service module of Access Gateway Service is built on top of Apache as an Apache application. This module handles the browser requests for access to resources and is responsible for sending authorized requests to the Web servers. Entries for these events are logged to the Apache log files.

/var/log/novell-apache2/

For more information, see sections Ignoring Some Standard Messages and Section 21.4.1, Managing Access Gateway Logs.

Ignoring Some Standard Messages

Apache cannot detect the proper use of domain-based multi-homing with wildcard certificates, which allows multiple proxy services to share the same SSL port. If you create reverse proxy services that are configured for domain-based multi-homing with SSL, Apache considers this a possible port conflict and logs it as a warning in the error.log file.

The error messages look similar to the following:

[<time and date stamp>] [warn] Init: SSL server IP/port conflict:
dbmhnsnetid.dsm.cit.novell.com:443 (C:/Program
Files/Novell/apache/conf/vhosts.d/dbmhNS-NetID.conf:18) vs.
magwin1430external.dsm.cit.novell.com:443 (C:/Program
Files/Novell/apache/conf/vhosts.d/magMaster.conf:18)

[<time and date stamp>] [warn] Init: SSL server IP/port conflict:
magdbmheguide.dsm.cit.novell.com:443 (C:/Program
Files/Novell/apache/conf/vhosts.d/dbmhMagEguide.conf:18) vs.
magwin1430external.dsm.cit.novell.com:443 (C:/Program
Files/Novell/apache/conf/vhosts.d/magMaster.conf:18)

You can ignore these errors because Access Gateway Service knows how to handle the traffic and send the packets to the correct proxy service.

For more information about Apache log files, see “Log Files”.

Modifying the Logging Level for the Apache Logs

If the Apache error log file does not contain enough information, you can modify the log level and the types of messages written to the file.

WARNING:If you set the log level to debug, the size of the file can grow quickly, consume all available disk space, and crash the system. If you change the log level, you need to carefully monitor available disk space and the size of the error log file.

To modify what is written to the Apache error log file:

  1. Change to the Apache configuration directory.

    /etc/opt/novell/apache2/conf

  2. Open the httpd.conf file.

  3. Find the LogLevel directive and set it to one of the following:

    debug, info, notice, warn, error, crit, alert, emerg

  4. Save the file.

  5. Restart Apache:

    /etc/init.d/novell-apache2 restart OR rcnovell-apache2 restart

  6. (Optional) If you set the level to debug and the log file still does not supply enough information, see Section 30.2.4, Enabling Debug Mode and Core Dumps.

Access Gateway Service Log Files

See Section 21.5.3, Access Gateway Appliance and Access Gateway Service Logs. You can gather these log files into a single zip file:

30.2.2 Verifying That All Services Are Running

  1. Log in to the server as the root user.

  2. Verify that the ActiveMQ service is running by entering the following command:

    ps -fea | grep novell-activemq | grep -v "grep"

    Lines similar to the following are displayed:

    107      18941     1  0 Apr01 ?        03:11:11 /opt/novell/java/bin/java -Xmx512M -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Dcom.sun.management.jmxremote -Djavax.net.ssl.keyStorePassword=xxxxx -Djavax.net.ssl.trustStorePassword=xxxxx -Djavax.net.ssl.keyStore=/opt/novell/activemq/conf/broker.ks -Djavax.net.ssl.trustStore=/opt/novell/activemq/conf/broker.ts -Dactivemq.classpath=/opt/novell/activemq/conf; -Dactivemq.home=/opt/novell/activemq -Dactivemq.base=/opt/novell/activemq -jar /opt/novell/activemq/bin/run.jar start

  3. Verify that one or more Apache proxy services are running by entering the following command:

    ps -ef | grep httpd

    Lines similar to the following are displayed:

    root   2983 30290  0 12:53 pts/0  00:00:00 egrep httpd
root   3163     1  0 May12 ?      00:00:29 /opt/novell/apache2/sbin/httpd
wwwrun 3165  3163  0 May12 ?      00:01:00 /opt/novell/apache2/sbin/httpd
wwwrun 3184  3163  0 May12 ?      00:00:01 /opt/novell/apache2/sbin/httpd
wwwrun 3188  3163  0 May12 ?      00:00:01 /opt/novell/apache2/sbin/httpd

  4. Verify that the user session cache service is running by entering the following command:

    ps -ef | grep novell-agscd

    Lines similar to the following are displayed:

    root  3259 30290  0 12:56 pts/0    00:00:00 egrep novell-agscd
108   5525     1  0 May11 ?   00:00:00 /opt/novell/ag/bin/novell-agscd -d
108   5526  5525  0 May11 ?   00:00:09 /opt/novell/ag/bin/novell-agscd -d

  5. Verify that the Tomcat service is running by entering the following command:

    ps -ef | grep catalina.base

    Lines similar to the following are displayed:

    ps -eaf | grep catalina.base 
novlwww  28764     1  0 Jul05 pts/0    00:02:05 /opt/novell/java/bin/java -Dnop -server -Xmx2048m -Xms512m -Xss128k -Djava.library.path=/usr/lib64:/opt/novell/eDirectory/lib64:/opt/novell/lib64 -Dcom.novell.nam.common.util.DeploymentMode=MAGAppliance -Dsun.net.client.defaultConnectTimeout=29000 -Dsun.net.client.defaultReadTimeout=28000 -Dnids.freemem.threshold=10 -Djavax.net.ssl.sessionCacheSize=10000 -Dsun.net.http.allowRestrictedHeaders=true -Djava.awt.headless=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/var/opt/novell/tomcat7/endorsed -classpath /lib/tools.jar:/var/opt/novell/tomcat7/bin/bootstrap.jar:/var/opt/novell/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/opt/novell/nam/mag -Dcatalina.home=/var/opt/novell/tomcat7 -Djava.io.tmpdir=/opt/novell/nam/mag/temp org.apache.catalina.startup.Bootstrap -config /opt/novell/nam/mag/conf/server.xml start

  6. Verify that the JCC service is running by entering the following command:

    ps -ef | grep /opt/novell/devman/jcc/conf/run.sh

    Lines similar to the following are displayed:

    root  3777 30290  0 13:03 pts/0 00:00:00 egrep /opt/novell/devman/jcc/
                                                conf/run.sh
root  5506     1  0 May11 ?      00:00:00 /bin/bash /opt/novell/devman/jcc/
                                                conf/run.sh

    When you are familiar with the services, you can use the following command to display information about all the services:

    ps -ef | egrep "novell-activemq|novell-agscd|/opt/novell/devman/jcc/conf/run.sh|catalina.base|httpd"

  7. If one or more services are not running, use the following commands to start the services:

    /etc/init.d/novell-jcc start OR rcnovell-jcc start

    /etc/init.d/novell-apache2 start OR rcnovell-apache2 start

    /etc/init.d/novell-agcsd start

    /etc/init.d/novell-activemq start OR rcnovell-activemq start

    /etc/init.d/novell-mag start OR rcnovell-mag start

  8. If a service does not start, view the log files to determine the cause. See the following:

30.2.3 Troubleshooting SSL Connection Issues

SSL handshakes fail when there is a discrepancy between the cipher suites and cipher strengths used by the clients and the servers. If you enable SSL connections between Access Gateway and the browser or between Access Gateway and the Web servers, you need to make sure that both sides are configured to support the same cipher suites and cipher strengths. This is especially important if you enable the options to enforce 128-bit encryption (see Configuring TCP Listen Options for Clients).

Access Gateway Service relies upon Apache to perform the SSL handshake, and Apache does not log the cause of SSL handshake failures, even when the log level is set to debug. To determine whether cipher strengths are the source of your problem, disable the options to enforce 128-bit encryption (see Configuring TCP Listen Options for Clients). If users are then able to authenticate, verify the cipher strengths, which are configured for the browsers and for the Web servers, are compatible with Access Gateway.

30.2.4 Enabling Debug Mode and Core Dumps

If the log files are not generating enough information to identify the cause of a problem, you can run Access Gateway Service in debug mode. You should not be running in debug mode except when you are trying to isolate a problem because of the following side effects:

  • Debug mode causes the size of the log files to grow quickly. They can grow large enough to consume all available disk space and crash the system. When running in debug mode, you need to carefully monitor available disk space and the size of the log files.

  • Debug mode opens additional ports. Anyone who has local access to Access Gateway machine can see the information displayed in the following local URLs:

    http://127.0.0.1:8181/server-status 
http://127.0.0.1:8181/server-info

  • Debug mode causes load and response times to slow.

Debug mode enables core dumps, X-Mag headers in LAN traces, and increases log levels by enabling advanced option in Access Gateway configuration. For example LogLevel debug. This will set apache log level to debug in the error_log file.

You can generate core dumps in the following two ways:

  1. Start /etc/init.d/novell-apache2 in debug mode. When there is a crash, core file will be created as /var/cache/novell-apache2/core.

  2. Without starting novell-apache2 in debug mode, perform the following:

    1. Set ulimit -c unlimited in /etc/init.d/novell-apache2 startup script.

    2. You can create the core directory under /tmp. Choose the file path based on the availability of disk space. Give the following command to create a directory in Access Gateway component:

      # mkdir -p /tmp/apache2-gdb-dump

    3. Set permission as follows:

      # chown novlwww:www /tmp/apache2-gdb-dump

      # chmod 0777 /tmp/apache2-gdb-dump

    4. Add the following advanced option in Access Gateway configuration as follows:

      CoreDumpDirectory /tmp/apache2-gdb-dump

    5. Apply changes to Access Gateway.

Whenever there is a crash, core file will be created as/tmp/apache2-gdb-dump/core.

For some crashes, the /tmp/debug000.log file is created. For more information about the log, see TID 7011804.

This section describes the following tasks:

Starting Apache in Debug Mode

Use the following commands to start debug mode:

/etc/init.d/novell-apache2 stop OR rcnovell-apache2 stop

/etc/init.d/novell-apache2 start debug OR rcnovell-apache2 start debug

Examining the Debug Information

  1. Examine the Apache error log file or copy it so you can send it to NetIQ Technical Support:

    /var/log/novell-apache2

  2. View the information at the local URLs or copy the pages to send to NetIQ Support:

    • http://127.0.0.1:8181/server-status

      This page displays debug information about caching, SSL, workers, and proxy information.

    • http://127.0.0.1:8181/server-info

      This page displays module and configuration information.

  3. If a crash occurred, examine the core dump file or copy it so you can send it to NetIQ Technical Support.

    /var/cache/novell-apache2

Disabling Debug Mode

Use the following commands to disable debug mode:

/etc/init.d/novell-apache2 stop OR rcnovell-apache2 stop

/etc/init.d/novell-apache2 start nodebug OR rcnovell-apache2 start nodebug

30.2.5 Useful Troubleshooting Tools for Access Gateway Service

Table 30-1 describes some of the tools available in Administration Console for solving potential problems:

Table 30-1 Useful Tools

Tool

Description

Re-push Current Configuration

If you have an Access Gateway that does not seem to be using the current configuration, you can use Administration Console to push the current configuration to Access Gateway. Click Troubleshooting. In the Current Access Gateway Configuration section, select an Access Gateway, then click Re-push Current Configuration.

Health icon

In Administration Console, click the Health icon to view details about the health of Access Gateway. For more information, see Section 24.4.1, Monitoring the Health of an Access Gateway.

30.2.6 Solving Apache Restart Issues

When you make configuration changes and update Access Gateway, Administration Console uses the JCC channel to send the configuration changes to Access Gateway. Figure 30-2 illustrates this flow.

Figure 30-2 Sending Configuration Updates to Access Gateway

JCC sends the configuration changes to Access Gateway Manager (AGM), which writes the Apache configuration to disk. Apache is sent a restart command, which causes Apache to read the new configuration, then Apache validates the configuration.

  • If the configuration is valid, Apache starts.

  • If the configuration is invalid, Apache fails to start.

If Apache fails to start after a configuration change, roll back to the previous configuration. Restore a backup if you have one, or use Administration Console to manually remove the modifications that have caused the problem. If this does not solve the problem, try the following:

Removing An Advanced Configuration Settings

Apache fails to start when it discovers a syntax error in any of the advanced options.

  1. Click Devices > Edit > Advanced Options.

  2. To reset all options to their default values, delete all options from the text box.

  3. Click OK.

    When you return to the Advanced Options page, all options are set to their default values.

  4. Click [Name of Reverse Proxy] > [Name of Proxy Service] > Advanced Options.

  5. To reset all options to their default value, delete all options from the text box.

  6. Click OK.

    When you return to the Advanced Options page, all options are set to their default values.

  7. Repeat these steps for each proxy service that has advanced options configured.

  8. Update Access Gateway.

Viewing the Logged Apache Errors

Apache generates and logs errors when it fails to start. A summary is displayed on the health page.

  1. In Administration Console Dashboard, click Devices > Access Gateways > Health.

    The page displays a summary of the problem from the Apache error log file. For Access Gateway Service, information from the rcnovell-apache2.out file might also be displayed.

  2. To view the entire contents of the Apache error log file, open a terminal window to Access Gateway.

  3. Change to the following directory and open the Apache error log file.

    /var/log/novell-apache2

  4. iew the contents of the rcnovell-apache2.out file.

  5. If you still do not have enough information to solve the configuration problem, continue with Viewing the Errors as Apache Generates Them.

Viewing the Errors as Apache Generates Them

Apache allows only a few errors to be sent to log files. To view all the errors, use the following procedure to display the errors in a terminal window.

  1. Copy the config.xml file in the current directory to a temporary location. Access Gateway allows only one XML file to reside in the current directory.

    /opt/novell/nam/mag/webapps/agm/WEB-INF/config/current

  2. Copy the XML file from the pending directory to the current directory and rename it config.xml.

    The file in the pending directory has a long numeric name.

  3. Change the ownership of the file from root to novlwww:novlwww.

  4. Use one of the following commands to restart Tomcat:

    /etc/init.d/novell-mag restart OR rcnovell-mag restart

  5. Restart Apache by using the following command:

    /etc/init.d/novell-apache2 restart OR rcnovell-apache2 restart

    Apache uses the terminal window to write the errors it discovers as it tries to process the config.xml file.

  6. At Administration Console, fix the configuration problems, then update Access Gateway.

The ActiveMQ Module Fails to Start

The Active MQ module is used for real-time communication between Administration Console and Access Gateway Service. Real-time communication is needed for commands such as purging cache, gathering statistics, and updating health. Figure 30-3 illustrates this communication flow.

Figure 30-3 Real-Time Communication

When the ActiveMQ module fails to start, you cannot apply any configuration changes, and Access Gateway does not set a listener for the configured port.

To start the module, it must be able to resolve the listening IP address to a DNS name. To install an Access Gateway Service, the machine must have a DNS name and the IP address must resolve to this name.

30.2.7 Understanding the Authentication Process of Access Gateway Service

When a user requests access to a protected resource, the request can be in one of the following states:

  • No session or cookie is established, because this is the user’s first request.

  • The user’s session is a public session because only public resources have been accessed.

  • A session is established, the user is authenticated, and the requested resource is from the same cookie domain and uses the same contract.

  • A session is established, the user is authenticated, and the requested resource is from the same cookie domain but uses a different contract or the contract has expired.

  • A session is established, the user is authenticated, but the request does not’ have a session cookie because the resource is on a different cookie domain.

  • A session no longer exists or does not’ exist on the proxy servicing the request.

Access Gateway Service must handle these conditions and others as it determines whether it needs to forward a login request to the Embedded Service Provider or use the user’s existing authentication credentials. The following flow charts take you through this process:

Figure 30-4 Identifying the Requester

These first steps determine whether Access Gateway knows the user that has submitted the request. In decision point 1, Access Gateway checks for a session cookie in the request.

  • If the request contains a session cookie, the session cookie needs to be validated. Processing continues with the task in decision point 2.

  • If the request does not contain a session cookie, the user is unknown and is assigned as a public user. Access Gateway continues processing with the tasks outlined in Figure 30-5.

When the request contains a session cookie, Access Gateway checks its local user store for a user that matches the session cookie. Each Access Gateway in the cluster maintains its own list of known users.

  • If the session cookie matches one of the locally known users, the user is assigned that identity. Access Gateway continues with the tasks outlined in Figure 30-5.

  • If the session cookie does not’ match one of the locally known users, Access Gateway needs to know if one of the other Access Gateways in the cluster knows the user. Processing continues with the task in decision point 3.

Access Gateway queries the session broker to see if one of the other Access Gateways in the cluster knows this user.

  • If a match is found, the user is assigned that identity. Access Gateway continues with tasks outlined in Figure 30-5.

  • If a match is not found, the user is unknown and is assigned as a public user. Access Gateway continues with the tasks outlined in Figure 30-5.

Figure 30-5 Determining the Type of Request

Access Gateway examines the request to determine what type of request it is.

If the request is a cookie broker reply, Access Gateway strips the cookie from the URL and redirects the request to the URL. The redirect is handled as a new request, and this new request flows to the task in decision point 6, where the URL is examined.

If the request is not’ a cookie broker reply, Access Gateway examines the request to see if it is a cookie broker request. If it is a cookie broker request, Access Gateway determines whether the user is authenticated with the contract required by the protected resource.

  • If the user is authenticated, Access Gateway creates a cookie broker reply. This reply is handled as a new request, and flows to the task in decision point 4.

  • If the user is not authenticated, the request is redirected to the Embedded Service Provider (ESP). The ESP interacts with Identity Server to authenticate the user. Identity Server, the ESP, and the reverse proxy all maintain authentication information. The ESP returns a new request, which flows to the task in decision point 6, where the URL is examined.

If the URL does not match a URL of a protected resource (PR), Access Gateway returns an HTTP 403 error to the user.

If the URL in the request matches a URL of a protected resource, Access Gateway needs to examine the protection type assigned to the resource. Access Gateway continues with the tasks outlined in Figure 30-6.

Figure 30-6 Determining the Protection Type Assigned to the Resource

You configure a protected resource as a public resource when an authentication procedure/contract is not assigned to the protected resource. In decision point 7, Access Gateway checks to see if a contract has been assigned to the protected resource.

  • If the protected resource has not been assigned a contract, Access Gateway is finished with its authentication checks and continues with policy evaluation.

  • If the protected resource has been assigned a contract, Access Gateway continues with the task in decision point 8.

For a user to gain access to a resource protected by a contract, the user must have authenticated with that contract, or if the contract is configured for it, the user can authenticate with another contract as long as the contract is of a equal or higher level.

  • If the user is authenticated with the required contract, Access Gateway is finished with its authentication checks and continues with policy evaluation.

  • If the user is not authenticated with the required contract, Access Gateway continues with the task in decision point 9.

Before the user is prompted for credentials, Access Gateway needs to know whether the protected resource has been enabled for non-redirected login (NRL).

  • If the resource has not been configured for non-redirected login, Access Gateway continues with the tasks outlined in Figure 30-7.

  • If the resource has been configured for non-redirected login, Access Gateway needs to examine the request for an authentication header and determine whether the header is valid. Processing continues with the tasks outlined in decision points 9a, 9b, and 9c.

If the request does not contain an authentication header, Access Gateway needs to determine how non-redirected login has been configured. On the Authentication Procedure configuration page, you can select to enable the Redirect to Identity Server When No Authentication Header Is Provided option.

  • If this option is enabled, Access Gateway continues with the tasks outlined in Figure 30-7.

  • If this option is disabled, Access Gateway returns an HTTP 401 unauthorized message.

If the request does contain an authentication header, Access Gateway must verify that the credentials are valid.

  • If the authentication credentials are valid, Access Gateway is finished with its authentication checks and continues with evaluating the protected resource for policies.

  • If the authentication credentials are not valid, the process is the same as if the request did not contain an authentication header and continues with the task in decision point 9c.

Figure 30-7 Evaluating the Cookie Domain

If you have configured your Access Gateway to use multiple domain-based proxy services, you can configure them to share the same cookie domain (domains of development.novell.com and support.novell.com can share the cookie domain of novell.com) or configure them so that they cannot share a cookie domain (domains of a.slc.com and b.provo.com cannot share a cookie domain).

When Access Gateway reaches the task in decision point 10, it has determined that the protected resource requires a contract and that user is not authenticated with that contract.

  • If the protected resource is in the same cookie domain, Access Gateway redirects the request to the Embedded Service Provider (ESP). The ESP interacts with Identity Server to authenticate the user. The ESP returns a new request, which flows to the task in decision point 6, where the URL is examined.

  • If the protected resource is in a different cookie domain, Access Gateway generates a cookie broker request. This new request flows to the task in decision point 5.

30.2.8 Issue While Accelerating the Ajax Applications

If you are accelerating an Ajax application that cannot handle redirect and uses an authentication contract of 5 or 10 min, then increase the contract time out. Ensure that your Ajax application refreshes at an interval of 2 or 5 min. As a best practice, ensure that the Ajax application refresh interval is less than 2/3 of the contract time out.

30.2.9 Accessing Lotus-iNotes through Access Gateway Asks for Authentication

This issue in not related to Access Manager. You need to configure authentication in Lotus-iNotes.

For more information about configuring Lotus-iNotes, see section Authentication in the iNotes Web Access Deployment and Administration guide.

30.2.10 Configuration Issues

If you get pending configuration issues when you apply changes on the device, one of the reasons could be that the soft link for the certs folder does not exist.

Enter the following command to check if the soft link exists for the certs folder:

ls -ltrh /opt/novell/apache2/

The following output is displayed:

lrwxrwxrwx 1 root root   34 2012-03-09 19:43 certs -> /etc/opt/novell/apache2/conf/certs

If the soft link does not exist, perform the following steps:

  1. Enter the following command:

    ln -sf /etc/opt/novell/apache2/conf/certs opt/novell/apache2/conf/certs

  2. Click Troubleshooting > Certificates.

  3. Select the store that is reporting errors, then click Re-push certificates. You can select multiple stores at the same time.

  4. (Optional) To verify that the re-push of the certificates was successful, click Security > Command

30.2.11 Cannot Inject a Photo into HTTP Headers

You can use the jpegPhoto LDAP attribute to store your photo in JPEG format. This LDAP attribute is not injecting the image into a custom HTTP header and returns a 400 Bad Request error.

Edit the index.php file and add the following line:

<img src="data:image/jpeg;base64,/9j/4....Base64 value got from customheader......."/>

30.2.12 Access Gateway Caching Issues

If you have caching issues with inodes, disk space, and cache corruption in Access Gateway, use Apache htcacheclean tool which is used to keep the size of mod_disk_cache's storage within a certain limit. This tool can run either manually or in daemon mode. When running in daemon mode, it sleeps in the background and checks the cache directories at regular intervals for cached content to be removed.

The htcacheclean utility tool is located at:

Linux: /opt/novell/apache2/sbin

The default cache location is:

Linux: /var/cache/novell-apache2

Example: To clear 1024 MBytes of cache, run the following command:

Linux: ./htcacheclean -v -t -p/var/cache/novell-apache2 -l1024M

For more information about Apache htcacheclean tool, see htcacheclean - Clean up the disk cache.

30.2.13 Issues while Changing Management IP Address in Access Gateway Appliance

If Access Gateway Appliance has two NICs, a public and a private, it is unable to change the Management IP address of Access Gateway Appliance to a new value. Administration Console connects to the changed IP address, but also tries to connect to the old IP address. The following procedure allows you to change the IP address manually:

  1. Stop the AG service /etc/init.d/novell-mag stop

  2. Stop the JCC service by using the /etc/init.d/novell-jcc stop command.

  3. Change the IP address in /opt/novell/devman/jcc/conf/settings.properties file.

  4. Change the IP address in /opt/novell/nam/mag/webapps/agm/WEB-INF/config/current/config.xml file.

  5. Change the IP address in /etc/opt/novell/apache2/conf/listen.conf file.

  6. Using YaST, change the network IP address.

  7. In Administration Console Edir, edit and change the IP address in the following attributes:

    • For a specific Access Gateway device entry:

      1. romaAGDeviceXMLDoc of ou=ag-xxxxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      2. romaAGDeviceSAXMLDoc of ou=ag-xxxxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      3. romaAGConfigurationXMLDoc of ou=WorkingConfig, ou=ag-xxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      4. romaAGConfigurationXMLDoc of ou=CurrentConfig ou=ag-xxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

    • For the specific Access Gateway (esp)-identity server entry:

      1. romaIDPDeviceSAXMLDoc of ou=idp-esp-xxxxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      2. romaIDPDeviceXMLDoc of ou=idp-esp-xxxxxx, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

    • For other Access Gateway device entry (if they are in a cluster):

      1. romaAGConfigurationXMLDoc of ou=WorkingConfig, ou=ag-yyyy, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      2. romaAGConfigurationXMLDoc of ou=CurrentConfig, ou=ag-yyyy, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

    • For tmp folder entry:

      1. romaAGConfigurationXMLDoc of ou=CurrentConfig, ou=tmp_zzz, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

      2. romaAGConfigurationXMLDoc of ou=WorkingConfig, ou=tmp_zzz, ou=AppliancesContainer, ou=Partition, ou=PartitionsContainer, ou=VCDN_Root, ou=accessManagerContainer, o=novell

  8. Start Access Gateway service by using the /etc/init.d/novell-mag start command.

  9. Start the JCC service by using the /etc/init.d/novell-jcc start command.

  10. Restart Administration Console, Identity Server and other Access Gateways in cluster.

30.2.14 Issue While Adding Access Gateway in a Cluster

You may get the following error while adding Access Gateway in a cluster:

Unable to read keystore: /opt/novell/devman/jcc/certs/esp/4C06F0AE2EFAED18/signing.keystore

To workaround this issue:

  1. Click Troubleshooting > Certificates.

  2. Select the store that is reporting errors, then click Re-push certificates.

    You can select multiple stores at the same time.

  3. (Optional) To verify that the re-push of the certificates was successful, click Security > Command Status.