26.4 Troubleshooting the Access Gateway

26.4.1 Useful Troubleshooting Files

The 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 26-1 illustrates these modules and the communication paths that the Access Gateway Service has with other devices.

Figure 26-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 the 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 the 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 the 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 the Administration Console. It handles health, statistics, configuration updates, and purge cache requests from the 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 the 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 the Gateway Service

The Proxy Service module of the 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 17.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 the 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 26.4.4, Enabling Debug Mode and Core Dumps.

The Access Gateway Service Log Files

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

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

26.4.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 the Access Gateway and the browser or between the 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).

The 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 the Access Gateway.

26.4.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 the 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 the 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 the 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 the 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 the Access Gateway configuration as follows:

      CoreDumpDirectory /tmp/apache2-gdb-dump

    5. Apply changes to the 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

26.4.5 Useful Troubleshooting Tools for the Access Gateway Service

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

Table 26-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 the Administration Console to push the current configuration to the Access Gateway. Click Auditing > Troubleshooting. In the Current Access Gateway Configuration section, select an Access Gateway, then click Re-push Current Configuration.

Health icon

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

26.4.6 Solving Apache Restart Issues

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

Figure 26-2 Sending Configuration Updates to the Access Gateway

JCC sends the configuration changes to the 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 the Administration Console to manually remove the modifications that have caused the problem. If this does not solve the problem, try the following:

Removing Any 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 the 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 the Administration Console, click Devices > Access Gateways > Health.

    The page displays a summary of the problem from the Apache error log file. For the 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 the Access Gateway.

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

    /var/log/novell-apache2

  4. View the contents of the rcnovell-apache2.out file too.

  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. The 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 the Administration Console, fix the configuration problems, then update the Access Gateway.

The ActiveMQ Module Fails to Start

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

Figure 26-3 Real-Time Communication

When the ActiveMQ module fails to start, you cannot apply any configuration changes, and the 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.

26.4.7 Understanding the Authentication Process of the 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 doesn’t have a session cookie because the resource is on a different cookie domain.

  • A session no longer exists or doesn’t exist on the proxy servicing the request.

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

Figure 26-4 Identifying the Requester

These first steps determine whether the Access Gateway knows the user that has submitted the request. In decision point 1, the 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. The Access Gateway continues processing with the tasks outlined in Figure 26-5.

When the request contains a session cookie, the 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. The Access Gateway continues with the tasks outlined in Figure 26-5.

  • If the session cookie doesn’t match one of the locally known users, the 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.

The 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. The Access Gateway continues with tasks outlined in Figure 26-5.

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

Figure 26-5 Determining the Type of Request

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

If the request is a cookie broker reply, the 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 isn’t a cookie broker reply, the Access Gateway examines the request to see if it is a cookie broker request. If it is a cookie broker request, the Access Gateway determines whether the user is authenticated with the contract required by the protected resource.

  • If the user is authenticated, the 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 the Identity Server to authenticate the user. The 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), the Access Gateway returns an HTTP 403 error to the user.

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

Figure 26-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, the 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, the Access Gateway is finished with its authentication checks and continues with policy evaluation.

  • If the protected resource has been assigned a contract, the 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, the Access Gateway is finished with its authentication checks and continues with policy evaluation.

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

Before the user is prompted for credentials, the 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, the Access Gateway continues with the tasks outlined in Figure 26-7.

  • If the resource has been configured for non-redirected login, the 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, the 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, the Access Gateway continues with the tasks outlined in Figure 26-7.

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

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

  • If the authentication credentials are valid, the 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 26-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 the 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, the Access Gateway redirects the request to the Embedded Service Provider (ESP). The ESP interacts with the 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, the Access Gateway generates a cookie broker request. This new request flows to the task in decision point 5.

26.4.8 Enabling Caching of Audit Events for Apache Gateway Service

Access Gateway sends audit events to the Audit Server through Platform Agent. You can enable the caching of events on Platform Agent. If the Audit Server goes down, Platform Agent will cache all audit events triggered during that period and send these to Audit Server when the Audit Server is up. Enabling caching prevents any loss of event data.

  1. Open the log4j.xml.base file.

    /etc/opt/novell/amlogging/config/log4j.xml.base

  2. Look for Audit Server entry. By default the EnableCaching value is set to false. The xml entry for Audit server looks as below:

    <appender name="AMAuditNSureAuditAppender"
    class="com.novell.nacm.logging.audit.AMNSureAuditAppender">
            <param name="AppendMode" value="DIRECT"/>
            <param name="ErrorHandling" value="DISCARD"/>
            <param name="CertificatePath"
    value="/etc/opt/novell/amlogging/certs/amnacert.pem"/>
            <param name="PrivateKeyPath"
    value="/etc/opt/novell/amlogging/certs/amnapkey.pem"/>
            <param name="EnableCaching" value="false"/>
            <param name="ServerCheckInterval" value="4"/>
    
            <filter class="com.novell.nacm.logging.audit.AMNSureAuditFilter">
            </filter>
        </appender>
    
  3. Modify the EnableCaching value from false to true.

  4. In the Administration Console, click Devices > Access Gateways > Edit > Auditing. If any of the events are enabled, then disable all the events by deselecting them. Click OK twice. On the Access Gateways page, click Update.

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

26.4.10 Accessing Lotus-iNotes through the 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 2.1 Authentication in the iNotes Web Access Deployment and Administration guide.

26.4.11 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 Auditing > 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

26.4.12 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......."/>

26.4.13 Access Gateway Caching Issues

If you have caching issues with inodes, disk space, and cache corruption in the 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:

On Linux: /opt/novell/apache2/sbin

The default cache location is:

On Linux: /var/cache/novell-apache2

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

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

For more information, see Apache htcacheclean.

26.4.14 Issues while Changing Management IP Address on an Access Gateway Appliance

If the Access Gateway Appliance has two NICs, a public and a private NIC, it is unable to change the Management IP address of the Access Gateway Appliance to a new value. The 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 the 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 the 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 the Administration Console, Identity Server and other Access Gateways in cluster.

26.4.15 Issue while Adding the Access Gateway in a Cluster

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

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

To workaround this issue:

  1. Click Auditing > 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.