Attempts to import Linux Access Gateway into the Administration Console fail after initial import fails

After a failed import of a Linux Access Gateway (LAG) into the Administration Console, all subsequent attempts to import the same LAG with the same IP address fail.  The following message may be visible in the Administration Console:

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

However, clicking "repair" does not resolve the problem.

When the LAG imports into the Admin Console, several objects are created in the eDirectory Conguration Store on the Admin Console.  If the import process fails after any of these objects have been created, attempts to import the same LAG using the same IP address will most likely fail.  In order for the LAG to be imported, these objects must all be manually removed from the Configuration Store.

Before editing the Config Store manually, first back it up with the ambkup.sh script.

It is important that only the objects from the failed import attempt are deleted.  Deleting any other objects will potentially break Access Manager configuration or remove other working devices.  The objects to be deleted will be identified by a device ID number. To determine the device ID's of the working devices, go to the Administration Console | Access Manager | Auditing | General Logging.  The device ID numbers will be listed next to the IP addresses of each device, for example:

10.0.0.101    ag-6E46B5BE098FFC82

In this example, the device ID number is 6E46B5BE098FFC82.  Take note of all the device ID numbers of working devices.  The LAG that failed to import may or may not be listed on this page depending on how far the import process progressed before failing.

Proceed to delete the objects from the failed import attempt:

1. In an LDAP editor, connect to the eDirectory server on the Administration Console.  The LDAP connection must be secure.
   
   
2. Browse to the following object:
   
   o=novell,ou=accessManagerContainer,ou=VCDN_Root,ou=PartitionsContainer,ou=Partition,ou=AppliancesContainer
   
   
3. Find the ID of the device that didn’t import:
   a. View an object that starts with ou=ag-[id].
   b. Check for the IP address in the object’s romaAGDeviceXMLDoc attribute.
   c. When you find the object whose IP address matches the LAG that did not import, note the ID number of the object, then delete it.  This ID is used to identify the other objects associated with the device.
   
   
4. Delete the associated ESP object named ou=idp-esp-[id].
   
   
5. Browse to the following object:
   
   o=novell,ou=accessManagerContainer,cn=nids,cn=cluster
   
   
6. If it exists, delete an object named SCC[id].
   
   
7. Browse to the following object:
   
   o=novell,ou=accessManagerContainer,cn=nids,cn=server
   
   
8. Delete the cn=idp-esp-[id] object.
   
   
9. Browse to the following object:
   
   o=novell,ou=accessManagerContainer,ou=VCDN_Root,ou=PartitionsContainer,ou=Partition,ou=KeyContainer
   
   
10. Delete all the objects that contain the server’s ID.

After deleting these objects, trigger a re-import of the LAG by running the following command on the LAG:

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

The steps above will resolve the problem with the re-import of a Linux Access Gateway failing after an initial import attempt failed.  However, these steps will not resolve the issue with an initial import if, for example, the LAG install failed to complete correctly, or the LAG has connectivity problems preventing it from importing.  Consult the Novell Access Manager product documentation for tips on troubleshooting LAG import issues.